5 Best Practices for Backends-for-Frontends

The Backends-for-Frontends (BFF) pattern is an interesting solution to a problem many teams face — meaningfully decoupling the frontend from the backend, insulating the former from changes to the latter. In this article, I’m going to quickly explain the BFF pattern, and then focus on some of the best practices you should be following when implementing it. If you’d like to know more about the pattern itself, I’d recommend reading<a href="https://samnewman.io/patterns/architectural/bff/" rel="noopener ugc nofollow" target="_blank"> this interesting article over here</a>. So let’s get going! <h1>What is the BFF pattern?</h1> BFF stands for Backend For Frontend, and it’s a very clever way to architect your application in a way so that no matter how many different frontend experiences you offer, the core backend services remain intact. What does this do differently? Well, sometimes you might be offering very distinct frontend experiences — multiple apps that are meant to re-use your backend services, while each offering very different UXs to your users. Think of a limited mobile UX, vs. a feature-rich desktop app, vs. a reporting SMS interface. These are three very different UI/UX, all consuming the same business logic at their core. But if you try to create a unique and generic set of microservices that can cater to all of those UI’s needs, you run the risk of introducing unnecessary coupling between the frontend and backend. This always leads to bloated and difficult-to-maintain codebases, and business logic leaking into the frontend. <a href="https://javascript.plainenglish.io/5-best-practices-for-backends-for-frontends-95041583f18a">Click Here</a>