Back to blog

Micro-Frontends: The Hype, The Lie, and The Reality

•2 min read

"We need to rewrite this in Micro-Frontends using Webpack Module Federation."

If I had a dollar for every time a mid-sized startup proposed this to solve their organizational issues, I wouldn't need to write code anymore. Micro-frontends (MFEs) are a brilliant solution if you are Spotify, Netflix, or a massive enterprise with 50 autonomous frontend teams. But if you have 8 developers? You are signing a death warrant for your platform's stability.

The Strategy of Pushback

When leadership pushes for MFEs because "it's what big tech does," your job as a Principal Engineer is to push back with cold, hard reality:

  1. Quantify the infrastructure tax: MFEs require a dedicated DevOps mindset for the frontend. You now need CI/CD pipelines that can independently deploy fragments, a routing shell that doesn't break when a remote fails, and a shared dependency strategy. This is a massive overhead.
  2. Acknowledge the UX degradation: Unless carefully orchestrated, MFEs lead to fragmented user experiences. Team A uses Tailwind; Team B uses styled-components. Suddenly, the user downloads 4MB of duplicate CSS, and the buttons look slightly different on the dashboard versus the billing page.
  3. Align on the real goal: Why do we want this? If it's because the build is slow, let's migrate to Vite or Turbopack. If it's because code reviews are bottlenecking, let's fix our PR approval process. Do not use architecture to solve a communication problem.

Build Monoliths First

A well-structured modular monolith (where domains are separated by strict repository boundary rules like Nx workspaces or simple NPM workspaces) will serve 95% of companies perfectly until they hit hyper-growth.

Architecture is not about picking the shiniest tool on Hacker News. It is about matching the complexity of the solution to the capacity of the team.