Welcome to the third chapter of our "Build in Public" microfrontends adventure!
No dull moments – Pure action-packed content. Lets get started.
As you know, many frontend apps face challenges with large legacy codebases tied to outdated tech stacks or rushed code due to delivery pressure. This can lead to a dilemma for project managers and technical architects. They're unsure about adopting the micro frontend architecture, fearing conflicts and despair.
However, there's a solution that relieves these worries. Instead of a complete app rewrite, the strategy is to gradually replace old app components or modules. This way, new features can be delivered to users without being slowed down by the old monolith.
Here's the trick: A single team can work on migrating one component/module at a time, while others maintain the existing parts of the codebase. Over time, this incremental approach leads to success.
Let me explain this process in detail.
Example 1
Suppose you have an old family car that's been reliable for years but is really showing its age. It's time for an upgrade but buying a brand new car would be an expensive overhaul.
Instead, you can modernize it piece-by-piece - replace the stereo one month, get new tires another month, install updated seat covers, etc.
This incremental upgrade approach lets you continuously improve the car over time.
Similarly, for an aging website with old technology, you can incrementally replace parts with new microfrontend features:
Month 1: Build a new home page as a microfrontend
Month 2: Extract checkout to a new microfrontend
Month 3: Modernize account settings as a microfrontend
This lets you upgrade the site gradually to avoid a disruptive rewrite.
Example 2
Imagine you have a 1970s-style house that you want to remodel into a modern, open floor plan.
You wouldn't bulldoze the entire house and rebuild overnight. That would be hugely disruptive for your family's living situation.
Instead, you would remodel in phases:
Phase 1: Demolish a small wing and build an open kitchen
Phase 2: Take down some walls to open up the living and dining rooms
Phase 3: Redo the closed off bedrooms into a master suite
Each phase focuses on remodeling part of the outdated house into modern style.
Over months and years, the incremental phases ultimately transition the full house.
This is less disruptive and gives flexibility to pivot plans based on learnings.
Similarly, incrementally refactoring a legacy app into microfrontends lets you focus on high value areas first while minimizing risk.
Over time, more of the application transitions in phases. But forcing overnight change is too disruptive.
Process of Incremental Transition:
1. Start Where It Matters: Get the Ball Rolling
Begin by identifying the parts of your application that will benefit most from the micro frontend approach. It's not about a complete overhaul; it's about identifying the key areas that can thrive within this new paradigm.
2. Coexistence with Monoliths: Let's Be Friends
Incremental transition doesn't mean waving goodbye to your existing monolith; it means coexisting harmoniously. Consider encapsulating micro frontends within your monolithic architecture. This enables selective migration and paves the way for gradual transformation.
3. Prioritize Use Cases: Time to Get Choosy
Prioritization is your guiding star. Choose use cases that align with business goals and user needs. This way, you incrementally improve the user experience and empower teams to innovate within their designated areas.
4. API Contracts as Connectors: The Magic Bridges
API contracts play a pivotal role in the incremental transition. They act as connectors, enabling smooth communication between micro frontends and the existing monolith. Think of them as bridges that ensure coherence and consistency.
Benefits include:
- Upgrade at your own pace
- Isolate riskier changes
- Mix old and new code during transition
- Experiment with new technologies in isolated microfrontends
So think of microfrontends as a way to modernize an outdated website incrementally, like giving an old car a piece-by-piece upgrade.
Challenges and Considerations
Of course, no transition is without challenges:
1. Synchronization: Coordinating changes across monoliths and micro frontends demands meticulous synchronization to maintain a coherent user experience.
2. Testing Strategy: Transitioning incrementally requires a thoughtful testing strategy. Ensuring compatibility and consistency during the transition is essential.
3. Communication Overhead: As micro frontends increase, so does the need for effective communication. Maintain clear lines of communication to prevent silos.
So, there you have it—your roadmap to acing the incremental transition in micro frontends. It's all about starting smart, keeping the peace, choosing your use cases, and building those magic bridges.
Next part of this series will be based on following topics :
Brief intro to web components and custom elements
Please like, follow, and share this post if you found it valuable. The more we can spread the word, the better we can collectively advance the state of web architecture.
I appreciate you coming along for the ride!
Stay tuned!
Top comments (8)
FYI, I created a Vite plug-in that converts any Vite-powered project to a single-spa root config or micro-frontend project: vite-plugin-single-spa
Good to know. thanks for sharing. @webjose
Can you share what is advantage of using single spa over module federation ? It would be helpful.
I haven't explored Module Federation, so I am really unable to answer the question at this moment. I started my learning with
single-spaand decided that I didn't like it the way it was because I did not want to move away from Vite.Long story short: You create your Vite project as you normally would, then apply the plug-in with one single property in the options and you now have either the root config project or the micro-frontend project.
Is this simpler than Module Federation? No idea, but it is very, very simple. The plug-in even injects the CSS.
Based on research :
Reasons to consider Module Federation:
Leverages existing Webpack knowledge, no new framework to learn
Allows decoupled integration of microfrontends without coordination
Enables lazy loading microfrontends on demand
Allows independent deployment of microfrontend apps
Can share dependencies and CSS between microfrontends
Uses browser standards like ES Modules instead of custom framework
Simpler data flow with localization of state
Active innovation and contributions from Webpack community
Reasons single-SPA may still be suitable:
If you need strong styling isolation between microfrontends
If you want to enforce specific patterns of integration
If you require sharing global state between microfrontends
If supporting non-Webpack frameworks is essential
If your team is very familiar with single-SPA already
Here is the link for Vite with module federation - npmjs.com/package/@module-federati...
Nice, thanks for the summary. Out of the list, I would say that:
Are also possible with
single-spa.Yes, but need to learn a new framework called single SPA. - Another layer , correct ?
Yes, but what if you don't know webpack? Then you have to learn a new thing too. I literally see no differences.
Correct . It makes sense as well.