Meteor’s Reactive GraphQL(Apollo) Is Just Awesome

Published in

KADIRA VOICE

6 min readFeb 10, 2016

Edit: Meteor’s Reactive GraphQL project is now re-branded as Apollo.
We discuss about Reactive GraphQL in this article. But it’s about Apollo too, because Reactive GraphQL is the core of Apollo.

Meteor is working on a reactive GraphQL implementation, and they released a high-level technical documentation yesterday. This is a review of that design document along with some of my personal insight into this project.

It’s GraphQL

GraphQL is an application-layer query language introduced by Facebook. It is accompanied by several other tools and libraries, including Relay, GraphiQL, and express-graphql. It has implementations in many languages.

If you are not aware of GraphQL or find it very hard to understand, just try our LearnGraphQL interactive course. You’ll love it (just like others).

What’s Reactive GraphQL?

First, have a look at the following diagram:

Here, Client A uses a GraphQL query to fetch data and render a view. That’s a blog post.
Client B just posted a new comment to this post.
That comment will be automatically pushed to Client A. The application developer (that would be you) doesn’t need to write anything explicitly to get that comment.

That’s what Reactive GraphQL is. You don’t need to re-fetch data manually or reload the page.

Basically, it’s just like Meteor but with GraphQL. You could use MongoDB, SQL databases, REST APIs, or nearly any data source.

Sounds great! How can I use it?

Reactive GraphQL Development Experience

Most of the hard work is done by the Reactive GraphQL libraries and tools. Therefore, you can simply write your GraphQL schemas on the server and GraphQL queries on the client.

Here’s a typical development experience:

You write a GraphQL schema on the server and use some special database drivers to get data from the databases.
You can also use your own data sources if needed.
In the client, you create queries and invoke mutations as you normally do with GraphQL.
For that, you need to use a client side library that comes with Reactive GraphQL. (It uses Relay’s cache behind the scenes and handles all the reactive stuff for you.)

That’s it. Now, all your GraphQL queries are reactive, and your client app always has the most recent data from your schemas.

Deploying & Scaling an App

Deploying a Reactive GraphQL app is also simple. Just deploy the app, and scale as many as containers(servers) you want. The server side app is purely a version of express-graphql with some Reactive GraphQL database drivers.

So you could deploy it and scale it just like any other Node.js app.

Sounds great! Where does it handle the reactivity?

Good question. Your app server does not know anything about the reactivity or how to invalidate queries. It just exposes some GraphQL schemas.

Reactivity is handled by another server known as the Invalidation Server.

Invalidation Server

This is a lightweight server that keeps track of versions of documents sent to the client via your GraphQL schemas. Your app server sends all the query requests and mutations to this server.

Your app clients can talk to this Invalidation Server and watch for any invalidations. If there is an invalidation, it will fetch data from your GraphQL app server.

This whole process is designed so that it maintains ease of use without compromising efficiency.
For more information, have a look at the design documentation.

This invalidation server doesn’t deal with your data. Basically, it knows nothing about the data.

You can think of this as a distributed version tracker.

Meteor is planning to build the invalidation server as an open source project as a part of this Reactive GraphQL project.

It’s very likely that there will be a hosted version of the invalidation server available for your app if you are using Galaxy (Meteor’s hosting service).
Therefore, you don’t need to worry about this server at all.

View Layer: React, Angular, Blaze, etc.

GraphQL is typically used with React-based apps using Relay.

But Reactive GraphQL is view layer independent.

On the client side, it is just a reactive data source. You could use it with any kind of view layer whether it’s Angular, React, Blaze, or something that has not been implemented yet.

If you need an example, check out Lokka. It’s a simple JavaScript client for GraphQL. The client side library of the Reactive GraphQL will be similar to Lokka but with some reactive goodies.

More Information

This is just an overview of Reactive GraphQL. This project is still in the design phase, and there will be changes to this design. Have a look at the following documentation for more information.

Reactive GraphQL: High Level Design

It’s written in simple language, and it’s an easy read. Make sure to follow the discussion, as well.

FAQ

Can I use Reactive GraphQL outside of Meteor?

Yes. You can use it in your existing Angular, React, or any other app. You may not even need to change your backend.

You can add a Reactive GraphQL server in front of your existing backend and let the client app talk to the Reactive GraphQL server.

Is this project available via NPM?

Yes. That’s the plan.

Can I host this outside of Galaxy (Meteor’s deployment service)?

Yes, of course.

Can I use React Router?

Yes, you’ll be able to. Reactive GraphQL is not router dependent, so you’ll be able to use it with any router.

How can I handle the auth logic?

There are some ways to handle the auth logic in GraphQL. You can always follow those. Meteor also has a great account system. You’ll be able to use that, too.

Will this solve my Meteor scaling issues?

Yes, of course. The Reactive GraphQL app server simply exposes some GraphQL schemas. It doesn’t keep your data on the server or do any diffing or invalidations.

There’ll only be a few things happening in the server. Thus, the app server will be very efficient. Additionally, you’ll be able to scale it horizontally without any issues.

Can I write GraphQL schemas in languages other than Node.js?

You can write GraphQL schemas in a wide variety of languages. That’s one reason why GraphQL is popular.

Technically, it should be possible to use Reactive GraphQL with any language. But you may need to do a few things yourself. Here are a few of them:

Talk to the Invalidation Server
Send some additional information to the client app

It’s too early to discuss this. But there’ll be a way to do that.

I write data directly into DB via some other app. How can Reactive GraphQL identify those changes?

For that, you need to talk directly to the Invalidation Server.

So, my client side app needs to talk to two servers (the app server and the invalidation server)?

Technically, yes. But in practice, these two servers could be the same, or you can proxy to the invalidation server via your app server.

It is also too early to discuss these things. However, please note that client-server communication will be designed with performance in mind.

How could I debug my Reactive GraphQL apps?

Performance monitoring is included in the Reactive GraphQL project. There’ll be tools/APIs to debug what’s happening inside.

Then you could decide how to make your app efficient. There will be a lot of knobs to tune your app for different performance expectations.

We (Kadira) are pretty excited to build tools on top of Reactive GraphQL performance APIs and to help you identify performance issues and optimize queries.

Reactive GraphQL will be an awesome project, and this will be beneficial for the whole JavaScript community, not just for Meteor developers.

Follow KADIRA VOICE for more articles like this.