- May 10, 2019
- Posted by: email@example.com
- Category: Web Development
Problems with RESTful architecture
- REST is the most popular choice for making network requests between client and server
- REST enables applications to communicate with each other by using plain HTTP with URLs and HTTP methods
- In a RESTful architecture, the backend defines what data is available for each resource on each URL
- It is common to access multiple endpoints to fetch data
- This leads to the problem of overfetching and underfetching
- This happens because the only way to fetch data is by hitting endpoints which return fixed data structures
How does GraphQL do better?
- GraphQL is not opinionated about the network layer, the payload format or even the application architecture. It is only a query language.
- With GraphQL, you send a single query to the GraphQL server that includes the concrete data requirements
- The server application offers a GraphQL schema, where it defines all available data with its hierarchy and types, and a client application only queries the required data.
Who’s using it?
- many more…
GraphQL is for everyone
Central source for data
It provides a central location, where all available data is described. The GraphQL schema is usually defined on server-side, but clients can read (query) and write (mutation) data based on the schema.
Designed for modern apps
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 perfect use for GraphQL schema stitching, which lets you aggregate all functionalities into one GraphQL schema.
Schema stitching makes it possible to create one schema out of multiple schemas. Think about a microservices architecture for your backend where each microservice handles the business logic and data for a specific domain. In this case, each microservice can define its own GraphQL schema, after which you’d use schema stitching to weave them into one that is accessed by the client. Each microservice can have its own GraphQL endpoint, where one GraphQL API gateway consolidates all schemas into one global schema.
Strongly Typed GraphQL
GraphQL is a strongly typed query language because it is written in the expressive GraphQL Schema Definition Language (SDL). Being strongly-typed makes GraphQL less error prone, can be validated during compile-time and can be used for supportive IDE/editor integrations such as auto-completion and validation.
GraphQL doesn’t take away performance bottlenecks when you have to access multiple fields in one query. Whether the request was made in a RESTful architecture or GraphQL, the varied resources and fields still have to be retrieved from a data source. As a result, problems arise when a client requests too many nested fields at once. Frontend developers are not always aware of the work a server-side application has to perform to retrieve data, so there must be a mechanism like maximum query depths, query complexity weighting, avoiding recursion, or persistent queries for stopping inefficient requests from the other side.
Implementing a simplified cache with GraphQL is more complex than implementing it in REST. In REST, resources are accessed with URLs, so you can cache on a resource level because you have the resource URL as identifier. In GraphQL, this becomes complex because each query can be different, even though it operates on the same entity.