If there’s any evidence needed to prove that what we’re building doesn’t actually need to be implemented as micro-services, it’s the fact that we’re essentially building a monolith backend-for-frontend (BFF) layer to serve the web-app and orchestrate the calls to the various backend services.
Not only does this prove that the whole idea of micro-services is essentially just a waste of time (if you’re building one large monolith for serving the web-app, why not just bundle all the application logic there?) but it also results in wasted effort. Want to limit how much a user can use a particular resource? It should go either in the BFF or the backend. Ideally, it should only go in one of the services. Well, if you have two devs working on two separate systems, and you’re in a bit of a rush, you’ll find that it’s implemented in both systems. Worse, you’ll find that the backend service has it set to 20, but the BFF service has it set to 30.
Luckily this one was caught during code review. But now you need to choose which one to keep. Maybe you decide to keep both since you don’t have time to change it now (again, you’re in a rush) but that now locks you into something that’s just harder to change. I want to make this configurable per environment to make it easier to test in Dev, but that’ll mean making the change in the BFF as well. Or I’ll need to remove one of the implementations. Again, duplicated effort that was unnecessary on the whole.
Argh, so frustrating!