Effortless Microfrontend Comms: A 5-Step Guide for 2025

Communication Patterns Comparison

Pattern	Best For	Pros	Cons
Browser Custom Events	Simple, infrequent notifications where decoupling is paramount. (e.g., “User logged out”)	- No external dependencies - Truly decoupled; listeners don’t need a shared library	- Data in detail property must be serializable - Can be hard to track/type without a central registry - Doesn’t work in non-browser environments (SSR)
Shared Event Bus (Pub/Sub)	The default for most cross-MFE communication. (e.g., “Product added to cart”)	- Centralized and explicit - Easily type-safe with TypeScript - Framework-agnostic	- Requires a shared library/instance, creating a small point of coupling - A poorly managed bus can become a bottleneck
Shared State Library	Deeply integrated UIs that share complex, reactive state. (e.g., a multi-step checkout form across MFEs)	- Single source of truth for shared data - State is reactive by default - Great developer experience with tools like Zustand or Jotai	- Creates the tightest coupling - Can violate MFE autonomy if overused - Can be complex to set up and manage state hydration

For most use cases, a Shared Event Bus strikes the perfect balance between decoupling and developer experience. It provides a clear, centralized channel without forcing microfrontends to share intimate state knowledge. Let’s dive deeper into that.

Step 3: Implement with a Lightweight Event Bus

The term “event bus” can sound intimidating, but at its core, it’s just a simple publish/subscribe (pub/sub) mechanism. You don’t need a heavy library for this. In fact, a perfectly capable event bus can be written in about 20 lines of TypeScript.

Here’s a minimal, modern implementation you could use:

// A simple, typed event bus implementation type EventHandler = (data?: any) => void; type EventMap = Record<string, Set<EventHandler>>;  export class EventBus {   private events: EventMap = {};    on(event: string, handler: EventHandler): () => void {     if (!this.events[event]) {       this.events[event] = new Set();     }     this.events[event].add(handler);      // Return a function to easily unsubscribe     return () => this.events[event].delete(handler);   }    emit(event: string, data?: any): void {     this.events[event]?.forEach(handler => handler(data));   } }  // Create a singleton instance to be shared across the application export const globalBus = new EventBus(); 

A microfrontend would then use this global instance to communicate:

// In your 'product-details' microfrontend import { globalBus } from '@your-org/shared-comms';  function handleAddToCart() {   const product = { id: 'prod-123', name: 'Flux Capacitor' };   // ...logic to add to cart...    // Emit an event for other MFEs to consume   globalBus.emit('ADD_TO_CART', { product }); }  // In your 'mini-cart' microfrontend import { globalBus } from '@your-org/shared-comms'; import { useEffect, useState } from 'react';  function MiniCart() {   const [itemCount, setItemCount] = useState(0);    useEffect(() => {     const unsubscribe = globalBus.on('ADD_TO_CART', (data) => {       console.log('Item added:', data.product.name);       setItemCount(prev => prev + 1);     });      // Clean up the subscription when the component unmounts     return () => unsubscribe();   }, []);    return <div>Cart: {itemCount} items</div>; } 

This approach is simple, explicit, and framework-agnostic. A React app can easily talk to a Vue or Svelte app without either one knowing about the other’s implementation details.

Step 4: Centralize and Type Your Events

Using an event bus is great, but it can still lead to chaos if you’re using magic strings for event names ('ADD_TO_CART') and untyped any payloads. This is where the real “effortless” part comes in. By creating a dedicated, versioned npm package for your communication layer, you create a single source of truth that provides autocompletion and type safety.

Imagine a package named @your-org/shared-events. Its structure might look like this:

/src/events.ts

// Define event names as constants to prevent typos export const MFE_EVENTS = {   cart: {     ITEM_ADDED: 'cart:itemAdded',     ITEM_REMOVED: 'cart:itemRemoved',   },   user: {     LOGGED_IN: 'user:loggedIn',     LOGGED_OUT: 'user:loggedOut',   }, } as const; // 'as const' makes these values readonly and specific

/src/types.ts

// Define the shape of your event payloads export interface CartItemAddedPayload {   productId: string;   quantity: number;   variantId?: string; }  export interface UserLoggedInPayload {   userId: string;   displayName: string;   token: string; }  // A map to link event names to their payload types export type EventPayloads = {   [MFE_EVENTS.cart.ITEM_ADDED]: CartItemAddedPayload;   [MFE_EVENTS.user.LOGGED_IN]: UserLoggedInPayload;   [MFE_EVENTS.user.LOGGED_OUT]: undefined; // Events can have no payload }; 

Now, you can create a slightly more advanced, fully-typed Event Bus that consumes these definitions. This provides an incredible developer experience, preventing entire classes of bugs at compile time. Your IDE will tell you if you’ve misspelled an event name or provided the wrong data shape.

Step 5: Isolate and Test Your Comms Layer

A key benefit of microfrontends is independent testing. Your communication strategy shouldn’t break this. Each microfrontend should be testable without needing to run the entire application shell and all its siblings.

The secret is to treat your communication bus as a dependency that can be mocked. When writing unit or integration tests for your microfrontend, you can provide a mock version of the event bus.

Here’s a conceptual example using a testing framework like Vitest or Jest:

import { render, fireEvent } from '@testing-library/react'; import { describe, it, vi, expect } from 'vitest'; import { MFE_EVENTS } from '@your-org/shared-events';  // Mock the entire shared-comms module const mockEmit = vi.fn(); vi.mock('@your-org/shared-comms', () => ({   globalBus: {     emit: mockEmit,     on: vi.fn(),   }, }));  describe('ProductDetails component', () => {   it('should emit an ITEM_ADDED event when Add to Cart is clicked', () => {     const { getByText } = render(<ProductDetailsPage product={...} />);      fireEvent.click(getByText('Add to Cart'));      // Assert that our bus was called correctly     expect(mockEmit).toHaveBeenCalledWith(       MFE_EVENTS.cart.ITEM_ADDED,       { productId: 'prod-123', quantity: 1 }     );   }); }); 

By mocking the bus, you can test both sides of the coin: you can verify that your component correctly emits events, and you can simulate incoming events to verify that your component correctly reacts to them. This ensures your microfrontend adheres to the communication contract in complete isolation.

Conclusion: From Chaos to Clarity

Effortless microfrontend communication isn’t about finding a magic bullet library. It’s about adopting a disciplined, intentional approach. By following these five steps, you shift from a reactive, chaotic model to a proactive, engineered one.

1. Define Contracts: Plan your communication like an API.
2. Choose Patterns: Use the right tool for the job, defaulting to an event bus.
3. Implement Simply: A lightweight, in-house bus is often all you need.
4. Centralize and Type: Create a shared package for event definitions to eliminate errors.
5. Test in Isolation: Mock your comms layer to maintain true microfrontend independence.

Building a large-scale frontend is complex, but the way your components talk to each other doesn’t have to be. Embrace these modern patterns, and you’ll spend less time debugging communication issues and more time delivering value to your users. That’s the real promise of microfrontends, finally realized.