Why we are using Meteor.call why not REST Apis, Also we can not test how efficiently Meteor methods works. I don’t know any tool with which I can test this?
Why we are not using the basic REST APIs where we could also measure the performance and check how much is the system capable of handling the request.
As per my opinion, One should use Meteor for subscription and publication part which also makes it different, but there is no way to test that either. Is there a way we can test the publications performance So that we have the idea how much is our system is capable of handling the concurrent users?
A RPC API, such as the Meteor methods, allows you to bake in some amazing interaction capabilities for your front-end user. But if a Rest API is all you need, and not much else, then maybe Express is a better option. On the other hand, if you want to stick with Meteor for other of its many capabilities, a REST-ful API is very easy to build, like this one, using the official webapp package.
Last time I checked, JMeter had support for WebSockets. Here’s an article on how one can run a load test properly for a Meteor app.
I don’t know where you hosted your app, but if you use Galaxy you can use the https://github.com/meteor/meteor-apm-agent package to get access to Meteor APM. Which gives you a lot of information about all your methods, and pub/sub.
I use it because it’s super easy. I don’t have to configure anything, or worry about translating data - or think about the transport layer at all. I love not having to make those decisions. Every decision I don’t have to make about that low level stuff means I can make better decisions about my specific problem domain.
I also like having the option in my apps to have real-time data if I should need it. Since I’m using Meteor, and it’s got all that plumbing already set up, why not just use methods?
Inside APM you can see all the methods and Subscriptions your app is using, and also their performance. And then start to analyze why they are slow or what’s going on. An example is here
Where you can see what’s going on during each method, for example, this is a method that I just optimized so, for example, it didn’t run the getRecentLocation twice and also I fixed the speed to under 100 ms after I saw how slow it was.
You use methods so that Meteor, as a framework, can understand the side effects of what the methods do. It lets server code run on the client. For many problem domains, that means zero-latency applications. REST alone doesn’t really do that.
@doctorpangloss has right, this is the best thing about Meteor.methods vs REST.
For the OP’s benefit, this is called “optimisic UI” and many of my users think it’s magical how quickly my website/app responds! Read more at the official docs and Meteor blog.
Your best bet is to wrap the contents of a method in a function, and test it like you were a backend engineer. Declare the collections the function uses with the local collection syntax. That’s sort of it. The appeal is in the simplicity of it all.
