Microfrontends should be a last resort

Years ago, long BC, I was at a tech conference and the CTO of a local tech giant gave a talk on micro services that was very good and touched on some of these same points. They, in fact, refactored in the monolith and then broke it out into micro services but, surprisingly, never shipped the refactored monolith ... they just kept it running full test suites as more and more of its features were carved off into micro services until the test suites were running entirely on the micro services. They shipped that.

During the Q&A somebody asked a question about their company's struggle to move their monolith to micro services and the CTO asked two questions that, at the time, was very illuminating: how many teams did they have and how many developers were in their tooling team. When they said they had a relatively small team the CTO said "you don't have any of the problems micro services solve, why are you switching".

> but now you call it a service

What is a problem in itself. On every sane place, most of the "services" aren't providing any on-demand service, instead they are just thematic monoliths doing all of a part of a task.

I'm settling on the opinion that a service-based architecture is always wrong. But people keep calling the good architectures by that name.

> Please understand that every environment, company, and project is different.

No doubt, but my point is there is a unifying metric that we can use to evaluate the effectiveness of these environments, Percentage of time spent on the environment itself versus on user needs. I think that number is too high for any system that is overly-decomposed.

> Microfrontends are very popular on the conference circuit, so I am probably about to make future job interviews awkward by criticisng them.

This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done

Certain teams and companies live and die by conference trends. If you can't also show interest in those trends, they don't want you.

I was asked to review hiring practices for the front-end team at a company I worked for a couple years back. They had a long list of questions about the latest web technologies and frameworks that they used to screen candidates. I was puzzled because we didn't use many of the technologies they listed. Several of them weren't even stabilized standards that could be used in production. The team lead explained that knowing about them was his primary signal for someone's overall competence.

They hired a lot of "smart" developers, but they also took forever to ship anything. They were always trying to do things like micro front-ends, rewrite part of the app in the latest framework, experiment with new web technologies that were too immature to ship, and other things that weren't really related to getting product out the door.

> modularise the code

You mean…

spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box?

Won’t that mean the connections between your modules start to become more important than the modules, and the work to maintain this system would only really be justifiable if the modules can be worked on in parallel?