GraphQL trade offs

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

GraphQL is under the 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 a fresh good material from famous Alex Xu I would like you to watch first, so I don't need to get into details here and do not repeat here.

While I fully support 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 in a bit different but definitely not "the best one because the new one". I would even say it's more like a SOAP way for even more specific business-cases. Below I will give more details on that point by showing parallels in between.

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 unreliable or poor connection. Basically, GraphQL allows you to execute less 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 the Big Data, or there are uniform way of represent the information from various sources.
   GraphQL allows you to optimize your development team throughput by letting your Front-End team think on what they want to get from the API, instead of your back-end team propose 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 case of SOAP. That's nothing new and may look normal when you are alone responsible for both Back-End and Front-End (building a Hello World). And it's OK while your team fits in one room (or shares 2 pizza :) ) 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 communicate 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 N+1 problem. Flexibility that GraphQL provides to the Client team comes with the possibility to make unpredictably slow database queries. Of course this can be mitigated by manual or automated testing, but worth keeping in mind. And definitely it might not be acceptable for some cases.

On GraphQL schema-stitching

To resolve a problem of coupling there is an idea of schema-stitching. In simple words, you can take two or more GraphQL schemas, and merge them altogether for the client's use, while generating them separately. Schema Federation is a 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 Feration v2.0 and an idea of supergraph.

To my opinion, this 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 trade-offs mentioned in the video and listed above before you get amazed on the benefits it provides.

References

GraphQL Specification
GraphQL over HTTP
Introducing GraphQLinq strongly typed GraphQL queries with LINQ to GraphQL
GraphQL API with .NET 5 and Hot Chocolate
Short GraphQL example in Node.js and Express JS framework
Introduction to GraphQL
Creating a GraphQL back-end with .NET GraphQL library
Getting started with GraphQL and HotChocolate
GraphQL schema design from the creator of HotChocolate GraphQL library
GraphQL and ASP NET Core - .NET Oxford - November 2019
Building Modern APIs with GraphQL
Getting started with GraphQL and HotChocolate
GraphQL Part 2 - Setting up project
Beyond REST with GraphQL in .Net core - Irina Scurtu
GraphQL Server with .NET Core Tutorial
GraphQL Schema Design
GraphQL for dotnet developers
Владимир Цукур — GraphQL — API по-новому
GraphQL #0 Введение
Статьи и презентации про GraphQL
Redux не нужен. GraphQL и Apollo Client
Разработка GraphQL API на ASP.NET Core // Бесплатный урок OTUS
Apollo GraphQL with React. Полный курс
Why Swagger is dead