Hello, guys!
Meteor 2.8.0 is out on our way to a MeteorJS Fibers-free. 
For all the details, check out our blog post!
Engage with us on Twitter
Don’t forget to retweet and like!
24 Likes
Way to go Meteor Team! Thanks for your continued dedication!
3 Likes
@grubba and the rest of the team that are working on making Meteor fibers-free, thanks and congrats.
I still have some questions about the migration guide and the blog post that can result to confusion.
From the migration guide:
As said before, the
callAsyncshould be used to call async methods.
From the blog post:
Now
Meteor.call()should be called for methods that run sync stubs. For methods that run async stubs, you should useMeteor.callAsync().
For clarifications:
-
If I have an async server method but a sync client stub, which one should I use?
-
What if vice-versa?
2 Likes
Hmm… is there any way to have like:
Collection.insertSync
Collection.insertAsync
and then have Collection.insert detect if its being called inside an async function?
1 Like
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