A short excursion into GraphQL
It is a short excursion into the query language GraphQL that will serve you book Alex Banks and Eva Porcello, which we gave in a couple of days ago. The book of the same authors is about React and Redux became a real bestseller (we are waiting for the 5th edition from the printing house). By the way, thanks to all who pointed us to the inaccuracy in the code and terms;) we made the book on such rapidly aging technology unnecessarily fast.
The author of today's article Robin Viruh also works on a book about GraphQL and libraries for this language, and in this article briefly explains the merits and characteristics of GraphQL as an alternative to REST
Shopify  
T he New York Times
When Facebook developed GraphQL and provided it in open access, other companies that created mobile applications also faced similar problems. This is how Netflix created the Falcor project, which can be considered an alternative to GraphQL. That once again confirms that for modern applications it is necessary exactly such solutions as GraphQL and Falcor.
A single source of truth
In GraphQL applications, there is a truth in the last instance: this is the GraphQL schema. It is the central source in which all the available data are described. While the GraphQL schema is usually defined on the server side, clients can read (query) and write (modify) data based on this schema. Thus, the server application, in essence, provides the exhaustive information available on the server, and the client side requests only what is required, by formulating requests for GraphQL, or modifies small information fragments, using changes to GraphQL.
GraphQL follows the current trends
GraphQL follows the current trends in creating applications. You can have only one application on the backend, but often it happens that this backend is used by many different clients (web client, mobile device, smart clock ) and all of them depend on the data stored in the backend application. Therefore, GraphQL can help not only to "make up both worlds", but also to meet the requirements of each client (connected, for example, using a network, nested data relationships, sampling only the required data) without having to create a dedicated API for each type of client.
On the other hand, on the server, we can not expect a single internal interface, but a group of microservices, each of which provides its own specific functionality. It is for this case that the GraphQL schema is ideally suited, the structure of which is such that you can aggregate all possible functionality in such a GraphQL scheme.
How is the GraphQL scheme stitched together.
Thanks to the stitching, one can be assembled from many others. When can I get into this situation? Suppose your backend is implemented using a micro-service architecture. Each microservice processes business logic and data relevant to a particular subject area. Therefore, each microservice can define its own GraphQL schema. After that it will be necessary to sew them together to collect from all schemes one, to which the client application will address. In the end, each micro service can have its own terminal GraphQL, and one Gateway GraphQL API will consolidate all the schemes into one global one to provide it to client applications.
The introspection of GraphQL is the ability to extract the GraphQL schema from the GraphQL API. Because the schema contains all information about all the data available through the GraphQL API, it can be used with great success for automatic generation of API documentation. However, the matter is not limited to documenting the API; Introspection can also be used to simulate a GraphQL schema on a client application (for testing purposes) or to extract schemes from multiple microservices and then cross-link these schemes.
GraphQL is a strongly typed query language written in the expressive schema definition language (SDL) for GraphQL. This language has the same merits as any strongly typed programming language. It is less error prone, allows validation at compile time and allows for integration with supported IDE /editor capabilities, such as autocompletion and input support.
In GraphQL, there are no API versions that we are used to in REST. In REST, it is normal to offer multiple versions of the same API (eg api.domain.com/v1/, api.domain.com/v2/), because resources or their structure may change over time. In GraphQL, you can translate the API into non-recommended fields. Therefore, the client receives a warning when he refers to a non-recommended field. After a while, the non-recommended field can be excluded from the scheme, then no more clients will use it. Thus, the GraphQL API can be developed without the need for versioning.
The growing ecosystem GraphQL
Ecosystem GraphQL is growing. It's not just about integrations with editors and IDEs related to the strongly typed nature of GraphQL; For GraphQL, as such, new full-fledged applications appear. For example, you can remember Postman, used when working with REST API, and now for the same purpose, but with GraphQL API, you use GraphiQL or GraphQL Playground. Also for you there are various libraries, for example, Gatsby.js, the generator of static websites for React, using GraphQL. For example, Gatsby.js allows you to write a blog engine that fills your blog with content during assembly through the GraphQL API. Therefore, you will also have CMS without the client part (eg, GraphCMS) that provide content (for the blog) via GraphQL. API. However, in this area not only technological components develop. Like mushrooms after the rain, conferences, mitapes and communities dedicated to GraphQL are growing, and it's also easy to find newsletters and podcasts on it.
If I turn to GraphQL, I go all-in?
Adding GraphQL to the existing technological stack, we certainly do not go all-in. Migrating from a monolithic backend application to the micro-service architecture, the very thing is to substitute the GraphQL API for newly mikroservices. After all, in the presence of many micro services, you and your team can safely embed the GraphQL gateway, stitching out the schemes and consolidating them into one global scheme. But the API gateway can be used not only with micro services, but also with a monolithic REST-application. This is how you can combine all your APIs on one gateway and migrate to GraphQL step by step.
Disadvantages of GraphQL
Next, we discuss some of the drawbacks associated with using GraphQL.
The complexity of GraphQL queries.
Sometimes GraphQL is used incorrectly, I try to replace it with a database on the server side. No, that will not do. GraphQL is simply a query language. When the request is to be resolved on the server side, there is usually a graphical implementation independent of GraphQL that provides access to the database. GraphQL in this case is indifferent. Moreover, GraphQL does not eliminate any bottlenecks with performance when you need to access one set of fields in one query (authors, articles, comments). Regardless of the architecture in which the request was made - RESTful or GraphQL, you still need to extract various fields from the source.
Thus, we will have a problem if the client sends a bunch of queries to many nested fields at once. Often, the developers of the client do not know how many different requests to the database have to be processed in the server application, if mass calls to the data begin. It is for such cases that a mechanism is needed (for example, the maximum depth of queries, the weighting of query complexity, the avoidance of recursion, persistent queries) to prevent the flow of too-expensive requests from the client.
The speed limit in GraphQL
Another problem is the speed limit. Whereas in REST it's relatively easy to say "no more than as many requests per day are allowed", it is difficult to formulate such an instruction for certain GraphQL operations, since there are not only "costly" and "non-waste" operations here, but also many intermediate gradations. It is for such cases of the company, providing public APIs GraphQL offer their own calculations for limiting the speed , often reducible to the above-mentioned maximum depths of queries and weighting the complexity of queries.
When working with GraphQL, the implementation of the simplified cache is much more complicated than in REST. Working with REST, we access resources by URL and, therefore, can organize caching at the resource level, since the resource URL can serve as its identifier. In GraphQL, this becomes more complicated, since all queries can be different, even though all operate on the same object. In one request you can request the author's name, and in the next - not only the author's name, but also the email address of the author. It is for such cases that you will need a more filigree cache at the field level, and it is not so easy to implement it. However, most libraries built on top of GraphQL offer such caching mechanisms directly out of the box.
Why not REST?
GraphQL is an alternative to the widespread REST architecture that connects client and server applications. Above, we repeatedly mentioned REST - so what are the obvious benefits of GraphQL, for which it is better to prefer REST?
Because REST provides URLs for each resource, we often get inefficient cascading queries. First, we select the "author" object identified by id, and then select all articles of this author marked with its id. In GraphQL, all this can be done in just one query, and in this respect it is much more efficient. Moreover, if you want to select all the author's articles, and do not touch the author information, then GraphQL allows you to isolate only those information fragments that you need.
Modern client applications are not designed to work with server applications, arranged on the principle of REST. Take for example the search result on the Airbnb platform. You are brought home, impressions of them and other related resources. The houses and impressions themselves will be REST-resources, so in the REST-architecture you will need to perform many queries on the network. If you, on the other hand, have a GraphQL API, all entities can be requested in one GraphQL query, matching them side by side (for example, at home and impressions), or as nested relationships (eg, articles from authors).
In the end, GraphQL shifts the emphasis towards the client; Now the client specifies what data it needs, and not the client indicates which information will be transmitted in the request. It was for this that GraphQL was first invented - after all, the mobile client Facebook required other data than the web client.
Finally, there are still situations in which REST is a valuable way of connecting client and server applications. Often, applications are tied to work with resources, and they do not require all the capabilities of such a flexible query language as GraphQL. However, I recommend at least try GraphQL when you start developing your next client-server architecture.
Only registered users can participate in the survey. Enter , you are welcome.
Want to translate the same author's article about libraries for working with GraphQL?
Voted by 1 user. Abstained 1 user.
It may be interesting
Situs QQ Online
Situs QQ Online