
I don’t understand micro-front ends - kiyanwang
https://medium.com/@lucamezzalira/i-dont-understand-micro-frontends-88f7304799a9
======
tekstar
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.

------
dymk
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.

