BFF

Intro

Heard recently about BFF. I have used it before, however, I like when people, become enthusiastic about a technology. It is so interesting almost funny, it also drives the incentive to discover it more.

I have refreshed myself on the topic, read a couple of articles and spotted a pattern. This article is about the dissonance I am feeling, after I used BFF, with what is being written about it, and what can be truly beneficial about it, in my opinion.

A little bit about the name

"Backend For Frontend" - if you call it this way you follow the usage coined by Phil Calçado PhilCalcado.com - BEFFE, however, it was shrunk to BFF by Nick Fisher. I think Phil Calçado is the first who described this pattern, though.

"Backend For Frontends" - if you call it this way you follow the usage promoted by Sam Newman SamNewman.io who adds some additional flavors to it.

Description

As PhilCalcado.com describes, it is a pattern that facilitates communication between FE with only one BE. For example segregated between Web and Mobile, you have one Mobile FE communicating with Mobile BFF, similarly for Web.

However, how it is used in reality or at least how I have seen it used, is that each domain be that, invoice, order, bill, contracts, etc. has it's own BFF. This is closer to how Sam Newman describes it SamNewman.io, however, at an even more granular level.

So it may solve the problem for the FE, as FE doesn't need to call various services, however, it just shifted towards BE.

Now, what it means to add a single field in a form? I will show two cases, the preferable one, and the worst case one.

Preferable flow to add one field

There are 3 PRs needed to add a single field. Just for visualizing it, each PR consists of:

Open PR
Receive approvals
Merge it
Deploy it on DEV
...

Worst case flow to add one field

Phil Calçado's PhilCalcado.com diagrams show they were making similar calls from BFFs, ending up defining a new layer to handle them, the so called "Application Service". I think they came to this solution because they didn't allow communication between Services in the first place, so they ended up building an additional layer. I would rather allow services call each other. Sam Newman also proposes the architecture where Services can call each other as an alternative.

Sam Newman proposes BFF for third party integrations also. I think the reason is that API can evolve internally quicker, and a BFF layer can help keeping a backward compatible communication.

How it is being promoted

BFFs can call any service, if required. I guess it also means that if the delivery is streamlined per domain you are still constrained to keep the backward compatibility at the service level because other BFFs, not from your domain, may call your service. Isn't it somehow evident or I am missing something ? I see this as an overhead, these systems hardly evolve, or evolve slowly(through API versioning), consequence to interdependencies.

However if you change the approach and allow services to communicate at the same time ban BFFs to call other services except from it's own domain then the meaning of BFF is diminished. You can directly send the response in the format FE expects without an intermediate layer to agregate info. ¯\_(ツ)_/¯

Maybe I am wrong, but I have started to think that the incentive for this patterns is driven by the rule of disallowing Services to communicate between them and, most probably, to avoid single point of failure provided by using a gateway layered architecture.

Conclusion

Putting everything together I realized the dissonance between how I have seen it used with how it is proposed to be used by authors, and how articles on this subject propose it. It took me a while to dissipate feelings about it and start objectively analyzing.

The way Phil Calçado describes it, makes a lot of sense to me, as they evolved their approach to a BFF layered one. And they coined it over an app with Mobile and Web interfaces. It dissonates with how I have seen this architecture applied per domain, where each team hold ownership over their BFF, and due to the lack of service gateway/discovery we had to maintain hard-coded urls per environment. I also found it cumbersome to implement changes on Service layer still having to cascade them to BFF layer. The amount of DTOs is big and redundant. Can be solved using libraries, but we weren't.

It is amazing how SoundCloud allowed projects to evolve. It was a well-founded process, every step was a particular solution to an emerging problem. This leads to concluding that an application evolving to BFF becomes much more suitable than it being applied from the start, as it just disables the teams to tailor their approach to client needs. Basically they loose adaptability. Isn't it an important factor?

Adding a new field means at least 3-4 PRs. There is a bunch of logs to consider to find a defect root cause. Each request consists of FE->BFF->Service->BFF->FE => 4 request, 8 message marshaling/unmarshaling, 12 chances something is not working(DB excluded). Code duplication is a concern. An additional layer is an overhead to me.

As opposed to gateway layered architecture BFF avoids single point of failure. Which has its benefits.

Overall it is an interesting approach, and while writing this article I became less reticent to using it in a gradually evolving manner as Authors describe it.