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)
and maybe:
- 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
Personal thoughts
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 create-xxx-app:
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.