GraphQL as an abstraction layer

One of the advantages of using GraphQL is that it provides an abstraction between service consumers and the teams maintaining the backend services.

In a backend-for-frontend (BFF) architecture, each BFF connects to any number of backend services. As you add new BFFs for each application, the number of connections proliferates, and changes to any backend services have major implications.

Service migration example

Suppose a company has an architecture with ten applications, each with its own BFF. The company is migrating one of many backend APIs to a different technology. As a result of the BFFs owning data orchestration, the organization must update ten different BFFs.

To avoid breaking changes, clients must:

• be aware of what is happening during those change,
• track timelines,
• and track changes to field names.

If the company used GraphQL as an abstraction layer, the consumers wouldn't need to know about this change because the organization has abstracted backend APIs behind a graph schema. The only change needed is at the GraphQL layer.

As a company grows, this could eliminate hundreds of updates, deployments, and dependencies due to the reduced impact of changes to backend services.

Conclusion

GraphQL is a powerful tool for abstracting away the complexities of backend services from frontend consumers. It can shield consumers from major changes to those services while reducing the impact of those changes. Ultimately, it provides choice and control to consumers without negatively impacting backend services.

Further reading

• Using GraphQL and REST Together
• Blog post on xolv.io: How to Move from BFFs to GraphQL Federation