My BFF - It's Not What You Think

Ever heard of BFF? No, it's not about your Best Friend Forever; it stands for 'Backend for Frontend.' In a recent project at work, we stumbled upon a challenge during the migration of our legacy backend (let's call it project A) to microservices (B). Our e-commerce website, powered by Vue.js, was consuming APIs from project 'A.' However, as the migration unfolded, we found ourselves needing to call the same API from two different sources (project A and B) for distinct markets (e.g., Italy and Germany) that had different payloads.

Implementing the logic to transform payloads into the same response so that the existing Frontend doesn't break wasn't an issue, the real headache was maintaining and scaling it. This scenario is just one example of how things can get messy when dealing with business logic in a complex Frontend environment. To tackle this problem, we adopted the 'Backend for Frontend' pattern. This pattern allows us to keep business logic away from the Frontend while keeping it close.

In this session, I aim to explain BFF, exploring what it is, how it operates, and how to seamlessly integrate it into existing projects. I'll share insights from a case study, discussing both the advantages and disadvantages of adopting this approach.

Allow me to delve into the world of BFF and discover how it can revamp our approach to Frontend development.

A Guide to Build Data-Driven UI Components in JavaScript Frameworks

Developers who are familiar with JavaScript Front-end frameworks know how to build reusable components and utilize them for lesser code repetition and clean architecture. We write markup and logic for every new requirement or enhancement that comes up. Also, most of the time we have to do a lot of conditional rendering. Whatever we do, we eventually write static code in our project. It is fine because that is how we all do it.

But what if I say we can eliminate the hustle of writing code for every new requirement or enhancement in existing work. We do not write the code yet new requirements get implemented themselves on the compile-time and changes reflect on the browser. Sounds crazy right? Well, we can achieve this phenomenal mechanism by generating UI on compile-time via a data model (which we also called metadata).
This metadata is nothing but a smart contract between Front-end and Back-end developers in the form of JSON (can be other formats) that tells our Front- end implementation what to render on the Browser. Hence, we remove the dependency of modifying Front-end implementation to incorporate new changes.

This mechanism is derived from the Data-Driven Programming approach and is being called "Data-Driven User Interface".

In this talk, I want to show how we can achieve this approach in our new or existing codebase. Also, what are the pros and cons of adopting it and when we should or should not adopt this approach.

- This talk is more like a workshop so I would prefer the timeslot for the session should at least be of 45-60 minutes.
- The targeted audience is intermediate JavaScript developers who know how to work with at least one of its frameworks.