Backend for Frontend is a popular approach to solving the difficulties of providing both mobile and desktop application user interfaces (UIs). This is an essential aspect of app development today, as almost 60% of total web traffic currently comes from mobile devices, with this number expected to increase in the future.
Because mobile and desktop UIs have very different requirements, delivering an optimal experience for both can be difficult for developers. If both UIs use the same API, backend services can become bloated and slow, harming the user experience.
Backend for frontend, or BFF, solves this issue by creating separate gateways for each UI. By avoiding a single point of entry, BFF architecture keeps backends simple while improving frontend user experience.
In this article, we’ll explore the backend for frontend architecture so that you understand how it works as well as its benefits and challenges and what to consider if your new apps involve legacy systems.
Is BFF a microservices architecture?
The short answer is yes. BFF is a microservice architecture pattern that provides an extra layer between your backend services and the interfaces that access them. It’s a variation of the API gateway pattern.
Backend for frontend architecture essentially decouples your frontend interfaces from your backend services. This results in greater flexibility and tailored user experiences, which makes it an attractive alternative to the traditional approach of using one general-purpose API for all client requests.
How does the BFF pattern work?
The backend for frontend design acts as a “middle man” between your legacy systems or microservices and frontend interfaces.
You can add as many BFFs as you like, but it’s common to create one for each device type or user experience. For instance, you might create a BFF for mobile users and another for those on a desktop. Or, you could create one for voice search and another for mobile.
With this approach, you add another BFF API each time you want to accommodate a new type of user, preserving your core backend services and preventing APIs from over-fetching and over-requesting, which slows systems down.
Whenever an application needs data, it simply calls the relevant BFF, for example, a mobile app will call the mobile BFF. The data is then aggregated and transformed into a mobile-friendly format before being sent back to the app.
BFF programming simplifies frontend development and enhances the performance of backend systems. This helps keep client UIs simple so that you can focus on creating an excellent user experience.
A backend for frontend pattern example
Let’s look at an example of the backend for frontend architecture in use.
SoundCloud used to have a monolithic legacy system with a single API that served multiple frontends. These included the web client, mobile apps, and partner apps.
Every time a new feature was added, the size and complexity of the API grew. Modifications were time-consuming and challenging, and it was difficult to meet the needs of so many applications.
To address these issues, SoundCloud implemented a BFF design pattern, creating a BFF for each frontend use case and providing a better experience for users. To reduce the cost and effort of development, each individual BFF was based on the same library.
The BFF architecture also helped SoundCloud to modernize by enabling them to migrate toward a microservice-based architecture that worked alongside their monolith system.
Benefits of using a BFF pattern
Using a BFF pattern offers several advantages in comparison to using a general API for all UI types. These include:
- Faster services
- Shared ownership
- Easier maintenance and error handling
- Stronger security
Let’s look at these in some more detail.
Faster services
Backend for frontend can significantly improve performance. Why? Because different apps don’t have to fight each other for access to backend data. Instead, they access the services in parallel.
For example, a mobile banking app and a desktop banking app would be able to call the backend at the same time, leading to faster responses and a better user experience.
BFF can also prevent API over-requesting and over-fetching, reducing the burden on backend systems. This in turn reduces latency and speeds up service delivery.
Finally, BFF development cycles are faster as teams can focus on one application at a time and no longer need to sift through complex layers of code.
Shared ownership
The BFF pattern means frontend development teams share ownership of this layer with backend teams. At the same time, you can separate frontend requirements from their backend counterparts.
With this design, frontend teams have greater control over how applications work. They're better able to optimize the user experience and can make necessary changes to the BFF themselves instead of relying on backend teams. This results in higher development speeds and faster time-to-market.
Similarly, backend teams can focus more on maintaining and improving backend services instead of supporting the frontend teams.
Easier maintenance and error handling
By separating frontend and backend requirements, BFF also makes application maintenance easier.
Your backend teams can focus on making the necessary modifications to backend systems when they are needed. This speeds up maintenance tasks and reduces system downtime. Changes to one BFF also don’t have any effect on other applications.
Another impact of BFF is an improvement in error handling. Instead of displaying every error to the application user, the BFF can determine which they need to see and only display these. This improves user experience since users aren’t continually bombarded by meaningless error messages.
Stronger security
Finally, having an extra layer between your backend and frontend systems improves security. The BFF can filter out data from an endpoint response that isn’t needed for a particular application. It’s also easier to hide sensitive information from frontend users. Both of these make it harder for criminals to target your systems.
Plus, by having a separate BFF for each application, you can tailor security measures to different interfaces, making it easier to mitigate the unique security risks of each interface. For example, you could include a backup service and remote wipe feature for mobile devices at the same time as having strong password and encryption services for desktop devices.
How to solve the challenges of BFF architecture
Although the BFF framework can be used to solve the problems caused by using a general API for all UIs, it can also present some challenges. These include:
- Fan out
- Fuse
- Duplication
- Increased components
We’ve outlined the ways you can mitigate or even eliminate these difficulties below.
Fan out
One potential side-effect of a backend for frontend design pattern is “fan out”. As a result of using multiple APIs and services, BFF subsequently also involves multiple points of failure. Any one failure can result in cascading failures across the BFF system, which will impact users.
Luckily, there are several ways you can combat this problem.
- Fault isolation: Create a termination point between each BFF and the services it provides access to. This way, if a backend service has an issue, it won't affect the rest of the BFF layer or frontend applications.
- Caching: Cache data that's frequently accessed so that if a service is unavailable, the BFF can return the cached data instead. This way, your UIs can still function.
- Service monitoring: Use BFF monitoring to track the performance of your backend services and resolve issues before they can cause a failure or further serious issues.
Fuse
“Service fuse” is when multiple BFFs share the same backend service. A failure in this set up can bring down all your BFFs and their associated UIs.
The only way to solve this problem is to deploy the service separately for each BFF and use fault isolation. Therefore, if the service fails for one BFF, it won’t affect the others.
You should also be aware that if one database is shared by multiple services it may become a fuse instead. In this case, you can either create separate databases or will have to accept the possibility of a fuse as a technical debt.
Duplication
Another potential problem is the duplication of code. Because different teams will be responsible for developing different BFFs, lack of communication can lead to repeated efforts and higher costs.
One solution is to ensure effective communication between different development teams. Also, if certain code or functionality will overlap between projects, consider creating a shared library that everyone can add to. This way, different teams won’t be wasting effort by writing the same code.
Increased components
The more BFFs you create, the more components you’ll have to manage. This increases system complexity and, potentially, cost. It can also make it difficult to know who’s responsible for maintaining each component. Furthermore, this issue will be exacerbated by needing to deploy services separately to prevent fuses.
Automation is one way to mitigate this, as it relieves a lot of the burden on your development teams. It’s important to clearly define responsibilities for each team and ensure clear communication between them when using automation.
In addition, consider which BFFs are necessary. For example, the user experiences for an Android analytics app and an iOS analytics app are similar enough that you don’t need to create a BFF for each. A single application for both types of devices should suffice.
Data sourced from statista.com.
When should you use a backend for frontend pattern?
Now that we know what the benefits and challenges of using the BFF pattern are, we can consider what the best use-case scenario for this architecture is.
|
You SHOULD use BFF if: |
You DON’T need BFF if: |
|
|
How can OpenLegacy help you with BFF microservices?
A useful microservice architecture pattern, backend for frontend caters to a range of frontend users and applications. OpenLegacy can help you unlock the potential of your legacy systems with BFF.
Our approach breaks down your legacy monolith into independently deployable microservices. This simplifies maintenance and lets you create a tailored experience for each application that accesses your services. These microservices are highly scalable and flexible, so they can grow as your enterprise does.
What’s more, with a BFF microservices approach, you can optimize resource usage, improve performance, and reduce time-to-market.
Schedule a demo, and see how OpenLegacy could benefit your business today.
FAQs on backend for frontend
What is backend for frontend?
Backend for frontend is a microservice architecture pattern that creates a layer between backend systems and frontend applications.
BFF works by creating a dedicated API for each user interface or device. This not only preserves the core integrity of your backend services but also lets you create a tailored experience for different types of users.
What is the purpose of BFF?
BFF helps overcome the challenges that arise from having a single API for all UIs. It improves the performance of backend systems and enhances the experience for frontend users.
BFF software development uses compostable architecture to create a tailored API for each type of user. It’s quick and easy to accommodate a new UI or device一just add another BFF.
How is BFF different from a traditional backend?
The main difference is that BFF technology uses separate APIs for different UIs or devices, instead of accessing all of them through just one API.
Traditionally, if you wanted to accommodate a new UI, such as for a mobile app, you’d have to add more functionality to your API. This causes the API to become more complex over time. Because it has to handle calls from all your applications, the system will run slower. Maintenance and upgrades can also become tedious and difficult.
With a BFF pattern, each device or UI has its own API. Applications can call the backend in parallel, and you can tailor each BFF to the individual user experience. This improves performance and reduces the burden on maintenance and development teams.
We’d love to give you a demo.
Please leave us your details and we'll be in touch shortly