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.

GraphQL - Part 1

 GRAPHQL 

    Though GraphQL was in use for years, recently its gaining more popularity. One would say, am happy with REST why GraphQL? Well, do you remember the days of SOAP API and dealing with xml?

REST has been the de facto standard for APIs for a while now, replacing the relatively cumbersome and XML-only SOAP-based APIs with an architecture that is more flexible, lightweight and easier to develop. However, REST is not without limits of its own. With pure REST, if you need to gather and combine data from multiple endpoints or entities, the API consumer typically needs to invoke multiple endpoints, collect the data from each of these endpoints and combine and filter that data into something useful.

 Advancement is inevitable and the need for speed, scalability while dealing with huge data is the drive for GraphQL. GraphQL tries to solve this problem by exposing all data through a single endpoint and allow the API consumer to write queries that retrieve the exact data required at any given moment, all with a single API call.

History

Facebook invented GraphQL, and now it is maintained by a large community of companies and individuals all over the world. GraphQL is a specification and, users shall create their implementation on different platforms conforming to the specification.

Netflix Open-Sourced their implementation called Falcor.

An easy example for folks coming from Test Automation world, it is like WebDriver being a W3C Specification, Selenium and WebDriverIO are its browser automation implementation.

Why Facebook created GraphQL is an exciting story in itself and is available here as a documentary.

One of the problems that Facebook wanted to solve is the speed and user experience of facebook.com. After a few ideas, the team came up with two main mantras that would work. The team started working towards achieving them, namely As little as possible, as early as possible and Engineering experience in service of user experience. They achieved this by unifying the fetching of code and data in one single GraphQL query—the GraphQL’s ability to ally the request and minimises network usage is outstanding. 

More… here.

What is GraphQL?

GraphQL is an API specification standard and an Open-Source data query and manipulation language. 

GraphQL follows WYAIWYG pattern What You Ask Is What You Get. GraphQL allows declarative data fetching where a client can specify what data it needs from an API.

GraphQL is promising and evolving by the adoption of a large group of companies rolling out GraphQL in production. However, there is definitely, few caveats in this new modern API design too like caching, Authorization, Error handling, n+1 problems. And there are ways to navigate through these problem areas.

AutomationAutomated: Evolution of V Model in Agile

AutomationAutomated: Evolution of V Model in Agile:                                  As we are moving towards Agile [ even PMP is adapting to Agile on 2021], we tend think Waterfall model, V m...