First thoughts on Apollo GraphQL

It Begins

While I've been working on more operations related technologies, my team at work has been busy with pushing forward in a new service using Apollo GraphQL. So I decided to take a look at what the hype's all about.

Setting Up

Setting up was pretty seamless. Install the dependencies and it's good to go. I followed this guide from the official docs

Apollo GraphQL includes a handy GraphQL Playground which seems better than the GraphiQL which was the way to go when I previously touched GraphQL.

To get started, one simply runs:

npm i apollo-graphql

And then in the code:

const {ApolloServer, gql} = require('apollo-graphql');

const staticData = [{a: 1, b: 2,},{a: 2, b: 3}];
const typeDefs = gql(`
  type Data {
    a: Number
    b: Number
  }
  type Query {
    data: [Data]
  }
`);
const resolvers = {
  Query: {
    data: () => staticData,
  },
};

const server = new ApolloServer({typeDefs, resolvers);
server.listen().then(({url}) => console.info(`Listening on ${url}`));

Monitoring

As an ops engineer, the first question I usually ask is "how do I monitor this thing?"

The official Apollo GraphQL documentation recommends the Apollo Engine, but that requires an API key, and it also meant that I would likely have different sources that I'd need to monitor when it comes to assessing the performance of the service. I'm looking for things such as response time, remote IP address, size of payload, request body structure et cetera

It would be nice if there could be some way to use Prometheus with this.

Option 1: Use the Context

So I explored a little and found the context option which could be passed into the ApolloServer constructor. It exposes a function that exposes the properties from both the incoming request and outgoing response. Could the context be used to inject a Prometheus metrics listener?

Option 2: Use the ApolloServer as a middleware

One nice thing about Apollo GraphQL is that it can be used as a middleware. Changing the dependency to apollo-graphql-express allowd me to use an Express server with express-prom-bundle to monitor the requests coming in. However, there's a problem: All paths are /graphql which doesn't really make sense.

Code Structuring

With the basic example, it's easy to see how the string passed to the gql function could be extended modularly.

Given that we have a directory structure that mimics our data model, each of these models could export a GraphQL type definition which can then be merged into a master schema of sorts. Took reference from this blog post.

Final Thoughts

GraphQL still seems pretty intriguing to me. According to what I've learnt about it so far, Apollo GraphQL also offers React Apollo GraphQL which seems to make writing queries easier and removes the need for using Redux, which is the real benefit I'm looking for.

• The ability to define response schemas is pretty interesting to me and allows us to easily test compatibility with other consuming/providing services with contract driven testing.
• Despite the benefit, how can we monitor it? A quick Google search doesn't turn up much on monitoring GraphQL queries. I'd rather have an unoptimised service that can be monitored that's written RESTfully, over an optimised one using GraphQL that cannot.