Micro-Frontends vs Traditional Frontends
Should You Grow One Garden or Many?
Software architecture can feel abstract, but metaphors help. So let’s imagine your frontend as a garden.
At first, you only have a backyard. You plant a few tomatoes, maybe a rose bush, and water them with a friend. Life is simple. Everything fits into that one cozy patch. That’s a traditional frontend: one codebase, one team, one deployment.
But what happens when your backyard becomes a park? Suddenly, you want a rose garden, a greenhouse, fruit trees, and a koi pond. You hire more gardeners. One insists on compost, another on hydroponics. They bump into each other, and a pest in the roses threatens the entire yard. Suddenly, one big patch isn’t working anymore.
That’s where micro-frontends come in: breaking your park into smaller, independent gardens, each tended by its own team.
What Is a Traditional Frontend?
A traditional frontend is a single, unified application. It works best when:
Your product is small to medium-sized.
A single team (or small group) maintains it.
Features are tightly connected and share logic.
Benefits:
Easy to keep a consistent design and user experience.
Simple deployment—one build, one release pipeline.
Shared state and data flow are straightforward.
Drawbacks:
As the app grows, deployments slow down.
Coordination between teams gets messy.
A single bug can affect the entire app.
In gardening terms, a tidy backyard is perfect when your needs are modest.
What Is a Micro-Frontend?
A micro-frontend splits your frontend into smaller, self-contained applications, each focused on a specific domain or feature. Together, they form a seamless experience for the user.
Think of it as building a neighborhood park instead of one oversized backyard.
The Key Pieces of the Park
Plots (Individual Apps): Each team manages its own micro-frontend (checkout, profile, search, etc.). They pick their own tools and ship independently.
Paths and Fences (Integration Layer): Routing, navigation, and shared layout keep the park coherent. Fences prevent one team’s mess from spilling into another’s.
Water Supply (Shared Services): Authentication, sessions, and APIs are like irrigation—shared infrastructure that everyone relies on.
The Entrance (Shell App): The shell is the front gate that pulls everything together. It provides the layout, header, and glue code for loading micro-frontends.
Why Split the Garden? The Benefits of Micro-Frontends
Autonomy and Speed: Teams can build and release independently.
Scalability: New “plots” can be added without redesigning the entire system.
Fault Isolation: One bug doesn’t crash the entire app.
Flexibility: Teams can use different frameworks or tools if necessary.
Where the Weeds Hide: Challenges of Micro-Frontends
Inconsistent Styles: Without a shared design system, the park looks mismatched.
Duplicate Dependencies: Multiple bundles can slow down performance if not optimized.
Shared Concerns: Authentication, analytics, and global state require careful planning.
Operational Overhead: More repos, more pipelines, more deployment complexity.
When to Choose Which Approach
Go traditional (one garden):
If you have a small product, a small team, and don’t expect rapid scaling.Go micro (many gardens):
If your app is large, your teams are many, and you need to release features independently without blocking each other.
Conclusion: It’s About Scale, Not Fashion
Choosing micro-frontends isn’t about chasing trends. It’s about recognizing when your “garden” is too big for one team to manage. If your app is small, stick with a single frontend—it’s simpler and faster. If your app is sprawling and your teams are stepping on each other’s toes, it’s time to build a park with multiple gardens.
And just like a real park, the success of micro-frontends depends on shared paths, fences, and a consistent style that makes it feel like one coherent place.
In a future post, we’ll dive into the practical steps for implementing micro-frontends—using tools like Webpack Module Federation and single-spa—without losing the magic of the garden metaphor.
