BFFs could be your new Best Friends Forever

Thank you, thank you John. Thank you so much for the lovely introduction. And as you mentioned, BFFs stand for backends for frontends. How many of you here have worked on BFFs or know what BFFs are? Oh, cool. A lot of you. Amazing. So I'm sure you will be able to relate to a lot of things that I talk about.

In this talk. So let me start by sharing a story. Okay, that's enough. So as you saw in the video that there used to be simpler times when you just had a simple frontend packed or served by a simple backend.

But with time as technology improved, so did a lot of our new devices, right? So we have now a lot of different types of frontend channels. And these front-end channels, they have very different requirements on how they represent the information, but they're currently still being served by the same backends, adding a lot of complexity at the backend, making those backends more like a monolith.

Now, over a couple of years, a lot of companies have been trying to move away from this monolithic architecture into a more microservice-oriented architecture. However, this change is not that easy and the problem is still the same. Even if you have got different microservices, they provide a generic API response and your front ends, when they consume that response, they have to manipulate it a lot to be able to represent it to their users, right?

So it is still the same. However, well, I have to say this, that if you have a really good architecture, then you might not really need it, but if you are still in that space of moving away from your monolith to microservice architecture, learning new things, then yes, definitely the problem still exists. Solution, we have BFFs.

So what is a BFF or a backend for frontend? A backend for frontend is not a backend, not a frontend, obviously. It is a thin layer that exists between your frontend and your backend. It is a very thin layer that acts as a custom backend for particular user experience.

So if you have an Android user experience, that BFF would actually be acting as a pseudo backend for your mobile experience or Android experience. Now, it has no business logic in there. There is literally no business logic. It is just there so that you do not do all that manipulation that you were doing in the frontend.

You instead do it in the BFF. Now, let's talk about an example. So if your front end was calling your backend for everything, instead, what it would do is it would actually call your BFF once, and then your BFF would make rest of the calls for you, and then finally give you the response, the way you need, the way your front end can easily consume it without having to manipulate it a lot.

Okay, so let's actually talk about some of the benefits of a BFF. First one being easy to maintain. Now, obviously, if it is a very thin layer, there is no business logic, you can actually maintain it easily. You can deploy and manage it independently. And who is the best team to manage or be responsible for it? It is your front-end teams, because they know.

What really needs to go in there. They know how their front end wants to consume that information. So if they create their own BFF, it is so much easier to delegate that responsibility to that team and have that vertical kind of an architecture. Next one would be resilient to API changes.

Now, say your backend team decides they want to introduce a new version. Or they just want to change the response that is coming from the APIs, right? Now, your front end might not be ready to consume it. So what you can do, you can actually use that BFF layer where you can transform that response and then directly consume it.

In fact, you can actually continue to use multiple versions having a BFF. You can actually slowly then go for graceful degradation. And change the versions later on. We currently have that use case in Prezi. Another thing is, if your APIs are experiencing a downtime, then you can actually cache the response in your BFF and then serve the content from your BFF, the cache response.

So your frontend has now decoupled and thus even if your API is experiencing a downtime, your frontend is still live. At least for the get calls, right? Um, finally, better error handling. Now, there, there can be a lot of different kinds of errors that come, that are thrown by the APIs and not necessarily you, you would be reading all kinds of errors from your front ends.

Again, you have your BFF and that little BFF layer you can actually use to read through those errors in a much better way and provide a better response for your users, more meaningful responses, better error handling. So, I know I've been talking about so many benefits of BFFs, but I have to mention one of the caveats, which is that your mileage may vary.

It really depends how you are actually implementing it. My experience at Prezi has been pretty positive. I have observed a good change even in the latency, to be honest. So talking about latency and reasons why I said your mileage may vary, you would have a question, hey, hang on, you're actually adding a layer. So what about that latency bit, right?

So I would ask you, how much data are you actually retrieving? And how much data are you actually processing? It really depends. There needs to be a balancing act between the two. So let me show you an example. So at Prezi, we sell gift cards, and let's go through a gift card buying journey.

So an order is placed by a customer. So a front end would actually make probably a call to the backend to create a draft order. The second one would be go back, come back again to create like a payment intent, go back, come back again and maybe we use third party tools, stripe or something, complete the payment, go back, come back again and maybe then fulfill the order.

So this back and forth is continuously going on between the frontend and backend, but once you introduce the BFF layer, then you just call your BFF once. Give it that information it needs, and then leave it up to the BFF to do all those calls and talk to your backends. This way, you minimize a lot of back and forth that is going on between your frontend and your backend, make it a much more simpler call from your frontend.

And what you can also do is you can actually place your BFF closer to your backend, maybe in the same system or same availability zone. And this way you can minimize the latency. Another example, we have like a wall of cards, so all the gift cards that we sell at Prezi. Now, obviously it is not something that updates like too frequently, so we can still serve the results from the cache.

So if we do that, we actually save some more time and do it. Another question you may have that, hey, so if we create multiple BFFs, we would be doing a lot of code duplication. So to that, I would say, I know a bit of code duplication, but it is much more targeted code, really, if you look at it. So, okay, another example.

So consider that when you are using your mobile apps, or you only want to show straight up card information, you don't want to load the whole list of cards, but there is web and web wants to do the whole list. The interfaces are different, the requirements are different.

So you might be doing a different kind of call for that, a different kind of manipulation for it. So it is more targeted code, really. And the best part is actually you are decoupling, even though there is a bit of duplication, you are decoupling your front end from your backend. So you are making it much more fault tolerant, you can make it scale independently, and there is more flexibility.

Now, let's actually discuss an example scenario at Prezi. So we used to be happy with a simple website, which was served from the backend, but then we grew. We grew and our website became consumer web. We also introduced a mobile channel. There's another frontend, which is Prezi Business.

There's another one which is Prezi resellers. With Consumer Web, it's just normal website, fine, good. With mobile, the other things are you can actually have push notifications, you can have geolocation data, you can also do video uploads which may not be possible in Consumer Web. With Prezi Business, the requirements could be, it is for businesses to place bulk orders, look at invoices, they have a very different interface.

And Prezi resellers, these are like the APIs that our clients can use to sell gift cards to their customers. So it is more of a B2B2C and we do not even have a front end for it. So again, these channels are very different. They have very different needs of consuming the data. So even though we at Prezi have been trying to move away from a monolithic architecture to a service-oriented architecture, we need something more and we need BFFs.

So this is version 1.0 that we propose. Okay, let's do one thing. Let's create a web BFF which will serve your consumer web, an Android for the Android app, and iOS 1 for the iOS app, and then their business BFF which could do both Prezi Business and Prezi resellers. Okay. Looks good.

We're happy. It would work. But how many BFFs are the right number of BFFs? Okay. Now that really depends on the things like, what are the code bases like? What are the teams like? Are there different teams? They're working differently. They have different release cycles.

What is the feature parity? What is the product roadmap? Those kind of questions, they really define on how many BFFs would be the right number of BFFs. So at Prezi, we thought, hey, so our Android and our iOS app, they need to have a feature parity. We have the same single mobile team that is working on it.

The code bases are shared, the version control is there. So, It might be actually better to instead have a mobile BFF. So we just have a mobile BFF. On the other hand, we realized for business, actually, Prezi Business and Prezi Resellers, they have two different teams.

They have very different product roadmap. They have very different features. Prezi Business has an actual interface, while Prezi Resellers really do not. They support different modes of payment. So how about we break it and have their own BFFs? So it really depends on your use case.

Now, I have to mention, neither too many BFFs nor too many microservices is going to solve your problem. It really depends on the use case and how effectively are they doing it. And again, it's never effective, is it? You're always changing things. Okay, now let's talk about BFFs with micro frontend architecture.

Before we do that, how many of you, I'm sure you all have worked on micro frontend architectures. Is there anyone who has not? Amazing. That's fine. So what is MFE or micro frontend architecture? If you are not aware, then it actually allows you to decompose your frontend application into little micro frontend applications that could be managed semi-independently and they work loosely together.

It makes it so much easier to develop, separate teams can work on it, they can release separately and it just works. So another example, we saw that, okay, with Prezi Business we actually have two MFEs. One is the portal and the other one is for campaigns. So the portal is all about checking invoices, placing bulk orders and campaigns is all about running promotions, discounts, etc.

Etc. And they're still being served from the same BFF. They have different requirements. There are two separate teams. So why not we actually create two separate BFFs? So now what we have done here is a business BFF serving the prezi business portal, a campaigns BFF serving campaigns and managed by the campaigns team. What we have done is we have created a vertical, the whole slice managed by a single team.

We have gone vertical, which is a really effective architecture to have. It makes it so much more easier to develop and release. Okay, now I know I have been boasting all about BFFs and why choose it? Why is it so good? Yes, it helps you with the specialized front-end needs and no, it helps with the performance optimization, gives more team autonomy, and you can even implement fine-grained security measures such as hiding sensitive information or reducing the risk of exposure exposing any critical information to unintended clients.

You can do a lot with BFF. Again, no business logic. But why not to choose a BFF? It is a thing there, I know, but it still needs developers. It still has a development complexity. You would still be creating resources. There are infrastructure costs, there are maintenance costs.

So there is an increased cost there. And if you are working on a smaller project, it might just be an overhead, really. You can then continue using your monoliths. Monoliths are not that bad either. And the finally, API synchronization. So if you have your backend APS, which I mentioned, say there's a version zero, version one, and you have multiple BFFs, they are consuming different versions, maybe they are using both the versions, they're using one version or v1 or v0, whatever, and what happens is you never know who is using what, and then sometimes when you want to synchronize them, it becomes really hard.

If you want to deprecate that v0, you won't be able to easily because there are still teams that are using it. So it becomes a bit hard when you want to synchronize what different BFFs are actually using. Okay, so what if your BFFs could be your enemies?

Does that mean that? Again, depends on your use case. So if you feel like it, I would recommend you should try GraphQL or API gateways or just create another microservice. Does my current architecture have to be changed?

No, not really. It is more of plug and play thing that you can do. If your method contracts are the same, you can just have minimal changes to match those contracts and then just plug it in. It really sometimes could be similar to a proxy but doing something more. Why should we invest hard-earned money and precious time in this?

As I mentioned, if you have a really good microservice architecture, you might actually not need it. If you are on a smaller project, a monolith can do it. But if you are in a journey where you are migrating away from a monolith to microservice architecture, you know your monolith has started failing you. It cannot handle, your database might start failing and things like that. Then BFFs could buy you more time.

They can buy you more time while you are actually migrating away from your monolithic architecture to a microservice-oriented architecture. So, Ashley, John, I have a good news. I'm done. So are you ready to befriend a BFF?