How to get Apollo 2.0 working with GraphQL + subscriptions

(with a bias towards Meteor)

Update (Nov. 28, 2017): The ‘Cache’ keyword from the ‘apollo-cache-inmemory’ NPM package has been replaced with ‘InMemoryCache’. The new code reflects the most current working code. If you have any more issues, please report them as we try to keep up with Apollo’s latest changes.

There’s a lot of turmoil right now as developers are learning that Apollo 2.0 has brought breaking changes to previous 1.0 implementations, and the official docs and most online examples are now outdated. I recently got 2.0 working (with subscriptions!) and I thought I would spare many from the hassle of forum hunting. For my purposes, I have implemented this in Meteor, but it’s only a hop, skip and a jump to Node.


A fully-functional example app can be found here.

Before we get started

I’ll leave the complete set of code to GitHub and just talk about some of the main components here, especially the parts that have changed. Everything here is working and accurate as of Nov. 28, 2017.

What you will need

Apollo 2.0 has ditched SubscriptionManager, networkInterface and a few other things in favor of Apollo-Link. It’s a good sign, as it means Apollo is maturing and is now going to become a platform on which other developers can build plugins. But this is only supported in newer versions of Apollo and we have to make some manual upgrades to keep all other packages in sync.

You will need the following NPM packages (pay attention to the versions):


If you’re using Meteor, the following packages will also be useful:

meteor add apollo swydo:blaze-apollo swydo:graphql webapp

(If you’re using React or Vue, feel free to use something other than swydo:blaze-apollo)

The Client

Most of the biggest changes have happened on the client side. Your client (with subscriptions) is now going to look something like this:

The Server

Unlike the client, this example uses more Meteor-specific code. Check the links in the comments to learn how you can convert certain pieces into more generic code using something like Express, if desired. Or just use Meteor.


Here is a quick peek at our resolvers. There aren’t many changes here, but if you are new to subscriptions, you can see them in action on the server here.


First, something that is important to understand about GraphQL publish and subscribe is that you must manually publish every time a change was made on the server. That is how updates are pushed to the client immediately. (Meteor folks may not be used to this, since they’ve always gotten this for free.)

Second, if you are only making changes to your data through GraphQL mutations, the example above will work just fine. However, if you are updating data from other places as well and want subscriptions to react to those changes just as quickly, you’ll want to call pubsub.publish("exampleSub", { exampleSub: data }); wherever those changes are made, where exampleSub is the name of your subscription and data is your complete object for that entity adhering to your GraphQL schema (in the example above, it is all data belonging to that Person).

Third, the reason the official Apollo docs advise against using PubSub in production is because it doesn’t scale to multiple servers. If you’re large enough that you need to run your app on multiple servers, you should use a PubSub implementation that supports it, like Redis, MQTT, or RabbitMQ.

About Pitchly

My name is Michael and I’m a Senior Product Engineer at Pitchly. We make it easy to manage and find information instantly across your entire organization and export that information into a variety of visual formats. Meteor, GraphQL, and Apollo are a large part of what we use. We’re also from Des Moines, Iowa. Sure it snows here, but we also have some pretty awesome corn!

If you have any questions for us about our work, lives or if you have a passion for GraphQL or Meteor, get a hold of us. We’re hiring!

Website — Twitter — LinkedIn