Hello, dear readers! Welcome to my blog. On this post, we will talk about a pattern that it is emerging from the boiling microservices hype to issue some problems between backend and frontend integration: the BFF pattern (Backend for frontends).

Thoughtworks & Soundcloud

The BFF term was coined by Thoughtworks from their experience on a project for Soundcloud. On that project, the goal was to migrate a monolithic system made on rails, towards a microservices ecosystem. That legacy system was serving several different interfaces, such as IOS and Android applications, web applications and so forth. The following drawn extracted from the thoughtworks site – see links for the original –  illustrates the AS-IS of the soundcloud ecosystem:

The problems began to arise as the microservice’s  ecosystem grown up, since as the services keep coming, the complexities for the front-end teams, responsible for consuming the ecosystem, scaled up from issues coming from complex orchestration to overhead caused by extensive message payloads which in some cases the interface doesn’t need.  This is a issue specially on mobile front-ends, since the overhead can lead to high memory consumption,  undesirable on mobile environments.

That issues leaded not only to technical problems but also to communication problems as well, since the front-end teams needed to address the refinements to the back-end teams, which needed to be convinced about the changes. This problems made the ecosystem harder to evolve, since the issues started to incur on delays on the schedule, harsh communications between teams, etc.

So, what was the solution for the problems faced by the project? Let’s find out.

Solution

To solve the problems, the project team came with a concept they coined as BFF (Backend For Frontends). On this pattern, the interfaces – or front-ends – instead of consuming directly the microservices, consume a facade layer, responsible for implementing all the orchestration and transformation necessary in order to simplify the complexity and payload overloads to the front-end. Three key points are worth to note on the approach taken by the team:

• The BFF layer is composed by several microservices which act as a facade for the different features of the system. As such, the components of this layer must be constructed with a feature-driven planning, meaning that they typically must be feature-grained;
• Since the focus of the construction is to serve as a facade for the front-end, the BFFs are constructed by the front-end team, which is responsible for them;
• The objective of a BFF is to serve as a facade to a specific feature for a specific interface. So, if a given feature is needed to be exposed to different interfaces such as a web interface and a mobile interface, then 2 different BFFs must be constructed to tackle the problem;

The drawn bellow shows the solution in practice:

The reader may notice that, on the drawn above, the BFFs are talking to a API on the monolith itself, instead of microservices. The reason for this is to demonstrate another benefit of the pattern: since the BFF layer abstracts the access between the front and the back-end, it eases the migration from a monolith architecture to a microservices architecture, by constructing the BFFs first. Not only that, but it is also possible to make “chains” of BFFs, where a BFF can reuse the logic already implemented by consuming another BFF, as we can see bellow:

Conclusion

And so we conclude our exploration of the BFF pattern. With a simple design, we can empower a microservices ecosystem, allowing the interfaces to make a better use of the architecture. Not only that, but it could also make a useful tool to facilitate a migration between the old monolith application and the new world of microservices. Thank you for following me on another post, until next time.

• Source article from thoughtworks:

https://www.thoughtworks.com/pt/insights/blog/bff-soundcloud

• Good article about BFF:

http://samnewman.io/patterns/architectural/bff/