REST a robust, 20 years old standard, but 20 years is long in our industry.

REST architecture is a simple way for clients and servers to interact with each other. REST was a great solution when it was first presented, but there are some pretty significant issues that it suffers from now.

A REST API is one that uses the model of Representational State Transfer. By using REST APIs, instead of creating remote procedure calls and remote method invocations, an application can be developed in relative freedom from any specific communication protocol and any specific message syntax and semantics.

Since 2000 when REST was first proposed, many things have changed.

REST turn 21 years old, he can be drunk now ;)

The problem with REST API is that it often represents the UI or web service. It is not enough just to call the service and return data. Anytime there is a need for secondary operations, like additional filtering or processing, we have to build another service (or update the old one). This problem becomes even more evident when working with big data or microservices architecture.

REST APIs are supposed to be simple, that’s part of the definition. Any API that thinks it needs to have description, parameters, payload, or other things in your call is just not a REST API.

So why GraphQL, open-sourced 5 years ago, stands out?

GraphQL is a query language that has the potential to be a game-changer for application development. For me, GraphQL queries represent a new way to build client-server applications, it’s a new language for APIs.

When you call your API endpoint in your frontend application you get a concrete response with the expected type. You are sure that the list of users for example has correctly typed fields and all the other types (like createdAt or friends) are also properly filled with data. You don’t have to write any type validation code.

A GraphQL Query is mirrored to it’s response.

GraphQL was developed in 2012 by Facebook engineers as an alternative to REST. It allows a client application that is requesting data from, for example, an API to ask for the data it needs without having to know ahead of time what the server is going to return. This makes GraphQL great because if a client wants just one piece of information, they can get it without wasting bandwidth and server resources.

This makes applications much more intuitive as developers no longer have their clients downloading data that they don’t need. This is especially relevant if we estimate that most of our clients will only need 10% of the whole dataset.

Finally, schema stitching is a technique that allows you to access multiple different APIs using a single GraphQL API. It is one of the key techniques for implementing the so-called Backend for Frontends architecture where the implementation of the server-side logic is abstracted from the frontend using a GraphQL API.

Query many data sources within a single request.

We have been working on the GraphQL schema stitching feature for some time at GraphQL Portal — it represents a significant improvement in how we can model APIs schemas.

If you want to learn how to convert REST to GraphQL or how to stitch several REST APIs into one GraphQL endpoint, read this article.

Is GraphQL The End of REST APIs?

There is no longer a debate about the supremacy of REST Vs GraphQL. GraphQL has emerged as a new technology that will change the way we build internal and external APIs

The creation of GraphQL Specification gives developers the freedom to work the way they like, together with more flexibility, reduced complexity, and better communication between components.

GraphQL development eliminates the challenges posed by multiple endpoints and ad hoc datasets. It creates one clear endpoint, simplifying how clients interact with the server and reducing the number of roundtrips required to fetch the data. This is innovative, flexible, extensible, and easy to use.

With GraphQL server, developers can create super-specific APIs and apps without having to worry about what’s going on behind the scenes. Plus, GraphQL eliminates any need for multiple APIs. It has been proven to reduce the total number of requests in an API from 200 per page load, down to just 3!

GraphQL gives you the capabilities to build your application and business in a more structured way, improve performance, implement your client-side requirements in an efficient way and help you migrate from REST API to GraphQL.

Developers will love GraphQL since it makes the code more readable and the development process faster and more effective.

GraphQL Portal makes it easy for you to get started with GraphQL.

Which companies use GraphQL?

Today there are more and more companies taking a closer look at GraphQL as a way to expose data on their website. Just to name a few companies; Shopify, Facebook, WordPress, Github, and Pinterest have all embraced GraphQL.

Why GraphQL could be a bad idea for your project?

Can GraphQL replace a REST API in all cases? No!

The use of GraphQL in Small Applications is not recommended. If you end up using GraphQL, REST is a better option because it’s more simple and predictable.

When you know certain URLs will be requested often, consider caching these in a web cache or CDN. Since a REST API provides many endpoints, you can easily configure a web cache to match certain URL patterns, HTTP methods, or specific resources.