Forem: Felice Lombardi

What is NOT a Micro-Frontend: Clearing the Confusion

Felice Lombardi — Fri, 13 Jun 2025 12:57:09 +0000

As a Senior Frontend Architect, I've witnessed countless discussions about micro-frontends where teams mistakenly identify architectural patterns, leading to poor decisions and technical debt.

My Pain Point: The Tragedy of Misunderstood Architecture

Let me tell you a story that still haunts me. I was in a crucial architectural meeting where we were deciding the future of our frontend strategy. The lead architect confidently presented their "micro-frontend solution" – and I watched in horror as they described what was essentially a glorified component library.

"We'll create reusable components," they enthusiastically explained, "the Login component, the Dashboard component, the UserProfile component. Each team can own their components, and we'll have micro-frontends!"

Fortunately, I managed to catch the problem in time. After hours of discussion and presenting concrete examples, I was able to convince them of the true meaning of what a micro-frontend entails. We'll explore what that means later.

But that wasn't the worst of it. In another project, I witnessed pure madness: an architect seriously proposing to compose entire pages using multiple iframes. "We'll have the header iframe, the sidebar iframe, the main content iframe, and the footer iframe," they said with a straight face. "Each team can own its iframe!"

Thankfully, a few days later, they walked back their proposal entirely.

This article aims to prevent that pain by clearly defining what micro-frontends are NOT, so you can avoid these painful mistakes.

Let's clarify what micro-frontends truly are by examining what they are NOT.

What Micro-Frontends Are NOT

❌ NOT Just Multiple SPAs Behind a Reverse Proxy

Many developers think that having several Single Page Applications (SPAs) running on different ports and routing them through a reverse proxy creates a micro-frontend architecture. This is one of the most common misconceptions.

# This is NOT a micro-frontend architecture
server {
    location /dashboard { proxy_pass http://react-dashboard:3000; }
    location /profile { proxy_pass http://vue-profile:3001; }
    location /billing { proxy_pass http://angular-billing:3002; }
}

Why it fails:

Full page reloads: When users navigate from /dashboard to /profile, the entire page reloads, breaking the single-page application experience.
No shared state: User authentication, cart data, or any global state is lost between applications.
Inconsistent UI: Each app loads its own CSS, fonts, and UI components, leading to visual flickering and inconsistent design.
Performance issues: Each transition requires downloading new JavaScript bundles, CSS files, and fresh API calls.
Browser history problems: Back button behavior becomes unpredictable across different applications.

Real-world analogy: It's like having separate websites pretending to be a single application – imagine if Gmail reloaded the entire page every time you switched from Inbox to Compose!

❌ NOT a Component Library or Design System

Another common confusion happens when developers think that using shared UI components from a design system equates to micro-frontends. While component libraries are valuable, they are fundamentally different from micro-frontend architecture.

// This is a component library, NOT a micro-frontend
import { Button, Modal, DataTable } from '@company/ui-components';

function UserManagement() {
    return (
        <div>
            <Button onClick={handleCreate}>Create User</Button>
            <DataTable data={users} />
        </div>
    );
}

Why it fails:

Shared dependencies: All teams must use the same version of the component library, creating coordination overhead.
No independent deployments: If the component library changes, all applications must update and redeploy.
Single point of failure: A bug in the shared component affects every application that uses it.
Limited team autonomy: Teams cannot make independent technology choices or significantly customize components.
Not business-focused: Components are UI building blocks, not complete business functionalities.

Think of it this way: Component libraries are like LEGO bricks that everyone shares, but micro-frontends are like complete LEGO sets (spaceship, castle, car) that different teams build and can swap in and out of a larger city.

❌ NOT iframe-Based Solutions

While iframes technically allow embedding different applications, they create more problems than they solve and represent an outdated approach that many beginners mistakenly consider "micro-frontends."

<div class="app-container">
    <iframe src="/dashboard-app" width="100%" height="500px"></iframe>
    <iframe src="/analytics-app" width="100%" height="400px"></iframe>
</div>

Why it fails:

Styling nightmare: Each iframe has its own CSS context, making it impossible to create consistent spacing, fonts, and colors across applications.
Communication barriers: Parent and child applications struggle to share data or coordinate actions (like showing loading states).
Accessibility issues: Screen readers and keyboard navigation break across iframe boundaries, failing users with disabilities.
Performance bottlenecks: Each iframe loads a complete HTML document with its own CSS and JavaScript, consuming unnecessary resources.
Poor mobile responsiveness: Iframes do not play well on mobile devices, leading to scrolling issues and touch interaction problems.
SEO challenges: Search engines have difficulty correctly indexing content within iframes.

Real-world comparison: Using iframes is like having separate TV screens for each room in your house instead of having one smart TV that can display different content – technically possible but clunky and inefficient.

❌ NOT Monorepos with Multiple Apps

Many developers assume that organizing multiple applications within a single repository (monorepo) automatically creates a micro-frontend architecture. This is a fundamental misunderstanding of what micro-frontends represent.

{
  "name": "company-apps",
  "workspaces": [
    "apps/dashboard",
    "apps/admin",
    "apps/mobile"
  ]
}

Why it fails:

Deployment coupling: Even if apps are separate, they are often deployed together, defeating the purpose of independent releases.
Shared build process: All applications typically use the same build tools, Node.js version, and deployment pipeline, limiting technology choices.
Code organization ≠ Runtime integration: Having separate folders doesn't mean the applications work together as a unified experience.
Missing runtime composition: Users still navigate between entirely separate applications rather than seamlessly integrated functionalities.
Coordination overhead: Teams still need to coordinate changes, updates, and releases because everything lives in the same repository.

Simple analogy: A monorepo with multiple apps is like having separate apartments in the same building – they are organized together but are still completely independent living spaces. Micro-frontends are more like having different rooms in the same house that work together to create a single living experience.

❌ NOT Route-Based Code Splitting

This is probably the most subtle misconception. Many developers believe that splitting their application's code based on routes and dynamically loading them creates micro-frontends. While code splitting is an excellent optimization technique, it's not the same as micro-frontend architecture.

// This is code splitting, NOT micro-frontend
const Dashboard = lazy(() => import('./Dashboard'));
const Profile = lazy(() => import('./Profile'));

function App() {
    return (
        <Router>
            <Routes>
                <Route path="/dashboard" element={<Dashboard />} />
                <Route path="/profile" element={<Profile />} />
            </Routes>
        </Router>
    );
}

Why it fails:

Single deployment unit: All code splitting happens within one application that is deployed as a single unit.
Single team ownership: One team still owns the entire application, including all routes and functionalities.
Shared dependencies: All route components use the same React version, same build tools, same everything.
Build-time splitting: The splitting happens when you build the app, not when different teams deploy their functionalities.
Technology lock-in: You can't have Dashboard in React and Profile in Vue – everything must use the same technology stack.
Coordination required: Adding new routes or changing shared logic still requires coordination with the entire team.

Easy way to remember: Code splitting is like having a large closet with organized sections (shirts, pants, shoes) – it's still one closet owned by one person. Micro-frontends are like having separate wardrobes that different people own and manage, but they all contribute to a unified clothing experience.

What Micro-Frontends Really Are

Micro-frontends are independently deployable frontend applications that:

Work together in a single page/browser context.
Are owned by different teams with full autonomy.
Are deployed independently without coordination.
Are integrated at runtime using composition techniques.

✅ A True Micro-Frontend Example

// Shell application (container)
import { registerApplication, start } from 'single-spa';

registerApplication({
    name: 'dashboard',
    app: () => System.import('@company/dashboard'),
    activeWhen: ['/dashboard']
});

registerApplication({
    name: 'user-profile',
    app: () => System.import('@company/user-profile'),
    activeWhen: ['/profile']
});

start();

// Individual micro-frontend (dashboard team)
import React from 'react';
import ReactDOM from 'react-dom';
import singleSpaReact from 'single-spa-react';

const Dashboard = () => <div>Dashboard Content</div>;

const lifecycles = singleSpaReact({
    React,
    ReactDOM,
    rootComponent: Dashboard
});

export const { bootstrap, mount, unmount } = lifecycles;

Key Indicators You're Doing Micro-Frontends Correctly

✅ Different teams can deploy independently.
✅ Applications seamlessly integrate at runtime.
✅ Teams can choose different technologies.
✅ Shared navigation and consistent UX.
✅ Applications can communicate when necessary.

When NOT to Use Micro-Frontends

Small teams (< 3 frontend teams)
Simple applications
Tight coupling requirements
Performance is hyper-critical
Limited infrastructure resources

Conclusion

Micro-frontends solve organizational problems, not technical ones. They enable team autonomy and independent deployment at the cost of increased complexity. Before adopting them, ensure you have the team structure and organizational needs that justify the architectural overhead.

The key is to understand that micro-frontends are about runtime integration of independently deployed applications, not just splitting code or using multiple technologies.

The Definitive Definition

To close this discussion, I'll share the definition from Luca Mezzalira, one of the most respected voices in the micro-frontend community and author of "Building Micro-Frontends":

"Micro-frontends are the technical representation of a business subdomain. They allow independent implementation with the same or different technology. Finally, they should minimise the code shared and owned by other subdomains owned by a single team."

This definition perfectly captures the essence:

Focus on business subdomain: Not technical functionalities, but complete business capabilities.
Strong boundaries: Clear separation of concerns and responsibilities.
Clear contracts: Well-defined interfaces for communication.
No shared logic: True independence between different subdomains.

When evaluating whether you're building true micro-frontends, ask yourself: "Does this represent a complete business subdomain with its own team, deployment cycle, and clear boundaries?" If the answer is no, you're likely dealing with one of the anti-patterns we've discussed.

What's your experience with micro-frontends? Have you seen these anti-patterns in your organization? Share your thoughts in the comments below! 👇

Angular vs. Blazor WASM: My Architectural Battle for Performance and Scalability!⚔️

Felice Lombardi — Fri, 06 Jun 2025 13:50:29 +0000

As a Technical Architect with years of experience in Angular, I dove headfirst into Blazor WebAssembly. The result? A comparative analysis that goes beyond a simple "what does what": it's a story of how these two platforms tackle the most critical challenges for any architect: performance, build optimizations, and dependency management.

It's not just about syntax; it's about business impact and scalability. Are you ready to see the cards on the table? 🚀

🏎️ Lazy Loading: Who Loads Faster and Better?

Lazy loading is our ace up the sleeve for lightning-fast startup times. But how do these two giants implement it?

Angular: The Master of JavaScript Modularity 🎯

Angular, with its router, makes lazy loading a breeze. Loading entire feature modules or individual standalone components (thanks Angular 17!) only when needed is a dream for modularization.

The mechanism is clean: it leverages dynamic ECMAScript import(). The browser downloads only what's necessary, when it's necessary.
Configuration? A single line in the routing:

// app-routing.module.ts
const routes: Routes = [
  {
    path: 'admin',
    loadChildren: () => import('./admin/admin.module').then(m => m.AdminModule)
  },
  {
    path: 'dashboard',
    loadChildren: () => import('./dashboard/dashboard.component').then(c => c.DashboardComponent) // Angular 17+
  }
];

A super-efficient flow that I love.

Blazor WebAssembly: Loading DLLs? A New C# Frontier 🌐

Blazor WebAssembly (.NET 5+) brought lazy loading to the .NET world, but the approach is different: we're talking about deferred loading of assemblies (.dll). Here, I had to reset my mind from the JavaScript paradigm.

You declare the assembly in the .csproj:

<ItemGroup>
  <BlazorWebAssemblyLazyLoad Include="MyApp.Features.Admin.dll" />
</ItemGroup>

And you manage it programmatically with ILazyAssemblyLoader:

// MyComponent.razor.cs (example)
[Inject]
private ILazyAssemblyLoader LazyAssemblyLoader { get; set; }

private async Task LoadAdminFeature()
{
    var assemblies = await LazyAssemblyLoader.LoadAssembliesAsync(
        new string[] { "MyApp.Features.Admin.dll" }
    );
    // ... post-load logic
}

Simple, yes, but it requires more manual management at the project level.

🚨 The Real Differences in Lazy Loading:

Characteristic	Angular	Blazor WebAssembly
Loading Unit	Module/Chunk (.js), Standalone Component	Assembly (.dll)
Granularity	High (module or component)	Limited (assembly level)
Integration	Natively in the Router	.csproj configuration and C# code
Tooling & DX	Mature (CLI, automatic)	Requires attention to project structure

My take here? Angular offers an almost magical fluidity in lazy loading thanks to its router integration. Blazor, while powerful, asks you to think more "in terms of .dll files" and less "in terms of UI routes."

🌳 Tree Shaking & Dead Code Elimination: Bundle Sizes Under Control?

Optimizing bundle size is vital. Let's see who wins the "dead code" battle.

Angular: The Scalpel of JS/TS Tree Shaking ✂️

Angular, with Webpack/esbuild/Vite, is a master of tree shaking. It removes unused JavaScript/TypeScript code thanks to static analysis of ES modules.

Result: Leaner bundles, reduced loading times. It's a proven mechanism that works great with well-structured code.

Blazor WebAssembly: The .NET IL Linker – A Double-Edged Sword 🔪

Blazor WebAssembly relies on the .NET IL linker for "trimming." It analyzes the CIL bytecode to eliminate unreachable classes and methods.

Enable in .csproj:

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
  <TrimMode>link</TrimMode>
</PropertyGroup>

But beware! Here I broke a sweat:

Reflection: Extensive use of reflection can fool the linker.
Untrimmed Libraries: Not all .NET libraries are "trim-friendly."
Warnings: Monitoring linker warnings is FUNDAMENTAL to avoid runtime issues. I've seen more than one MissingMethodException!

⚠️ The Insidious Differences in Tree Shaking:

Aspect	Angular	Blazor WebAssembly
Basic Technique	Static JS/TS analysis	IL Linker (CIL bytecode)
Target Language	JavaScript	.NET Intermediate Language (CIL)
Effectiveness	Excellent with ES modules and pure functions	Good, but compromised by reflection and untrimmed libraries
Main Risks	Minimal	Runtime exceptions if linker is too aggressive

My biggest challenge here? Learning to "talk" to the IL linker. It's not an automatic process like JS tree shaking; it requires greater architectural awareness of dependencies.

⚙️ AOT vs JIT Compilation: Startup and Performance Under the Magnifying Glass

Compilation is the heart of performance. Here, the two frameworks take radically different paths.

Angular: AOT by Default – JavaScript Ready to Go! 🚀

Angular compiles AOT (Ahead-of-Time) by default for production builds. HTML and TypeScript become optimized JavaScript before the browser sees a single byte of code.

Benefits (which I love): Fast startup, build-time errors (not runtime!), security, and better tree shaking. The browser downloads code that's already ready for execution.

Blazor WebAssembly: JIT by Default, Optional AOT – A Difficult Compromise 🤔

Blazor WebAssembly by default uses JIT (Just-in-Time) compilation: the .NET runtime interprets the CIL code in the browser. This can slow down the initial startup.

But from .NET 7+, there's optional AOT: CIL is translated into native WebAssembly before deployment.

Enable AOT:

<PropertyGroup>
  <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

Blazor AOT Advantages: Incredible runtime performance, less memory consumption.
Blazor AOT Disadvantages (and this is where the choice becomes critical):

MASSIVE Payload Increase: Compiled WebAssembly code is much larger. This is a trade-off you must justify.
Very Long Build Times: AOT compilation is intensive and can extend build times.

🤯 Crucial Differences in Compilation:

Aspect	Angular (AOT)	Blazor WASM (JIT Default)	Blazor WASM (Optional AOT)
Phase	Build-time	Runtime	Build-time
Startup	Fast	Slow (downloads .NET runtime + CIL interpreter)	Medium (downloads larger native WebAssembly)
Performance	Good (optimized JS)	Medium (CIL interpretation)	High (native WebAssembly)
Payload Size	Optimized	Medium (.NET Runtime + CIL)	Very heavy (.NET Runtime + WASM)

The architect's dilemma? In Blazor, you either accept a slower startup with a contained payload (JIT), or gain runtime speed by heavily sacrificing bundle size (AOT). Angular, on the other hand, offers you the best of both worlds for JavaScript frontend.

🧬 Shared Dependency Management: The Double-Edged Sword of Modularity

How do we manage common code? Both have an approach, but with different consequences.

Angular: Injector Hierarchy and `providedIn: 'root'` – The Singleton Paradigm 🌿

In Angular, SharedModules are the norm. The key is the injector hierarchy. I've learned that for global, tree-shakable singleton services, providedIn: 'root' is a blessing:

// my-singleton.service.ts
@Injectable({
  providedIn: 'root' // Singleton and tree-shakable
})
export class MySingletonService { /* ... */ }

Without this, you risk multiple instances of services in lazy-loaded modules, a classic mistake to avoid.

Blazor WebAssembly: Shared Projects and Linker Constraints – .NET in the Browser 🏗️

Blazor uses .NET class libraries (.dll) for code sharing (MyApp.Shared). It seems familiar to .NET developers, but...

Beware of the pitfalls!

Payload: Even a small part of a DLL can drag the entire assembly into the bundle, unless the linker works miracles.
Incompatible Dependencies: I've spent hours debugging System.IO.File or Entity Framework Core magically appearing in the browser and crashing everything! Server-side APIs don't live well in WebAssembly.
Trimming: Shared libraries must be trim-friendly or the linker won't do its job.

💡 Best Practices and Architectural Considerations: My Lessons from the Field

Angular:

Services: Always providedIn: 'root' for singletons.
Modularity: Logical, lazy-loaded.
Bundle Analysis: Webpack Bundle Analyzer is my best friend.
UI Performance: OnPush change detection where possible.

Blazor WebAssembly:

Shared Projects: Minimal and lightweight, only DTOs and strictly client-side logic.
Isolate Dependencies: No server-centric dependencies on the client!
Linker: Configure it aggressively and monitor IL warnings.
Reflection: Use it extremely sparingly.
AOT: Evaluate it only for critical performance needs, aware of the payload increase.

Conclusion of the "Duel" 🥊

Angular and Blazor WebAssembly are both thoroughbreds for client-side development, but with different souls.

Angular: Maturity, refined integration of lazy loading and tree shaking, solid ground for those seeking robustness and a vast ecosystem.
Blazor WebAssembly: The excitement of bringing C# to the browser. A flat learning curve for .NET devs, but requires constant vigilance on dependency management and runtime/compilation implications.

As an architect, my choice is never "one or the other" upfront. It depends on project requirements, team expertise, and tolerance for compromises.

🤯 Final Thoughts from an Architect: When I Wouldn't Use...

This is the most important part for me: when is a framework not the best solution?

I wouldn't use Blazor WebAssembly if...

Absolute priority on initial load and mini bundles: The .NET runtime, while optimized, can be an obstacle for sites requiring an almost instantaneous "first paint."
Maximum runtime performance with high computational loads (without AOT): If I cannot accept the AOT payload increase, default CIL interpretation might not be enough for intensive calculations.
Extended frontend ecosystem and mature UI libraries: For very specific UI/UX needs, the Blazor ecosystem, while growing, is still less supplied than the JavaScript one.

I wouldn't use Angular if...

Small, rapid projects or prototypes: Its opinionated structure and "boilerplate" can slow down contexts where prototyping speed is the absolute priority. Angular can be "overkill."
Team with little frontend experience or preference for other paradigms: The learning curve for TypeScript, RxJS, and complex DI can be steep. If the team prefers more minimalist libraries, Angular might not be the right choice.
Maximum end-to-end C# code reuse: If the goal is to reuse C# business logic between backend and frontend, Angular obviously doesn't offer this intrinsic advantage.

And you? What have been your experiences or your "never agains" with Angular or Blazor WebAssembly? I'm curious to hear your perspectives! 👇

Forem: Felice Lombardi

What is NOT a Micro-Frontend: Clearing the Confusion

My Pain Point: The Tragedy of Misunderstood Architecture

What Micro-Frontends Are NOT

❌ NOT Just Multiple SPAs Behind a Reverse Proxy

❌ NOT a Component Library or Design System

❌ NOT iframe-Based Solutions

❌ NOT Monorepos with Multiple Apps

❌ NOT Route-Based Code Splitting

What Micro-Frontends Really Are

✅ A True Micro-Frontend Example

Key Indicators You're Doing Micro-Frontends Correctly

When NOT to Use Micro-Frontends

Conclusion

The Definitive Definition

Angular vs. Blazor WASM: My Architectural Battle for Performance and Scalability!⚔️

🏎️ Lazy Loading: Who Loads Faster and Better?

Angular: The Master of JavaScript Modularity 🎯

Blazor WebAssembly: Loading DLLs? A New C# Frontier 🌐

🚨 The Real Differences in Lazy Loading:

🌳 Tree Shaking & Dead Code Elimination: Bundle Sizes Under Control?

Angular: The Scalpel of JS/TS Tree Shaking ✂️

Blazor WebAssembly: The .NET IL Linker – A Double-Edged Sword 🔪

⚠️ The Insidious Differences in Tree Shaking:

⚙️ AOT vs JIT Compilation: Startup and Performance Under the Magnifying Glass

Angular: AOT by Default – JavaScript Ready to Go! 🚀

Blazor WebAssembly: JIT by Default, Optional AOT – A Difficult Compromise 🤔

🤯 Crucial Differences in Compilation:

🧬 Shared Dependency Management: The Double-Edged Sword of Modularity

Angular: Injector Hierarchy and providedIn: 'root' – The Singleton Paradigm 🌿

Blazor WebAssembly: Shared Projects and Linker Constraints – .NET in the Browser 🏗️

💡 Best Practices and Architectural Considerations: My Lessons from the Field

Angular:

Blazor WebAssembly:

Conclusion of the "Duel" 🥊

🤯 Final Thoughts from an Architect: When I Wouldn't Use...

I wouldn't use Blazor WebAssembly if...

I wouldn't use Angular if...

🔗 Useful Resources (For those who want to dig deeper!):

Angular: Injector Hierarchy and `providedIn: 'root'` – The Singleton Paradigm 🌿