Category: Architecture pattens

What are we talking about with BFF?

I had a quick chat recently on using this pattern or not for a brand new platform we are building. My reco was not to go for it anytime, I propose to explain here why.

Several blog posts describe this pattern quite efficiently. For a detailed description, you can just have a quick look here or here. To make it short, lets consider it as the correct pattern for ATAWAD anti-pattern.

> Read more about ATAWAD anti-pattern

When talking about cloud and how to design "digital" modern IT systems, microservices and APIs sound to become mandatory.

As front-ends needs are heterogeneous in terms of required features, performances or connectivity, using the same services (APIs) is a non-sense. The backends for frontends pattern takes that into account and proposes an intermediate layer for specific needs of each channel :

Using the wrong tools or the right tools the wrong way…

The concept is definitely interesting, I would even say mandatory when talking about system with high numbers of transactions or a lot of underlying "back-end" services. The possible complexity and risk come from the implementation of such a pattern.

When back-end is not at the back

First beware of misunderstanding. BFF is a matter of front-ends and what is considered to be a back-end for a mobile app. I.e. : the rest of the world, i.e. : a middle-office in a world of appropriate architecture design.

As stated above, accessing business microservices directly from front-ends can become quite a challenge and complex in case of huge number of such services. In addition, complexity of an IT system tend to increase over time (yes it does :-)), and what was initially a quick win can easily become another famous anti-pattern : the Big Ball of Mud. Anyone knowing a bit of legacy systems will recognize here the "normal pattern" for doing IT.

In fact, issues don't come from the high number of services, but from the high number of things exposed which should not be services.

Defining appropriate services requires appropriate business domains management. "Management" is not only a clear definition of a domain boundaries but also the team structure to ensure overall consistency of IT solution and roadmap. We might discuss Domain Driven Design for Agility and microservices (aka scalabily and fault tolerance solution) in another post.

This BFF is mine

When comes the question of introducing a channel or device specific layer comes the question of who owns responsibility for its implementation (not even talking about maintenance). You'll face three main challenges :

1. Usually a new component implementation comes from a specific business need. As a consequence, new developments (even for front) will be tight to some really limited set of business domains, not to say one.
2. The frontend team deals with frontends. This seems obvious, but this means that most of the time, a frontend team will not have the relevant technologies, tooling and legitimacy to deal with lower architecture layers.
3. The solution shall come from an independant team, lets say the one in charge to define a consistent, future proof architecture, i.e. the architecture team. Unfortunately most of the time architecture teams do not have custom components implementation budget (and even less if you think about services embedding business).

Keep it for what it is : a commodity abstraction layer

As a consequence, avoid as much as possible specific developments when dealing with BFF pattern. Coming back to basics, the BFF pattern is only a concept of introducing a technical abstraction, filtering and routing layer. When talking about overall infrastructure, this is the definition for API gateways between an IS system and the external world.

Such capabilities are meant to ensure performance, caching, security, throttling with external world. Nothing new here. It's just bringing additional business value to the "DMZ" infrastructure concept :

It can also enable service composition between multiple IS sytems. On french market for example, mutual insurance associations M&A (Mergers and Acquisitions) are increasing. Rebuilding core legacy systems at such pace is nearly impossible. However, frontends for clients and employees need to be harmonized. In such case, "internal" API gateways prove to be of great use to enable smoother transformation roadmaps :

We have these exact two needs when talking about BFF pattern : ensure appropriate throttling and security per channel and loose coupling of Business Domains services :

The BFF pattern alone is useless

If the BFF pattern itself can be quite convenient, it shall only be seen as a technical mitigation plan and combined with root causes of possible problems remediation :

• A given channel is expected to have massive read access to specific data : lets optimize Data Access and caching
• On the other side, a given channel does massive updates and inserts which could jeopardize back-office processes (quantified-self measures, online orders... ) : lets put in place CQRS pattern.
• You fear for your business services scalability and fault tolerance : lets design microservices and go for containerization.

An IT solution is often a future business issue

Unfortunately, an IT solution is most of the time not a solution but a future issue (e.g. : Legacy systems). Whereas a business solution can become an IT standard (e.g. : Big data approaches) .

The real solution to introduce loose coupling between channels and business services and both keep your IT under control and have Agility is not by building intermediate services. As we start to see with the above examples, root causes and appropriate actions can only be found with business needs and associated Non Functional Requirements analysis.The underlying Business Domains and associated services will be the key to success (or failure).