Special thanks to Sashko for making a lot of the slides that are used in the above presentation and for working on Apollo!

Apollo is the new GraphQL based stack that the Meteor Development group has been working on. Recently, they have released a technical preview of the Apollo platform, so now we can get a feel for what the architecture of an Apollo-based app will look like.

A lot is happening in the JavaScript community

A lot is happening in the JavaScript community today. There are a plethora of front end frameworks for rendering views. There are frameworks for handling data flow. New tools for querying data. Tons of build tools to pick from.

But, if we look back, we can see where Meteor started from, what the underlying goal was, and how that goal applies looking forward.

What Meteor Provides

The MDG group has been focusing their efforts on the Meteor framework and the Galaxy cloud platform. Meteor does a lot of things. When it started 4 years ago, the JavaScript world was a completely different place. Client-side rendering was a concept that was just gaining traction, NodeJS was just becoming popular, and single page apps were starting to become a reality. Meteor came out of the box with a lot of custom tools to fill in all the things you needed to build a complete application entirely in JavaScript.

The most exciting part of the Meteor experience has always been the data. Meteor achieved this with the Distributed Data Protocol (DDP), mini-Mongo on the client, and MongoDB on the backend.

Meteor has built Blaze and these build tools because they didn’t exist back 4 years ago. Now, there are a variety of options for the view layer and tons of build tools. The data system, on the other hand, is something where many new tools are springing up in the JavaScript ecosystem. The goal is to keep the data part of Meteor magical. In Meteor, you often write code as if the data you need is already on the client.

REST vs Meteor

Let’s go over some of the main properties of Meteor’s data system, from a developer productivity point of view:

Meteor is declarative – you can tell the server what information you are interested in via subscriptions, and the server figures out how to get it to the client in the most efficient manner.

Meteor is semantic – instead of blobs of JSON fetched from endpoints, data in Meteor is organized into collections where each object has an ID (leveraging the ids in Mongo). You always have a way of referring to a specific object.

Meteor is stateful and includes caching: Meteor doesn’t load the same data twice, since both the client and the server are aware of what has already been sent over the network. This means you can preload a lot of data and rely on the system to only send diffs, making prolonged interaction with the app more effecient.


The goal for the Apollo project is is bring these properties that make Meteor so nice to work with to every app. Whether that app is written in Rails or Express, or has a Microsoft SQL server database or Dynamo DB.

The goal is to start with JavaScript as the client, but to also branch out and provide libraries for Swift and Java.

In order to achieve a system like this, MDG had to look for or create a language for decoupling the database from the views that use it. Luckily, Facebook has released GraphQL, a query language where views can request only the data they need from the server to render their view.

Mongo to GraphQL

The query language is agnostic of the database or databases that drive it. When a view queries for a user, the user data might be pulled in from MongoDB, or MySQL, or PostgreSQL or all three.

So what is GraphQL?



GraphQL is a way of making queries that get interpreted by the server. The server will respond only with the data that you asked for.

GraphQL is made up of schemas and resolvers. Schemas have types and types can be nested. Here in this example, a user can be type, and the profile picture is another type. Our front end may request a user with a profile picture – but it doesn’t care where those pieces of data come from. The user data may be in MySQL, and the profile picture might be in Postgres. The resolvers on the server are in charge of mapping these type requests to database requests and responding with the data.


10000 foot view

Here is how a complex application may use Apollo from a 10,000 foot view. There can be many clients and backends working together that the Apollo server would sit inbetween. It would take GraphQL requests and resolve to to their data sources and respond with the data that the client asked for.

Apollo gives you a principled, unified, and scalable API for all of your client apps, agnostic of what is going on in the backend.

So what happens when the client make a request?



Screen Shot 2016-05-05 at 10.08.45 PM

While you can get a lot of benefits of using GraphQL through simply sending POST requests to your server, it becomes much better once you have a smarter client that can avoid fetching data you already have, and give you other features that we’ll talk about below. Let’s compare what we’re thinking about with Apollo and GraphQL to Meteor’s current data stack:

Screen Shot 2016-05-05 at 10.08.26 PM


For more information, see: