GraphQL: the peacemaker between client and server

Managing data complexities from different sources.

in Software developmentBy Matheus Paiva, Software Engineer

Imagine that you are a rookie of the Bacon Corporation — the coolest of the coolest companies from my imaginary world. They make the hipster-est products and they want you to build a report that contains a ranking of the best consumers of their active products, ordered by consumption and grouped by region.

Challenge accepted! You ask permission to create an endpoint to deliver all the data that you will need to fetch from the Bacon web app. You already have written in your head the query that you will use to glue all of that data together with a lot of JOINs. And a bunch of mustache people starts laughing at you. You receive a big NO.

Of course, the backend of the Bacon Corporation has an API first architecture. They use microservices that do one thing and do it well. They have rules. Their backend looks nothing like a portion of spaghetti. Au contraire: all the services are solid and run smoothly as a well-oiled engine. So, no, go away with your spaghetti JOINs, they say.

They are RESTfull all the way down. And, also, they already have all of that information available and spread across their microservices. You just have to glue it together. JUST IT.

So you start building the page. You make a request to get their active products. Then you make a request to get the available regions. Then you ask for the product’s consumption statistic by region. And, after that, you take the best seller product for each region and ask for the biggest consumers for each of them.


More or less 25 requests later, you are there. Now you have all the data you need — and also a lot of data that you don’t need. You just have to glue it together. The Product People wants to know why it is taking so long to complete the task. “It is just a list of tables”, they say. And you just want to cry with all of the unnecessary complexity you got in your hands.

How did you get in that rabbit hole? And, a better question, how the hell will you get out of there?

GraphQL as a microservice orchestration solution

They said, “work smart, not hard”. The above situation is one of those where GraphQL truly shines. Having a GraphQL layer orchestrating a group of APIs can reduce from the previous 25 requests to only one with all the needed data — nothing more, nothing less.


There is no magic here. GraphQL is a query language and an implementation that works on top of HTTP. It sends and receives text using a single endpoint, passing the query as the POST payload. Simple as that. But, because of how the query language was created, it’s very practical to describe the requested data in details.

GraphQL can be seen as a “client assistant” that exists in the server side. It gives what the client asks in a very customized way. Metaphorically, suppose you have a personal assistant and you ask him to get chicken wings, a toy for your kids and a car wash. He goes out. If this personal assistant was GraphQL style, he would arrange these 3 things in one round trip and respond back to you.

Here at Hexis Technology Hub, our clients don’t pay for just another ordinary page. We exist to provide solutions to non-trivial problems, whether building smart reports or a gamified dashboard. So, it’s common for us to manage very complex front-end projects that require data access from many different sources. In those cases, not having to deal with this kind of complexity on every page is a big win.

GraphQL is graphical

The name “GraphQL” sounds like “graphical” and it’s no coincidence. When you see a GraphQL query, you will probably understand why:

In the above example, it’s visually intuitive to understand what is being requested. We want to retrieve a list of 10 articles, but only some properties — title, content, date of publication, author and comments. From the author of each article, we want to get the name, e-mail and the title of the last 3 articles. From the comments, we want the content and the author’s name and e-mail.

You don’t need to be an expert to surf on that query. And that query is all the client needs to receive the information at once and in that custom shape. With a little help of libraries like Apollo GraphQL, the client will be spared of hundreds and hundreds of lines. Sure you can say that these lines were spent implementing the GraphQL server. But later, when you decide to create a new client (or a second page), that bad complexity will be already resolved for a lot of cases. And resolving complexity is not the only benefit of using GraphQL in this situation.

GraphQL will boost your performance

I said that, with GraphQL, the Bacon report would reduce from 25 requests to only one, and that’s true. But you can argue that the API will yet receive 25 requests, only that this time the GraphQL server is making the requests. Indeed. But let’s imagine that all the server are running under the same network. The requests are not traveling from Germany to Japan 25 times. One request will travel from Germany to Japan, then all the 25 requests will travel internally. And that can represent a big gain of performance.

GraphQL is client first

The Bacon back-end team has nothing to worry about. The “API first” approach is not contrary to the GraphQL existence and the corporation will keep following this guideline. It’s the GraphQL’s job to create fluid communication between the APIs and the clients. Lee Byron, one of the creators of GraphQL, talked about the “client first” mindset necessary when creating a GraphQL server.

Thinking graphs is nothing like thinking resources. Resources are linear and have a very limited scope. Graphs, on the other hand, are like neurons. The information is always relative. The same data should be accessed from lots of point of view. As an exercise when creating a future-proof GraphQL structure, draw it down and see if it looks like a network.

To sum up

The Bacon Corporation is very happy with you!

  • The customers are happy because the web app is faster than ever;
  • The managers are happy because you are delivering value faster than ever;
  • The company is happy because you added a cool and trendy tech to its stack;
  • You are happy because you have time to work smart, not hard.

You go home and enjoy the sense of accomplishment. :)

Powered by ChronoForms -

Get in touch