If you are one of the few lucky ones that successfully ported your legacy monolithic application to a microservices architecture, be aware the nightmare might not be over. The fact that you have broken down your backend into smaller, interconnected services, doesn’t mean you got away from building monolithic apps. This is especially true if you have been following the BFF (Backends For Frontends) pattern, that is, building a service for each type of client (iOS, Android, Desktop). These services grow exponentially as you make your user interfaces more complex and feature-rich. “Do we need a new search bar?”, “Sure, let’s add a new endpoint to the microservice.”
“Do we need to show a new toast to comply with EU cookie law?”, “No problem, let’s create another endpoint.” Some people might break the BFF service down into multiple services, even though this means duplicating code. I am not a big fan of repeating code, why would you have two developers writing the same functionality? Another common option is to abstract functionality and shares it across services via a library. My recommendation: push any complex logic downstream. It is OK to create 100 endpoints in your BFF service is just a pass-through to other downstream services performing an orchestrated task. In this context, avoid duplicating code, avoid using libraries, respect the single responsibility principle: your BFF service is just a router to your backend.
Latest posts by Leo Celis (see all)
- Challenges in Implementing Federated Learning in Ad Tech - 10/09/24
- Graph Neural Networks for RTB Systems - 10/02/24
- Measuring Emotional Impact in Local Campaigns - 09/25/24