As you know, GraphQL was originally developed for the convenience of front-end developers. It provides a strong contract for communication between client and server and is essentially a query language for passing and receiving typed data. In addition, GraphQL is a description of the data schema, automatic documentation and an insanely rich tooling or set of development tools compared to the available interfaces and protocols that are present today.
Companies implementing blockchain technology can successfully use the GraphQL toolkit. And given the fact that such a form of service as SaaS is in great demand today, it is quite possible to use it for graphql blockchain solutions.
Story Stages
Necessity of GraphQL
Among developers, operators and experts, the question is often raised: “Do we need GraphQL?”. Let’s figure it out.
So, GraphQL is needed:
– in interaction between backend and frontend developers;
– at a large number of micro services with their own endpoints;
– if there are large entities ;
– if you need static code analysis;
– if closely in the paradigm of 4 REST API operations;
– if there are many different entities with connections and clients want to collect aggregations themselves
GraphQL has three main characteristics:
1 – data predictability
2 – data aggregation
3 – a rigid system of types
Real situation
Almost always, the development of any product is divided into two components: frontend and backend. Imagine that there is a certain client application and there is a service that processes data. While the service itself enters the data sources, and communicates with the client through the API. The standard solution for this is REST-API.
The difficulties in this case are: writing documentation and data differentiation. Let’s take an online store as an example. Everyone knows that the essence of any store is the product. It is at the epicenter of all the activities of the online store.The implementation of the tasks of all tools, including the product catalog, basket, order history, product cards, reviews, etc., is aimed at the product. Requests for goods are made in different places and in different forms. As the store develops and the number and assortment of goods increase, reviews and all kinds of variations appear, the work of the server becomes much more complicated. Of course, there are some tools to solve this problem when working with the REST API, but with an increase in the number and variety of requests, the information grows exponentially and this leads to the appearance of huge amounts of information, which ultimately becomes an unbearable task for the REST API.
Facebook, at one time trying to get away from such a problem, offered GraphQL as a solution. When using GraphQL, the documentation becomes automatic, it becomes possible to choose exactly what you need to get, and, finally, the best option is implemented, in which you can reflect several entities in one query. The load on the server with this approach has decreased significantly. However, not only this showed a positive effect from GraphQL. Backend and frontend developer processes have also been simplified.
Prior to this, before creating a new field, the backend developer had to talk to the frontend developer to decide which endpoint he would add or extend. Then he had to implement the extension, update the documentation and give it to the frontend developer to work on. In the case of GraphQL, the process began to proceed as follows. The backend developer, starting not from the request, but from the entity, simply adds the required field to a certain type of product, implements the logic for receiving it, and gives to the frontend developer.
In turn, the frontend developer also had to first talk to the backend developer to find out which endpoint could get new information. Then he had to study the documentation, implement the logic of working with a new endpoint or with an extended old one, and only then work with this field. After the introduction of GraphQL, the frontend developer also starts to build on the essence. He knows that some field has been added to the product, then he enters the required request, adds the required field in it, and then immediately uses it.
Cons of GraphQL
Using the example above, we can conclude that the IT industry has received a convenient and useful tool for its use. However, you need to clearly understand that for all its undoubted merits, GraphQL is not a “silver bullet” and it should be used only where necessary. This means that there are some activities where this tool will be ineffective.
GraphQL complicates the processes:
– in some MVPs;
– in reporting and analytics systems;
– in common authentication services;
– in teams where GraphQL is not known
