Apollo is just space related enough so you can adopt other names related to other space projects. Meteor’s new ambition is so crazy and I think it is worth talking about. Being as transparent as possible is great. Meteor wants to build a reactive GraphQL data server layer and make it open source.


Meteor is very tight into mongo and Meteor Development Group (MDG) wants to decouple a lot of its old tech stack. At the moment there are oplog tailing, DDP, pup sub functionality, and MiniMongo and it is lacking all the documentation.

So what is Meteor going to be? You can build another Meteor app and you will be able to modify your Meteor app as you go. MDG will create an organisation with lots of use cases and packages. So Meteor will not going to manage the view. Meteor is conceptional a guideline that tells you how all the tools will work together. So Apollo will be a major component within a technology stack. Or call it a build system. MDG thinks Apollo is a solution to the Data problem and Meteor is the solution to javascript fatigue. What ever that means.

What is Redux?

Is basically a method to share state in your UI in a easily debug way. So with React you want to keep a global state in a global immutable way and all that is primarily a UI state. With Redux you are trying to manage your UI state.

What is Relay?

Relay is a framework designed to provide data-fetching functionality for applications developed in the React framework (introduced in 2013, again, by Facebook). Developers are encouraged to compose these React components naturally, and let Relay take care of composing the data queries into efficient batches. And Apollo will be using Relay.

Relay seems to have a lot of similar components like optimistic UI updates. It also has a client side storage. Like Meteor, a local copy and it has a way to update your ui. Relay contains all those components, too. To use Relay is a bit more complicated at the moment, but is modular. So better in the long run.

Mutations are both, a GraphQL and Relay thing. The GraphQL server has a list of mutations which are an endpoint of writing data. They are almost like meteor methods with arguments. What is on top of mutations is what is on top of meteor methods. It gives you an optimistic UI with reactivity build in. When you write a mutation you need to specify what has to be updated after the method is done. So for Apollo they need to come up with a better solution to handle post processing without having to write to much code.

The way it works in Meteor, when you do a method call DDP takes a timestamp and oplog waits until that time is over and the method has completed. So you need to understand your whole lifecycle plot in order to do optimistic UI. That is going to be hard for Apollo. So the client will need to do some calculating in order to help with optimistic ui.

It will be a bit different for Apollo, every optimistic UI change will be associated with a mutation. It is almost like writing to the client in Meteor. When that mutation is complete you through away all updates. In Meteor you can update all collections in MiniMongo and still become changed after the server decides what you are allowed to do in your app. The optimistic UI of Meteor will be part of Apollo. This is really a build tool system.

What is GraphQL

GraphQL is a data querying language designed to describe the increasingly complex nested data dependencies of modern applications. Facebook have been using it to build their native applications for some time now. On the server end, GraphQL is configured to map queries with underlying data fetching code. In GraphQL you have to specifically specify every field you want. For REST, it depends what the server decides to send back to you.

Apollo is going to make this reactive. You are going to take your object graph with nodes and edges. Nodes are users, tasks, todos, everything you can think of. Like collections in Meteor. Apollo is going to track dependencies on Nodes. That means when you access a certain type of data and you track what type of data has changed. Apollo’s tracker will work on a multi client basis. It will be very hard but so good.

Reactive GraphQL or Apollo

Lets say you access a certain database entry and reference this with a dependent tracker. Is this version of user outdated? You need to check on the server and on the client. This server will be a separate component of GraphQL and might be implemented separately but will be part of a reactive Apollo.

There are multiple levels of tracking data. At the very basic level, every time you read and write the data you talk to the invalidation component and you get an invalidation. On top of that you can put a life messaging system. You could also work with Meteor and attach a life query system against you server. So anytime data changes you get a notification. Or instead watching the database, you should be watching the database and listen to changes on a collections. So you can build very naive systems. Some pub sub systems don’t even guarantee to deliver all the data you might expecting.

In order to put that into an reusable component MDG will have to test this with apps and they say they are going to test this with chat apps. So until than, no Apollo will ever be successful. It is a big hype but a good direction.

There will be a different way to do security with GraphQL. The community is already working on this topic and MDG will have to rethink its current strategy. In the current state, you should be doing all data reduction on the server side and send only what you need.

Meteor developers will move towards a more versatile data layer to be used with other technologies under the hood. Outside the meteor, developers have the impression MDG is going through an identity crisis. Apollo isn’t the first approach, apparently MDG was trying to build this layer in the past. So Meteor will become a very command line tool to build awesome web apps!

P.S.: Apollo will open so many doors. Just think about the rails community! Legacy rails apps will become reactive!