Skip to content

Instantly share code, notes, and snippets.

@devbyray
Created July 30, 2025 14:00
Show Gist options
  • Select an option

  • Save devbyray/bda01b3f8dae69b0ff88862e26577a34 to your computer and use it in GitHub Desktop.

Select an option

Save devbyray/bda01b3f8dae69b0ff88862e26577a34 to your computer and use it in GitHub Desktop.

Still the Right Choice, But for Different Reasons

My opinion changes slightly, but micro-frontends remain the correct architectural choice for your situation. Here's why:

The Real Value Driver: Independent Deployment + Legacy Migration

Your core requirement is independent deployment of modules, not team coordination. This single requirement justifies micro-frontends regardless of team size.

Your Requirement Why MFE Solves It Alternative Solutions
Independent module deployment Each module has its own pipeline, can deploy individually ❌ Monolith: All modules deploy together
Legacy .NET → Modern migration Gradual replacement without big-bang rewrites ❌ Full rewrite: High risk, long timeline
Preserve existing module boundaries Maps directly to your current .NET MVC module structure ❌ Component library: Loses deployment independence

Why This Is Different from "Single Team Over-Engineering"

Typical Single Team Scenario Your Scenario
❌ Building greenfield app from scratch ✅ Migrating legacy system with established boundaries
❌ Could use simpler monolith architecture Must maintain independent deployments (business requirement)
❌ Team coordination is the only "benefit" ✅ Technical migration strategy + deployment independence
❌ Adding complexity for future-proofing ✅ Solving current, concrete problems

The "Modular Monolith" Alternative (Worth Considering)

There is one alternative worth evaluating: Modular Monolith with selective deployment:

Modular Monolith Approach:

your-modernized-app/
├── modules/
│   ├── user-management/     # Can deploy independently 
│   ├── reporting/           # Can deploy independently
│   ├── billing/             # Can deploy independently
│   └── shared/              # Shared components
├── deployment/
│   ├── deploy-user-mgmt.yml # Deploy only user management
│   ├── deploy-reporting.yml # Deploy only reporting
│   └── deploy-all.yml       # Deploy everything

Comparison: MFE vs Modular Monolith

Aspect Micro-Frontend Modular Monolith
Independent Deployment ✅ True independence ⚠️ Selective deployment (still shared runtime)
Technology Flexibility ✅ Each module can use different frameworks ❌ Must use same tech stack
Legacy Migration ✅ Replace modules incrementally ⚠️ Must migrate all modules to same new tech
Development Complexity ⚠️ Higher (Module Federation, routing) ✅ Lower (standard Vue app)
Runtime Isolation ✅ One module crash doesn't affect others ⚠️ Shared runtime (one module can crash others)
Bundle Size ⚠️ Potential duplication ✅ Better sharing

My Recommendation: Stick with Micro-Frontends

Given your specific constraints, micro-frontends remain the better choice because:

1. Legacy Migration Path

  • You can replace one .NET MVC module with Vue while others stay .NET
  • No "big bang" rewrite required
  • Users see gradual improvements

2. True Independent Deployment

  • Module A can deploy on Monday, Module B on Friday
  • No coordination needed between module releases
  • Rollback only affects one module

3. Risk Mitigation

  • If Vue module fails, .NET modules keep working
  • Gradual user migration (feature flags)
  • Easy fallback to legacy versions

Simplified Implementation Strategy

Since you're one team, you can eliminate some MFE complexity:

Don't Over-Engineer:

  • ❌ Don't create separate teams for each module
  • ❌ Don't use different tech stacks per module (stick to Vue 3)
  • ❌ Don't build complex cross-module communication

Do Keep It Simple:

  • ✅ One shared UI component library
  • ✅ Consistent routing patterns
  • ✅ Shared authentication service
  • ✅ Standard deployment pipeline template

Your Architecture:

Deployment Pipeline:
├── user-management-mfe/     # Deploys to /user-management/*
├── reporting-mfe/           # Deploys to /reporting/*
├── billing-mfe/             # Deploys to /billing/*
├── shared-ui-lib/           # Used by all modules
└── host-shell/              # Routes to appropriate module

Bottom Line

Yes, micro-frontends are still the right choice for you, but for architectural reasons (independent deployment + legacy migration), not organizational ones (team coordination).

The key is to implement them simply - don't add unnecessary complexity just because you can. Focus on solving your real problems: gradual modernization and independent deployment.

Your proof-of-technology should validate that you can:

  1. Deploy modules independently ✅
  2. Migrate incrementally from .NET to Vue ✅
  3. Share common UI components across modules ✅
  4. Maintain good developer experience for your team ✅

This is exactly the right use case for micro-frontends.

Sources [1] MonoRepo vs MultiRepo in a single team? : r/ExperiencedDevs https://www.reddit.com/r/ExperiencedDevs/comments/ywbw0a/monorepo_vs_multirepo_in_a_single_team/ [2] Micro Frontend Architecture: A Complete Guide to Modern ... - Treinetic https://treinetic.com/micro-frontend-architecture-a-complete-guide-to-modern-frontend-development/ [3] Benefits and challenges of monorepo development practices - CircleCI https://circleci.com/blog/monorepo-dev-practices/ [4] All end user,core module,libary module under one application https://www.outsystems.com/forums/discussion/90650/all-end-user-core-module-libary-module-under-one-application/ [5] Micro Frontend Architecture: Scaling Web Applications Effectively https://www.spiralcompute.co.nz/deconstructing-the-monolith-embracing-micro-frontend-architecture-for-scalable-web-apps/ [6] Monorepo Guide: Manage Repositories & Microservices - Aviator https://www.aviator.co/blog/monorepo-a-hands-on-guide-for-managing-repositories-and-microservices/ [7] 6. How to Work with Multiple Teams and Environments - Gruntwork https://www.gruntwork.io/books/fundamentals-of-devops/work-with-teams-and-environments [8] Micro Frontend Architecture - Nx https://nx.dev/technologies/module-federation/concepts/micro-frontend-architecture [9] Creating separate monorepo CI/CD pipelines with GitHub Actions https://blog.logrocket.com/creating-separate-monorepo-ci-cd-pipelines-github-actions/ [10] spring - How does a Multi-Module Project build equate to multiple ... https://stackoverflow.com/questions/57836249/how-does-a-multi-module-project-build-equate-to-multiple-microservices-is-one-t [11] Microfrontends a Developer's Guide: Advantages and Disadvantages https://dev.to/joacod/microfrontends-a-developers-guide-advantages-and-disadvantages-2ane [12] Micro Frontends: Hosting and independent deployments in a mono ... https://blog.bredvid.no/micro-frontends-hosting-and-independent-deployments-in-a-mono-repo-with-github-actions-aws-s3-d70d58c1518e [13] Service per team - Microservices.io https://microservices.io/patterns/decomposition/service-per-team.html [14] Adapting to Micro Frontend Architecture: A Comprehensive Guide https://blog.devops.dev/adapting-to-micro-frontend-architecture-a-comprehensive-guide-4f64f56d479d [15] Monorepos and branch-based deployment : r/ExperiencedDevs https://www.reddit.com/r/ExperiencedDevs/comments/1g2e613/monorepos_and_branchbased_deployment/ [16] What Is a Modular Monolith? - Milan Jovanović https://www.milanjovanovic.tech/blog/what-is-a-modular-monolith [17] Micro frontends architecture - Lùkla https://www.luklagroup.com/en/change-adopt-en/micro-frontends-architecture/ [18] Micro Frontends with Module Federation in Monorepo - Michal Zalecki https://michalzalecki.com/micro-frontends-module-federation-monorepo/ [19] Solved: Re: Multiple teams working on same sharing repo https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/multiple-teams-working-on-same-sharing-repo/m-p/555631/highlight/true [20] The Micro-Frontend Architecture Handbook - freeCodeCamp https://www.freecodecamp.org/news/complete-micro-frontends-guide/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment