For write methods (insert, update, upsert) we have the option to include a callback parameter, the presence of which will make the call asynchronous. However, when reading data using findOne and fetch, the callback option is noticeably absent.
In the case of findOne, the Node.JS MongoDB driver supports a callback option, so I’ve been able to get around this limitation by using the rawCollection and wrapping the callback in Meteor.bindEnvornment.
It should be pretty simple for Meteor to include the callback option for findOne at least. Was this intentionally omitted for a good reason?
I’m genuinely curious as to why you want to use callbacks. Using rawCollection() to access the underlying npm package methods means you can use the non-callback form of those. Doing that returns a promise, which in turn means you can use async/await, which is a much cleaner and more intuitive approach than callbacks.
Good point. I wasn’t aware that node’s mongodb API methods return promises when no callback is provided.
I still wonder why Meteor decided to exclude the callback option for their API’s collection read methods, though, and whether this was just arbitrary or intentional.
I believe it was intentional, as Meteor went to great lengths to hide away any asynchronous work and greatly simplify development.
With collection read methods, Meteor hides the async nature of the query using Fibers. This is also what lets you run write queries and other async methods on the server in a synchronous fashion (including HTTP requests, without blocking!). This was all designed long before promises and async/await
On the client side, because the database is in-memory, queries can be synchronously performed and so the callbacks aren’t needed there either