Find out the differences between GraphQL and REST
GraphQL has recently stood out in the world of web architecture. Since its release in 2015 and the subsequent creation of a foundation with the same name, this query language has gained ground by overcoming the most common limitations of the REST protocol when communicating data.
GraphQL today emerges as a new way to address all the operations you can perform through REST but is even more efficient. It enables better communication between systems and helps companies maintain the flexibility needed to adapt to the accelerated changes from the client-side.
REST: even great ideas get old
We regularly use REST APIs to tie functionality to the interface when working with web architecture. We love the ease with which REST allows systems and software to communicate with each other to achieve, for example, a quality digital experience.
Unfortunately, REST has been overtaken by the changes and demands in the client-side requirements. It does not let to optimize the information selection and transfer, which generates the problems of over-fetching and under-fetching.
In other words, in your query, you get more or less of the requested data, generating additional queries to obtain the required information and unnecessary use of the client's bandwidth, preventing an optimal performance of the platform on slow connections.
What is REST?
When we talk about REST, we refer to RESTful API, an architecture that defines the integration protocols between systems and application software. REST is the acronym for Representational State Transfer. In simple terms, it means that when a client (site or app) sends a request via a REST API, the response represents the state of the requested object (data).
The latter implies that the response is stateless; it is not recorded, meaning that each call response is unique and is not remembered in subsequent calls. The client must enter the information in each request and where it would be common to receive the data in JSON format.
In addition, for REST queries, each entity or data type requires its own entry point. What on a small scale is quite practical, for large corporate sites becomes a complex extension of data access points, partly the reason for the problems already mentioned.
REST issues
Let's take a look at each of the drawbacks mentioned above:
- Over-fetching: refers to when the result of a query contains more information than requested, which does not prevent the query from being satisfied but implies a higher memory and data consumption at the time of execution.
- Under-fetching: is the opposite situation, when the answer to a query contains less information than requested, for example, if we asked for the best books of 2021 and obtained a list of titles but without their authors.
What is GraphQL?
GraphQL is a query language for APIs, and it provides a middleware that allows handling complete server-side requests. It bases its operation on data schemas that are constructed beforehand using the "GraphQL Schema Definition Language," which is the syntax that defines types, fields, and relations between them.
Figuratively speaking, data schemas are the contracts between clients (app, mobile, etc.) and servers. They define how a client accesses data, adapting the response to the client's specific requirements.
We know it sounds very similar to SQL and its relationship with databases, but GraphQL does not depend on databases; its goal is to communicate clients with servers. Moreover, GraphQL has only one entry point which executes all queries.
Thus, being based on data schemas, it does not require an entry point for each entity, which solves the REST problem about over-fetching and under-fetching since the queries executed are answered according to the requirements.
Commonalities with REST
GraphQL is gaining ground over REST because it also shares commonalities:
- Let's start with the aforementioned stateless condition.
- Both share their polyglot status concerning the backend language. They are also highly compatible with different frontend frameworks, which explains why they are such popular alternatives in web architecture.
- As already mentioned, GraphQL has a single entry point for queries, unlike REST which has an entry point for each category.
- The POST method executes each query, so we forget about DELETE, GET or PUT. The queries are rather a description of what you want to get as a response.
Differences with REST
The main differences that make GraphQL a good alternative, especially for large platforms, are:
Greater autonomy in your team and better information management
All these similarities and differences derive in operational terms that internally the frontend and backend teams will work autonomously from each other since they both know the data structure previously defined in the schema. On the other hand, GraphQL does not need to adjust the APIs every time the product or design requirements change.
In GraphQL, there are functions called "resolvers" that take care of populating a field's data in your schema. Whenever a client queries for a particular field, the resolver gets the requested data from the appropriate source. This allows delivering more and better information from the backend, improving the analysis of digital interactions, and identifying bottlenecks or low points that impact conversions.
At Reign, since we met GraphQL, we have sought to bring this technology to large companies because it allows focusing on the development of APIs tailored to each one, streamlining the development, and facilitating the work within the teams.