Functions versus methods?

can someone explain the difference between these two?

notificationInsert = function(noteAttributes) {

Meteor.methods({
notificationInsert: function (noteAttributes) {

does it matter if wrappered in Meteor.Server? Impact on reactivity? In terms of being called with a callback?

A Meteor method is a server function that can be called from the client (Remote Procedure Call). See the Meteor documentation for more.

1 Like

Let’s say you’ve got 1 and 2 both on client and server. And you’ve got function 3 on client. Your 3 can call 1 only on client, but 2 both on client and server. So 1 when called from 3 will have access only to minimongo, but 2 will also have access to your server database and all server functions.

thanks brajt.

Following ups.

  • would there be a use case for writing a client side Method? Would one ALWAYS use functions for client side? and methods for server?
  • and in you clarification of server / client, you highlight probably the real issue - around what can be reactive or not. I’m guessing w/ the Method (aka server), if you want that to be reactive, that’s where you start down the path of 'callback hell"?

Methods by default are both server and client side. This way when you try to call server part of the method, what of course takes time, the client part (which is called a stub) automatically updates without waiting for server response. This feature is called latency compensation and thanks to that, your user can see the result in an instant, as if he run the server on his own computer. Then, if the server response turns out to be different than the stub, the client data gets replaced by server data in the background.

Of course you can restrict them to be only server side if you don’t want the stub. You can also differ the stub and server method by using isServer etc. As for your question - no, there is no use case that I can think of which would require creating client-only method. It’s possible, but why make things overcomplicated if you can simply use a function?

No, there is no callback hell with server methods. Why would there be? You can make it a callback hell, by following the path of bad design. But good devs don’t go this way. You can also use promises if you really need to chain your methods.

Google “meteor stub” for more.

As an update to anyone else wrestling with this… best answer (for me) so far:

Any time you want to call server from client - use a method.

functions can be used for server 2 server or client 2 client, but don’t cross the streams. Largely this is about security and locking down what can be seen on the client side.

Hey you might be interested in checking it the rough draft of the Meteor guide on methods: http://guide.meteor.com/methods.html

It explains stuff in excruciating detail if you want to know how everything works.

And u get kadira tracking method call duration and stuff even on production.
Is there any other way how to track non-method functions on production without debugger.
Something what can be let ON during production and does not need to call log on start and end of every function we want to track ?

Whoops, no they aren’t. If you are’t using packages this really depends on where you place the file.

[quote=“fvg, post:9, topic:13049”]
Whoops, no they aren’t. If you are’t using packages this really depends on where you place the file.
[/quote]In packages you also have to define to explicitly just to make your answer complete.

By being both server and client side I mean simply that you can use them both on the client and server, like it is specified in Meteor documentation and like I explain in a use case in the same paragraph from which you cut off this sentence.

A case when user places methods in his /server or /client folder is not a default state. Default state is how things works outside of any folders (like you can see in official Meteor tutorial). And methods work perfectly fine out of the box both on client and server.

So yes, by default methods are both client and server side.

I believe we both have more important things to do than argue about such a trivial thing.