GraphQL vs. REST: You Really Don’t Have to Choose

Forums like StackOverflow are full of “GraphQL vs. REST” posts, and much of the discussion about GraphQL starts with this tale of dueling architectures, but companies don’t necessarily need to choose one or the other. While both technologies provide methods of fetching data from a backend system, they solve different problems and approach data from different ends of a spectrum.

GraphQL provides a strongly typed schema definition language to describe data that lives across any number of systems in a way that is intuitive and useful to clients. Client teams can then use a declarative query language to describe the data they need. GraphQL also reduces sequential network calls, as it allows clients to fetch a graph of data with a single query, so it doesn’t have to individually fetch all the related entities, compose them and return the data to the client.

By contrast, REST encourages a more resource-oriented approach to organizing and deploying services, usually along domain boundaries. It’s more focused on modeling entity relationships than it is on serving data to the client in a demand-driven way.

Articles that place the two technologies in competition with each other often lose sight of the bigger picture — they both serve an important purpose in an enterprise’s architecture. Because they approach data from different perspectives, GraphQL can be a complementary technology to REST.

Implementing the GraphQL Integration Layer

So how do companies actually use GraphQL and RESTful services together? Many organizations write a graph layer on top of existing service and data layers rather than replacing them altogether. This federated graph layer abstracts the complexity of REST endpoints for client teams as the graph layer exposes a single endpoint for all operations instead of the otherwise hundreds of unique REST endpoints.

This architecture is often called a supergraph or a federated graph and was introduced by Apollo in 2019. It creates an abstraction layer that can replace most backends-for-frontends (BFFs) or experience APIs. Client teams can use a declarative query language to fetch precisely the data they need using a single query, with all composition occurring server-side. This approach reduces the number of client-to-server round trips required to fetch resources, especially ones with complex relationships. Implementing this type of architecture is simpler than it seems as it doesn’t require rewriting the backend stack.

For example, in a traditional client-API architecture, fetching a resource and a subset of properties from two related resources would require a total of three round trips to the server. The client would also have to compose the API responses, parsing through the entire payload and discarding unnecessary data.

👁 Image

A supergraph, by contrast, can fetch these resources on the backend. This leaves the responsibility of fetching data and composing it into the appropriate shape to a server-side application, which often has more compute power and lower network latency than client-side applications. These performance gains can be even more prominent if the client is a mobile app with a potentially unstable signal or lower data rate limits.

The combined GraphQL and REST API architecture also shows performance benefits when the backend service is not one API but a set of microservices. The same principle applies, but rather than eliminating three round trips to a single service, GraphQL eliminates three round trips to three services, each with its own network latencies and load levels.

Scalability Across Current and Future Clients

GraphQL offers an unmatched level of operational scalability because it provides a single façade to clients while remaining agnostic about the underlying data sources. Whether your backend consists of RESTful microservices, monolithic SOAP APIs or even other graphs, GraphQL can act as a way of exposing those data sources in a uniform way without the complexity of managing multiple endpoints and implementations at the client.

By providing an easily accessible interface for clients to request exactly the data they need, a GraphQL and REST architecture can speed up backend development as well. Rather than building one-off backends-for-frontends for each client, a supergraph promotes composability and reuse not just for current clients, but for future projects as well. This has benefits for both frontend and backend teams:

• With less one-off integration and orchestration code to write, backend teams have more time to focus on the underlying systems that power the product.
• Frontend teams can ship more clients or even implement micro-frontends, without relying on new and bespoke backend-for-frontends.

For companies with public APIs, a GraphQL implementation also provides a level of self-documentation that can be difficult to achieve with a REST API. The GraphQL server provides clients speedy access to the data being requested, while the backend services remain a set of highly structured REST APIs.

The hybrid GraphQL and REST API architecture also addresses a problem many companies face when attempting to scale their architecture: how to serve a diverse array of clients with various security, compliance or regulatory requirements. A pure GraphQL setup should not be completely relied on to manage the complexity of database access and the necessary business logic, while a pure REST API would present challenges associated with handling the diversity of data fetching required for an ever-growing number of clients. However, the combination of the two can be tremendously powerful in an environment where your architecture needs to scale to accommodate a growing variety of customers and client systems.

An Evergreen Architecture

The hybrid GraphQL — REST API design can holistically improve an architecture under pressure to scale. It allows an existing backend to remain untouched in the pursuit of greater client-facing flexibility. Layering GraphQL on top of REST rather than moving away from REST altogether saves the tech org the pain of a complete re-architecture. It’s all of the benefits at a much lower cost.

This design also allows the client-facing part of the architecture to develop organically and independently, without accumulating the tech debt incurred by trying to fit a highly structured relational model like REST into a flexible multiclient data layer. This means less engineering time spent on refactoring or paying down tech debt, and more time spent on building essential features.

The end goal of any tech stack should be to build a stable, scalable and profitable product. Breaking free of the traditional boundaries and integrating GraphQL and REST into a single architecture can allow greater flexibility and unlock paths for growth that would otherwise be difficult to achieve.