GraphQL is changing the game of Web Querying. Here’s how.

GraphQL is the next generation API architecture which has been gaining a lot of traction as it brings a lot more efficiency for developers to set up an API. Within just two and a half years since its inception, it has become the forefront of API designing and development. This is in part because of its claim to provide a “Query language for your API”.

But is it really worth the hype? In this article, I will explain how GraphQL is changing the way an API queries the data and what future GraphQL holds for the API development community.

GraphQL accelerates product development

With helpful features like caching, realtime or optimistic UI updates, GraphQL lets organizations speed up the product development with the teams working on features that really are important. With GraphQL, it is possible to completely redesign the UI of an app without needing to touch the backend.

Furthermore, GraphQL supports schema-driven development which allows developers to define types that can be used across both server and client. This has a drastic impact on your design process. While using GraphQL you will be looking at your APIs as a collection of types rather than looking at it as a mere collection of REST endpoints.

SEE ALSO: Tutorial: How to quickly deploy a TIG stack using Puppet Bolt

Before you develop your new API, you not only have to think but define what data types your API will expose. These types are called a schema. This allows a front-end developer to be aware of several important properties of a query. For instance: if it takes arguments if it’s a list or just an “entity”. Moreover, if it’s a specific entity, what are the fields of that entity (say name and email).

Schema driven design methodology is something that gets all of your team on the same page; because even a backend team will have a clear understanding of the data it needs to store and deliver. The frontend team will know about the definitions that are needed to build user interfaces. All in all, everyone can get into their shoes and get their asses to work. This, in turn, increases product development speed and efficiency.

GraphQL singlehandedly solves data fetching problems

A long time ago, I was working on a project where we changed our API design from SOAP to REST. Our line of thought was simple: provide more flexibility to developers. I won’t deny the fact that it worked pretty well sometimes. For our team, it was a good move.

However, as our application evolved in future changes, we faced a lot of problems due to over-fetching and under-fetching information through REST APIs. One reason for this problem is that REST APIs always return a fixed structure. That said, each resource in REST is represented by an endpoint. So, in a real-world application, we would end up having a lot of endpoints for a lot of resources. This way, you can’t get the exact data unless you create a specific endpoint for that.

For instance: if we need to fetch the firstName and lastName of a user in a REST API, there’s no way we can get the data without fetching the whole object.

GraphQL entered the API industry as a response to solve the problem of a lot of endpoints.

Facebook has experienced the pain of establishing APIs from their HTML5-based version of flagship mobile application back in 2011-2012. They realized that they needed a new API design to ensure peak performance. With GraphQL being a single endpoint, developers have the liberty to reduce the number of network calls they need to make and ensure that the data they require can be only retrieved.

Going by the example given above (where we needed to fetch the firstName and lastName of user), GraphQL fetches it by:

Another organization, GitHub, has had an interesting take on why they decided to sunset REST API and chose GraphQL:

[We] heard from integrators that our REST API also wasn’t very flexible. It sometimes required two or three separate calls to assemble a complete view of a resource. It seemed like our responses simultaneously sent too much data and didn’t include data that consumers needed.

The biggest difference between GraphQL and REST is the implementation across a variety of client and server languages and libraries. GraphQL decoupled the back-end and front-end application systems by introducing an intermediary application layer. This helped in establishing a mechanism to access organization data in a way that aligns with an organization’s business domains.

GraphQL boasts of a rich ecosystem and helpful community

Ever since its inception, GraphQL has evolved drastically with the origin of great tooling support for developers. When it first came out, the only tooling support for GraphQL was the graphql-js reference implementation.

However, as it continues to get support from different directions, many more reference implementations of GraphQL API are released in different languages with multiple GraphQL clients. Tools such as GraphQL Faker, graphql-config, Prisma, GraphQL playground etc. can be now used to build APIs using GraphQL. The additional factors such as adaptability, power, ease-of-use that GraphQL offers have raised the industry standards and expectations of developers.

Moreover, the GraphQL community rapidly grows as it continues to get more support from renowned organizations. The community is very active on social groups such as Facebook, Meetup, and Slack. For instance, the dedicated Facebook group for GraphQL helps developers share and contribute to open source projects. This helps to maintain knowledge flow and give novice developers a chance to get involved with the community.

SEE ALSO: Automated build and deployment of Docker containerized OSGi applications on Kubernetes

Furthermore, there are many conferences that take place in the community such as GraphQL, GraphQL Europe, GraphQL Day and GraphQL Summit to name a few.

In GraphQL, Response and Request are directly related

Unlike RESTful APIs where the language we use for the request is different than the language we use for the response, GraphQL asserts on a language where request and response are directly related to each other. Using a similar language for communication between the client and server makes debugging easier and any kind of deviation can be detected. As a result, these deviations can be used to find out the exact query fields that are not resolving in a correct manner.

In GraphQL, all your clients see is a schema. They write a query of what they wish to get. They send a request and take back the data they asked for and nothing more.

Conclusion

GraphQL is really changing the game of Web querying and API development. That’s why many organizations are betting on it. However, it still has a long way to be hailed as a ‘silver bullet’ of API development.

One of the greatest benefits of GraphQL is that it can be used alongside the existing APIs as a compliment solution. This improves the performance of an application in a great deal and let developers concentrate on the most important areas of application development.

The post GraphQL is changing the game of Web Querying. Here’s how. appeared first on JAXenter.