Expose your API as a restaurant menu with GraphQL
Read the whole menu, choose your favorite meal, and join the GraphQL kitchen where the API’s communication protocol revolution is being cooked over high heat.
GraphQL technology is a query language to expose your API. In comparison to the popular REST standard, GraphQL exposes a schema in a single endpoint and provides a query language for any client (mobile, web, and so on) to consult specific data to the API.
When we say specific data, we mean really specific. Whereas in REST endpoints are provided and the information interface is defined by the backend developer, in GraphQL the client decides which fields of each entity to ask for.
GraphQL advantages
General comparison
Design
The first advantage we should mention is having only one entry point for our API. For that reason, the backend integration with any client is easier and safer. The typed schema for the API exposure clearly defines what the client can ask for and includes a deprecation policy for breaking changes. These features simplify the continuous development of the application. A key aspect of this advantage is the acceleration of development, mainly, when building fast applications like CRUD APIs or middlewares.
Performance
To go over this topic, we can compare the difference between having a well-designed API with an endpoint per entity with a GraphQL single endpoint application. Imagine the typical scenario where you have to ask for a set of orders and their products’ details. In this case, in REST we would do two requests: GET /orders and then GET /products. In GraphQL you would only need one for the orders and the corresponding products. Thus, we are reducing backend requests and improving speed. In a pay per use infrastructure (like AWS Lambda or Azure functions), we would also be cutting costs in the backend usage.
Are you ready for more? As we said before, in GraphQL we can ask for specific fields and avoid getting the ones that are unnecessary. Let’s assume our products have 25 fields modeled in a Mongo database. To our web client, we only need to show the product name, picture, and price. However, in the same model, we store other fields such as description, category, brand, size, and so on. As I said in the title, this is like reading the menu and only ordering what you like (in this case, what you need).
Community
GraphQL is being used by big companies such as Airbnb, Twitter, Github, and many more. New tools are being built and maintained making GraphQL stronger in maintainability, and its community is increasingly growing. Here we can see the Stack Overflow engagement in questions:
Our experience with Graph QL
At Wolox, our greatest challenge with GraphQL was to build a fintech application to provide credit card benefits for users. We had three weeks and I was the architect in a small team. We decided to go with GraphQL to accelerate the backend-frontend integration. We developed an extensible model on the backend to consider future new features and new types of clients, like mobile or statistics visualization. And we manage to do it successfully!
Our takeaway is:
- With GraphQL our development is faster.
- GraphQL is useful for scalable apps with different types of clients.
- Backend-frontend integration failed fewer times than in Rest integrations.
- Developers like GraphQL! In the end, the whole team was happy coding with GraphQL frameworks (we used NodeJS with Apollo server for backend and React with Apollo Client). Thus, we decided to train the Wolox NodeJS backend team in GraphQL with a meetup.
I strongly recommend you giving GraphQL a try in a new project, wrapping up an old service with performance issues or updating one that your team does not like to maintain. That’s the kitchen’s chef recommendation and…Bon appétit!
