Introduction
The 2 main forms of design and interaction we use in modern API development are REST and GraphQL.
In most cases, developers start their API development career by creating a REST API, but later, as they get down to the details of the issue, it becomes clear that the REST API approach is not the ideal approach for all cases. GrahpQL takes us out of the situation where REST is ineffective.
PS: If you want to dive into the details of REST, read this article.
Although GraphQL was first used in production by Facebook in 2012 (under the name SuperGraph), it was made open-source only in 2016.
GraphQL is currently the most popular approach for API development design and interaction with REST.
Why was GraphQL created?
One of the main reasons for the need for GraphQL was to avoid the problems that arise when mobile versions of applications use the same API (REST API) as the desktop version.
So imagine that there is a mobile version of a website you use. Because the desktop version can process more data, it receives more data from the server.
Below is an example of REST Response, which is "too big" for mobile requirements, and we need only part of the information.
{
"user": {
"id": 5,
"name": "Yakumo",
"surname": "Mutsu",
"rank": 56,
"email": "[email protected]",
"profilephoto": "....................."
}
}
However, when the user data is loaded for the first time, we need only a part of this data in the mobile version. On the other hand, the resource-based distribution of those data (REST) seems to be an ideal choice for design. Since there is almost no internet problem in the desktop version, it does not cause any problem with receiving data from different resources and displaying them as a single piece of information. First, after the user data is loaded, we load other data based on his id. That is, we conduct a kind of synchronous operation.
But what we are talking about is not a perfect choice for mobile versions. For mobile versions, either a different API should be created or a less and more dynamic resource acquisition by adopting a different approach than REST.
What is GraphQL?
GraphQL allows us to provide a more efficient API interaction and design process with mobile and other low-resource devices in mind. Although it was mainly designed for mobile devices, it is used in modern days for more dynamic, effective information exchange. Unlike the classic REST API design using GraphQL, if you need to get information from several resources, it is possible to do this synchronously on a single query basis, not resource by resource.
GraphQL is now widely used in microservice design as well.
REST vs GraphQL
- The REST API design form we use is usually intended for desktop devices. In most cases, mobile versions require a lightweight, less resource-intensive version of the same endpoint. In this case, using GraphQL, we can get only the necessary data according to the mobile's requirement. (reducing over-fetching and under-fetching)
- REST usually has a resource-oriented design. When a resource projection is needed, the parent resource must be obtained first, and then other child resources must be called. This is a kind of synchronous and delayed calling because you cannot get information about a dependent resource without loading one main resource (multiple endpoints, multiple requests).
- REST usually returns a single static data per endpoint. However, even if we apply to only one endpoint using GrahpQL, we can retrieve different data structures. (Flexible data retrieval)
- To get information from several resources in REST, you have to request those resources separately. This often leads to late data acquisition when some techniques are not used. GrahpQL allows us to obtain information from several resources with just one request and present it to the user as a single piece of information. (Reduced number of requests)
- Changes in REST design are accompanied by versioning. GraphQL overcomes the problem of versioning and allows you to make additions more conveniently without making changes on the other side.
- Unlike REST, GraphQL has an architecture designed for the mobile and front end. Thus, by getting only the data we need and overcoming the resource-oriented design problem, the payload size and the number of requests are reduced.
- In more dynamically changing API designs, REST is not a good choice. Because it has a static structure. Depending on the situation, for example, the same endpoint receiving several arguments or returning several different structures is not suitable for REST, but GraphQL solves this problem.
- In the Microservice architecture, each service is responsible for its resources, and GrahpQL is a good choice when receiving information from several services and displaying them as a single resource.
- When developing a single-page or native mobile app, GrahpQL's principle of "give only the information the user needs" and "there is a resource, not resources" allows us to develop frontend-heavy applications.
- Fast iteration – Frontned works on its own User story without depending on the backend; it does not wait for the backend to prepare a REST endpoint
Verb operations such as PUT, DELETE, POST, and PATCH in REST design are simply called Mutation in GrahpQL.
GET in REST API is called Query in GraphQL.
Starting from the next article, we will dive into the practical details of using GraphQL.