Meteor Reactivity Alongside GraphQL Apollo


I love Meteor but I also understand that GraphQL is the future because:

  1. You get API documentation out of the box
  2. It’s getting standardised and lots of developers start to learn it
  3. Miles ahead in terms of scalability, ability to stitch and connect with others APIs beautifully

Many more…

So this is just a small video of something I hacked quickly. For people that are unfamiliar with GraphQL Apollo it’ll look weird and ugly, but I’ll take care of those parts. Long story short, we can do it, we can have the beauty of Meteor inside Apollo. And this would be a production ready npm and meteor package within the next months.



Can’t wait to take a look at this later! I have been playing around with this type of thing at home and have hit some struggles, so you have impeccable timing!



Now, wouldn’t it be great if MDG worked on some of this integration work between Apollo and Meteor?


This is cool! and I think it’d be a great add to have pub/sub api similar to that of Meteor’s RPC to the GraphQL ecosystem, but please allow me to scrutinize this a bit :slight_smile:

This seems like reinventing Meteor’s pub/sub API using GraphQL, but if someone is building a typical 3 tier app, without the need for a self documented API that can stitch with other APIs since they’re a small team with little integrations, wouldn’t that be a downgrade relative to Meteor’s Methods RPC given the amount of boilerplate and complexity added?


@hluz it would be great for MDG to work on so many things, but they have limited resources. It’s up to us the community to support them, heck they gave us Meteor for free, and MIT licensed…

@moberegger I’ve hit struggles as well, outdated documentation on their website, but after doing some digging, looked at other’s boilerplates, I managed to hook it up. My vision is to have a meteor/apollo-super package, that gives you:

  1. Painless reactivity (that works with redis-oplog)
  2. Websocket stiching and Meteor user accounts integration, out of the box.
  3. Is properly merging with Grapher (Grapher is still the bomb.)
  4. Ability to have… reactive data graphs! But it won’t be the main focus I just explored the fact and it’s possible.

@alawi yes. it’s almost reinventing, it’s more like adapting the beautiful concept that MDG came up with, and putting it inside GraphQL. My vision is to hack something to make GraphQL as simple as possible. The reason I started adopting GraphQL is that I was pondering about evolving Meteor’s API in something self-documentable, something better decoupled ( and what I realised is that I was slowly reinventing GraphQL… so I said to myself STOP! and got on the bandwagon.

GraphQL beauty lies in it’s ability to self-document itself, it will become a standard and will be widely known by many developers. I can simply write backend code, expose my schema, my mutations, put in a graphql mocker, and the frontend engineer can already start coding without needing my implementation… it’s very lovely, and there are many advantages to it…

Anyway, that “Simple” part is what I’m working on (in my spare time)


I’m not sure if this might help but Apollo introduced the ability to create custom directives, perhaps the reactivity can be simplified by creating libraries that introduce custom pub/sub directives to reduce the boilerplate code?

Just thinking loud here.


Looks great!
Is there any chance you could publish your code somewhere?
I would love to take a look, without retyping the chunks I can steal from the video :wink:


I no longer have it in that form, sorry. I will publish the packages next week. I’ve finished the API, and I worked a lot on how to architect large scale graphql code, I am very pleased with this approach. Will share all my findings and knowledge with the community, as I always do.


I have a novice question …

May anyone please, please tell me how was the Apollo/GraphQL/Meteor combo until now? What was missing from what we have now with this revelation.

Didn’t we have Pub/Sub with GraphQL & Meteor before?

Please tell me how does the above post help us so much with scalability? Ability to stitch & connect with other Apis is obvious. Or may I say, how does Apollo etc. help so much with scalability? It’s really important for me to know this.

Is the scalability only bcoz of a separate client: Apollo wires up all apis and leaves the Meteor Server out of it?? Or are there other aspects to scalability with this setup (above)?

I am starting hunting for resources on internet wrt this.

Many thanks.


I think Api scalability is quite obvious. Are there any other aspects to Scalability?

Tooling is much improved owing to Static Types.