Where Does GraphQL Fit In the Stack?

GraphQL is a popular language, and it’s getting more popular by the day. We hear front-end developers, mobile developers, and back-end developers talking about GraphQL. So it’s clear that developers use GraphQL across the stack. But where exactly does GraphQL fit in the stack, and what benefits do you gain by using it?

In this article, we’ll first do a quick recap of what “the stack” looks like without GraphQL, and then we’ll dive into how adding GraphQL changes it and what that means for building applications.

The Stack Without GraphQL

An architecture without GraphQL will usually consist of three layers — the UI layer, the service layer, and the data layer. The specific structure of those three layers will look different depending on the size and needs of the company.

UI Layer

The UI layer consists of all clients that interact with any backing APIs (the service layer). Including web apps, mobile apps, streaming devices, kiosks, etc.

Data Layer

The data layer consists of all the data stores accessed by the service layer. Depending on the architecture of the service layer, the data layer could take on many forms.

Service Layer

The service layer exposes one or more APIs to the UI layer. It can take on many different shapes, but for now, we’ll cover three common architectures:

1. Client-to-service — The service layer consists of internal and external APIs exposed to the UI layer, creating a direct client-to-service relationship.
2. API Gateway — The service layer consists of a single API that sits in front of other backing services. Clients interact only with the API Gateway.
3. Backend-for-frontend— The service layer consists of multiple smaller APIs responsible for one or more clients that sit in front of other backing services.

While these architectures are functional, they fail to expose more capabilities to the UI layer without forcing more complexity on the clients. The constantly increasing number of endpoints makes managing communication with the service layer difficult. As the number of endpoints increases, the client’s ability to iterate decreases.

The service layer often evolves into architectures like the API gateway and BFF patterns to prevent the clients from managing many endpoints. However, even with APIs explicitly built for a few or even a single client, they still have the problem of an increasing number of endpoints as the API surface grows.

Adding GraphQL into the stack solves this problem. Let’s dive into what this means and closely examine how GraphQL changes the stack by introducing a new layer called the graph.

The Stack With GraphQL

GraphQL serves as the doorway into the graph layer. The graph layer fits in between the UI layer and the service layer. It brings all of a company’s data and services together into one consistent, secure, and discoverable interface so that anyone can access it through a single endpoint.

Because the graph layer only exposes a single endpoint through GraphQL, it decouples the UI from changes further up the stack, and it will always remain a single endpoint, no matter how large the service layer and graph layer may get.

Clients can now focus on building the product instead of building the infrastructure needed to manage all the endpoints from the service layer. Inversely, the service layer can evolve freely, without worrying about affecting clients.

Conclusion

Let’s return to the original question: where does GraphQL fit in the stack? We’ve uncovered that using GraphQL changes application architecture by adding the graph layer to the stack. So GraphQL does more than fit into an existing layer in the stack — it forms the foundation for a completely new layer.

With the graph layer in place, clients can access what they need through a single endpoint. In addition, the reduced surface area allows developers on both the client and server sides to build independently, creating a more flexible architecture.