With GraphQL Keep an overview of the data
Data is retrieved and modified via APIs. The best-known approach for this is REST: every resource can be found at a specific address. But the more complex your digital product, the more complex the data - and the more addresses that have to provide more and more data to cover all needs.
GraphQL offers an answer to this: each query specifies which data is required; in this way, data exchange can be bundled under one address without losing clarity.
Imagine you work in retail.
Your catalog includes thousands of products that you present on the Internet. All of them can be rated by users. The ratings can be commented on and liked. These reviews are then displayed in your app, the community platform and the product overview.
You already handle 3 types of data for this: Users, products and posts. They each have their own data structure and are related to each other. In the app, you want to display the contributions to a product, in the community the contributions per user.
To make matters worse, REST APIs already exist for user and product data. So do you need to set up another REST API for user contributions? It would be great to have a technology that is powerful and yet does not increase complexity. Curtain up for GraphQL.
GraphQL: The maximally flexible API
GraphQL is designed for flexible data exchange - including a better overview, as all data is typed. This makes it a powerful alternative to REST.
The GraphQL schema is the "master plan": It defines the data structure and guarantees that the data is delivered in a specific form. If you know what to expect, you don't have to deal with missing data and the resulting bugs. The schema can be used to easily Types generate, which in TypeScript can be used. This makes developers happy, which in turn makes the product better.
Avoids under- and overfatting
Clients define which data they need and receive exactly this data back - and not five products and twelve articles that are not displayed anywhere (Overfetching). But enriched with all user information that would have to be collected separately with REST (Underfetching).
Enables rapid further development
Because each client defines the required data during the query, the API can serve new use cases with minimal effort: All posts written in the last 7 days? No problem. All comments on a product and the names of everyone who has liked it? Nothing could be easier. Or just the comments with likes? No problem!
Makes versioning unnecessary
GraphQL APIs can serve new needs and still remain backwards compatible as the desired data structure is defined in each client. This is in contrast to REST APIs, where changes to the data structure require versioning to ensure that existing clients are not confronted with data in an unknown form.
Caching? Of course!
Maximum flexibility does not come at the expense of performance: resource-intensive queries can also be cached with GraphQL. The cache is deleted again when the data changes. This allows users to see the most up-to-date data at all times - reliably and quickly.
Our experience
Our community platform Reactions relies on GraphQL. We gathered a lot of know-how while building it - and blogged about it: Building Enterprise Grade APIs with GraphQL, MySQL and Node.js. We have also used GraphQL in combination with Elasticsearch: GraphQL and Elasticsearch: A Love Letter.
This is where GraphQL comes in:
