Why not use sync style code everywhere in stead of callbacks and promises? (limitations? good practices?)


#1

hi,

if you use Synchronous code on the server, will it not block all other users? or what is the effect of this? What I see now is that it makes life so easy without all the callbacks. In my case I have to do something (create an app) via REST API on a remote server, for all the customers of my company. So I create a loop

For each user
create app
next user (if the previous one is really finished otherwise I flood my remote API server)

thanks


#2

Found this by accident

On the server, this function can be run either synchronously or asynchronously. If the callback is omitted, it runs synchronously and the results are returned once the request completes successfully. If the request was not successful, an error is thrown. This is useful when making server-to-server HTTP API calls from within Meteor methods, as the method can succeed or fail based on the results of the synchronous HTTP call. In this case, consider using this.unblock() to allow other methods on the same connection to run in the mean time. On the client, this function must be used asynchronously by passing a callback.

So the event loop is only for the current user? Other users are not blocked?


#3

When it talks about running a function “synchronously” on the server, it really means that the function call is “synchronous style”. The function is still run async using the fibers library that Meteor depends on. You write the function call like it is sync, but it really runs async, freeing up the event loop (and server thread), until the result comes back.

Of course actual sync tasks, like calling _.filter(bigList, someFunction) will still run sync and block the event loop (and thread).


#4

Ah, that is so cool!!! And therefore we dont need promises or callbacks on the server? Like you say: under the hood if I make a http call, it uses async fibers…

So in a good meteor app you won’t see this in the server side? Only from client to server we need promise or callbacks? But since the client should be thin I can imagine that you do most things on the server… Mmm, while writing this… I know that also on the client you can do sync to the server, so that DOES cause blocking then?

When or when not should I use this? Ps I read a lot of threads but this remains unclear, I see all people making callback code. So why do that if it can be sync style with meteor?

Also see


#5

mmm, so maybe you can only use a sync method call from client event to meteor method if you don’t expect a return value?

All examples I see use this style

 Meteor.call('copyApp', this.qDocId, (error, result) => {
                        if (error) {
                            sAlert.error(error);
                            console.log(error);
                        } else {
                            console.log('app removed');
                            sAlert.success("QVF '" + currentApp.qDocName + " copied in the QMC");
                            updateSenseInfo();

                        }

this is soo cool: