Apollo Stack: Goals, Challenges, First Components

Apollo Stack: Goals, Challenges, First Components

This is a brief review of a presentation about the Apollo Stack given at the Meteor Night on March 31st. Sashko Stubailo, a co-author of Meteor guide and MDG member, gives an an explicit insight into what actually Apollo is going to be. It’s a nice introduction for people who are not familiar with this project. At the same time this is a great material to deepen the knowledge for those tech geeks who are already acquainted with this technology.

Apollo is the next generation of the data stack inside Meteor. To better understand its concept, let’s find out what has motivated the Apollo team to start on this project.

In Sashko’s opinion, the most exciting innovation brought with Meteor is its data system. With Meteor a client/server divide became much less of a burden. You no longer have to worry about getting your data from place to place. On top of that Meteor app development is the first to offer:

  • Declarative data requirements, and simple manipulating with them, e.g. pre-opening or closing when needed
  • Better control of your data. Every document in the database has an ID, which you use to directly query a set of collections
  • Stateful client-side cache. Client keeps the track of all the data it has. If you go from one page to another, you may not have to be loading all the time. You may reuse some of the previous data load instead.

 

The idea of Apollo team is to take the data system like Meteor’s and make it work in almost any type of application. Though, while Meteor implies the reactivity by default, with Apollo you will be able to turn it on only when needed. This eliminates the issue of compromising between using Meteor’s benefits and building a static website. Another thing in Meteor that isn’t optimal when your database is not MongoDB is that the client specifies its data requirements using a set of subscriptions and MongoDB queries. Apollo is planned to be a system that lets you have a totally generic data without being coupled to a database. That’s why Apollo team faced the need for:

  1. a query language that was decoupled from the back-end data sources
  2. a more semantic way to tell the server what data you need, so that the client has a power to ask for exactly the data he needs.

 

The Apollo team has solved these problems with the choice of GraphQL. It’s a nested query language. Sashko lists the following benefits that it will give Apollo compared to Meteor:

  • no subscriptions needed: just a query is enough to get the required data;
  • client decides what to request by sending the GraphQL query with the exact shape of data it needs;
  • the reactivity will be built on top of the request/response model, which means you don’t have to make your function reactive if you don’t want to;
  • schema is built into GraphQL, so you know exactly what data your server can
  • give you just by writing the API in GraphQL;
  • can be queried with basic HTTP;
  • application-level query language.

 

Sashko gives a step-by-step explanation of what exactly happens when you send a GraphQL query from the client. He emphasizes on the importance of having clarity of how your app works, while Meteor doesn’t always provide a complete insight into an app operation.

We want you to know exactly what queries are being made, how those queries got generated by your UI, and what kind of impact that’s having on your database queries, APIs and server. And that’s something I haven’t seen in any system yet.

 

Besides GraphQL the Apollo team plans to use some other powerful tools developed by Facebook (e.g. Relay, GraphQL-JS, Graphene, Sangria and other).

To sum up, Sashko briefly introduces the first two components of Apollo. Apollo server: a simple GraphQL translation layer on top of your backends. It has a declarative schema and allows to fetch data from as many backends as you want. Apollo client: offers Meteor-like caching, optimistic UI, reactivity, pagination, etc. that are adoptable for any type of an application. It has a razor-sharp focus on transparency, simplicity and ease of debugging.

Watch complete talk by Sashko Stubailo at Meteor YouTube channel:

P. S. On the April Meteor Night Sashko introduced the alpha release of Apollo and its demo (This is the link to a particular place in the video, where Sashko’s presentation starts. If it doesn’t work that way, start watching at 1:29:00).