Why you should use GraphQL

GraphQL is one of those technologies that you see everywhere. Everyone is talking about how it’s the next greatest thing, it's going to take over the world. I’m here to tell you that it will, here at Our Very Own we used it both in a project from the start and as a gateway to a mobile application. In both instances it was a great choice, not only did we return only what was needed but we also kept everything consistent and clean. Once the initial hurdle of adoption was overcome, the frontend developers loved it. With one endpoint they could call different “functions” and get back as little or as much data as they wanted.

Project from scratch

We started a brand new project January of 2018, we decided to use GraphQL to really test out the hype, it also helped that we had a team of fresh graduates so they had little experience with alternatives such as REST, so it didn’t matter what we used, there was going to be a learning curve. With this in mind we took the leap, plunging head first into the world of GraphQL. The GraphQL documentation is quite fantastic, it has clear, easy to read documentation and best of all it uses Starwars in its examples. Simply reading through their guides will give you a great understanding of how the technology works, with this reading we were able to get a working demo returning a few items in a list.

On the backend side we used Elixir and their implementation of GraphQL, Absinthe. On the opposite end of the spectrum, Absinthe didn’t have as good documentation, but then again they don’t have Facebook behind them. Once we had a good grasp of both the core concepts of GraphQL and the Elixir implementation we were ready to create our first query. We decided to return a list of items as this is the easiest test.

Success, we can return a list of items. With this first step in the bag it became a matter of incrementally trying things and seeing what breaks until things work (like most programming when you first start). It’s mostly smooth sailing until you get to very complex queries. One of the core features of GraphQL is it’s ability to get as much or as little data as you want, this often requires you to traverse the graph, with each traversal you’re calling another query, often this leads to an N + 1 problem. It becomes slower and slower the more items you have. This very quickly becomes a problem, to fix this you need a handy GraphQL feature called dataloader. With dataloader you can batch up the queries into one database hit. You turn a list of items, where each item then returns a child item into two database calls. This reduces the number of calls from N + 1 to 1 + 1. The first call will get each item, then the second call will bulk grab each child item of each item from the first list. This fixes the N + 1 problem that quickly turns into quite a headache.

Existing project

You don’t always have the luxury of starting a project from scratch, or maybe you’re talking to a few third party REST clients. In this case you really don’t have control of what they send, or do you? No you don’t, but you can fake it for the frontend. We had a project that didn’t that we needed to talk to a bunch of different third party APIs, REST clients. We needed to build a mobile application and as you probably know bandwidth can often be at a premium on a mobile device. With this in mind it became import that we reduce the data sent to the device. In comes GraphQL on it’s shiny steed, we created an Elixir gateway that would sit in front of each of the third party libraries that we built for each one of the REST clients. Each REST client would have its own library that would call the endpoint. The gateway would then call that library and the frontend would then call the gateway, only grabbing what it wanted. This simple method meant that the frontend only ever saw one endpoint, yet it was talking to multiple REST clients. The frontend didn’t even know that it was talking to a REST client at all, all it thought was “Thanks for the data”. This architecture allowed us to bypass the limitations for the most part with REST and replace them with the benefits of GraphQL.

What we learned

We learnt that GraphQL is a far superior technology than that of REST. However, good luck trying to shoehorn GraphQL into a production system after the fact. We realise that not everyone has the luxury of using GraphQL but if you do, you’re going to have a great time. Yet if you get the opportunity to use it in a new project or you need to tie together a bunch of third party services then you should strongly consider using GraphQL. The biggest benefit for us hasn’t been on the backend side, but the frontend. The frontend developers have really enjoyed having an easy and consistent way of calling data. It allowed us to create a generic call for the frontend and then allow them to pick and choose what they needed, how complex it needed to be, meaning we didn’t have to write another call if they wanted a child item of a parent, they could just call it. This cut down our development time tremendously, we could write the code for each table ie. authors and blog_posts, then with a few lines we could stitch them together and you could get authors and then all the blog posts they have written.

We started with no prior knowledge of GraphQL and after one year, we couldn’t think of using any other technology. It solves so many issues, it's easy for newcomers to pick up and the documentation uses Star Wars examples. It really is a fantastic language and I strongly recommend using it for your next project or to uplift an existing one.