Should I use GraphQL or REST in 2022?

7 min readApr 23, 2022

With Graphql’s growing community, I have increasingly been asked why it is so popular and why We would want to pick GraphQL or REST over the other. This is not a simple question. So to answer this, we should start by understanding what they are all about.

What is REST API?

REST (representational state transfer) was developed by Roy Fielding in 2000 and open-sourced in 2015. It is an architectural style for an API that uses HTTP requests to access and use data. It is the most used architecture style and can be found in many large companies including Amazon, Google, Linkedin, and many more.

It is Stateless meaning that it doesn’t require any knowledge of the client's state to correctly interpret the request. all of the necessary information is included in the request itself.

It usually fetches JSON data and is available to any server-side language and any frontend framework.

In REST you have to provide the right HTTP verb to a valid endpoint containing a valid body.

HTTP Verb

With REST API you will first have to define your HTTP verb, which is where you define the type of operation that will perform. the HTTP verb would be either POST, GET, PUT, PATCH, or DELETE, corresponding to the CRUD operations.

Path

The path is an endpoint, which is a communication channel containing a specific protocol. The path would commonly look like this: /api/users and /api/users/:id .

Body

In REST we don’t use the body in the GET request. But for all other requests, we use it to define what the data should look like.

What is GraphQL?

GraphQL (Graph Query Language) is developed by Facebook in 2012 and open-sourced in 2015. It is used widely used by many companies including meta (Facebook / Instagram), Github, Twitter, and over 1700 other companies.

It was designed to make APIs fast, flexible, and developer-friendly. And just like REST, it is both stateless, available to any frontend framework and any server-side language, and usually fetches JSON data.

But where GraphQL becomes very unique, is its way of communicating with the front end…

HTTP Verb & Path

In Graphql the HTTP verb is always POST, and it only has one endpoint, which most people set to be /graphql .

Body

The body in GraphQL is where you define your operation and its parameters. In GraphQL there are 3 operations:

query: fetching data
mutation: manipulating data
subscription: subscribing to a WebSocket

The interesting part about GraphQL is its hierarchical nature.

The interesting part about GraphQL is, how you on the front end choose what data you want to receive, in a hierarchical structure. Sending parameters with your request is also different since you define their types in GraphQL. Below you can see an example of a query request from the front end, to a GraphQL API:

What GraphQL does better

Data fetching control is one of the core benefits of GraphQL. This increased fetching control prevents over-fetching because the frontend developers can specify only the data they need. At the same time, it also prevents under-fetching, because you can fetch all relevant data in a single query.

A single API call, allows you to request multiple resources. this minimizes both time and bandwidth by reducing the number of network round trips to the server. It also helps to prevent waterfall network requests, where you are dependent on the result of one call, to create another.

The customizable response makes it a great benefit to the front end of the application. This involves the ability to define an alias for fields and resolve each of the values into different values.GraphQL also provides the opportunity for schema stitching which allows you to combine multiple, different schemas into a single schema.

GraphQL brings the front end and back end closer together, better than any other architecture. It is self-documenting — with the provided playground, the front-end developers can quickly explore the API and the shape/type of the individual components. By matching this with the front-end developers' ability to generate a query matching their requirements, the development team will become less prone to communication errors.

Versioning is Not Required like it is in REST architecture. in REST, developers create new versions (e.g. api.domain.com/v1/, api.domain.com/v2/) due to changes in the protocol. In GraphQL you can add new fields and deprecate older fields, where the client will receive a deprecation warning when querying a deprecated field.

It is easily modifiable. Graphql exposes a single endpoint that allows you to access many resources. If your UI changes and will require either more or less data — it doesn’t have an impact on the server, because you can shape the query on the frontend. This makes it much faster to perform changes on existing projects.

What REST does better

One of the most common complications with GraphQL is its abnormal client-side architecture which is super dissimilar to the REST architecture. REST is still the leading architecture and most developers know it inside out.

REST has many build-in features, that make it super easy to implement a simplified cache, file upload, or even a rate limitation per API key. Whereas you will need to work with third-party libraries to enable these features in GraphQL.

Rest is still a better choice for Complex queries. GraphQLs nested architecture can turn into a bottleneck when creating complex queries. Because you can end up having to create very deeply nested queries with a lot of recursions.

Although GraphQL is strongly typed it is still easier to create good error handling in RESTful APIs. GraphQL always returns the 200 Ok status for every API request, including those with errors. This makes it difficult to manage errors and makes it hard to integrate monitoring tools.

REST has libraries that can inherit the GrahQL architecture. Some developers don’t know this, but there are libraries out there like “JSON schemas” where you can achieve the controlled fetching functionality as seen in the example below:

GET /books/1492030716?fields=title,pageCount

Direct comparison

Which should I use?

First of all, I strongly encourage you to get familiar with both. Because they are currently the two most common architectures in the industry and chances are high that you will run into both of them at some point.

If you need to choose one of them for your project, the common recommendation is to stick with REST except if you are developing:

Apps for devices where bandwidth usage matters, such as mobile phones, smartwatches, and IoT devices.
Applications where nested data needs to be fetched in a single call, like a social networking platform.

But Graphql has improved and got more libraries solving almost all the previous concerns. So the general approach listed above is pretty outdated in my opinion.

The only large complexity left in GraphQL, with no library to solve it yet, is the deep nesting and recursion in complex quires. But as long as your application won't require any super complex fetches and you use GraphQL correctly, I strongly encourage you to obtain the many benefits of using GraphQL in your project.

Be free to leave any constructive criticism if you have any, and if you liked this article don’t hesitate to share or follow, to stay updated on the latest Software engineering advice.

Links

https://www.contentstack.com/blog/tech-talk/why-and-when-to-use-graphql/

https://strapi.io/blog/graph-ql-vs-rest-how-to-make-the-right-choice

https://blog.logrocket.com/why-you-shouldnt-use-graphql/