Why “Backend For Frontend” Application Architecture?

One of the hallmarks of digitization’s success is the widespread adoption of applications, from mobile to client apps, as the benchmarked standard to serve, interact, and communicate with users. And few things have played such a significant role in this evolution as Microservice Architecture.

As one would imagine, the requirements of mobile and desktop applications differ significantly. With technology evolving rapidly and consumers’ needs shifting constantly, it becomes increasingly complicated to serve both desktop and mobile-based apps with the same backend microservices. With separate teams working on their respective frontend application interfaces, all it takes is a single bottleneck on the backend to derail the progress if it fails to satisfy the demand of the application. And as any developer knows, this complexity, this opportunity for error and misalignment will only certainly translates to a diminished experience for the user.

But it isn’t the only way.

Backend For Frontend Architecture

Backend For Frontend (BFF) architecture is the key to enhanced and improved user experience. A BFF layer consists of multiple backends developed to address the needs of respective frontend frameworks, like desktop, browser, and native-mobile apps. One of the biggest appeals of BFF is it ensures seamless user interaction regardless of the platform the frontend application is running on. It also enhances the overall efficiency of smart devices’ as the applications developed following BFF architecture optimize resource usage while the application is in use. In BFF, there are APIs for specific uses; significantly reducing the surface area that needs to be secured while greatly enhancing user confidence.

In monolithic applications, APIs contain unnecessary data that is sometimes of no use for consumer applications, or at best, a single frontend application instance. Let’s take the example of banking transactions. If the user wants to know their last transaction, a frontend application running on the smartwatch only needs the transaction amount from the API. Developing a generic API in such a case will have unnecessary data in response that’s of no use for a smartwatch but could be used for the client app running on the browser. Such an API will cause overhead on smartwatch applications. Developing a dedicated BFF backend for the smartwatch would help achieve an optimized solution, not only void of overhead cost, but would actually improve the user experience.

Filling the Design Gap

In BFF application architecture, development teams create a dedicated backend application or service for each frontend application interface. Such a backend service only fulfills one frontend application interface like web, mobile, or any other interface developed in different frontend frameworks. Developers can further fine-tune each backend service to best meet each interface’s needs without worrying about dependency.

The backend system in BFF architecture is different from traditional APIs. In general, public APIs or monolithic backend applications serve the need for web and mobile-based applications with the same endpoint. The diagram below depicts how an open API serves the different frontend applications developed in a different framework.

On the other side, BFF facilitates each frontend application interface to directly fetch the data from the backend system’s respective microservice. The diagram below demonstrates how “Browser BFF” and “Mobile BFF” are two backend interfaces developed to serve a unique requirement.

The Benefits of BFF

BFF is impacting the development community in many positive ways and here are just a few reasons behind its appeal:

• Multiple frontend application interfaces can call their respective BFF backends in parallel, and dedicated backend services can respond faster.
• Following BFF architecture reduces the time to make modifications and enhancements in backend systems with dedicated teams working on the upgrades.
• The BFF layer in the overall system architecture can benefit from hiding sensitive or unnecessary data before transferring it to the frontend application interface, which helps simplify the system.
• BFF backend systems can use any protocol like FTP, SOAP, REST or GraphQL to request data from microservices, but still use a single protocol when interacting with the frontend application interface.

The Challenges of BFF

While the appeal of BFF is evident to even the most novice developers, it’s common to encounter challenges and important to consider them before following BFF:

Fan Out: In BFF, a breakdown of the single service can bring the entire BFF system down. The below diagram shows how a crash in the backend system can cut off your one frontend application interface from the rest of the system.

Fuse: In the BFF layer, any microservice downtime that responds to multiple BFFs can impact the whole system. Below represents how a failure in microservice Sa is changing the three different BFF backends.

Duplication & Reuse: There is a high chance of code duplication as multiple development teams take care of different BFFs. In the case of communication gaps, the same implementation can happen across BFFs, making the development cost double.

Extra Services & Components: Not following the right DevOps practices can lead to unwanted deployments that could create unnecessary backend components running on your server or cloud, occupy resources, and result in slower response time.

Overcoming these Challenges

Challenges are meant to be overcome and those standing in the way of the benefits of BFF easily fall into the category. Here are a few solutions to the challenges mentioned above:

Solve Fan Out: To prevent the software system from going down just because of one BFF layer, developers should implement fault isolation mechanisms. For this, ideally, each BFF service would have its own termination point. As the number of deployments increases, the system will have better fault isolation and high software availability to end-users. It’s helpful while designing a software system, rethink when and what services to be split.

Remediate Fuses: This approach is only possible if there is no dependency among the BFFs running under the system, and there is no shared database involved. If services have to share databases, then chalk this one as technical debt, which will be solved partially by eliminating fan out.

Reuse: In case some features will overlap significantly between different BFFs and development teams should identify shared characteristics that can be developed under a single BFF service to be reused. This reduces development costs and decreases time to market.

When to use BFF Architecture?

Just like every software design pattern has its benefits and challenges, it can also be said that they have their own ideal instances of usage. The decision to choose the best fit for your software depends heavily on features and circumstances, but here are a few points worth considering:

• If your software system is supposed to use a shared or general-purpose backend service that takes significant time to develop and is hard to maintain, consider BFF. It can significantly help reduce time and cost.
• If functional requirements across different frontend application interfaces (mobile and web-browser, etc.) are significantly different, having a dedicated BFF service for each of your frontend frameworks will drastically reduce maintenance complexity.
• In case your software system needs to develop the optimized backend for a specific frontend interface, BFF is a suitable option.

Take Away

Backend For Frontend is a design pattern created with not only the developer but, more importantly, the user and their experience in mind. It is the answer to the ever-growing adoption of applications to meet, interact, and serve customers, ensuring consistency while still meeting their diverse and evolving needs. And while BFF, like anything, is not without its challenges, I hope that I have not only shown you how to successfully mitigate them, but convinced you that its benefits would undoubtedly outweigh any difficulties along the way.

The above was written in collaboration with Uzi Murad, Account Executive, and Imran Salahuddin, Senior Manager, Software Engineering, both of mobileLIVE.

Like what we say? You’ll love what we do. See for yourself.