What is Backend for Frontend Pattern?
This pattern says that you create one backend per user interface. So if you have multiple user interfaces, say Mobile and Desktop-based UI, then you create one backend for Mobile and one backend for Desktop.
One backend per-interface allows you to fine-tune the behavior and performance of each backend to best match the needs of the frontend environment, without worrying about affecting other frontend experiences.
What are the advantages of Backend for Frontend Pattern?
- Each backend is specific to one interface, it can be optimized for that interface. Also in this case, each backend will be smaller, less complex, and likely faster than a generic backend that tries to satisfy the requirements for all interfaces.
- Each interface team has the autonomy to control their own backend and doesn’t rely on a centralized backend development team.
- This gives the interface team flexibility in language selection, release cadence, prioritization of workload, and feature integration in their backend.
- If you are changing the backend, you don’t have to get it tested with all kinds of user interfaces.
What the need for Backend for Frontend Pattern?
Consider an application was initially be targeted to be used as desktop web UI. So you created a backend service in parallel that provides the features needed for that UI.
As the application’s user base grows, a mobile application is developed that must interact with the same backend.
The backend service becomes a general-purpose backend, serving the requirements of both the desktop and mobile interfaces.
But the capabilities of a mobile device differ significantly from a desktop browser, in terms of screen size, performance, and display limitations. As a result, the requirements for a mobile application backend differ from the desktop web UI.
These differences result in competing requirements for the backend.
- The backend requires regular and significant changes to serve both the desktop web UI and the mobile application.
- Often, separate interface teams work on each frontend, causing the backend to become a bottleneck in the development process.
- Conflicting update requirements, and the need to keep the service working for both frontends, can result in spending a lot of effort on a single deployable resource.
As the development activity focuses on the backend service, a separate team may be created to manage and maintain the backend.
Ultimately, this results in a disconnect between the interface and backend development teams, placing a burden on the backend team to balance the competing requirements of the different UI teams.
When one interface team requires changes to the backend, those changes must be validated with other interface teams before they can be integrated into the backend.
What are the key points to consider when implementing Backend for Frontend Microservices Design pattern?
- Consider how many backends to deploy.
- If different interfaces (such as mobile clients) will make the same requests, consider whether it is necessary to implement a backend for each interface, or if a single backend will suffice.
- Code duplication across services is highly likely when implementing this pattern.
- Frontend-focused backend services should only contain client-specific logic and behavior. General business logic and other global features should be managed elsewhere in your application.
- Consider how long it will take to implement this pattern. Will the effort of building the new backends incur technical debt, while you continue to support the existing generic backend?
