Monolithic vs Micro Frontends: Angular Decision Guide

It can be confusing to choose between a monolithic Angular app and micro frontend approach. It depends on many factors like team size and availability, app complexity, deployment needs and scalability. Here is a detailed breakdown with proper explanations with examples.

Monolithic Angular App

When to Use:

1. Small to Medium-sized teams: One codebase is easier to manage.
2. Single domain application: Features are tightly coupled.
3. Tightly integrated features: Navigation, state, and layout are shared.
4. Simple deployment pipeline: Only one app to build and deploy.

Drawbacks:

• Hard to scale with more teams.
• Larger bundle size over time.
• Deployment of a small feature requires redeploying the whole app.

Example: E-Commerce Admin Dashboard

• Features: Orders, Products, Users, Analytics.
• All features are closely integrated and use shared services like authentication, theming, and state management.
• The same team works on all modules

A monolithic app works well here because:

• Shared state and services are easier to manage.
• Code changes and deployment are unified.
• No need for isolation between teams/features.

Micro Frontends in Angular

When to Use:

1. Large teams: Multiple independent teams working on separate features.
2. Multiple domains: Example – Admin panel, Customer portal, Marketing site.
3. Need for independent deployments: Each team manages its own build, deploy, and runtime.
4. Tech heterogeneity: Teams may use different versions of Angular or other frameworks.

 Drawbacks:

• Higher initial complexity.
• Shared state and routing need orchestration.
• Integration overhead and runtime performance if not optimized.

Common Tools:

• Module Federation (Webpack 5)
• Single SPA
• Nx Monorepo

Example: Banking Application with Micro Frontends

Features:

• Customer Dashboard
• Loan Management (built by Team A)
• Credit Card Services (built by Team B)
• Investment Portal (built by Team C)

Each team:

• Maintains its own Angular app.
• Deploys independently.
• Communicates via shared events or custom services.

The shell app (or host) loads these features at runtime using Module Federation or Single SPA.

Code Snippet (Module Federation Example):

Shell webpack.config.js:
ModuleFederationPlugin({ remotes: { loanApp: 'loanApp@http://localhost:4201/remoteEntry.js', cardApp: 'cardApp@http://localhost:4202/remoteEntry.js' }
})
Shell Routing Module:
{ path: 'loans', loadChildren: () => loadRemoteModule({ type: 'module', remoteEntry: 'http://localhost:4201/remoteEntry.js', exposedModule: './LoanModule' }).then(m => m.LoanModule)
}

Summary Comparison Table