GraphQL trade offs
Tags: graphql, api, backend
Published: 2022-11-12 19:17:34

**_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._**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cqcp79afuekis0lotxwk.png)

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.

{% embed https://www.youtube.com/embed/yWzKJPw_VzM %}

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](https://stackoverflow.com/questions/97197/what-is-the-n1-selects-problem-in-orm-object-relational-mapping).
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](https://www.apollographql.com/blog/announcement/backend/the-supergraph-a-new-way-to-think-about-graphql/). 

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](http://spec.graphql.org/)
[GraphQL over HTTP](https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md)
[Introducing GraphQLinq strongly typed GraphQL queries with LINQ to GraphQL](https://www.giorgi.dev/dotnet/introducing-graphqlinq-strongly-typed-graphql-queries-with-linq-to-graphql/")
[GraphQL API with .NET 5 and Hot Chocolate](https://www.youtube.com/watch?v=HuN94qNwQmM")
[Short GraphQL example in Node.js and Express JS framework](https://www.youtube.com/watch?v=ZQL7tL2S0oQ")
[Introduction to GraphQL](https://www.youtube.com/watch?v=anW5Qpuh5kI")
[Creating a GraphQL back-end with .NET GraphQL library](https://www.youtube.com/watch?v=6duKEokTZ44")
[Getting started with GraphQL and HotChocolate](https://www.youtube.com/watch?v=Hh8L6I2BV7k)
[GraphQL schema design from the creator of HotChocolate GraphQL library](https://www.youtube.com/watch?v=1VEMqTw8xSo")
[GraphQL and ASP NET Core - .NET Oxford - November 2019](https://www.youtube.com/watch?v=q-5MUqLAEFs&amp;list=WL&amp;index=98")
[Building Modern APIs with GraphQL](https://www.youtube.com/watch?v=bRnu7xvU1_Y&amp;list=WL&amp;index=82")
[Getting started with GraphQL and HotChocolate](https://www.youtube.com/watch?v=Hh8L6I2BV7k&amp;list=WL&amp;index=84&amp;t=3s")
[GraphQL Part 2 - Setting up project](https://www.youtube.com/watch?v=XoM1zHZug68&amp;list=WL&amp;index=86&amp;t=24s")
[Beyond REST with GraphQL in .Net core - Irina Scurtu](https://www.youtube.com/watch?v=0Aqy8h0W3RQ&amp;list=WL&amp;index=86&amp;t=1460s")
[GraphQL Server with .NET Core Tutorial](https://www.youtube.com/watch?v=JiiELR_UiDo&amp;list=WL&amp;index=88&amp;t=2s")
[GraphQL Schema Design](https://www.youtube.com/watch?v=1VEMqTw8xSo&amp;list=WL&amp;index=89")
[GraphQL for dotnet developers](https://blog.jeremylikness.com/blog/graphql-for-dotnet-developers/")
[Владимир Цукур — GraphQL — API по-новому](https://www.youtube.com/watch?v=YgRmgHPTXr4&amp;list=WL&amp;index=79")
[GraphQL #0 Введение](https://www.youtube.com/watch?v=kZs7CXrtT-s&amp;list=WL&amp;index=81")
[Статьи и презентации про GraphQL](https://github.com/nodkz/conf-talks#apolloclient-%D0%B8%D0%BB%D0%B8-relay-%D1%81-%D1%84%D1%80%D0%B0%D0%B3%D0%BC%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8-%D0%B2%D0%BE%D0%BB%D0%BE%D1%81%D0%B0%D1%82%D1%8B%D0%B9-graphql-holyjs-piter-2019")
[Redux не нужен. GraphQL и Apollo Client](https://www.youtube.com/watch?v=OezyScvU9-c&amp;list=WL&amp;index=78")
[Разработка GraphQL API на ASP.NET Core // Бесплатный урок OTUS](https://www.youtube.com/watch?v=VQWkY2HpZnA&amp;list=WL&amp;index=89&amp;t=4063s)
[Apollo GraphQL with React. Полный курс](https://www.youtube.com/watch?v=GMJNSBur-lM&amp;list=WL&amp;index=81")
[Why Swagger is dead](https://github.com/nodkz/conf-talks/tree/master/articles/swagger")