GraphQL is becoming more and more popular, and its supporters are promoting it as a tool to solve all the problems that arise when working with REST APIs. In this new article, we are looking into what is really behind their comparison, whether it is urgent to replace REST with GraphQL and how to find a brainy approach when choosing a front-to-back communication architecture.
Graphql. Tom, Web-developer:
What is GraphQL
GraphQL is a graph query language that began to be used internally by a large company in 2012; in 2015 it was introduced to the developer community, and since 2018 has been under the wing of the Linux Foundation.
Unlike the REST API, where the /users entry point returns users with a predetermined set of fields, GraphQL allows the client to define the set of data it needs. For example, the query user { name age } will return only the user’s name and age.
Within GraphQL, several new terms appear that were not there when working with the REST API:
- mutation – requests to change and add data;
- resolver – the function of accessing a data source, such as a database;
- scheme – a typified description of the data source or, in other words, the structure of the response;
- subscription – a way to automatically update data from the server.
Despite its growing popularity, GraphQL advocates do not promote it as a replacement for REST but rather as an addition to existing capabilities, as it has advantages that, when using REST, can be “more expensive” to develop.
Advantages of GraphQL
As the authors and supporters of the language say, and what I saw, the main advantages of GraphQL over the classic REST API are that it:
- Works not only over the HTTP protocol but also over Websockets, SSH and many others.
- Instead of several endpoints, it refers to one through which all requests pass – /graphql.
- Strongly typified – the response scheme describes the type of each field and its mandatory nature in the request.
- Provides a built-in platform for testing and debugging queries – graphiql.
- Fewer steps to describe resources – just describe the dependency diagram – and you already have queries users {}, user (:id) {} and user (:id) { posts {} }.
- Provides the ability to pass arguments to the request at any level of nesting – user(:id) { posts {} } and user(:id) { posts(type: “draft”) {} }.
But the most important thing is that GraphQL is very flexible in how it works. You can query both “users with their posts” and “users and posts” – and this is within the same request. This solves the REST-specific problem of asking users first, then posts, then comments.
Disadvantages of GraphQL
If we talk about the inconvenience, then the first thing that comes to mind is the frequently used query “return all fields”.
“I don’t want to write field descriptions users {name surname age phone address}, I want users { * }” – in response, GraphQL modestly says “create fragment AllFileds on User {name surname age phone address} and call Users { … AllFileds }””. This immediately brings us back to where it all began – “what fields are we going to return in /users?”.
The second inconvenience for me as a person working with Laravel is the repeated description of the model. I have already implemented a model that describes which fields to return and what data type they have. Why should I do the same again?
The third inconvenience is the toolkit. The graphql-%language_name% standard library does not provide the ability to work with .gql and .shema files – all this must be written through the primitive structures of the language.
Want something more comfortable? Describe schema via type User {id: ID name: String}? Syntax highlighting and jump to schema definition? Put a wrapper specific to the library/framework.
Conclusion
In general, GraphQL is convenient, and I’m even in favor of using it, but on business. It reduces getting data to a single request through a single “give it all” endpoint; it is strongly typed – and no “false” strings in the default boolean field; a great debugging tool that knows everything about the data schema. From the point of view of changing the paradigm of communication with the backend – why not?
Rest Api. George, Web-developer:
What is REST API
REST (Representational State Transfer) is an architectural style of interaction between application components, most often client and server. The term itself was proposed in 2000 by Roy Fielding, one of the creators of the HTTP protocol. There was a set of only six restrictions and requirements:
- Architecture “Client-Server”;
- Statelessness, i.e. request autonomy;
- Requirements for interface uniformity (permanence, manageability through views, work with self-sufficient messages and work through hypermedia);
- Layer system, that is, the division of the system into a hierarchy of layers with the condition that each component can see only the components of the child layer;
- Code on demand;
- Caching.
GraphQL, on the other hand, is an API query language that was developed by one of the large companies to solve their problems: simplifying work with large amounts of data. But, in the end, it was luckyto see the light and become popular.
From all above mentioned, it turns out that comparing these two terms is as pointless as comparing any style and language (oh, wait). But, fortunately or unfortunately, the far-fetched opposition of REST vs. GQL has flowed into the plane of confrontation between the supporters of the “server-first” and “client-first” approaches.
Advantages of REST API
First, REST works with definitions that are intuitive to any programmer, such as a request method or a response code. Yes, for this you need to know things like http codes, their classification and types of responses. But knowing this, you can program the behavior of your application without having to parse the response.
Let’s talk separately about working with http codes. According to the agreements that the architecture developers came to, the server response is always additionally accompanied by a code: 200 – everything is fine, 300 – redirect, 401 – authorization is needed, and so on. That is, REST always returns a response, accompanied by a code that can be used to determine what to do next. And on any system, you can write one always working driver to work with http codes. In GraphQL, we lose the possibility of such beautiful error handling.
Secondly, REST makes it very easy to cache requests. This allows you to partially or completely eliminate some of the interactions between the client and the server and improve system performance.
And in most cases, the REST functionality will be enough. The thing is, you need to distinguish between such concepts as “Public API” and just “API”. Often, front-end developers write a client for an API service that will be the only recipient of data. In this case, GraphQL is redundant. The user wants to see certain functionality by clicking on a certain button, and the rest is of no interest.
In addition, REST does not restrict various “add-ons” above itself in any way, including specifying the fields parameter to GET requests (which will give us only those fields that we need) or the relations parameter. To be fair, this can be tricky. For example, in caching.
And no one forbids to slightly deviate from the REST principle in the usual sense, and facilitate it by using verbs in the URL or a different response format in the resources. For example, if we have users who have articles, the URL should be: user/id/1/articles. In the current understanding of REST, each such entity should have 6 specifications: get, update, delete, and so on. If you want to have additional filtering or modification of the response, no one prevents you from having a so-called verb and, accordingly, getting a URL: /users/1/atriclesWithComments
In fact, there are many examples of using the REST approach. These are all modern browsers, YouTube, Reddit and my favorite game Eve Online with an API for third-party applications, and their resources cover the wishes of third-party developers as much as possible.
Disadvantages of REST API
A big problem with the REST API is the inability to specify the response format in the request.
There are two downsides here. Firstly, you cannot specify only those fields that the frontend needs. We always get all the information, which makes the data set that is chasing between the client and the server heavier.
Secondly, you can not specify the desired links to the desired level. That is, if we need a complete breakdown about a user, we write requests: “Give users, give articles, give the number of comments on each article.” But in this way, some mistakes are avoided. For example, when working with GraphQL, this needs to be monitored: the public API is public, that by specifying links, you can request such a selection that it is easier for the server to return a 504 error than to try to do it.
Also, in basic REST, all users are traversed manually via GET /users/, GET /users/1, GET /users/2 … GET /users/N. Using GraphQL solves the problem of N + 1 queries.
Conclusion.
Thus, if you know its functionality and use it, the REST approach in most cases covers all the needs in application development. Both GraphQL and REST can only compete on public API issues. So, learn how to competently build an application, do not chase the hype and be smart about choosing tools.
