GraphQL: the peacemaker between client and server

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.

Source: https://blog.logrocket.com/the-increasing-nature-of-frontend-complexity-b73c784c09ae

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.

Source: https://blog.apollographql.com/how-do-i-graphql-2fcabfc94a01

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.