GraphQL APIs and performance

I published an article on API paradigms a few weeks ago that touched fairly heavily on GraphQL. Reactions were generally very positive, but a misconception came up more than a few times around how GraphQL isn’t appropriate for public APIs because it implies unknown and unbounded considerations around backend performance.

It’s true that performance can be a challenge, but it’s not true that GraphQL somehow forces you to expose routes that are not performant. A GraphQL schema is designed the same way as your traditional REST-ish API in that a service operator only reveals routes where they can ensure good quality of service for users, and good stability for their own backend.

For a general feel of the API that GraphQL implementations provide, here’s the most basic possible example from the graphql-js README:

var schema = new GraphQLSchema({
  query: new GraphQLObjectType({
    name: 'RootQueryType',
    fields: {
      hello: {
        type: GraphQLString,
        resolve() {
          return 'world';
        }
      }
    }
  })
});

Note the resolve function. The library doesn’t figure out how to map onto your data’s internal structure, you tell it how to. Here’s a more complex example that shows the same thing.

Of course, a schema allowing rich data access will be beneficial for its users, but operators have the freedom to increase that complexity at their own pace, ensuring that revealed queries, subqueries, or fields are suitably performant as they go. The API is powerful, and just like in REST, a service’s internal structure stays decoupled from its public API.