While i wrote this post, i noticed, there are two directions meteor could take:
the apollo route (probably what mdg wanted)
Embrace the ecosystem around react or vue and apollo: I think meteor’s biggest contender in this is next.js and nuxt.js. I never tried nuxt.js but i guess it’s similar to next.js. Both lack a data-layer however, which is usually fullfilled with apollo and any db (mongodb, sql, whatever). What’s also missing is reactivity, which made meteor really unique, but its also a not needed in many projects.
So to seperate it from next.js I would:
- deep and seamless apollo integration. Seriously, this was promised by mdg, but never done properly
- out-of-the-box authentification&authorization through graphql and meteor’s account system
- out-of-the-box reactivity using graphql-subscriptions, websocket-channel and some pub/sub like redis for cloud-environments
- client-libs if needed to help with these features for react and vue, building upon apollo-client
- out-of-the-box integration of apollo-platform (optional, but mdg could be interested in a deeper integration)
- give a good migration path from ddp-pub-sub to apollo so that we can deprecate ddp-pub-sub, because it is holding meteor back.
Having said that, here is the other path:
2. back to the roots
You can create a stack like described above without meteor using current best practices. This is initially more effort, but gives you a flexible stack.
However, meteor was great, because you could setup a project so fast and it needed nearly 0 configuration. So tiny could just add some missing pieces to meteor:
- focus on ddp-pub-sub, add missing features, make it scale using https://github.com/cult-of-coders/redis-oplog
- focus on one view layer, maybe even go back to blaze or settle on one of the others
- first-class router and server-side-rendering
I guess mdg themself had the same thoughts about which direction meteor could take. This resulted in a split of the community. Some prefered to stay with the original way, others migrated to react (or vue) and graphql. Arunoda, who contributed a lot to meteor also did not believe anymore in the original, monolythic nature of meteor. I also share many of his thoughts. Meteor in its original form (blaze, mongodb and pub/sub) is a dead-end. It’s great in the beginning, but its hard to scale it application-wise, e.g. add more clients like native clients, split the backend in services, integrated other services, etc. (of course its possible, but not without a lot of research, experience and effort).
So i personally would love to see it going in a direction like these
They create an (opinionated) setup using best practices, but hide the configuration until you “eject” it. So if you need to diverge from the original setup, you can eject a part of it, and customize it. This could give the best of both worlds.
Some words for mdg/apollo
I think giving meteor to tiny was the right decision, but i would love to see you guys give us some of this sweet meteor magic in our apollo-stacks. E.g. build a library for next.js that adds easy authorization/authentification through apollo. Or a library for 0-config graphql-subscriptions. Or a nice orm-layer, a 0-config prisma2/photon integration would be awesome.