First of all, consider what is GraphQL. By definition, GraphQL is a query and data manipulation language for APIs, as well as an environment for executing these queries. The language was developed in 2012 on Facebook for the company`s internal needs, in 2015 it became public. Even if you`ve never heard of GraphQL before, chances are you know or have used products that are written using it. The first is the social network Facebook. In addition, they work with GraphQL to develop products such as GitHub, Pinterest, Shopify, New York Times and many others. Let`s return to the creation of language. The fact that it was created on Facebook for a project with a large amount of heterogeneous data, suggests that when working on such a product may be situations with limitations of the REST-architecture. For example, getting a user`s profile, posts, and comments from the beginning doesn`t seem like a daunting task. But if we take into account the amount of data in the system and assume that all this data is stored in different databases (for example, MySQL and MongoDB), it becomes clear that this will require several REST-endpoints. If you imagine how much data and diverse data sources, it becomes clear why it was necessary to develop a new approach to working with the API. This approach is based on the following principle: it is better to have one "smart" endpoint that will be able to work with complex queries and return data in the form and to the extent that the customer needs. At the heart of any GraphQL API implementation is a data schema - a description of what data types it can work with, what data types it can return in response to a request (they are described in the GraphQL type system). To work with any API, the user needs to know what types of objects can be obtained, fields to select, what fields are available in internal objects, etc. When working with the GraphQL API, the client does not care where the data he requests comes from. It simply queries the amount it needs, and the GraphQL server returns the result. Therefore, we can imagine that the scheme is a contract between the API and the client, because before the client executes any request, this request is validated according to the scheme of this API. Comparison of GraphQL API and REST API As noted earlier, GraphQL has been developed as a more efficient alternative to the REST architecture for developing application programming interfaces. Therefore, these 2 approaches have common features: They provide a single interface for working with remote data. The request is most often answered in JSON format. But GraphQL also has many advantages over REST: It is customer-oriented, it allows the client to get the information and to the extent that he needs - no more and no less. Unlike REST, you only need one endpoint to work. GraphQL is a highly typed language that allows you to pre-evaluate the correctness of the query before the execution stage of the program. GraphQL provides the ability to combine queries. Queries to the GraphQL API always return the expected result that matches the data schema of this GraphQL API. Using GraphQL reduces the amount of data transmitted to the client, as the client must require only the data he needs. That is, if when using REST the endpoint determines what data and in what form the client will receive, then when using GraphQL the client should not request superfluous data, thereby reducing the amount of response of the server. In practice, the use of GraphQL increases the independence of front-end and back-end developers. Once the schema has been agreed, front-end developers will no longer ask to create new endpoints or add new parameters to existing ones: back-end developers describe the data schema once, and the front-end specialist creates queries and combines data as needed. At the heart of any GraphQL API is a description of the types you can work with and which you can return - as mentioned earlier, the schema. Since GraphQL services can be written in many languages, a universal GraphQL schema language has been developed for this purpose. Consider the main types of data that it supports. The most basic types of GraphQL are object types, which are an object and a set of fields that describe it. Arguments are a set of key-value pairs that are tied to a specific field. They are transmitted to the server and affect how the data for a particular field will be obtained. Arguments can be both literals and variables. They can be used in any field, regardless of their level of nesting. For example, here to the field Film the argument id (in this example literal type ID) is bound: Enum - A special scalar type that is limited to a specific set of values. Interfaces - An abstract type that includes a set of required fields, which must include the types that this interface inherits. If this is not done, a schema validation error will occur. There are special types that define the type of operation that the client wants to perform, such as retrieving data or changing it. These types are entry points for the API. Any GraphQL API must have at least one query, but mutations and subscriptions are optional. It is worth noting that, despite their special status, these special types are the same as other GraphQL object types. Query. We can say that this is an analogue of GET in REST. This data type is mandatory for any GraphQL. This is a simple request for information about all the movies (as the name implies). Already at this stage you can see the important advantage of using GraphQL: we get only the data we need in the application (in this case, the id, title and episode number of the movie). Thus, in practice, the client does not have to receive all the data, regardless of whether they are needed or not, and sometimes perform quite complex filtering, if you can get only the necessary data and continue to work only with them. Mutations. A special type that, unlike query, is used to change data (we can say that it is an analogue of POST). The main difference between query and mutation is their behavior when receiving query results: when query is executed, the processing of the result fields will be performed in parallel, as they do not change the data. In turn, in mutations this is done sequentially to ensure data integrity. Subscriptions. This is a new special data type that allows you to implement the publisher / subscriber system. That is a way of sending data to a client who "listens" to this data in real time. Unlike the previous 2 special types, here the server`s response does not come once, but each time certain conditions are triggered on the server, provided that the client "listens" to this data. We can say that this is an analogue of push notifications that work in the same system with all other types of requests - query and mutations. The advantage of this approach is that the client and in this case can use arguments to determine the conditions under which the result from the server should come to the client. In the example, only data about the created movie is expected. If there is a change in the available information about the movie, its deletion or any other event, the client will not receive this information.