How to Use GraphQL to Build Backend-For-Frontend?
The de fact norm for any client-server or service-to-service communication is REST APIs. But different clients have different needs, and REST-like APIs end up.
Updated
On this page
Key takeaways
- The de fact norm for any client-server or service-to-service communication is REST APIs.
- Spending a lot of time on a single deployable resource can be caused by conflicting update requirements and the need to keep the service operational for both front ends.
- But eventually, we’re eager to use GraphQL and tailor it to the various business requirements to create a more flexible and effective API.
The de fact norm for any client-server or service-to-service communication is REST APIs. But different clients have different needs, and REST-like APIs end up over or under-fetching data. As a result, there is a disorganized I/O between the front end and back end. Calls to many services, third-party APIs, and so forth would be necessary for each page to render.
GraphQL and BFF Design Patterns #
A server-side runtime for queries as a query language for an API is part of GraphQL. GraphQL is developed to make APIs flexible, quick, and developer-friendly by putting the customer requirements first and delivering them precisely what they demand.
Integrating several backend services and sources gives each client a single interface to get only the data they require. Although GraphQL makes it simple to create BFFs, it aids in the resolution of some of these challenges. It enables the customers to specify their needs and only acquire those things. Additionally, it allows the server to specify the kind of data it can offer as DSL. Despite this, GraphQL and BFFs are not universally applicable solutions. We would always have to work backwards from the demand to fit the technology to the requirement.
This post will discuss the Backend-For-Frontend design and how developers may implement GraphQL to eliminate traditional REST APIs’ drawbacks.
Backend-For-Frontend (BFF) Pattern #
Make distinct backend services that can only be used by particular frontend applications or user interfaces. This method can be helpful when you don’t want to customize a single backend for numerous interfaces. Sam Newman was the first to explain this pattern.
Context and Problem #
Firstly, the software might be designed with a desktop web UI in mind. Usually, a backend service that offers the functionalities required for that UI is developed concurrently. A mobile application that communicates with the same backend is created as the application’s user base expands. The backend service transforms into a multifunctional backend that can meet the needs of both desktop and mobile interfaces.
However, a mobile device’s capabilities are very different from those of a desktop browser in terms of screen size, performance, and display restrictions. As a result, a mobile application backend has different requirements than a desktop web UI.
Due to these variances, the backend has conflicting requirements. Frequent and regular updates are needed for the backend to service both the desktop web UI and the mobile application. The backend frequently becomes a bottleneck in the development process since different interface teams frequently work on each front end separately. Spending a lot of time on a single deployable resource can be caused by conflicting update requirements and the need to keep the service operational for both front ends.
A different team may be formed to manage and maintain the backend because the development activity concentrates on the backend service. In the end, this causes a rift between the interface and backend development teams, placing the responsibility on the backend team to strike a compromise between the conflicting demands of the various UI teams. Before being merged into the backend, changes to the backend that are required by one interface team must first be vetted with other interface teams.
Solution #
Make a backend for each user interface. Without being concerned about how it will impact other frontend experiences, fine-tune each backend’s behavior and performance to best suit the needs of the frontend environment.
Each backend can be optimized for a particular interface because it is unique to that interface. It will be smaller, simpler, and probably faster as a result than a general backend that tries to meet the needs of all interfaces. Each interface team is independent and responsible for managing its own backend, independent of a centralized backend development team. The interface team now has language choice, release cycle, workload priority, and feature integration options in their backend.
Why is GraphQL The Go-to Technology for BFFs? #
A rising number of businesses are adopting GraphQL as an “API gateway” to simplify their microservices architecture or to unify their data into a single graph. There are many tools and SDKs for GraphQL that support multiple languages; thus there are numerous methods to build up your API.
Future of GraphQL Architecture #
You’ve already heard about GraphQL, a runtime and query language for open-source data. Not only React developers are enthusiastic about GraphQL. Developers working with Angular, iOS, and Android are interested in GraphQL’s features. Its popularity is rising quickly, and for a good reason: GraphQL provides solutions to several real issues that developers face daily. Because of this, organizations like Twitter, Intuit, and Drupal are implementing it.
A fresh engineer can utilize your API in less than 5 minutes thanks to GraphQL. To learn more about GraphQL, utilize it in your next project, and try to persuade your coworkers or boss to start using it, regardless of whether you’re a React, Angular, Ember, iOS, or Android developer. Many developers are just learning about GraphQL and finding a welcoming and helpful community of other beginners online.
Conclusion #
Many businesses, like PayPal, Courser, and others, were searching for a REST API substitute to develop unique solutions. Facebook developed GraphQL, which they released as open source in September 2015. Since then, big companies have adopted GraphQL at an exponential rate. Furthermore, the ecosystem is changing quickly. With all the lessons learned, technology will continue to grow over the coming years, easing the process for development and deployment at scale and operating in production.
We sincerely hope that this introduction has given you a better understanding of GraphQL and how it could improve data management. Like everything else, GraphQL has its restrictions and might not be the best strategy in every situation. But eventually, we’re eager to use GraphQL and tailor it to the various business requirements to create a more flexible and effective API.
Related reading