GraphQL Trade-Offs

It's very easy to fall in love with technology sold by professional marketers. However, software engineering is hard because there is no one solution to fit every case.

GraphQL has been a focus for a couple of years already. Before you add this nice-looking abbreviation to your resume, I would like to share summarized points and thoughts on it based on production experience. There is fresh, good material from the famous Alex Xu I would like you to watch first, so I don't need to get into details or repeat them here.

While I fully support the concerns mentioned in the video, there are a few things I would like to add:

GraphQL Is Not Going To Replace REST or SOAP

It's just one more way to build an API a bit differently, but definitely not "the best one because of the new one." I would even say it's more like a SOAP for even more specific business cases. Below I will give more details on that point by showing parallels between them.

GraphQL Is Created To Solve a Few Specific Problems

It is covering the cases where:

1. You're doing business where most of the users are running from "smartphones". Such users are frequently switching networks/ISPs while they go and may work with an unreliable or poor connection. Basically, GraphQL allows you to execute a fewer number of requests from the mobile application to the API. However, the devil is in the details.
2. You can easily fit all the data (that you need to use on the client/UI) into a single data model (or data graph). It might be because you work in Big Data, or there are uniform ways of representing the information from various sources. 

GraphQL allows you to optimize your development team throughput by letting your front-end team think about what they want to get from the API instead of your back-end team proposing their data model or guess on what is the most optimal API and data model. It's not very efficient to wait for API change (by back-end engineers) every time you need to change the UI side. Thus, UI developers are happy because they can play with data and find various ways to use it or show it. However, are they knowledgeable enough to do this safely? This benefit comes with a cost.

GraphQL Brings Trade-Offs

It requires you to be ready for a few things, though:

1. You have to generate the schema of the API, just like in the case of SOAP. That's nothing new and may look normal when you are alone and responsible for both the backend and frontend (building a "Hello, World!"). And it's ok while your team fits in one room (or shares 2 pizzas) and can easily speak to each other very quickly. However, if your team is large and/or updates API objects frequently, you can quickly get tired of this process. Every time back-end engineers update API and regenerate schema, they have to connect with some peers that need to pick up their updates. They have to spend more effort on building and maintaining additional CI automation steps, as well as communicating better and more frequently using chats, messengers, etc. Clearly, your development process becomes more tightly coupled and fragile. It doesn't enable so much flexibility in experimentation as REST.
2. It takes control of your API performance out of the hands of your back-end development team and into the clients' hands (UI/client development team). Using its strong typing GraphQL enables so-called client‐specified queries. In worse cases, it leads to an N+1 problem. The flexibility that GraphQL provides to the client team comes with the possibility of making unpredictably slow database queries. Of course, this can be mitigated by manual or automated testing but is worth keeping in mind. And definitely, it might not be acceptable in some cases.

On GraphQL Schema-Stitching

To resolve the problem of coupling there is an idea of schema-stitching. Simply worded, you can take two or more GraphQL schemas, and merge them all together for the client's use, while generating them separately. Schema Federation is the way to go.

The problem, though, is that even this idea was far from a perfect solution. That's why companies building complicated tooling around GraphQL and, specifically, Apollo recently (as of summer 2022) introduced Federation v2.0 and an idea of supergraph. 

In my opinion, this is all a sign of problems at the core of the protocol. It adds unnecessary cognitive load and architecture complexity to the world of software sandcastles, which become even more fragile.

The End

Clearly, GraphQL narrows down the number of use cases it solves and is not a silver bullet. You have to evaluate the trade-offs mentioned in the video and list above before you get amazed at the benefits it provides.