What is GraphQL?
Before we look at the features, let's understand what GraphQL is. This data query language and data manipulation language was created by Facebook developers in 2012. Initially, GraphQL was developed for the internal needs of the company. 3 years later, its release to the public was announced. Since November 7, 2018, work on the language has been conducted by GraphQL Foundation. The language became especially popular among programmers after it received the open source status.
The vast majority of Internet users are aware of the existence of Facebook. Many are also familiar with services such as Airbnb, GitHub, Pinterest, New York Times, and Shopify. All of these products were developed using GraphQL.
This query language is designed for client-side applications to access database data. The key concept of GraphQL is a schema, which is an entity that allows the manipulation of database data. A client application can thus create, read, update, and delete data. This provides the 4 main functions for working with the database, denoted as CRUD (create, read, update, delete).
The peculiarity of GraphQL is its independence from data sources. All work is organized within a particular application and not in the database. It does not matter where the data is actually stored. For complex projects requiring efficient data management, you can hire a database programmer to ensure seamless integration of GraphQL with your systems.
All queries in this language can belong to two groups. The first group includes reading requests. In terms of GraphQL terminology, they are simply called queries. Queries from the second group modify data - create, update, or delete them.
Client-server interaction in GraphQL
GraphQL requests are processed and executed by a standard HTTP server with a pre-prepared and "attached" schema. This process is as follows:
- Root queries and mutations need to define fields. For this purpose, the data types used in the application (typeDefs) and the resolver functions that process the request and return information for a particular field are declared.
- User (more precisely, the client program) sends a request. The server processes it according to the attached schema and outputs the appropriate data structure.
Unlike REST architecture, this process doesn't require multiple endpoints for each information source. All data is passed through the same gateway already filtered by the schema. The client (user) gets exactly the information he or she requested. In REST API, to fulfill this task would be necessary to create either a new endpoint for each request or one common endpoint with subsequent data filtering on the client side by all available means.
4 GraphQL benefits
GraphQL is not an absolutely universal tool for exchanging data between the application and the database. In some cases, a simpler and more rational solution would be to use REST. At the same time, this GraphQL allows developers to minimize the number of client requests, optimize the user interface, and ensure the normal interaction of multiple applications with different data sources. Here are 5 advantages of GraphQL.
Client centricity
Processing of queries is not done on the database but on a GraphQL server that allows developers to connect to many different data sources. This allows clients to get an accurate answer to their query regardless of where the information was taken from.
Performance and convenience
Due to the high sampling accuracy, a client receives only the information he needs at the moment. This reduces the load on the channel, which is especially useful for web applications running on a microserver with extremely limited capacity.
API documentation
In GraphQL, every API change is automatically documented. This is achieved by closely linking the code to the API. This means that developers don't have to spend a lot of time documenting while still being able to quickly view the history of changes.
Detailed error documentation
In REST, errors are found by checking the server response to HTTP headers. From that, the developer can determine what went wrong, what caused it, and how to fix the bug. In GraphQL, the server extensively documents each error, specifying the recognizer and a specific query fragment. The developer can choose in which form it is more convenient to receive information: text, stack trace, or error code.
Situations where GraphQL may be useful
GraphQL was originally created to handle large amounts of heterogeneous data stored in different databases: for example, information from user profiles, their interests, lists of pages visited, subscriptions, and subscribers. Processing them with the help of classic REST-based architecture has limitations and difficulties. In particular, for each data set from one database, developers must create a separate endpoint (a gateway connecting the server processes to the external interface). Below are situations when GraphQL may be useful.
The desire to minimize the number of client requests
Many applications spend the lion's share of their time making many rather complex HTTP requests. They have to execute them very often. The GraphQL technology is based on the same principle of interaction through queries. However, if the language features are used correctly, the number of client-side queries decreases significantly (down to a single query).
This technology best suits multi-user applications and services that handle large data sets. Using GraphQL in these cases will have a noticeable effect on the performance of client programs.
No data denormalization to optimize the user interface (UI)
The so-called denormalization trap often occurs in applications working with large relational databases. It is considered quite a standard situation, although far from being ideal. It is detrimental to application performance. Using GraphQL nested queries significantly reduces the need to denormalize data.
Multiple data sources handled by multiple applications
This problem is partially solved by the traditional means of REST API. However, the client-side queries are still uniform, which creates a problem. For example, developers have a large project that includes several client applications (including mobile applications) and an API for developers. Under standard conditions, they would need to create a separate query tool for each client.
This would result in the need to support multiple HTTP implementations running on different platforms at all times. Consequently, there would be confusing API endpoints with no uniform structure of query execution tools.
What do MaybeWorks developers especially like about GraphQL?
We work a lot with GraphQL when assisting our clients in web development. Here are 4 things we love the most.
High sampling accuracy
The benefits of sampling data as accurately as possible are obvious to every developer. The GraphQL tools allow our developers to request the API to get exactly the set they need. It offers a vastly improved, simple, and accurate function compared to a traditional REST pattern.
The server provides only one endpoint on a particular user request rather than multiple such points returning fixed data sets. The high selectivity of the language concerning the requested data allows our developers to minimize the amount of data transmitted.
As a result, the mobile client can receive less data, as little data is required to work on small screens.
Multiple selections per query
This peculiarity of the language follows from the above. Since only a single endpoint is provided, the server retrieves the data using a declarative scheme. That is, a single request can obtain all the necessary information from the database.
For example, you need information about a music group - its name, ID in the database, and song titles. The traditional way would need to send at least two requests to two points - /artists and /tracks, respectively. GraphQL offers to implement it in one powerful function. The effectiveness of this feature is hard to overestimate, especially when working with declarative API structures.
Deprecation
It is common practice among programmers to use several API versions. It often results in unexpected responses. Modifying existing resources or modifying their structure usually results in creating a new API version while the previous one is simply deprecated.
Let's look at an example. Suppose there is an API with the address api.domain.com/resources/1. It is assumed that there will soon be changes in the structure of resources. So MaybeWorks developers need a version of the API, which in this case, will be fixed at api.domain.com/resources/2.
In turn, the previous version is automatically obsolete. It will remain active until all users finally switch to the new version. The resources of the previous version will also be considered outdated. Querying them will give unexpected results, including notifications of an older version.
The GraphQL language implements one of the most remarkable mechanisms. It is possible to declare the API as obsolete. Querying this field gives a warning, and the field itself is removed after some time in case of absence of access to it.
So, instead of creating new versions of the API, its gradual evolution is implemented. At the same time, the structure of the API remains the same.
Compatibility with modern applications
Creating modern applications implies a comprehensive approach: the server part is developed, which exchanges data with client applications. Thus, all web applications, mobile programs, and smart devices may require only one backend application. This technology makes the most efficient use of data.
The GraphQL language also follows this modern trend by interacting with the server side of applications and performing all client tasks. In particular, client requirements such as creating nested relationships, fetching certain data, and network optimization are met. In this case, there is no need to allocate a separate API for each specific case.
Most often, when developing the server part, several microservices are formed. Each of them is designed to perform specific functions. This is easily accomplished with a special GraphQL feature called schema stitching. This technology assembles several circuits into a common one.
Each microservice is assigned its own GraphQL schema and endpoint and then combined into a unified structure with which the application's clients directly interact. All circuits are combined into one and accessed by a single API gateway.
The considered function GraphQL allows following the modern programming style. Using GraphQL queries to merge multiple schemas into a single global scheme, MaybeWorks developers open access to resources for multiple client applications.
MaybeWorks - reliable IT Staff Augmentation Provider with top-level QraphQL experts
In one of our latest projects, our developers assisted the development of a real estate platform that allows users to tour homes independently, contactless, and safely. This project consisted of 3 parts: Client app, Admin app, and Mobile app. The technological stack was React, Nest, TypeScripе, and GraphQL.
The main responsibilities of our developers were implementing new features regarding requirements and design, refactoring an existing code base, and improving database storage. Also, they were responsible for setting up Amazon CI/CD and moving the project from Restful API to GraphQL, along with connecting and configuring according to the application logic.
We quickly and effortlessly provided our client with the required experts for real estate platform development. Feel free to contact us right now!
