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.
But, if we look back, we can see where Meteor started from, what the underlying goal was, and how that goal applies looking forward.
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.
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.
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.
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.
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?
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:
For more information, see: