GraphQL is a technology that’s rapidly rising in popularity. Here at Big Nerd Ranch, we always like to use the best available tool to solve our customer’s problems. We recently had a client project which looked like a great fit for this new technology. We spent three months working with GraphQL as our main API design for an iOS app.

In this series of blog posts, we’ll look at what made GraphQL an appealing technology, the benefits and shortfalls we discovered while using it, and what we recommend others do when considering using this technology in their own projects. Let’s get started!

Why GraphQL

There are a handful of useful features that GraphQL promises. They are:

Decoupled frontend and backend development

Once the GraphQL schema is defined, it is trivial to deploy a mock server that the frontend devs can build against while the real backend is implemented.

Data fetching optimized for mobile

The get-what-you-ask-for approach of GraphQL saves bandwidth. The client can ask for multiple screens worth of data in one request, which would be multiple requests in a traditional REST API.

Client controls the network cost

GraphQL is designed to minimize the cost of fetching data from an app. You can batch multiple requests for independent objects together to minimize the number of network connections. You can specify exactly which properties you need from those models to minimize the payload. And this can all be done dynamically on the client side, without a deployed change to the API.

Robust tooling

Apollo has a large suite of libraries that seem to meet all GraphQL needs. Apollo Server claims it is, “The best way to quickly build a production-ready, self-documenting API for GraphQL clients, using data from any source.”

Type-safe models for free

One of the promises of the Apollo GraphQL iOS SDK is that it automatically builds type-safe models that match your GraphQL queries. We don’t need to build codable models separate from our queries – if we want a new model or a new property we just need to ask for it. The build system handles the rest.

Why not GraphQL

Let’s play devil’s advocate for a minute. What are some good reasons to not use GraphQL on a project?

REST is well established

REST has been the standard means of building APIs for years now. It’s well understood by both our backend team and our mobile team. If you have a solid understanding of what the primary objects were in your data model, a REST service is relatively easy to create.

Unknown unknowns

The biggest risk anytime you adopt a new technology is that you have gaps in your understanding that don’t surface until something fails. Documentation isn’t a perfect substitute for experience.

Decision time

On this particular client project, a few key points tipped us towards using GraphQL:

• The API’s clients will only be mobile apps. Since GraphQL is designed to be consumed by mobile clients, that’s a clear point in its favor.
• The data model is subject to change. While this can be done with REST, the schema-based approach of GraphQL can make changes to the data model easier to implement and mock.
• We had read plenty on the draw of GraphQL and were comfortable with its tradeoffs.

How did it go? Check out Part 2 to see.