GraphQL is an open-source query language created by Facebook, a company that unsurprisingly remains at the pinnacle of web-based software development. Before GraphQL went open source in the year 2015, Facebook has used it internally for their mobile apps since the year 2012, as an alternative to the common REST architecture. It allows requests for specific data, giving clients more control over what information is sent.

This is more difficult with a RESTful architecture because the back-end defines what data is available for each resource on each URL, while the front-end always has to ask all the information in a resource, even if only a part of it is needed. This problem is called over-fetching. In the worst-case scenario, a client application has to read multiple resources through multiple network requests. This is over-fetching, but also adds the requirement of waterfall network requests.

A query language like GraphQL on the server-side and client-side lets the client decide which data it needs by making a single request to the server. Network usage was reduced dramatically for Facebook’s mobile applications as a result, because GraphQL made it more efficient with data transfers.

Facebook open-sourced the GraphQL specification and its reference implementation in JavaScript, and multiple major programming languages implemented the specification since then. The ecosystem around GraphQL is growing horizontally by offering multiple programming languages, but also vertically, with libraries on top of GraphQL like Apollo and Relay.

A GraphQL operation is either a query (reading), mutation (writing), or subscription (continuous reading). Each of those operations is only a string that requires to be constructed according to the GraphQL query language specification. Fortunately, GraphQL is evolving all the time, so there may be other operations in the future.

Once this GraphQL operation reaches the back-end app, it can be interpreted against the entire GraphQL schema there and resolved with data for the front-end app. GraphQL is not opinionated about the network layer, which is often HTTP (HyperText Transfer Protocol), nor about the payload format, which is usually JSON (JavaScript Object Notation). It is not opinionated about the application architecture at all. It is only a query language.

Why should you consider a GraphQL API?

There are many reasons to consider GraphQL API. Some of them are mentioned below:

GraphQL APIs have a strongly typed schema

One of the biggest drawbacks of most of the APIs is that they are lacking strong contracts for what their operations look like. Most developers have found themselves in situations where they need to work with deprecated API documentation, lacking proper ways of understanding what operations are supported by an API and how to access them.

A GraphQLschema is the backbone of every GraphQL API. It clearly defines the operations (queries, mutations and subscriptions) supported by the API, including input arguments and possible responses. A schema is an unfailing contract that specifies the capabilities of an API.

GraphQL schemas are strongly-typed and can be written in the simple and expressive GraphQL Schema Definition Language (SDL). Thanks to the strong type-system, developers are getting many profits that are unconceivable with schemaless APIs. As an example, build tooling can be leveraged to validate API requests and check for any errors that might occur in the communication with the API at compile-time. One might even get auto-completion for API operations in their editor.

Another benefit of the schema is that developers do not have to manually write API documentation any more — instead, it can be auto-generated based on the schema that defines the API. That is a game-changer for API development!

No Over-Fetching or Under-Fetching

With GraphQL, developers can fetch only what is needed. Nothing less, nothing more. This solves the problems that occur due to over-fetching and under-fetching.

Over fetching happens when the response fetches more than what is needed. Consider the example of a blog home page. It displays the list of all blog posts (just the title and URLs). However, to display this list, one needs to fetch all the blog posts (along with body data, images, etc.) through the API, and then show only what is required, usually through User Interface (UI) code. This impacts the performance of your app and consumes more data, which is expensive for the user.

With GraphQL, one defines the exact fields that one want to fetch (i.e., Title and URL, in this case), and it fetches the data of only these fields.

Under fetching, on the other hand, is not fetching sufficient data in a single API request. In this case, one needs to make additional API requests to get related or referenced data. For instance, while displaying an individual blog post, one also need to fetch the referenced author’s entry, just so that they can display the author’s name and bio. GraphQL handles this well. It allows you to fetch all relevant data in a single query.

Openness, Flexibility, and Power

GraphQL APIs solves the data loading issues with its 3 attributes. First, it is an open specification rather than software. One can use GraphQL to serve many different needs at once. Secondly, GraphQL is flexible enough not to be tied to any specific programming language, database or hosting environment. Third GraphQL brings in power and performance and decreases code complexity by using declarative queries instead of writing code.

Documentation is a first-class citizen

The documentation for a GraphQL API lives side by side with the code that contains it. Combined with the typed schema, this means that one can generate accurate and up to date documentation whenever any changes occur. Using GraphQL’s introspection feature, one can query the schema itself to explore its contents and documentation.

GraphQL embraces modern Trends

GraphQL embraces modern trends on how applications are developed. You may only have one backend application, but multiple clients on the web, phones, and smartwatches depending on its data. GraphQL can be used to connect both worlds, but also to fulfil the requirements of each client application network usage requirements, nested relationships of data, fetching only the required data without a dedicated API for each client.

On the server-side, there might be one backend, but also a group of microservices that offer their specific functionalities. This defines the best use for GraphQL schema stitching, which allows you to aggregate all functionalities into one GraphQL schema.

Saves Time and Bandwidth

GraphQL allows users to make multiple resources request in a single query call, which saves a lot of time and bandwidth by decreasing the number of network round trips to the server. It also helps to save waterfall network requests, where one need to resolve dependent resources on previous requests. For example, consider a blog’s homepage where you are required to display multiple widgets, such as recent posts, the most popular posts, categories, and featured posts.

GraphQL Introspection

A Graph QL introspection makes it possible to retrieve the Graph QL schema from a Graph QL API. Since the schema has all the information about data available through the Graph QL API, it is best for auto-generating API documentation. It can also be used to mock the Graph QL schema client-side, for testing or retrieving schemas from multiple microservices during schema stitching.

GraphQL is protocol agnostic

Graph QL is protocol-agnostic which means it does not depend on anything HTTP ( HyperText Transfer Protocol). We do not use HTTP methods or HTTP response codes with Graph QL, except for using it as a channel for GraphQL communication.

Request and response are directly related

In Graph QL APIs, the language used for the request is directly related to the language used for the response. Since we use a similar language to communicate b/w clients and servers, debugging issues become easier. With Graph QL APIs queries mirroring the shape of their response, any deviations can be detected, and these deviations would point us to the exact query fields that are not resolving as they should be resolved.

Open source ecosystem and a fabulous community

Graph QL has evolved in leaps and bounds from when it was open-sourced. The only tooling available for developers to use Graph QL was the graphql-js reference implementation when it came out first. Now, reference implementations of the Graph QL specification are available in various languages with multiple Graph QL clients. Moreover, you also have multiple tools like Prisma, Graph QL Faker, Graph QL Playground, graphql-config etc to develop GraphQL APIs.

The GraphQL community is growing rapidly. Whole conferences are exclusively dedicated to Graph QL, Graph QL Europe, Graph QL Day and Graph QL Summit to name a few.

Superior Developer Experience

The biggest reason for using Graph QL is the superior developer experience that it provides in comparison to alternatives like REST. An interesting thing to note is that with Graph QL, front-end developers stand to benefit a ton. The client-driven approach offers a lot of power to the clients to query for what they like by creating custom queries.

GraphQL enables rapid product development

Graph QL makes front-end developers’ lives easy. Thanks to Graph QL client libraries like- Apollo, Relay or Urql, front-end developers are getting features such as caching, realtime or optimistic UI updates basically for free — areas that could have entire teams dedicated to working on them if it was not for GraphQL.

Increased productivity among front-end developers leads to a speed-up in the development of the product. With Graph QL, it is possible to completely redesign the User Interface (UI) of an app without needing to touch the back-end.

GraphQL for React, Angular, Node and Co.

Graph QL is not just exciting for React developers, though. While Facebook showcased Graph QL on a client-side application with React, it is decoupled from any frontend or backend solution. The reference implementation of Graph QL is written in JavaScript, so the usage of Graph QL in Angular, Vue, Express, Hapi, Koa and other JavaScript libraries on the client-side and server-side is possible, and that is just the JavaScript ecosystem. Graph QL does mimic REST’s programming language-agnostic interface between two entities, such as client or server.

Summary

  1. Graph QL is the in-thing in web development today
  2. Graph QL is revered by everyone who says there is nothing more wonderful
  3. Graph QL is typed, and that makes it so magical.
  4. Graph QL offers a really good looking IDE that makes it so easy to develop the queries
  5. Graph QL makes services so easy to code (all it needs is a gesture and all the little thingies arrange themselves in perfect harmony)
  6. Graph QL drastically reduces chatty network traffic and improves the speed to ‘burn rubber’ levels even before ignition is turned on
  7. Graph QL uses in-built security rules that make it so easy to provide role-based authorization
  8. Graph QL is loved equally by server and client tech stacks
  9. Graph QL specifies a good abstraction layer for databases.
  10. Graph QL has subscriptions and those are so so amazing.
  11. Graph QL reduces work on the server-side.
  12. Development iterations are easier on the client.
  13. Graph QL passes only the required data between client and server.

When to Use GraphQL

Graph QL works best for the following scenarios:

Apps for devices such as mobile phones, smartwatches, and Internet of Thing (IoT) devices, where bandwidth usage matters.

  • Apps where nested data are required to be fetched in a single call. For example, a blog or social networking platform where posts need to be fetched along with nested comments and commentators details.
  • Composite pattern, where app retrieves data from various, different storage APIs. For example, a dashboard that fetches data from multiple sources such as logging services, backends for consumption stats, third-party analytics tools to capture end-user interactions.
  • The proxy pattern on client-side: Graph QL can be added as an abstraction on an existing API so that each end-user can specify response structure based on their requirement. For example, clients can create a Graph QL specification according to their requirements on common API provided by FireBase as a back-end service.

Wrap Up

In the end, GraphQL is a protocol and a query language. Graph QL API can access data directly but for most use cases Graph QL API is a data aggregator and an abstraction layer. The layer that improves the velocity of development, reduces maintenance and makes designers happier. For these reasons, Graph QL makes even more sense for a public API. Companies are adopting Graph QL in droves. Companies like IBM, PayPal and GitHub claim a big success with Graph QL.