I completed another Stephen course in Udemy. It is the GraphQL and Apollo client course. I really love the way Stephen Grider lays it out in his own unique style. There are 100s of blog posts on “Why GraphQL” or “GraphQL vs REST”. And I do not want to take sides. However, I have listed down two specific cases where GraphQL shines.
Writing a Hello world application
I am not referring to writing a Hello world application for understanding GraphQL. But a real Hello world application which is quite simple in its purpose. Let us say, we want to build a employee directory. Alphabetical listing of employee names. On clicking, you have a page for each employee, which has some unstructured data. Basically, the employee detail page is different from one department to another. Consider Dell. An employee in the hardware division may have different details in the employee page compared to an employee working in the software division. For this kind of simple application which spans only a couple of pages (listing page and detail page), GraphQL is a good choice. Let me explain why.
We define a schema file. The schema file has queries and mutations bundled together. Queries get data. Mutations modify data. By defining queries and mutations, we are designing the system quite well. Graphiql is a browser tool for executing queries and mutations. It is very similar to Postman or Fiddler in purpose.
As you can see from the screenshot, for a simple app, the schema explorer documents the design. With REST, we do not have a central place to see all the API. Yes, there are equivalent tools like Swagger. But using Swagger is not as elegant as using Graphiql.
For a small app, the self documenting feature is quite useful. Another advantage of using GraphQL is state management in our React app is taken care by the Apollo client or Relay library. We do not need to use Redux or Mobx. But just Apollo client or Relay. State management in our React apps become a bit simpler.
With larger apps, the advantages outlined here are of no value. For a large application, the Graphiql documentation explorer will have so much entries that it does not have much meaning. Also, for large apps, if we want to modify something, we have to write code both at the client and the server. And sometimes, it gets a bit painful especially for apps which are very transactional.
But for small apps, which have a listing page and a detail page, I will highly encourage the use of GraphQL. It is self documenting. And we use Apollo client for state management in the client.
Integrating micro-services
Micro-services is the buzz word now. We have decentralised apps each having its own data store and specialising in doing one thing very well. All micro-services expose their functions as API. The front-end usually works across all these micro-services. And sometimes, we have to integrate data across these services. Here is another area where GraphQL has a huge value. We define a common schema across all these micro-services and resolve it in specific ways. I want to elaborate on the previous statement. A concrete example helps.
Consider an e-commerce company. And we use Dell again as an example. Each country has its own product catalog. A customer may want to purchase a specific server, say PowerEdge. And some PowerEdge model is not available in the product catalog of my country, India. But, it is available in the product catalog of Singapore. The traditional way that Dell uses to handle multiple product catalog is for the customer to select a specific country and then shop within that country’s catalog. But with GraphQL, we have a better way of doing things.
Each country exposes the product catalog as a micro-service or some API. We define a GraphQL schema for the dell.com website. When I browse the website, we make a query. And this query calls country-specific product catalogs and gets back the item. Each country specific product catalog may optionally have its own response shape. And it is upto the GraphQL server to understand these differences and collate data.
In this way, GraphQL allows collating data from different micro-services by defining a common schema.
Summary
Though it might appear as if I am selling GraphQL, I am not. The technology has its place in the web application ecosystem. In my opinion, it is very good for small apps, the Hello world apps, as it has self-documenting feature. And it is very good at integrating multiple micro-services into a common schema. I probably won’t use GraphQL in medium-sized or large-sized monolithic apps. But definitely will use in the next small app that I develop. And if I work for the big guns, I will suggest using GraphQL as a platform across multiple APIs.