Node-fiber NOTE OF OBSOLESCENCE

core
28

i wouldn’t start a meteor 2.0 branch. With typical semantic versioning, you would increase this number on a breaking change and its not the time for a breaking change.

i would only maintain fiber if and when it won’t work for any future node version.

instead someone should go to the whiteboard and sketch out how a fiber less pub/sub could work (giving up isomorphic code? working with promise in a smart way?) and provide a new api that does not rely on fiber without removing the old way of doing things, but try to deprecated it (and warn).

Personally i have only one bigger project that uses pub/sub anymore and tend to migrate to graphql in that project (if i need to migrate at all). I would advice to at least consider switching to another (existing) datalayer as an option.

2 Likes
29

Hence why I started a DDP library. Its client only at first, but maybe I should aim to build a server version as well. A bit like how the Apollo Server and Apollo Client work together

1 Like
31

I believe when most of us mention MDG we mean whoever currently responsible for codebase and its open source roadmap. While it’s community-powered and open for contributions, it isn’t open for merging by contributors.

1 Like
32

Oh, for sure. I said that in case you meant you were contacting the actual previous owner of Meteor (they are still MDG, afaik). I see the new owner, Tiny, mentioned all the time since the acquisition.

I genuinely thought you didn’t know. :slight_smile:

1 Like
33

:ok_hand: just want to make sure we are on the same page, and we are :slight_smile:

1 Like
34

Just bumped into this presentation: Why Fibers Make Sense For Meteor

Screenshot from 2020-08-17 00-51-53
Screenshot from 2020-08-17 00-51-531368×757 81.1 KB

4 Likes
35

Hey @dr.dimitru we respond to all applications, maybe you are sending to an old email? Not sure.

Always remember, MDG is not the owner of Meteor anymore, Meteor Software (part of Tiny capital) is.

You can send messages to us at hello@meteor.com :slight_smile:

1 Like
36

Using Fibers makes some server side async code match the synchronous client side code style, but if we were starting today, I’d rather make both server and client use async/await instead. Then it’s isomorphic without Fibers.

My 2 cents would be to start to work toward removing, or at least reducing the prevalence of Fibers on a package by package basis. This can be done in a way which would preserve backward compatibility for as long as possible, by maintaining the existing Fibers branches of various packages, and doing a major version bump (or even forking and creating new names for packages) for packages that would migrate off Fibers. Of course, Fibers would have to be removed from core. There is a large body of packages that use Fibers (or more specifically, use packages that rely on Fibers), but Meteor’s versioning system can accommodate that, since everything is locked to Meteor and/or package version number anyway.

My primary motivations are 2: 1) I’ve noticed Fibers trip up new users quite a bit. Many newbie questions are about interactions with Fibers. 2) They aren’t supported by React’s SSR and might be causing memory leaks (I haven’t been able to confirm presicely that Fibers are the cause yet - I’ll eat a lot of crow if it’s from something else…).

/2 cents

3 Likes
37

Hey, as a developer I’m not a big fan of big breaking changes or full re-writes, I believe software can be written in a way that it can live for a very long time.

That said, our plan here on Meteor Software (Tiny) is to keep Meteor as compatible as possible without compromising quality, I know that is a hard task but this is what we are trying to do in every case, including Fibers.

Then our plan is to study the direct impacts of removing Fibers, we probably already know the answer but we want to confirm.

The solution I see for now is to provide a way for people to avoid Fibers but keep Fibers working for existent projects, as @alawi said unless we have a patch breaking Fibers we still have time and we can see how Fibers is going to behave on Node 16 as well before Node 14 is close to an end.

Our focus in the core now is on HMR (I’m coordinating with @zodern on this https://github.com/meteor/meteor/pull/11117), Tree-shaking (https://github.com/meteor/meteor/pull/11164) + Dead code elimination (https://github.com/meteor/meteor/pull/11107). I believe these 3 PRs are not that far from being merged. Then we can start to think about other big tasks in the core, like Fibers replacement or alternative API.

One thing I can ensure for all of you, I’m also a Meteor user, I also have Meteor apps in production (https://www.bemarke.com, https://app.archlive.com.br are just a few public examples) and then we are NOT going to do anything that is BAD for Meteor users or for companies relying on Meteor to make money. As some people mentioned in this thread, we are open to conversation, if you have any questions feel free to reach me out here on private or also on our Community Slack.

We don’t have anything to hide. Our roadmaps (Galaxy and Meteor) are public and we want the best for Meteor in all possible ways. As I said in the podcast, Tiny bought Meteor because we believe in Meteor and we are going to make Meteor better and better.

Also, a different discussion is about semantic versioning and Meteor, I believe Meteor is not bumping the version as frequent as we should, if you look to other big frameworks/platforms they are bumping the major version all the time, that is good to show for people that are not using the platform everyday that we are moving forward, that we are adding things. That (bumping the major version) is not allowed only when we add breaking changes. It’s the opposite, if you have big breaking changes you SHOULD bump your major version, if you don’t, you CAN bump your major version as well but you don’t HAVE to.

Meteor is a platform and not just a library so we can make major bumps even trying to keep our breaking changes at minimum, as we are going to do. What I mean by that is that maybe, we are going to have Meteor 2.0 soon, and then Meteor 3.0 and then 4.0 and so on. Meteor is a great platform, up-to-date with all major dependencies and we are still using Meteor 1.x for all the releases, this is not good IMO. If you are not using Meteor everyday and you see Meteor is still on 1.x as it was many years ago you are going to conclude that Meteor is dead and we know that Meteor is not dead at all.

Sorry for the long post, to wrap up:

  • We are confident in the future of Meteor, keeping Fibers or providing alternatives. Meteor is not going to die because of Fibers.
  • We are confident that we are one of the best choices in terms of productivity and stability for many types of web-based apps (including Hybrid Mobile apps). And we are going to be even better soon (HMR, Tree-shaking, etc)
  • We are confident that Galaxy will continue to be the best way to have Meteor apps running in production. And Galaxy is also going to receive new updates (as it is already receiving many) for a long time. Cool features for the community is also in our pipeline, trust me :wink:

How you can help?

  • Promote your work with Meteor for your friends and in social medias.
  • Help triaging issues and reviewing PRs.
  • Propose ideas and constructive threads in the Forums like this one.
  • Reach us out! Don’t be afraid, we don’t bite. Are you afraid of something? Talk to us. Do you have a question? Talk to us. Our goal is to help and to improve Meteor.

See you!

29 Likes
38

I’m also checking from time to time the progress on this library with Spider, it’s cool to have something on NPM that could reproduce DDP protocol and Meteor features. Let’s see how this ends up :wink:

15 Likes
39

Thanks @filipenevola for sharing your insights. I also think that backwards compatibility is important.

On the other hand, when I was still a noob with Meteor, Fibers actually confused me a lot. I remember numerous occasions where I ran into the mysterious “code has to run in a fiber” error. Nowadays, I know how to fix this, but it still feels weird.

I think the best option would be to mimic Fibers on top of async/await, if this is possible, to let people gradually migrate whenever they have time to do so.

1 Like
40

Totally agree. The fiber error can also turn people off of Meteor entirely because it feels very odd when you first hit it.

2 Likes
41

I would even go as far as saying they are a pretty bad design concept, at least from a modern perspective. They “hide” the fact that some code has to run asynchronously, without any clue that this is the case. With async/await, you are pretty aware of this. With Fibers, you have absolutely no clue when a method is actually awaiting something. Of course, it’s easy to state this in hindsight (back in these days, there was only callback hell), but it’s another reason to slowly migrate.

1 Like
42

Interesting. This presentation also contains some slides where benjmn explains why mimicking Fibers with async/await (as I was hoping for) might be a bad idea. But maybe this could only be restricted to Meteor’s pseudo-synchronous API?

43

I do have a question.
I remember the days when you could meteor deploy your app for free.
I know Galaxy has free hosting for a period of time, and that there are business reasons behind charging for it but if personally, I could deploy my Meteor apps just like I do with my Netlify ones that would be really really awesome.

Is the free hosting ever making a comeback? (sorry if this was asked before)

At this point in my career I would be able to actually spend the money on a tiny container for my side project apps, but it is a fact that early on and for a lot of people in my country this would represent making a sacrifice somewhere to get that going. I hope I make sense.

Still rooting for Meteor, thanks for all the hard work!

1 Like
44

This post above explains it

45

Yes, I saw that, but I thought it was pretty cryptic. To me, coroutines and async/await do not look that different. When you set an await statement, this is pretty much the same as placing a yield. Ok, the await returns the result of the async operation, while a yield typically returns something comparable to a Promise. But actually, the async op returns a Promise, too, which you can see if you don’t await the call. So the await it’s more or less syntactic sugar (plus it allows to try/catch the statement). Maybe he was relating to the special form of Meteor‘s fibers that also hold some Meteor-specific state?

46

Coroutines is something that doesn’t exists in Node.js codebase, the closest native implementation is Worker Threads.

At the same time Fibers “C-extension” brings coroutines implementation to Node.js allowing blocking in separate “fibers” (e.g. threads), as well as assigning context/state to a “thread”.

As I understand initially Fibers were used to solve two Node.js issues:

  1. Session context/state on server (needed to maintain DDP/WebSocket “private” sessions);
  2. Parallelization (e.g. multi-thread).

Thread blocking was a bonus-feature in that case. Having done() as a last argument in methods, or this.ready() as we have in subscriptions, or support returning Promise from method would ease transition to asynchronous implementation.

Hope that helps to understand coroutines and what tasks were solved using it.

Feel free to jump in if I’m wrong or missed something.

4 Likes
47

Very good summary @dr.dimitru. If someone wants a deeper dive, there is this article on how async/await differs from coroutines. Uses Go’s goroutines for comparison. https://danoctavian.com/2019/03/25/thinking-coroutines-nodejs/

3 Likes
48

An issue I always have with async/await is if the function is deep into a series of function calls. Using async/await require transforming the entire function hierarchy into async.

Seems like this is a clear advantage of fibers. I think moving to workers will have the same issue (but I just used them sparingly and not much adept with it)

3 Likes