But the dependency of being async goes outwards. The function becomes async if the calls inside are async and not the other way around
What do you mean?
On a higher level, I just feel like, the async pattern is the future, and it would be kind of ugly if we have to write +Async on everything forever.
However, I understand that it’s required for backwards compatibility.
What if we had a package like mongo-async-only that makes Collection.insert(), etc, async, and disable all the Fibers stuff entirely?
I’d rather go pure async… also, I think converting a code base would not be difficult?
1 Like
I just meant that the decision of using MongoDB async functions is not dependent if the calling function is async or not.
An async function now calling Collection.insert will have an issue if the expected insert is required by the succeeding code i.e. it must be awaited.
1 Like
For large codebases, a per module/sprint approach is necessary
Right but that is a fair trade off - if you’re writing async functions, do not use the Fibers related logic. It’s a good constraint?
As discussed previously, there is a need to consider existing projects (including large ones) and the need to move out of node 14 in less than 6 months. Those are the real constraints we are working with here
IMO better to do a breaking Meteor 3.0 - gotta rip the bandaid off.
MongoDB implementation is already a bit of hack and does not mirror the core API’s well… this is just piling onto that.
4 Likes
Great work with the 2.8 release. The plan above seems to be well thought out. I do have a question that doesn’t seem to be answered in the docs.
Is the plan to keep the sync versions of fetch() and alike on MiniMongo? I imagine this is necessary to keep Tracker working? I have a lot of sync client side code that would need to be fundamentally rewritten if the synced versions was removed. Backend seems pretty straight forward for us, but syntactically front end is much harder due to how angular templates works (cant iterate over Promise<Array>)
I read through the migration guide and am a bit confused about the samples provided here:
Why is it necessary to rename the server-side methods? Shouldn’t it be transparent to the client whether the method’s implementation on server-side is sync or async? AFAIK, that was possible even before 2.7.
The only reason I could think of is that you would want to call the methods directly, on server-side. But that’s a more advanced feature, if you ask me. In its current state, the migration guide is kinda misleading, or I am completely wrong about this.
I am asking because this would have a big impact on any application that uses third-party clients (in our case, a Unity app), where the client code is updated independently of the server code.
EDIT: Ok, I now think I understand why. The reason seems to be the client-side stubs. So I guess if I don’t use them for a specific method (i.e. it is only run on server-side), and I also don’t call them directly on server-side, it doesn’t matter if the method is implemented async or sync (because DDP is in between)?
3 Likes
Yes. The problem is the stubs. If you don’t need them, you’ll be fine calling the methods as you please.
If you find something out of this line, please let us know.
3 Likes
In version 3.0, all the mongo methods are going to be async. And these MongoDB methods with the Async word will be removed.
We created them now, because it’ll be easier for you to replace your current MongoDB methods just by adding an async word in from of them. In version 3.0, all you’ll need to do is perform a find-replace and remove the async word from all the MongoDB methods.
3 Likes
That sounds like a truly terrible idea since it means that there will be no way to write code against 2.9 that also works as is against 3.0. Could you at least keep the async-named methods around for a few versions after 3.0?
Also, changing the method names back but changing their signatures to be async will make all old meteor code found in forums etc be incompatible in hard-to-detect ways.
Please reconsider
I feel you, having to rename the methods sucks. On the other hand: if you keep both, people would expect that the “non-Async” ones are sync…
And regarding old Meteor code: the switch to Meteor 3 will break most existing examples (and packages, which is even worse!) anyways, if they access async data, since Fibers will be gone.
1 Like
Thanks for the clarification. I think this should be mentioned in the migration guide.
Anyways, we have to get through this, as we have to get rid of Fibers. Thanks for caring for this super-important endeavour.
3 Likes
I expressed myself poorly there, sorry!
I didn’t mean to say that we’ll immediately remove async-named methods. It will eventually happen down the road in a 3.X.X version because methods like insert and insertAsync will essentially be the same, so it wouldn’t make sense to keep both.
But even this can be discussed when the time arrives, so don’t worry.
2 Likes
Perfect - thanks for chiming in again!
/Per
Hello,
We have started of migrating and adding Async suffix on the server functions and async keywords before the function name (we are duplicating all our functions…)
But As I read your message @waldgeist I do not understand if we need to do it or not ?
Is it fine to leave Meteor.users.findOne(blabla) and all other mongo call like this on the server ?
or not and transform this into : await Meteor.users.findOneAsync(blabla) everywhere on the server ?
Our methods are only defined on the server (not on the client)
We really need to be sure because we have a very large codebase and this migration process will take us months…
Thanks for your feedbacks
This question is of interest to me as well. I’ve been using Meteor for 7 years and have a lot of code. And I’m reluctant to upgrade to 2.8 right now because I’m not sure if every server-side method needs to be “upgraded” to this async wrapper or not 
1 Like
Hi, as the migration guide states, you can update your app to this version without having to change anything.
What this version gives you is the option to do so! You can already slowly start to update your app to work with async MongoDB methods.
Remember that you’ll have to do this work eventually. So you can start now. But you don’t need to do everything at once.
3 Likes