The world of tech is all about advancing, improving, and evolving. Sometimes quickly, and sometimes it takes a while for changes to catch on.
When it comes to micro frontends, it’s been a longer process to acceptance, but we’ve fully embraced all the positive possibilities they bring.
Micro frontends as a concept started showing up on the radar of developers and others in the space back in 2016. And then it gained even more prominence with Martin Fowler’s piece on the frontend architecture in 2019.
“In this article we'll describe a recent trend of breaking up frontend monoliths into many smaller, more manageable pieces, and how this architecture can increase the effectiveness and efficiency of teams working on frontend code.”
At its core, micro frontends simply means taking that monolith on the front end – the rigid, immovable, indivisible – and breaking it down into smaller pieces.
Imagine working on this ancient monolith. It must have taken many artists, working together simultaneously, to get it all complete and cohesive. Now, imagine that complex, beautiful work of art is a web page, and the multiple artists are multiple engineers and developers. Or, they could be marketers, content creators etc. taking on smaller tasks. We’re continuously aiming to lower the bar in terms of what is needed to build a site on Fathym.
Micro frontends are what the name suggests. They’re multiple, miniature pieces of a website’s front end that come together to give all the functionality, customization and power needed.
Micro frontends are:
Individual, independent, smaller frontends.
Multiple teams work on their own projects concurrently.
That means smaller, incremental deployments. One team isn’t waiting on another to push their deploy.
Smaller, more cohesive codebases. That makes them easier to maintain and change, too.
Allow for scaling teams as needed.
Give the ability to rewrite, change or update parts of frontend incrementally. That means fixing bugs or changing features of a site doesn’t force the site to be down for maintenance.
Benefits for teams
Large organizations with complicated, detailed and beautiful websites can utilize micro frontends for many reasons.
Being able to break tasks down into bite-sized chunks keeps developers from being overwhelmed and helps them be efficient. On top of that, those multiple, smaller teams can work at their own pace, autonomously. The blog team won’t be delayed by, say, the e-commerce team and so on. Projects can be completed at their own pace as teams work concurrently toward the larger goal.
Benefits for fixes/bugs
Of course, the more features and the more complicated a website is, the more intricate and involved the code on the back end. However, when each feature is made of smaller amounts of code, they’re easier to update. And when the code breaks for some reason, those errors are easier to find. On top of that, because the code is decoupled, the entire website doesn’t have to go down to fix one feature’s bug.
Benefits of flexibility (With JavaScript frameworks)
One more massive advantage of micro frontends is each one of those smaller pieces can be created with different tools.
That means you can flashup a website in mere minutes with plug-and-play open-source apps. Or, you can go low-code/your code. We invite developers to get as complicated as they like while making something inspired, and at the same time, developers can use whichever JavaScript framework they’d like.
Fathym’s micro frontends platform allows the use of popular frameworks like Angular, React, Vue, Svelte and more. Plus, each bit of the website (blog, gallery, e-commerce etc.) can be built with a different framework, if that team so desires.
That’s an amazing amount of flexibility considering those frameworks are valued for different abilities.
Conclusion
Micro frontends aren’t a new concept, but they are the wave of the future. Many larger companies already use the architecture – IKEA, Spotify, Upwork, and SoundCloud among others – and we believe that adoption will only continue to grow over time.
Join Fathym
We invite you to sign up for our freemium platform now, not only to achieve your goals, but to have a little fun while you’re at it, too.
Top comments (8)
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.
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.
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!
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).
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.
This why we need 32gb ram to run chrome, maybe you should rethink how big of a JS stack is necessary
Thanks, this hepled me to understand this topic better.
Wonderful! Thank you.
Wonderful! I hope it helps you, too. Reach out if there's anything else I can help explain. Cheers