Ironically, whatever the article says is hidden because mediums front end seems broken on mobile safari right now, greying out the article but not displaying their annoying modal call for signup.
The author makes some claims about team efficiency and I suspect hand-waves away issues that pop up when implementing micro frontends - "if you ran into that problem, you're just not doing it right!"
There's a lot of naivety in a statement like this:
> I fully agree with Federico here, being able to choose whatever technology we want could be a recipe for disaster… what if we use only the best part of it?
Like wow why didn't anybody else think of that? When making an engineering decision that'll have long-term impacts on the productivity of a company, why not just exercise all the good aspects and don't fall into the traps of the bad parts?
The author makes some claims about how micro services keep bundle size reasonable, but this is still difficult to solve once your "micro" service begins to grow in size (and it will grow in size!). This is what code-splitting solves and it's entirely compatible with a unified frontend. In fact, unified frontend makes managing bundle size easier, because sufficiently large companies can build custom infrastructure to automatically split up their bit homogeneous frontend.
There's other dubious claims about scale as well - he claims 100s of engineers are "at scale", but that's still enough to be working on a number of separate projects that they can all be understood at the "macro level". Wait until you get to 1000s of engineers.
Then coordination between teams becomes worth its weight in gold, and you can only use it sparingly. But microservices force a separation that leads to effectively factions of engineers solving similar infrastructure problems but in incompatible ways, which is not only inefficient, but also means there is no canonical set of "best practices" to fall back on.
Microservices also make the mistake of thinking that code will be owned by one business unit forever, and that the shape of the team will remain static, and if it is transferred to another team, the entire service will transition. This is not true, real-life teams are much more flexible than that, and the reasoning about the ownership of a service eventually degrades into madness.
I've been observing a company transition to a micro-frontend architecture from a Rails app, and it's been probably the worst engineering decision I've seen so far (aside from the move to service oriented architecture in general). A good portion of this is because not enough engineering resources were put into the foundational - which is a failing of both management and senior engineering. There is a basic framework for doing sort-of a frontend microservice, but it's brittle, comes ultra-configurable, and already there's 10s of copies of various common components which are visually and behaviorally identical (but have different APIs). It's a productivity and documentation nightmare.
