GraphQL vs REST comparison - Is This Solution from Facebook Worth Taking the Risk?
If you are linked to the programming industry in any way, you have probably heard about GraphQL, a technology created by Facebook in response to real problems they faced. Some may still be sceptical about it, but others see it as an improvement on REST APIs.
In this article, I am going to show you why GraphQL is a viable solution for both new and existing applications and what its advantages are when compared to REST.
What Is GraphQL - You Have Probably Used It Today
GraphQL was kept secret for over three years. It was born as a solution to the mobile market problems that Facebook experienced in 2012 and which many companies face today.
Facebook needed an efficient way of defining complex data requirements. At that time, Facebook was looking for a solution that would prevent fetching too little or too much data or making an absurdly huge number of endpoints.
At the time of its official release to the public, GraphQL was already serving a tremendous number of requests a day.
GraphQL is a technology Facebook users have been using unknowingly, and it has already been implemented in giants like Pinterest, Coursera, Shopify or Github.
REST is Not Flexible
In a typical REST API, a new endpoint is made when data requirements change, and, additionally, the endpoint one must remain untouched. Removing old endpoints could cause unupdated apps to break. Due to this, the amount of almost identical and nearly indecipherable code might grow rapidly. This is fine for small applications which include little variety in served data, but it can be a complete nightmare for any other app. The more endpoints you have, the harder they are to maintain.
REST Will Eventually Cause Overfetching
In a perfect world, endpoints are optimised and they provide the ideal amount of data. This, however, is often not the case. Sending just the right amount of data makes loading times shorter and directly decreases the likelihood that a customer will close an app due to frustration. This should be a huge deal for most product owners and often leaves a massive amount of room for improvement in existing REST applications.
REST Has Problems with a Lack of Documentation
It is not unusual for developers to work with the code they inherited from other developers. Many applications are made to last years after their launch. Over their lifecycle, changes will be made and new programmers will be introduced to the code that already exists. A REST architecture becomes extremely difficult to maintain and understand because it grows over time.
When You Should Consider GraphQL
Many companies today face problems GraphQL is able to solve, such as: fetching only the needed piece of data, documenting APIs, making applications scalable and easy to maintain and more. Here are some arguments why implementing it should be considered.
You Can Use GraphQL to Solve Your Problems Without Changing Your Stack
You can use the existing endpoints and databases in your queries, which allows you to take advantage of GraphQL’s features on top of the existing code base. In fact, Facebook initially used GraphQL only to deliver news feeds to iOS and Android users.
GraphQL Has Only One Endpoint, Serving All the Data It Is Provided With
The front-end of your app can request any data it needs, and no additional information will be fetched. This not only prevents under- or over-fetching, but it also precludes creating countless endpoints which would be hard to document and maintain.
GraphQL Might Just Have the Best API Documentation System out There
It is strongly typed so you have the full knowledge of what your data looks like and it comes with an IDE called GraphiQL, which lets you see and query your data easily. This makes finding bugs and working with data actually easy. Just take a look at this Star Wars API made by Facebook developers:
This is GraphiQL in action. On the left, we can see what a query looks like and how it is documented. Isn’t it beautiful?
GraphQL Is Backwards Compatible
The newest versions still support code from GraphQL’s early days. Here is what one of the core creators, Lee Byron, wrote:
“Facebook's GraphQL schema (over 4-years-old, 1,000s of types at this point, and under active development by 100s of engineers) has never needed a versioned breaking change, and still supports the 4-year-old shipped versions of iOS and Android apps.”
Wrapping up
Every time a new, unoptimised endpoint is made, it generates waste, and some profit is lost. Every time a new, fancy, optimised endpoint serving a very specific use case is made, the app becomes more difficult to maintain. Technological debt may easily stop companies in their tracks for years. Every data-oriented software requires scalability, good documentation and the optimisation of endpoints.
This is unlikely to change in the near future and REST APIs aren’t always the best option. GraphQL was created to solve such problems and might just be the perfect solution for your company.
There Will Be More!
At Netguru, we are very excited to give this new, sophisticated technology a try and are currently working on some real-life solutions using it with Node.js. If you are wondering when Node.js is a suitable solution you can read our insights here. This is not our last article about GraphQL so stay tuned!
