DEV Community: mhmoud ashour

5 Angular Micro Frontend Mistakes That Only Show Up in Production

mhmoud ashour — Wed, 15 Jul 2026 14:08:39 +0000

Micro Frontends demo beautifully. Two remotes, a shell, a shared header — everything loads, everyone claps.

Then you ship to production, and a different category of problems appears. Problems that never show up in tutorials, never fail in local dev, and never get caught in code review — because they're not code problems, they're architecture problems.

I've spent the last couple of years building and maintaining Angular Micro Frontends (Native Federation, Nx, Angular 17→21) on a large government platform. Here are the 5 mistakes I either made myself or watched teams make — and how to avoid each one.

1. Sharing dependencies without pinning strategy

The default instinct: share everything. Angular, RxJS, your UI library — mark it all as shared and move on.

// federation.config.js — looks harmless
shared: {
  ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
}

This works until two teams deploy remotes built against different minor versions of a shared singleton. With strictVersion: true, one remote refuses to load at runtime. With strictVersion: false, you silently get two copies of RxJS and your takeUntilDestroyed starts behaving strangely across boundaries.

The fix: treat shared singletons (Angular core, RxJS, your design system) as a contract, not a convenience. Pin exact versions in a single source of truth (root package.json in an Nx monorepo makes this trivial), and make version bumps a coordinated event across all remotes — not something each team does whenever.

Rule of thumb: if it holds state or uses DI, it must be a singleton with a pinned version. If it's a pure utility, don't share it at all — duplication is cheaper than a version conflict.

2. Letting remotes own their auth logic

Every remote implementing its own token handling feels "independent." In reality you get:

4 slightly different interceptors
Token refresh races (two remotes refreshing the same token simultaneously, one invalidating the other)
Logout that works in the shell but leaves a remote with a live token in memory

The fix: authentication is a shell concern. The shell owns the token lifecycle, exposes it through a shared singleton service (or a tiny shared lib in your monorepo), and remotes consume — never manage — auth state. One interceptor, one refresh flow, one logout.

// libs/shared/auth — the ONLY place tokens live
@Injectable({ providedIn: 'root' })
export class AuthTokenService {
  private readonly token = signal<string | null>(null);
  readonly token$ = this.token.asReadonly();
  // refresh logic lives here, once
}

If this service isn't a shared singleton, each remote gets its own instance and the whole design collapses — which is exactly why mistake #1 and #2 usually appear together.

3. Routing as an afterthought

In the demo, the shell lazy-loads each remote on a route and everything is fine. In production you discover:

Deep links into a remote 404 on refresh because the shell's router doesn't know the remote's child routes
Two remotes both defining a /settings route
Browser back button jumping between remotes in ways users don't expect

The fix: define a routing contract early. The shell owns top-level route prefixes (/billing/** belongs to the billing remote, period), remotes own everything under their prefix, and no remote ever registers a route outside its namespace. Enforce it with a naming convention and a code review checklist — it's a 10-minute agreement that saves weeks.

4. No fallback when a remote fails to load

Remotes are loaded over the network. Networks fail. A deploy can briefly serve a broken remoteEntry.json. If your shell does this:

loadRemoteModule('billing', './Module') // and nothing else

…then one broken remote takes down the route, and depending on where it sits, sometimes the whole app shell with it.

The fix: every loadRemoteModule call gets a catch with a real fallback — an error component, a retry, and monitoring:

{
  path: 'billing',
  loadChildren: () =>
    loadRemoteModule('billing', './Module').catch(err => {
      monitoring.captureRemoteLoadFailure('billing', err);
      return import('./fallback/remote-unavailable.module');
    }),
}

This sounds obvious. Almost nobody does it, because in local dev the remote always loads.

5. Micro frontends without micro deployments

The most expensive mistake isn't technical. Teams adopt MFE architecture, then deploy all remotes together, from one pipeline, on one release train.

Congratulations — you now have all the complexity of Micro Frontends with none of the benefit. The entire point is independent deployability.

The fix: each remote gets its own CI/CD pipeline (GitHub Actions + Nx affected commands make this clean — only rebuild what changed), its own versioning, and its own ability to ship on a Tuesday afternoon without asking anyone. If you can't deploy one remote alone, you don't have Micro Frontends; you have a distributed monolith with extra network requests.

The pattern behind all five

None of these are coding mistakes. They're decisions that need to be made before the first remote is written — dependency contracts, auth ownership, routing namespaces, failure handling, deployment boundaries.

That's the real cost of MFE: not writing the code, but knowing which decisions matter.

If you want a starting point where these decisions are already made — Native Federation setup, shared auth singleton with JWT, routing structure, failure fallbacks, and per-remote GitHub Actions pipelines, all wired in an Nx workspace on Angular 21 — I open-sourced a free starter:

👉 NgMFE Lite on Gumroad — free, MIT, includes Arabic/RTL support out of the box.

Questions about any of the five? Drop them in the comments — I answer all of them.

I Got Zero Sales — So I Built a Free Version of My Angular MFE Kit

mhmoud ashour — Fri, 03 Jul 2026 12:42:20 +0000

129 views. 0 sales.

That was my NgMFE Pro starter kit after weeks of building and promoting it.

Instead of giving up, I asked myself: why would someone pay for something
they've never touched?

So I built a free version.

What is NgMFE?

NgMFE is a production-ready Angular 21 Micro Frontend Starter Kit I built
from real enterprise experience working on fintech and govtech projects
for Gulf region clients.

Every project started the same way: weeks of boilerplate before writing
a single line of business logic. I packaged everything into a kit so
you never have to do that again.

NgMFE Lite — Free Version (New)

🆓 Get it here: https://mhmoudashour.gumroad.com/l/bqceke

What's included:

Angular 21 + Native Federation setup
Shell Application with basic routing
Placeholder Micro Frontend
Shared Library skeleton
Angular Material + Tailwind CSS

NgMFE Pro — Full Version

🔒 Everything in Lite, plus:

JWT Authentication (Guards, Interceptors, Token Management)
NgRx Signals Store (shared state across MFEs)
Arabic RTL + i18n (English, French, Arabic)
GitHub Actions CI/CD pipeline
Full Dashboard Micro Frontend
Professional Documentation

👉 Get Pro: https://mhmoudashour.gumroad.com/l/ngmfe

Why I'm sharing this honestly

I believe in building in public.
124 views and 0 sales is not failure — it's feedback.

The feedback was: let people try before they buy.

So here we are.

Download the free version, explore the architecture, and if it saves
you time — consider upgrading to Pro.

Live Demo

See it running here: https://ng-mfe-shell.vercel.app
(Login: admin / admin)

Have questions about the architecture decisions?
Drop a comment below — I read everything.

I Built an Angular 21 MFE Starter Kit — Giving Away 3 Free Copies for Honest Feedback

mhmoud ashour — Sat, 27 Jun 2026 09:19:58 +0000

I’ve been working on enterprise Angular Micro Frontend projects for clients in the Gulf region for years. Every new project started the same way: weeks of boilerplate setup before writing a single line of business logic.
So I packaged everything into a starter kit.
What’s inside
• Angular 21 + Native Federation (not Webpack Module Federation)
• NgRx Signals Store for state management
• JWT Auth with refresh tokens, guards, and interceptors across shell and remotes
• Arabic RTL support out of the box
• GitHub Actions CI/CD pipeline ready to go
• Polyrepo structure — shell and remote apps as separate repos
Why I’m giving copies away
Honest numbers: 124 views, 0 sales.
I’d rather put it in the hands of 3 real developers and get genuine feedback than keep guessing what’s missing.
What I’m asking in return
Just set it up, use it, and tell me:
• Is it actually useful?
• What’s missing or confusing?
• Would you pay for it? If not, why?
How to get a free copy
Drop a comment below or reach out to me directly. First 3 devs who respond get it free — no strings attached.
Happy to answer any questions about the architecture decisions too.
📩 Want a free copy? Comment below or DM me on LinkedIn: https://www.linkedin.com/in/mahmoud-ashour-abdelrahman

Or get it directly on Gumroad:

mhmoudashour.gumroad.com/l/hdditr

Angular Signals + Zoneless Change Detection — The Biggest Performance Upgrade in 2026

mhmoud ashour — Sun, 05 Apr 2026 18:46:14 +0000

Angular just changed everything about how reactivity works.

If you’re still using Zone.js and ChangeDetectionStrategy.OnPush to optimize performance — there’s a better way in 2026.

Angular Signals + Zoneless Change Detection is the biggest performance upgrade Angular has ever shipped.

Here’s everything you need to know.

What Are Angular Signals?

A Signal is a reactive value that automatically notifies Angular when it changes — without Zone.js watching everything.

import { signal, computed, effect } from '@angular/core';

// Create a signal
const count = signal(0);

// Read it
console.log(count()); // 0

// Update it
count.set(1);
count.update(val => val + 1);

// Computed signal — updates automatically
const doubled = computed(() => count() * 2);

// Effect — runs when signals change
effect(() => {
  console.log('Count changed:', count());
});

Simple. Powerful. Zero boilerplate.

The Problem With Zone.js

Before Signals, Angular used Zone.js to detect changes. Every time anything happened — a click, an HTTP request, a setTimeout — Zone.js triggered change detection across your entire app.

This is why Angular apps got slow at scale.

// Old way — Zone.js watches everything
@Component({
  changeDetection: ChangeDetectionStrategy.OnPush // needed for performance
})
export class OldComponent {
  count = 0;

  increment() {
    this.count++; // Zone.js detects this
  }
}

The problem? Zone.js can’t know which component actually changed. So it checks everything.

The New Way — Signals + Zoneless

// New way — Signals tell Angular exactly what changed
@Component({
  template: `
    <p>Count: {{ count() }}</p>
    <p>Doubled: {{ doubled() }}</p>
    <button (click)="increment()">+1</button>
  `
})
export class NewComponent {
  count = signal(0);
  doubled = computed(() => this.count() * 2);

  increment() {
    this.count.update(v => v + 1);
  }
}

Angular now knows exactly which component needs to re-render. No more checking everything.

How to Enable Zoneless Change Detection

In Angular 21, you can go fully zoneless:

// main.ts
import { bootstrapApplication } from '@angular/platform-browser';
import { provideExperimentalZonelessChangeDetection } from '@angular/core';
import { AppComponent } from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [
    provideExperimentalZonelessChangeDetection()
  ]
});

Then remove Zone.js from your polyfills:

// angular.json — remove this line
"polyfills": ["zone.js"] // ❌ Remove

// After
"polyfills": [] // ✅ Clean

Real Performance Difference

Here’s what you gain going zoneless with Signals:

Metric	Zone.js	Signals + Zoneless
Change detection scope	Entire app	Only changed components
Bundle size	+33KB (zone.js)	0KB overhead
Initial render	Slower	Up to 45% faster
Memory usage	Higher	Lower
Large list performance	Degrades	Stays fast

Signal Inputs — The New @Input()

Angular 21 replaces @Input() with signal inputs:

// Old way
@Component({})
export class CardComponent {
  @Input() title: string = '';
  @Input() count: number = 0;
}

// New way — Signal inputs
@Component({
  template: `
    <h2>{{ title() }}</h2>
    <p>{{ count() }}</p>
  `
})
export class CardComponent {
  title = input<string>('');
  count = input<number>(0);

  // Computed from inputs
  summary = computed(() =>
    `${this.title()} has ${this.count()} items`
  );
}

Signal inputs are readonly — no accidental mutations. And they work perfectly with computed signals.

Signal Outputs — The New @Output()

// Old way
@Component({})
export class ButtonComponent {
  @Output() clicked = new EventEmitter<void>();
}

// New way
@Component({
  template: `<button (click)="handleClick()">Click me</button>`
})
export class ButtonComponent {
  clicked = output<void>();

  handleClick() {
    this.clicked.emit();
  }
}

Model Signals — Two-Way Binding

Angular 21 introduces model() for two-way binding:

@Component({
  template: `
    <input [value]="name()" (input)="name.set($event.target.value)" />
    <p>Hello, {{ name() }}!</p>
  `
})
export class FormComponent {
  name = model('');
}

Migration Strategy

Don’t rewrite everything at once. Follow this order:

Step 1 — Start using signal() for local component state
Step 2 — Replace @Input() with input()
Step 3 — Replace @Output() with output()
Step 4 — Replace services with signalStore() (NgRx Signals)
Step 5 — Enable zoneless change detection

Each step is independent — you can migrate gradually. ✅

Common Mistakes to Avoid

❌ Reading signals outside reactive context:

// Wrong — won't track changes
ngOnInit() {
  const value = this.count(); // reads once, not reactive
}

// Right — use effect() for side effects
effect(() => {
  console.log(this.count()); // tracks changes
});

❌ Mutating signal values directly:

// Wrong
const items = signal([1, 2, 3]);
items().push(4); // doesn't trigger update!

// Right
items.update(arr => [...arr, 4]);

❌ Creating signals inside loops or conditions:

// Wrong
if (someCondition) {
  const signal = signal(0); // unstable
}

// Right — always at component level
mySignal = signal(0);

Want a Production-Ready Angular 21 Setup?

I built NgMFE Starter Kit — a complete Angular 21 Micro-Frontend boilerplate with Signals and NgRx Signals pre-configured:

⚡ Angular 21 + Native Federation
📡 NgRx Signals for state management
🔐 JWT Auth + Route Guards
🌍 Arabic RTL support
🌙 Dark/Light mode
🚀 CI/CD with GitHub Actions + Vercel
✅ 13 unit tests passing

🔴 Live Demo: https://ng-mfe-shell.vercel.app
(login: admin/admin)

🛒 Get the kit:
👉 https://mhmoudashour.gumroad.com/l/hdditr

📦 Want the code? Grab the free version: **NgMFE Lite
👉 https://mhmoudashour.gumroad.com/l/bqceke

💼 Need it set up for your project?
👉 https://www.upwork.com/services/product/development-it-set-up-angular-micro-frontend-architecture-for-your-enterprise-app-2037100004401414520?ref=project_share

Have questions about Angular Signals or the migration? Drop them in the comments! 🙏

How to Use NgRx Signals for State Management in Angular Micro-Frontend Apps

mhmoud ashour — Thu, 02 Apr 2026 13:28:33 +0000

Angular state management has come a long way.

From services with BehaviorSubjects, to NgRx Store, to now — NgRx Signals.

If you’re building a Micro-Frontend architecture in 2026, NgRx Signals is the state management approach you should be using. Here’s why — and exactly how to implement it.

What Are NgRx Signals?

NgRx Signals is a reactive state management library built on top of Angular’s native Signals API. It gives you:

A simple, lightweight store
No boilerplate compared to classic NgRx
Fine-grained reactivity
Works perfectly across micro-apps

The Problem With State in Micro-Frontends

In a Micro-Frontend setup, each app is independent:

Shell App (Port 4200)
├── Auth App (Port 4201)
└── Dashboard App (Port 4202)

The challenge — how do you share state between them without tight coupling?

Classic NgRx is overkill for this. BehaviorSubjects get messy. NgRx Signals hits the sweet spot.

Setting Up NgRx Signals

Install the package:

npm install @ngrx/signals

Step 1 — Create a Shared Signal Store

In your Shell app, create a global store:

// shell/src/app/store/app.store.ts
import { signalStore, withState, withMethods, patchState } from '@ngrx/signals';

export interface AppState {
  theme: 'light' | 'dark';
  language: 'en' | 'ar' | 'fr';
  isAuthenticated: boolean;
  user: { name: string; role: string } | null;
}

const initialState: AppState = {
  theme: 'light',
  language: 'en',
  isAuthenticated: false,
  user: null,
};

export const AppStore = signalStore(
  { providedIn: 'root' },
  withState(initialState),
  withMethods((store) => ({
    setTheme(theme: 'light' | 'dark') {
      patchState(store, { theme });
    },
    setLanguage(language: 'en' | 'ar' | 'fr') {
      patchState(store, { language });
    },
    setUser(user: { name: string; role: string }) {
      patchState(store, { user, isAuthenticated: true });
    },
    logout() {
      patchState(store, { user: null, isAuthenticated: false });
    },
  }))
);

Step 2 — Use the Store in Your Shell Component

// shell/src/app/app.component.ts
import { Component, inject, effect } from '@angular/core';
import { AppStore } from './store/app.store';

@Component({
  selector: 'app-root',
  template: `
    <div [class]="store.theme() === 'dark' ? 'dark-theme' : 'light-theme'"
         [dir]="store.language() === 'ar' ? 'rtl' : 'ltr'">
      <router-outlet />
    </div>
  `
})
export class AppComponent {
  store = inject(AppStore);

  constructor() {
    // Persist theme to localStorage
    effect(() => {
      localStorage.setItem('theme', this.store.theme());
    });
  }
}

Step 3 — Access Store in Micro-Apps

Since the store is providedIn: 'root' and shared via the Shell, micro-apps can inject it directly:

// dashboard/src/app/dashboard.component.ts
import { Component, inject } from '@angular/core';
import { AppStore } from '../../../shell/src/app/store/app.store';

@Component({
  selector: 'app-dashboard',
  template: `
    <div>
      <h1>Welcome, {{ store.user()?.name }}</h1>
      <button (click)="toggleTheme()">
        Switch to {{ store.theme() === 'light' ? 'Dark' : 'Light' }} mode
      </button>
    </div>
  `
})
export class DashboardComponent {
  store = inject(AppStore);

  toggleTheme() {
    const newTheme = this.store.theme() === 'light' ? 'dark' : 'light';
    this.store.setTheme(newTheme);
  }
}

Step 4 — Add State Persistence

Keep state alive across page refreshes:

// shell/src/app/store/app.store.ts
import { signalStore, withState, withMethods, withHooks, patchState } from '@ngrx/signals';

export const AppStore = signalStore(
  { providedIn: 'root' },
  withState<AppState>(() => ({
    theme: (localStorage.getItem('theme') as 'light' | 'dark') || 'light',
    language: (localStorage.getItem('language') as 'en' | 'ar' | 'fr') || 'en',
    isAuthenticated: !!localStorage.getItem('auth_token'),
    user: null,
  })),
  withMethods((store) => ({
    setTheme(theme: 'light' | 'dark') {
      localStorage.setItem('theme', theme);
      patchState(store, { theme });
    },
    setLanguage(language: 'en' | 'ar' | 'fr') {
      localStorage.setItem('language', language);
      patchState(store, { language });
    },
    setUser(user: { name: string; role: string }) {
      patchState(store, { user, isAuthenticated: true });
    },
    logout() {
      localStorage.removeItem('auth_token');
      patchState(store, { user: null, isAuthenticated: false });
    },
  }))
);

Step 5 — Feature Store for Each Micro-App

Each micro-app can also have its own local store:

// dashboard/src/app/store/dashboard.store.ts
import { signalStore, withState, withMethods, patchState } from '@ngrx/signals';

interface DashboardState {
  widgets: Widget[];
  isLoading: boolean;
  selectedWidget: Widget | null;
}

export const DashboardStore = signalStore(
  withState<DashboardState>({
    widgets: [],
    isLoading: false,
    selectedWidget: null,
  }),
  withMethods((store) => ({
    setLoading(isLoading: boolean) {
      patchState(store, { isLoading });
    },
    setWidgets(widgets: Widget[]) {
      patchState(store, { widgets, isLoading: false });
    },
    selectWidget(widget: Widget) {
      patchState(store, { selectedWidget: widget });
    },
  }))
);

NgRx Signals vs Classic NgRx

Feature	Classic NgRx	NgRx Signals
Boilerplate	Actions, Reducers, Effects, Selectors	Just a store
Learning curve	High	Low
Bundle size	Larger	Smaller
Reactivity	Observable-based	Signal-based
Angular 17+ fit	Good	Excellent
Micro-Frontend use	Complex	Simple

Why NgRx Signals is Perfect for Micro-Frontends

✅ No boilerplate — less code to share between apps
✅ Fine-grained updates — only components using changed signals re-render
✅ Simple injection — just inject(AppStore) anywhere
✅ Persistent state — easy localStorage integration
✅ TypeScript friendly — full type safety out of the box

Want This Already Set Up?

I built NgMFE Starter Kit — a complete Angular 21 Micro-Frontend boilerplate with NgRx Signals pre-configured:

⚡ Angular 21 + Native Federation
🔐 JWT Auth + Route Guards
🌍 Arabic RTL support
🌙 Dark/Light mode with NgRx Signals
🚀 CI/CD with GitHub Actions + Vercel
✅ 13 unit tests passing

🔴 Live Demo: https://ng-mfe-shell.vercel.app
(login: admin/admin)

🛒 Get the kit:
👉 https://mhmoudashour.gumroad.com/l/hdditr

📦 Want the code? Grab the free version: **NgMFE Lite
👉 https://mhmoudashour.gumroad.com/l/bqceke

Have questions about NgRx Signals or state management in Micro-Frontends? Drop them in the comments! 🙏

The Ultimate Guide to Building Enterprise Micro-Frontends with Angular 21 & Native Federation

mhmoud ashour — Mon, 30 Mar 2026 04:47:52 +0000

Introduction

Micro-Frontend (MFE) architecture is no longer a "luxury" for big tech—it’s a necessity for enterprise teams that need to scale. But in 2026, the way we build them has changed. If you’re still relying on heavy Webpack configurations, you’re already behind.

In this guide, I’ll show you how to build a production-ready MFE system using Angular 21 and Native Federation.

Why Native Federation?

Standard Module Federation is tied to Webpack. Native Federation is framework-agnostic and works natively with Vite and esbuild.

•
Speed: 10x faster builds.

•
Future-Proof: No more Webpack version hell.

•
Simplicity: Uses standard browser features (Import Maps).

The 3 Pillars of Enterprise MFEs

The Shell (The Orchestrator)

The Shell isn't just a wrapper; it's the brain. It handles:

•
Authentication: Centralized JWT handling.

•
Routing: Dynamic loading of remote modules.

•
Shared State: Using NgRx Signals for lightweight, reactive data sharing.

The Remotes (The Features)

Each remote app (Auth, Dashboard, Settings) should be independently deployable. If your Dashboard team breaks something, your Auth app should still work.

The Shared Library

Don't duplicate your UI components. Use a shared library (@mfe/shared) for your Tailwind configurations, Angular Material themes, and common utilities.

The "Hidden" Challenge: RTL & Multi-language

Most MFE tutorials ignore the Middle Eastern market. If you're building for clients in the UAE or KSA, Arabic RTL support isn't optional.

•
The Problem: How do you sync the RTL direction across 5 different micro-apps instantly?

•
The Solution: A centralized DirectionService in the Shell that propagates state via Import Maps.

🚀 Stop Reinventing the Wheel

Building this architecture from scratch takes 100+ hours of configuration, testing, and debugging.

I’ve already done the hard work for you. I built NgMFE, a production-ready boilerplate that includes:

•
✅ Angular 21 + Native Federation

•
✅ Full JWT Auth & Route Guards

•
✅ Native Arabic RTL Support

•
✅ CI/CD with GitHub Actions

Save weeks of development and launch your enterprise app today.

👉 Get the NgMFE Starter Kit on Gumroad

https://mhmoudashour.gumroad.com/l/hdditr

📦 Want the code? Grab the free version: **NgMFE Lite
👉 https://mhmoudashour.gumroad.com/l/bqceke

🔴 View the Live Demo

https://ng-mfe-shell.vercel.app/auth

Conclusion

Micro-frontends are powerful, but only if the foundation is solid. Don't get stuck in "configuration hell." Focus on building features, not architecture.

Have questions about Native Federation? Drop a comment below!

How to Set Up JWT Authentication in Angular Micro-Frontend Apps

mhmoud ashour — Fri, 27 Mar 2026 14:34:58 +0000

If you’ve ever tried to implement JWT authentication in an Angular Micro-Frontend architecture, you know the pain.

It works fine in a single app. But the moment you split into multiple micro-apps, questions start piling up:

Where does the token live?
How does each micro-app access it?
How do you protect routes across different apps?
What happens when the token expires?

I’ve solved this in real enterprise projects. Here’s exactly how I do it.

The Problem With JWT in Micro-Frontends

In a standard Angular app, JWT auth is straightforward — store the token, attach it to requests, guard your routes.

But in a Micro-Frontend setup you have multiple independent apps:

Shell App (Port 4200)
├── Auth App (Port 4201)
└── Dashboard App (Port 4202)

Each app is built and deployed separately. So how do they share authentication state?

The Solution — Centralized Auth in the Shell

The key principle is simple:

Handle authentication once in the Shell app. Let all micro-apps inherit it.

Here’s how:

Step 1 — Store the Token Centrally

In your Shell app, create an Auth Service:

// shell/src/app/services/auth.service.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class AuthService {
  private tokenKey = 'auth_token';

  isAuthenticated = signal<boolean>(this.hasValidToken());

  login(token: string): void {
    localStorage.setItem(this.tokenKey, token);
    this.isAuthenticated.set(true);
  }

  logout(): void {
    localStorage.removeItem(this.tokenKey);
    this.isAuthenticated.set(false);
  }

  getToken(): string | null {
    return localStorage.getItem(this.tokenKey);
  }

  private hasValidToken(): boolean {
    const token = localStorage.getItem(this.tokenKey);
    return !!token;
  }
}

Step 2 — HTTP Interceptor for Automatic Token Attachment

Instead of manually adding the token to every request, use an interceptor:

// shell/src/app/interceptors/auth.interceptor.ts
import { HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { AuthService } from '../services/auth.service';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const authService = inject(AuthService);
  const token = authService.getToken();

  if (token) {
    const authReq = req.clone({
      headers: req.headers.set('Authorization', `Bearer ${token}`)
    });
    return next(authReq);
  }

  return next(req);
};

// shell/src/app/app.config.ts
import { provideHttpClient, withInterceptors } from '@angular/common/http';
import { authInterceptor } from './interceptors/auth.interceptor';

export const appConfig = {
  providers: [
    provideHttpClient(withInterceptors([authInterceptor]))
  ]
};

Step 3 — Route Guards

Protect your routes with guards:

// shell/src/app/guards/auth.guard.ts
import { inject } from '@angular/core';
import { Router } from '@angular/router';
import { AuthService } from '../services/auth.service';

export const authGuard = () => {
  const authService = inject(AuthService);
  const router = inject(Router);

  if (authService.isAuthenticated()) {
    return true;
  }

  return router.createUrlTree(['/auth/login']);
};

export const guestGuard = () => {
  const authService = inject(AuthService);
  const router = inject(Router);

  if (!authService.isAuthenticated()) {
    return true;
  }

  return router.createUrlTree(['/dashboard']);
};

Apply them to your routes:

// shell/src/app/app.routes.ts
import { Routes } from '@angular/router';
import { authGuard, guestGuard } from './guards/auth.guard';

export const routes: Routes = [
  {
    path: 'auth',
    canActivate: [guestGuard],
    loadRemoteModule({
      remoteEntry: 'http://localhost:4201/remoteEntry.js',
      remoteName: 'auth',
      exposedModule: './AuthModule'
    })
  },
  {
    path: 'dashboard',
    canActivate: [authGuard],
    loadRemoteModule({
      remoteEntry: 'http://localhost:4202/remoteEntry.js',
      remoteName: 'dashboard',
      exposedModule: './DashboardModule'
    })
  }
];

Step 4 — Handle Token Expiry

Add token expiry handling to your interceptor:

import { HttpInterceptorFn, HttpErrorResponse } from '@angular/common/http';
import { inject } from '@angular/core';
import { Router } from '@angular/router';
import { catchError, throwError } from 'rxjs';
import { AuthService } from '../services/auth.service';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const authService = inject(AuthService);
  const router = inject(Router);
  const token = authService.getToken();

  const authReq = token
    ? req.clone({ headers: req.headers.set('Authorization', `Bearer ${token}`) })
    : req;

  return next(authReq).pipe(
    catchError((error: HttpErrorResponse) => {
      if (error.status === 401) {
        authService.logout();
        router.navigate(['/auth/login']);
      }
      return throwError(() => error);
    })
  );
};

How Micro-Apps Access Auth State

Since the Shell handles auth centrally, micro-apps simply read from localStorage:

// dashboard/src/app/services/token.service.ts
import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class TokenService {
  getToken(): string | null {
    return localStorage.getItem('auth_token');
  }

  isLoggedIn(): boolean {
    return !!this.getToken();
  }
}

No need to duplicate auth logic in every micro-app. ✅

The Complete Flow

User visits /dashboard
→ authGuard checks isAuthenticated()
→ Not authenticated → redirect to /auth/login
→ User logs in → token stored in localStorage
→ Shell updates isAuthenticated signal
→ Redirect to /dashboard
→ Dashboard micro-app loads
→ HTTP requests automatically include Bearer token
→ If 401 received → logout and redirect to login

Want This Already Set Up?

I built NgMFE Starter Kit — a complete Angular 21 Micro-Frontend boilerplate with all of this pre-configured:

⚡ Angular 21 + Native Federation
🔐 JWT Auth + HTTP Interceptor + Route Guards
🌍 Arabic RTL support
🌙 Dark/Light mode
🚀 CI/CD with GitHub Actions + Vercel
✅ 13 unit tests passing

🔴 Live Demo: https://ng-mfe-shell.vercel.app
(login: admin/admin)

🛒 Get the kit directly:
👉 https://mhmoudashour.gumroad.com/l/hdditr

📦 Want the code? Grab the free version: **NgMFE Lite
👉 https://mhmoudashour.gumroad.com/l/bqceke

Building Micro-Frontend auth and hit a problem? Drop it in the comments — happy to help! 🙏

Native Federation vs Webpack Module Federation — Which Should You Choose in 2026?

mhmoud ashour — Thu, 26 Mar 2026 11:27:25 +0000

If you’re building a Micro-Frontend architecture with Angular in 2026, you’ve probably asked yourself this question:

Should I use Native Federation or Webpack Module Federation?

I’ve used both in real enterprise projects.
Here’s my honest comparison.

What is Module Federation?

Module Federation allows multiple separately built applications to share code at runtime. Instead of building one giant app, you build multiple smaller apps that load each other’s code dynamically.

This is the foundation of Micro-Frontend architecture.

Webpack Module Federation

Webpack Module Federation was introduced in Webpack 5 and became the standard way to build Micro-Frontends in Angular.

How it works:

// webpack.config.js
module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'shell',
      remotes: {
        dashboard: 'dashboard@http://localhost:4202/remoteEntry.js',
      },
      shared: ['@angular/core', '@angular/common'],
    }),
  ],
};

Pros:

✅ Battle-tested and widely used
✅ Large community and documentation
✅ Works with any framework

Cons:

❌ Slow build times — Webpack is heavy
❌ Complex configuration
❌ Hard to debug version conflicts
❌ Not native to Angular’s build system

Native Federation

Native Federation was built specifically for modern bundlers like Vite and esbuild. It brings Module Federation concepts to faster build tools.

How it works:

// federation.config.ts
import { withNativeFederation, shareAll } from '@angular-architects/native-federation/config';

export default withNativeFederation({
  name: 'shell',
  remotes: {
    dashboard: 'http://localhost:4202/',
  },
  shared: {
    ...shareAll({ singleton: true, strictVersion: true }),
  },
});

Pros:

✅ Much faster build times — Vite-based
✅ Simpler configuration
✅ Better integration with Angular 17+
✅ Smaller bundle sizes
✅ Better developer experience

Cons:

❌ Newer — smaller community
❌ Less documentation available
❌ Some edge cases not fully covered yet

Real Performance Comparison

From my experience building enterprise Angular apps:

Metric	Webpack MF	Native Federation
Cold build time	~45 seconds	~8 seconds
Hot reload	~3-5 seconds	~500ms
Bundle size	Larger	Smaller
Config complexity	High	Medium
Angular 17+ support	Good	Excellent

Which Should You Choose?

Choose Webpack Module Federation if:

You’re maintaining an existing project already using it
You need maximum community support
Your team is already familiar with it

Choose Native Federation if:

Starting a new Angular project in 2026
Build speed matters to your team
You’re using Angular 17 or later
You want better developer experience

My Recommendation

For any new Angular enterprise project today — go with Native Federation.

The build speed improvement alone makes it worth it. In large enterprise projects I’ve worked on, switching from Webpack MF to Native Federation reduced our build time from 45 seconds to under 10 seconds. That adds up to hours saved every week across a team.

Want a Production-Ready Setup?

I built NgMFE Starter Kit — a complete Angular 21 Micro-Frontend boilerplate using Native Federation with everything pre-configured:

⚡ Angular 21 + Native Federation
🔐 JWT Auth + Route Guards
🌍 Arabic RTL support (unique!)
🌙 Dark/Light mode
🚀 CI/CD with GitHub Actions + Vercel
✅ 13 unit tests passing

🔴 Live Demo: https://ng-mfe-shell.vercel.app
(login: admin/admin)

📦 Want the code? Grab the free version: **NgMFE Lite
👉 https://mhmoudashour.gumroad.com/l/bqceke

Have questions about Micro-Frontend architecture? Drop them in the comments — happy to help! 🙏

Why I built NgMFE Starter Kit

mhmoud ashour — Sat, 21 Mar 2026 14:46:11 +0000

The Problem
Every Angular enterprise project I worked on started the same way — weeks of setting up Module Federation, authentication, routing, and CI/CD before writing a single line of business logic.
What NgMFE Starter Kit includes:
⚡ Angular 21 + Native Federation
🔐 JWT Auth + Route Guards
🌙 Dark/Light mode
🌍 Arabic RTL support
✅ 13 unit tests passing
📚 Full documentation
Who is it for?

Angular developers building enterprise apps
Teams who want to skip boilerplate setup
Agencies delivering Micro-Frontend projects for clients

Live Demo:
👉 https://ng-mfe-shell.vercel.app
(login: admin/admin)
Support the launch:
👉 producthunt.com/posts/ngmfe-starter-kit

Building a Production-Ready Angular 21 Micro-Frontend Starter Kit with Native Federation

mhmoud ashour — Thu, 19 Mar 2026 13:56:57 +0000

🚀 NgMFE Starter Kit is live on Product Hunt today!
Your support means everything 🙏
👉 Upvote here

🔴 Live Demo: https://ng-mfe-shell.vercel.app
(login: admin/admin)
💰 Get it: https://mhmoudashour.gumroad.com/l/hdditr
After 4 years building Micro-Frontend systems
for UAE government platforms and fintech
dashboards, I decided to package everything
into a reusable starter kit.

What is NgMFE Starter Kit?

A production-ready Angular 21 boilerplate that
gives you everything needed to build enterprise
Micro-Frontend applications.

Live Demo

🔴 https://ng-mfe-shell.vercel.app
(credentials: admin/admin)

Tech Stack

Angular 21 + Native Federation (Vite-based)
Angular Material + Tailwind CSS v3
JWT Authentication + Route Guards
NgRx Signals state management
Multi-language: English, French, Arabic RTL
Dark/Light mode with persistence
GitHub Actions CI/CD
13 unit tests passing

Why I Built This

Setting up MFE architecture from scratch
takes weeks. I've done it multiple times
for real enterprise clients in UAE and KSA.

The hardest parts are:

Configuring Native Federation correctly
Setting up shared libraries
Handling auth across micro-apps
Making RTL work with Tailwind

This kit solves all of that out of the box.

Architecture Overview

The kit has 3 apps:

Shell (host) — runs on port 4200
Auth (remote) — runs on port 4201
Dashboard (remote) — runs on port 4202

Each app is independently deployable.
The shell loads remotes dynamically
using Native Federation.

Get It

Available here:
https://mhmoudashour.gumroad.com/l/hdditr

📦 Want the code? Grab the free version: **NgMFE Lite
👉 https://mhmoudashour.gumroad.com/l/bqceke

MIT License — use in commercial projects.

Happy to answer any questions about
the architecture in the comments!