GRAPHQL Part 2

GraphQL has two parts: 

1.  A Server component, a GraphQL server to accept the incoming requests and send back data precisely. 
2. A Client component, to send a POST request (with payload) to the GraphQL server. 

GraphQL uses a type system to define the capabilities of an API. All the types declared in an API are written in a schema using the GraphQL Schema - Schema Definition Language (SDL). It serves as a contract between the client and the server to define how a client can access the data. Defining the Schema allows the back-end and front-end teams to concentrate on their piece of work without much communication. 

WORKFLOW 

     Developing a GraphQL API revolves around three main concepts. 

Firstly the Schema

Secondly, the Queries

Thirdly the Resolvers 

 • Declarative syntax to Query the data you’d need from the Client to the Server

 • GraphQL would generate the payload based on the query and it has a JSON response with data on it. 

 • Server sends the payload back to the Client and the data gets displayed onto the Client

GraphQL vs. REST API

Data fetching 

Data fetching is one of the most significant improvements in GraphQL when compared to REST.

REST API retrieves the necessary information by accessing multiple endpoints.

With REST API sometimes need to use multiple different endpoints to fetch the required data. 

GraphQL is a query language, and your query (request) when triggered it precisely responds with the expected data, no extra information gets retrieved. No more over and under fetching of data. 

GraphQL gives you precise data. GraphQL you’d send a query [nested queries] and GraphQL responds with exact data. 

 Reference https://www.howtographql.com/basics/1-graphql-is-the-better-rest/ 

 Data Operation

 In REST API, each resource is represented with an endpoint, and it’s apparent to end up having multiple endpoints. The data fetch done using the CRUD (Create, Read, Update and Delete) operation via multiple endpoints. 

Whereas, In GraphQL, everything perceived as a graph and it’s connected and represented as a single endpoint. It also has unique features like Query, Mutation and Subscription. 

Versioning

In REST API, it is prevalent to see APIs have a different version like v1, v2 and so on. 

In GraphQL, there’s no need since it is based on Schema and users can quickly mark those types as deprecation for the fields that are no longer needed. This also saves a huge time in back and forth testing on different versions of the same API. 

Benefits of a Schema & Type System

Once the GraphQL schema is defined, the teams working on frontend and backends can do their work without further communication since they both are aware of the definite structure of the data that’s sent over the network.

Frontend teams can easily test their applications by mocking the required data structures. Once the server is ready, the switch can be flipped for the client apps to load the data from the actual API.

Insightful Analytics on the Backend

GraphQL allows you to have fine-grained insights about the data that’s requested on the backend. As each client specifies exactly what information it’s interested in, it is possible to gain a deep understanding of how the available data is being used. This can for example help in evolving an API and deprecating specific fields that are not requested by any clients any more.

With GraphQL, you can also do low-level performance monitoring of the requests that are processed by your server. GraphQL uses the concept of resolver functions to collect the data that’s requested by a client. Instrumenting and measuring performance of these resolvers provides crucial insights about bottlenecks in your system.