DEV Community

Discussion on: Explaining micro frontends as simply as possible

peerreynders profile image

These days people assume module federation when they hear "micro frontend", overlooking that there are a whole range of approaches that fall under that term.

IKEA didn't even use the term micro frontend but Microservice Websites, utilizing client-side transclusion, server-side transclusion, and edge-side includes.

allows the use of popular frameworks like Angular, React, Vue, Svelte and more.

Hopefully not at the same time - these frameworks are trying minimize their respective bundle footprints for a reason, so it would a shame to negate that effort.

richkurtzman profile image
Rich Kurtzman Author

Thank you for your informed reply. I always enjoy learning about all of this!

Our Micro Frontends at Fathym allow you to use Angular, React, Vue, Svelte at the same time (On different projects). As the main picture on the piece illustrates, one could have a blog with Gatsby, a main page designed with React and a forum created with Angular.

It seems to make sense that a developer would want to use only one framework, but when you have many teams working on a huge project, there's a possibility using multiple frameworks makes sense. Thanks again!

peerreynders profile image
peerreynders • Edited on

there's a possibility using multiple frameworks makes sense.

I think this is a case of "just because you, can doesn't mean you should"–the standing wisdom is to settle on a unified infrastructure in order to minimize the negative impact on end user experience.

For example, while not related to micro frontends in particular, Etsy standardized on Preact to streamline their development efforts rather than going forward with a Preact/React split.

Microservices and micro frontends are largely a technical solution to organizational challenges of large scale systems where complexity is used to manage complexity - aiming to shift development complexity (managed by the customer) to operational complexity (managed by the service provider).

When it comes to micro frontends, it’s been a longer process to acceptance

Perhaps because micro frontends tend to benefit organizations upwards of a certain scale and at a certain level of maturity/stability (example: AutoScout24)

From that perspective the association between a "flashup" (presumably derived form "startup") and micro frontends could be premature. As Adam Ralph in "Finding Your Service Boundaries" observes:

"Now is there anyone here working in a startup or a startup-ish kind of environment? Yeah it's just a few hands going up. Alright so for you guys I've got a little bit of bad news. If you're getting excited about this kind of stuff and you think this is interesting be very wary of using it too early in this, in a startup phase. So the problem is that startups are very good example of where you might not want to use this, at least initially because startups don't know what their businesses are yet."

The problem with microservices (and by extension micro frontends) is that boundaries are fairly expensive to change, at least in comparison to a modular monolith. Within an established organization the various bounded contexts within their domain should be relatively stable—for startups that is not typically the case.