Exactly. This is too much overhead cost which grows as the code grows and as well as the team. That’s why we choose to do one thing for everything.
2 Likes
I don’t buy this as a reason but as an excuse. Not sure if anybody here really avoid parallel calls for server performance
1 Like
I think this whole thing is an artefact of Meteor’s creation in a time when there wasn’t a “normal” and the Meteor team bet big on Fibers and being able to write sync style code everywhere for async operations.
The only way to have simple sync execution on the client was to force those calls to be executed in a queue,
Now, I agree that going all-in on Fibers was a mistake. No other framework chose to follow the same pattern, and then the major async pain points started getting solved by language features like Promises, Generators and async/await.
But before these existed, I can understand why MDG made the choice they did.
Personally, I am fairly agnostic to the approach, but our impementation makes many inter-related db calls, and users can often make many changes to the same collection over a few seconds.
For this reason we’ve kept the blocking behaviour by avoiding async/await and promises in methods. Otherwise we would probably have issues with order of operations and inconsistent final state.
We also extensively take advantage of Meteor’s optimistic UI, so even when the server is busy processing all the instructions, the client doesn’t notice because it’s already updated for them.
3 Likes
Good points. this.unblock() and sync methods are very useful for “real-time apps” without handling state manually in the client
Our use case for running this.unblock() in publications is simply to allow a web page to finish loading a bit faster. In our Meteor apps, the client subscribes to multiple publications and we want to avoid an unnecessary delay on the server side.
1 Like
@vlasky does your PR for using this.unblock() in publications for 2.3 prevent the issue experienced by @waldgeist ?
@rjdavid I expect it to experience the same issue. I quote from my previous reply earlier in the thread.
1 Like
I have just done some testing and investigating. I confirm that Meteor.publish() does NOT currently support having an async function as the second argument. Only Meteor method handlers can currently be declared as async.
Promise resolution code would need to be added to function _publishHandlerResult() in livedata_server.js in the ddp-server core package, and possibly some new code in other places as well.
2 Likes
I was on a roll this evening, so I implemented the required code in core package ddp-server to allow an async function to be passed to Meteor.publish(). My initial testing suggests that this achieves the same performance benefits as running this.unblock() at the start of a non-async publish function.
My pull request can be found here:
8 Likes