Why we are using Meteor.call why not REST Apis

#1

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?

Any Help would be greatly appreciated.

#2

Perhaps Meteor APM (Kadira) can help with the measurements.

1 Like
#3

Because

RPC-based APIs are great for actions (that is, procedures or commands).

More here: https://www.smashingmagazine.com/2016/09/understanding-rest-and-rpc-for-http-apis/

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.

4 Likes
#4

Thanks I didn’t know this is RPC Based. Also, Can we test any Meteor.method using JMeter or something?

#5

AFAIK, Kadira is not in use now. I used MontiAPM as Kadira. Is MontiAPM is same as kadira?

#6

monti is based on the open source version of kadira that MDG bought in recent years, so yes, it’s basically the same

#7

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.

2 Likes
#8

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?

4 Likes
#9

Yes you are right, But In short, as of now we don’t know how can we test it So that we know how much our system is capable of handling the requests.

#10

Yes, this is good tool but this is more on the analytics part I would need something to test the performance of our Meteor.methods.

#11

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

image

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.

Hope it helps

2 Likes
#12

None of these answers are really right.

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.

2 Likes
#13

@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.

#14

hi @doctorpangloss, Thanks! Could you also tell me how to test them like wecan test a normal api using tools like JMeter or any other?

#15

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.

#16

@doctorpangloss, Can you give any sample example for this?