Chapter 15: Advanced Architectures: Microfrontends and WebSockets

Welcome to Chapter 15, where we’ll dive into advanced architectural patterns that empower you to build highly scalable, maintainable, and interactive React applications for the enterprise world. As your applications grow in complexity and team size, traditional monolithic frontend architectures can become bottlenecks. Similarly, static data fetching might not cut it for experiences demanding instant updates.

In this chapter, we’ll demystify Microfrontends, an architectural style that breaks down large frontends into smaller, independently deployable units, leveraging Webpack’s Module Federation. This approach fosters team autonomy and faster development cycles. Concurrently, we’ll explore WebSockets, a powerful protocol for real-time, bi-directional communication, essential for features like live chat, notifications, and collaborative tools. You’ll learn not just what these technologies are, but why they solve critical production problems, how to implement them step-by-step, and how to avoid common pitfalls.

Before we embark on this exciting journey, ensure you have a solid grasp of fundamental React concepts, including components, hooks, basic state management, and an understanding of client-server communication via HTTP. Let’s build some truly modern and robust React applications!

Core Concepts

Microfrontends: Scaling Your Frontend Development

Imagine building a massive e-commerce platform with dozens of features: product listings, user profiles, shopping cart, checkout, order history, recommendations, and so on. If all these features live within a single, gigantic React application (a monolith), a few problems quickly emerge:

Slow Development: Multiple teams working on the same codebase leads to constant merge conflicts, code reviews become bottlenecks, and deployments are risky.
Technology Stagnation: Upgrading React or a major library becomes a monumental task, often delaying innovation.
High Cognitive Load: Developers need to understand the entire application, not just their specific feature.
Deployment Risks: A small bug in one feature can bring down the entire application.

This is where Microfrontends come to the rescue!

What are Microfrontends?

Microfrontends are an architectural pattern where a large, complex frontend application is broken down into smaller, independent applications, each managed by a distinct team. Think of it as applying the microservices philosophy to the frontend. Each microfrontend is a self-contained unit that can be developed, tested, and deployed independently.

Why Microfrontends? (The Problem Solved)

Team Autonomy: Each feature team can work on their microfrontend in isolation, choosing their own tech stack (within reasonable limits), and deploying on their own schedule.
Faster Development Cycles: Smaller codebases mean less complexity, fewer merge conflicts, and quicker feature delivery.
Increased Resilience: A failure in one microfrontend is less likely to affect the entire application.
Incremental Upgrades: You can upgrade parts of your application to newer React versions or libraries without a full rewrite.
Scalability: Both in terms of codebase size and the number of development teams.

What Happens if Ignored? (The Failures)

Ignoring microfrontends in large-scale projects often leads to the aforementioned “monolith pain”: slow development, demoralized teams, fear of deployment, and a codebase that becomes a tangled mess over time.

How Microfrontends Work with Module Federation

While there are several ways to implement microfrontends (e.g., iframes, web components, server-side composition), Webpack 5’s Module Federation has emerged as a powerful and elegant solution specifically for JavaScript applications.

Module Federation allows multiple separate builds (each a microfrontend) to consume code from each other at runtime. It treats each application as a “host” or a “remote” (or both).

Host Application: The main application that consumes one or more “remote” microfrontends. It acts as the orchestrator.
Remote Application: An independent microfrontend that exposes some of its components or modules to be consumed by a host.

The magic happens at build time and runtime. Webpack generates special “remote entry” files that hosts can load dynamically. Crucially, Module Federation also handles shared dependencies, ensuring that common libraries like React are loaded only once, even if multiple microfrontends depend on them. This prevents bundle size bloat and ensures consistent versions.

Let’s visualize this with a simple diagram:

In this diagram, the “Host Application” loads and renders components from “Product List,” “Shopping Cart,” and “User Profile” microfrontends. All these microfrontends, plus the host, can share common dependencies like React, ensuring an efficient bundle.

WebSockets: Real-time Communication Powerhouse

Most of your application’s data fetching likely relies on HTTP requests. While excellent for many scenarios, HTTP has a fundamental limitation for real-time interactions: it’s stateless and typically client-initiated (request-response). For features that demand instant updates from the server, like a live chat, stock ticker, or collaborative document editing, traditional HTTP polling (where the client repeatedly asks the server for updates) is inefficient and introduces latency.

What are WebSockets?

WebSockets provide a persistent, full-duplex communication channel over a single TCP connection. Once established, both the client and the server can send messages to each other at any time, without the overhead of HTTP headers for each message.

Why WebSockets? (The Problem Solved)

Instant Updates: The server can push data to the client as soon as it’s available, eliminating polling delays.
Bi-directional Communication: Both client and server can initiate communication.
Efficiency: After the initial HTTP handshake, the protocol is very lightweight, reducing latency and bandwidth usage compared to repeated HTTP requests.
Real-time Features: Essential for chat applications, live notifications, online gaming, collaborative editing, and dashboards.

What Happens if Ignored? (The Failures)

Without WebSockets, achieving real-time features would typically involve:

Long Polling: The client holds an HTTP connection open until the server has data, then closes and re-opens. This is better than short polling but still has overhead and is not truly bi-directional.
Short Polling: The client repeatedly sends HTTP requests at intervals. This is resource-intensive, introduces latency, and can overwhelm servers.
Poor User Experience: Users experience delays in receiving critical updates, making the application feel sluggish and unresponsive.

How WebSockets Work

Handshake: The client initiates a standard HTTP request to a WebSocket server, but it includes an Upgrade header, signaling its intent to switch protocols.
Connection Upgrade: If the server supports WebSockets, it responds with an Upgrade header, confirming the protocol switch.
Persistent Connection: The HTTP connection is then “upgraded” to a WebSocket connection. From this point, the connection remains open, and both client and server can send data frames (messages) to each other efficiently.

Integrating WebSockets in React

React itself doesn’t have built-in WebSocket support, but you can easily integrate the native browser WebSocket API or use a more robust library like socket.io-client (which provides fallbacks and reconnection logic). The key is to manage the WebSocket connection’s lifecycle within a React component or, more cleanly, within a custom hook.

Step-by-Step Implementation

Let’s get our hands dirty by setting up a basic microfrontend architecture using Webpack 5’s Module Federation and then integrating WebSockets into a React component.

3.1. Setting up a Microfrontend with Module Federation

We’ll create two React applications:

app-host: The main application that will consume other microfrontends.
app-remote-products: A microfrontend that exposes a product listing component.

Prerequisites:

Node.js v20.11.0 (LTS as of Feb 2026)
npm v10.5.0

Step 1: Create the Host Application (`app-host`)

First, let’s create our host application. We’ll use create-react-app for simplicity, but in a real-world scenario, you might use Vite or a custom Webpack setup.

Create React App: Open your terminal and run:

npx create-react-app app-host --template typescript
cd app-host

Install Webpack Dependencies: Module Federation requires Webpack. Since create-react-app abstracts Webpack, we’ll need to eject or use react-app-rewired to customize the Webpack configuration. For this guide, we’ll use react-app-rewired for a less intrusive approach.
```
npm install --save-dev webpack@5.90.3 webpack-cli@5.1.4 webpack-dev-server@4.15.1 html-webpack-plugin@5.6.0 babel-loader@8.3.0 @babel/core@7.23.9 @babel/preset-react@7.23.3 @babel/preset-typescript@7.23.3 react-app-rewired@2.2.1
```
Note: These versions are current as of Feb 2026. Always verify the latest stable releases against official documentation.

Modify package.json scripts: Replace the react-scripts commands with react-app-rewired in your package.json:

"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test",
  "eject": "react-scripts eject"
},

Create config-overrides.js: In the root of app-host, create config-overrides.js to modify the Webpack config. This file will house our Module Federation setup.

// app-host/config-overrides.js
const { ModuleFederationPlugin } = require('webpack').container;
const deps = require('./package.json').dependencies;

module.exports = function override(config, env) {
  config.plugins.push(
    new ModuleFederationPlugin({
      name: 'app_host',
      remotes: {
        // This tells the host where to find the remote entry file for 'products_app'
        // The format is '<remote_name>@<remote_url>/remoteEntry.js'
        products_app: 'products_app@http://localhost:3001/remoteEntry.js',
        // We'll add a cart_app later in the challenge
        // cart_app: 'cart_app@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        // Share React and ReactDOM. Crucial for performance and consistency.
        ...deps,
        react: {
          singleton: true, // Only allow a single instance of React
          requiredVersion: deps.react,
        },
        'react-dom': {
          singleton: true,
          requiredVersion: deps['react-dom'],
        },
        // Add other shared dependencies as needed, e.g., a shared UI library
      },
    })
  );

  // Important: Allow dynamic public path for Module Federation to resolve remotes
  config.output.publicPath = 'auto';

  return config;
};

Explanation:

name: 'app_host': A unique identifier for this host application.
remotes: An object where keys are the names you’ll use to import remote modules, and values are the name@url/remoteEntry.js of the remote. We’re pointing to localhost:3001, which will be our app-remote-products.
shared: This is critical. It defines dependencies that should be shared between the host and remotes.
- singleton: true: Ensures that only one instance of the module is loaded at runtime, preventing multiple React instances which can cause issues.
- requiredVersion: Specifies the minimum or exact version required. This helps prevent version conflicts.

Update app-host/src/App.tsx: Now, let’s dynamically load a component from our future products_app remote.

// app-host/src/App.tsx
import React, { Suspense } from 'react';
import './App.css';

// Dynamically import the remote component.
// The 'products_app' part comes from the `remotes` config in config-overrides.js
// The './ProductList' part is the module exposed by the remote app.
const RemoteProductList = React.lazy(() => import('products_app/ProductList'));

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <h1>Host Application</h1>
      </header>
      <main>
        <h2>Welcome to our E-commerce Platform!</h2>
        {/* Suspense is required for React.lazy components */}
        <Suspense fallback={<div>Loading Products...</div>}>
          <RemoteProductList />
        </Suspense>
      </main>
    </div>
  );
}

export default App;

Explanation:

React.lazy(): This built-in React feature allows you to render a dynamic import as a regular component. It works perfectly with Module Federation.
Suspense: Required when using React.lazy() to display a fallback UI while the remote component’s bundle is being loaded.

Step 2: Create the Remote Application (`app-remote-products`)

Now, let’s create the microfrontend that will expose the ProductList component.

Create React App: Open a new terminal tab and run:

npx create-react-app app-remote-products --template typescript
cd app-remote-products

Install Webpack Dependencies: Similar to the host, we need to install the Webpack dependencies and react-app-rewired.

npm install --save-dev webpack@5.90.3 webpack-cli@5.1.4 webpack-dev-server@4.15.1 html-webpack-plugin@5.6.0 babel-loader@8.3.0 @babel/core@7.23.9 @babel/preset-react@7.23.3 @babel/preset-typescript@7.23.3 react-app-rewired@2.2.1

Modify package.json scripts: Again, replace react-scripts with react-app-rewired:

"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test",
  "eject": "react-scripts eject"
},

Create config-overrides.js: In the root of app-remote-products, create config-overrides.js for its Module Federation setup.

// app-remote-products/config-overrides.js
const { ModuleFederationPlugin } = require('webpack').container;
const deps = require('./package.json').dependencies;

module.exports = function override(config, env) {
  config.plugins.push(
    new ModuleFederationPlugin({
      name: 'products_app', // Unique name for this remote application
      filename: 'remoteEntry.js', // The file that the host will download
      exposes: {
        // What components/modules this remote app makes available
        './ProductList': './src/components/ProductList.tsx',
      },
      shared: {
        // Share React and ReactDOM, just like the host
        ...deps,
        react: {
          singleton: true,
          requiredVersion: deps.react,
        },
        'react-dom': {
          singleton: true,
          requiredVersion: deps['react-dom'],
        },
      },
    })
  );

  // Important: Allow dynamic public path for Module Federation
  config.output.publicPath = 'auto';

  return config;
};

Explanation:

name: 'products_app': The unique name that the host will use to refer to this remote.
filename: 'remoteEntry.js': This is the bundle that Webpack will generate, containing the manifest of exposed modules. The host downloads this file to understand what’s available.
exposes: An object mapping a public alias (./ProductList) to the actual path of the component within this remote application.

Create app-remote-products/src/components/ProductList.tsx: This is the component we want to expose.

// app-remote-products/src/components/ProductList.tsx
import React from 'react';

interface Product {
  id: string;
  name: string;
  price: number;
}

const products: Product[] = [
  { id: 'p1', name: 'Laptop Pro', price: 1200 },
  { id: 'p2', name: 'Wireless Mouse', price: 25 },
  { id: 'p3', name: 'Mechanical Keyboard', price: 80 },
];

const ProductList: React.FC = () => {
  console.log('ProductList component rendered from remote app!');
  return (
    <div style={{ border: '2px solid #28a745', padding: '15px', borderRadius: '8px', margin: '20px' }}>
      <h3>Products (from Remote Microfrontend)</h3>
      <ul>
        {products.map(product => (
          <li key={product.id}>
            {product.name} - ${product.price.toFixed(2)}
          </li>
        ))}
      </ul>
      <p style={{ fontSize: '0.8em', color: '#666' }}>
        This content is rendered by `app-remote-products`.
      </p>
    </div>
  );
};

export default ProductList;

Update app-remote-products/src/App.tsx: This remote app can also be run independently. Let’s make its App.tsx render the ProductList for standalone testing.

// app-remote-products/src/App.tsx
import React from 'react';
import './App.css';
import ProductList from './components/ProductList'; // Import locally for standalone run

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <h1>Product Microfrontend</h1>
      </header>
      <main>
        <ProductList />
      </main>
    </div>
  );
}

export default App;

Step 3: Run the Applications

Start app-remote-products (Port 3001): In the app-remote-products terminal:
```
npm start
```
This should open http://localhost:3000 (or another port if 3000 is busy). We need it to run on 3001 as configured in app-host. To do this, create a .env file in app-remote-products root:
```
PORT=3001
```
Then, npm start again. Verify it runs on http://localhost:3001.
Start app-host (Port 3000): In the app-host terminal:
```
npm start
```
This should open http://localhost:3000.
You should now see the “Host Application” header, and below it, the “Products (from Remote Microfrontend)” section, proving that the ProductList component is being loaded and rendered from app-remote-products! Check your browser’s network tab; you’ll see remoteEntry.js being fetched from localhost:3001.

This setup demonstrates the core of Module Federation. Each application can be developed and run independently, yet they compose into a single user experience.

3.2. Implementing WebSockets in React

Now, let’s switch gears and integrate WebSockets to enable real-time updates. We’ll create a simple chat application within our app-host (or any React app).

Step 1: Create a Custom `useWebSocket` Hook

A custom hook is the perfect place to encapsulate WebSocket logic, managing connection state, messages, and cleanup.

Create app-host/src/hooks/useWebSocket.ts:

// app-host/src/hooks/useWebSocket.ts
import { useState, useEffect, useRef, useCallback } from 'react';

interface WebSocketMessage {
  type: string;
  payload: any;
}

const useWebSocket = (url: string) => {
  const [isConnected, setIsConnected] = useState(false);
  const [lastMessage, setLastMessage] = useState<WebSocketMessage | null>(null);
  const ws = useRef<WebSocket | null>(null);

  const sendMessage = useCallback((message: WebSocketMessage) => {
    if (ws.current && ws.current.readyState === WebSocket.OPEN) {
      ws.current.send(JSON.stringify(message));
    } else {
      console.warn('WebSocket not connected. Message not sent:', message);
    }
  }, []);

  useEffect(() => {
    // 1. Establish connection
    ws.current = new WebSocket(url);

    ws.current.onopen = () => {
      console.log('WebSocket connected!');
      setIsConnected(true);
    };

    ws.current.onmessage = (event) => {
      try {
        const message: WebSocketMessage = JSON.parse(event.data);
        setLastMessage(message);
      } catch (error) {
        console.error('Failed to parse WebSocket message:', event.data, error);
      }
    };

    ws.current.onclose = () => {
      console.log('WebSocket disconnected.');
      setIsConnected(false);
      // Implement re-connection logic here for production apps!
    };

    ws.current.onerror = (error) => {
      console.error('WebSocket error:', error);
      setIsConnected(false);
    };

    // 2. Cleanup on component unmount
    return () => {
      if (ws.current) {
        ws.current.close();
      }
    };
  }, [url]); // Re-run effect if URL changes

  return { isConnected, lastMessage, sendMessage };
};

export default useWebSocket;

Explanation:

useState hooks track connection status and the last received message.
useRef holds the WebSocket instance itself. This prevents it from being re-created on every render.
useEffect manages the WebSocket lifecycle:
- It establishes the connection (new WebSocket(url)).
- It sets up event listeners (onopen, onmessage, onclose, onerror).
- The return function handles cleanup (ws.current.close()) when the component unmounts, preventing memory leaks.
sendMessage: A useCallback wrapped function to send data over the WebSocket. It checks if the connection is open before sending.
Important: For production, you’d add robust reconnection logic with exponential backoff in the onclose handler.

Step 2: Create a Simple WebSocket Server (for testing)

Before we integrate the hook, we need a WebSocket server to connect to. This is a very basic Node.js server using the ws library.

Create a new directory for the server: Outside your React apps, create a folder like websocket-server.
```
mkdir websocket-server
cd websocket-server
npm init -y
npm install ws@8.16.0
```

Create server.js in websocket-server:

// websocket-server/server.js
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', ws => {
  console.log('Client connected');

  ws.on('message', message => {
    console.log(`Received: ${message}`);
    // Broadcast the message to all connected clients
    wss.clients.forEach(client => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(message.toString()); // Ensure message is a string
      }
    });
    // Also send back to the sender for confirmation/display
    ws.send(message.toString());
  });

  ws.on('close', () => {
    console.log('Client disconnected');
  });

  ws.on('error', error => {
    console.error('WebSocket error:', error);
  });
});

console.log('WebSocket server started on port 8080');

Run the WebSocket Server: In the websocket-server terminal:
```
node server.js
```
You should see “WebSocket server started on port 8080”.

Step 3: Integrate `useWebSocket` into a React Component

Let’s create a simple chat component in app-host to demonstrate the hook.

Create app-host/src/components/ChatWindow.tsx:

// app-host/src/components/ChatWindow.tsx
import React, { useState, useEffect } from 'react';
import useWebSocket from '../hooks/useWebSocket';

interface ChatMessage {
  user: string;
  text: string;
  timestamp: string;
}

const ChatWindow: React.FC = () => {
  const [messages, setMessages] = useState<ChatMessage[]>([]);
  const [inputMessage, setInputMessage] = useState('');
  const currentUser = 'User' + Math.floor(Math.random() * 100); // Simple random user ID

  // Connect to our WebSocket server
  const { isConnected, lastMessage, sendMessage } = useWebSocket('ws://localhost:8080');

  useEffect(() => {
    if (lastMessage) {
      // Assuming lastMessage.payload is a ChatMessage
      setMessages((prevMessages) => [...prevMessages, lastMessage.payload]);
    }
  }, [lastMessage]); // Only react to new messages

  const handleSendMessage = (e: React.FormEvent) => {
    e.preventDefault();
    if (inputMessage.trim() && isConnected) {
      const chatMessage: ChatMessage = {
        user: currentUser,
        text: inputMessage,
        timestamp: new Date().toLocaleTimeString(),
      };
      sendMessage({ type: 'chat', payload: chatMessage }); // Wrap in our WebSocketMessage format
      setInputMessage('');
    }
  };

  return (
    <div style={{ border: '2px solid #007bff', padding: '15px', borderRadius: '8px', margin: '20px', maxWidth: '400px' }}>
      <h3>Live Chat ({isConnected ? 'Connected' : 'Disconnected'})</h3>
      <div style={{ height: '200px', overflowY: 'scroll', border: '1px solid #ccc', padding: '10px', marginBottom: '10px', backgroundColor: '#f9f9f9' }}>
        {messages.length === 0 ? (
          <p>No messages yet. Say hello!</p>
        ) : (
          messages.map((msg, index) => (
            <div key={index} style={{ marginBottom: '5px', textAlign: msg.user === currentUser ? 'right' : 'left' }}>
              <strong style={{ color: msg.user === currentUser ? '#007bff' : '#6c757d' }}>{msg.user}:</strong> {msg.text}
              <small style={{ display: 'block', fontSize: '0.7em', color: '#aaa' }}>{msg.timestamp}</small>
            </div>
          ))
        )}
      </div>
      <form onSubmit={handleSendMessage} style={{ display: 'flex' }}>
        <input
          type="text"
          value={inputMessage}
          onChange={(e) => setInputMessage(e.target.value)}
          placeholder="Type a message..."
          disabled={!isConnected}
          style={{ flexGrow: 1, padding: '8px', borderRadius: '4px', border: '1px solid #ccc' }}
        />
        <button
          type="submit"
          disabled={!isConnected || !inputMessage.trim()}
          style={{ marginLeft: '10px', padding: '8px 15px', borderRadius: '4px', border: 'none', backgroundColor: '#007bff', color: 'white', cursor: 'pointer' }}
        >
          Send
        </button>
      </form>
    </div>
  );
};

export default ChatWindow;

Add ChatWindow to app-host/src/App.tsx:

// app-host/src/App.tsx (updated)
import React, { Suspense } from 'react';
import './App.css';
import ChatWindow from './components/ChatWindow'; // Import our new ChatWindow

const RemoteProductList = React.lazy(() => import('products_app/ProductList'));

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <h1>Host Application</h1>
      </header>
      <main style={{ display: 'flex', justifyContent: 'space-around', flexWrap: 'wrap' }}>
        {/* Microfrontend Section */}
        <section>
          <h2>Welcome to our E-commerce Platform!</h2>
          <Suspense fallback={<div>Loading Products...</div>}>
            <RemoteProductList />
          </Suspense>
        </section>

        {/* WebSocket Chat Section */}
        <section>
          <h2>Real-time Communication</h2>
          <ChatWindow />
        </section>
      </main>
    </div>
  );
}

export default App;

Test the Chat:
- Ensure your websocket-server is running (node server.js).
- Ensure app-remote-products is running (npm start in its directory, port 3001).
- Ensure app-host is running (npm start in its directory, port 3000).
Open http://localhost:3000 in two separate browser tabs (or even different browsers). Type a message in one tab, and you should see it instantly appear in the other tab, as well as in the sender’s own chat window. You’ll also see messages logged in your websocket-server terminal. This demonstrates successful real-time bi-directional communication!

Mini-Challenge

Now it’s your turn to extend these concepts!

Challenge 1: Extend Microfrontend Communication

Task: Create a new microfrontend called app-remote-cart that displays a shopping cart icon with an item count. When a user “adds a product” in app-remote-products (you can add a simple button next to each product), the app-remote-cart should update its item count. The app-host should facilitate this communication.

Hints:

For app-remote-cart:
- Create a new React app (npx create-react-app app-remote-cart --template typescript).
- Configure config-overrides.js to expose a CartIcon component, running on PORT=3002.
- The CartIcon component should display a count (e.g., Cart (0)).
For app-host:
- Add cart_app: 'cart_app@http://localhost:3002/remoteEntry.js' to remotes in its config-overrides.js.
- Import RemoteCartIcon using React.lazy() in App.tsx.
- To enable communication, you could use a shared state management library (like Zustand or even React Context) that is exposed and consumed via Module Federation, or rely on browser Custom Events. A simple approach for this challenge is to pass a callback function from the host to the RemoteProductList as a prop, which then updates a state in the host, and that state is passed to the RemoteCartIcon.
For app-remote-products:
- Modify ProductList.tsx to include an “Add to Cart” button for each product.
- If you’re using the callback prop method, the ProductList component will need to accept a prop like onAddToCart: (product: Product) => void.

What to Observe/Learn:

How to orchestrate communication between independent microfrontends through the host.
The flexibility of Module Federation for composing complex UIs.
The importance of careful dependency management.

Challenge 2: Enhance WebSocket Chat with User Typing Indicators

Task: Modify the ChatWindow component and the websocket-server to include “typing…” indicators. When a user starts typing in the input field, a message should be sent via WebSocket to notify others. When they stop, another message should clear the indicator.

Hints:

For ChatWindow:
- Use useState to track if the current user is typing.
- Implement a debounce function or setTimeout/clearTimeout to send typing:true when typing starts and typing:false after a short delay (e.g., 1 second) of no input.
- Send these “typing status” messages via sendMessage.
- Maintain a list of active typing users (useState<string[]>) based on incoming WebSocket messages.
- Display these users (e.g., “John, Jane is typing…”) below the chat window.
For websocket-server:
- Add logic to handle “typing status” messages.
- Broadcast these messages to all other clients.
- You might need to store which clients are currently typing.

What to Observe/Learn:

Handling different types of messages over a single WebSocket connection.
Implementing debouncing for real-time events to avoid excessive network traffic.
Managing transient state (like “typing”) across multiple clients.

Common Pitfalls & Troubleshooting

Microfrontends (Module Federation)

Dependency Mismatch/Duplication:
- Pitfall: Each microfrontend bundles its own react, react-dom, etc., leading to huge bundles and potential runtime errors (e.g., “Invalid hook call”).
- Why it happens: Incorrect or missing shared configuration in ModuleFederationPlugin.
- Troubleshooting:
  - Always use singleton: true for core libraries like react and react-dom. This forces Webpack to load only one instance.
  - Specify requiredVersion to ensure compatibility. If a remote requires a different major version than the host, Module Federation can either fail or load both versions (if singleton is false), which you usually want to avoid for React.
  - Use a tool like webpack-bundle-analyzer to inspect your final bundles and see if dependencies are duplicated.
Global CSS Conflicts:
- Pitfall: Styles from one microfrontend bleed into another, causing unexpected visual glitches.
- Why it happens: Global CSS selectors (e.g., button {}, .container {}) are not scoped to their respective microfrontends.
- Troubleshooting:
  - CSS Modules: The default for create-react-app (.module.css files) provides local scoping.
  - CSS-in-JS: Libraries like Styled Components, Emotion, or Tailwind CSS (with JIT/PostCSS scoping) provide excellent scoping mechanisms.
  - BEM Naming Convention: A disciplined naming convention can help reduce conflicts, though it’s not foolproof.

Runtime Errors from Remotes:

Pitfall: If a remote microfrontend fails to load or throws an error during rendering, it can crash the entire host application.
Why it happens: JavaScript errors, network issues preventing remote bundle download, or misconfigured Module Federation.

Troubleshooting:

React Error Boundaries: Wrap your dynamically loaded remote components with React Error Boundaries. This allows you to gracefully catch errors within a subtree and display a fallback UI without crashing the whole application.

// Example of an Error Boundary
class MyErrorBoundary extends React.Component<{ children: React.ReactNode }, { hasError: boolean }> {
  state = { hasError: false };
  static getDerivedStateFromError(error: any) {
    return { hasError: true };
  }
  componentDidCatch(error: any, errorInfo: any) {
    console.error("Microfrontend error:", error, errorInfo);
    // Log error to an error tracking service
  }
  render() {
    if (this.state.hasError) {
      return <h2>Something went wrong loading this section. Please try again.</h2>;
    }
    return this.props.children;
  }
}
// Usage:
// <MyErrorBoundary>
//   <Suspense fallback={<div>Loading...</div>}>
//     <RemoteProductList />
//   </Suspense>
// </MyErrorBoundary>

Robust Loading States: Ensure Suspense fallbacks are user-friendly.

WebSockets

Connection Dropping/Reconnection:
- Pitfall: WebSocket connections can drop due to network instability, server restarts, or idle timeouts, leading to lost real-time updates.
- Why it happens: The nature of network communication.
- Troubleshooting:
  - Implement Reconnection Logic: Your useWebSocket hook (or library) should automatically attempt to reconnect with an exponential backoff strategy. This means waiting longer between reconnection attempts to avoid overwhelming the server.
  - Heartbeats (Ping/Pong): Implement a ping/pong mechanism to keep the connection alive and detect dead connections. Both client and server send small “ping” messages and expect a “pong” response.
  - Libraries: Consider socket.io-client or reconnecting-websocket for robust, battle-tested reconnection logic.
Message Ordering and Loss:
- Pitfall: WebSockets, by default, do not guarantee message order or delivery. In high-traffic or unreliable network conditions, messages might arrive out of order or be lost.
- Why it happens: TCP (which WebSockets use) guarantees order and delivery at the transport layer, but application-level messages might still be processed out of order if your code doesn’t account for it, or if a message is lost before it’s sent over the socket due to client-side issues.
- Troubleshooting:
  - Application-Level Acknowledgements: For critical messages, implement an ACK (acknowledgement) system. The sender includes a unique ID, and the receiver sends an ACK message back once processed. If no ACK is received within a timeout, the sender retries.
  - Sequence Numbers: Include a sequence number with each message. The receiver can then reorder messages or request retransmission if a gap is detected.
Security (Authentication & Authorization):
- Pitfall: An open WebSocket server can be exploited by unauthorized users, leading to data leaks or malicious actions.
- Why it happens: Forgetting that WebSockets, like any network endpoint, need protection.
- Troubleshooting:
  - Authentication on Handshake: Authenticate the user during the initial HTTP handshake (e.g., by checking a cookie or an Authorization header). Only upgrade the connection if authentication succeeds.
  - Token-based Authorization: For subsequent messages, ensure the server authorizes actions based on the user’s identity established during the handshake. Don’t trust client-side data.
  - Same-Origin Policy: Browsers enforce the Same-Origin Policy for WebSockets, but server-side checks are still crucial.

Summary

You’ve just taken a significant leap into advanced React architectures! Let’s quickly recap the key takeaways from this chapter:

Microfrontends address the challenges of scaling large frontend applications and development teams by breaking down monolithic UIs into smaller, independently deployable units.
Webpack 5’s Module Federation is a powerful tool for implementing microfrontends in React, enabling different applications to share and consume modules at runtime while efficiently managing shared dependencies.
WebSockets provide a persistent, full-duplex communication channel for real-time interactions, offering superior performance and user experience compared to traditional HTTP polling for dynamic content.
Implementing custom React hooks is an elegant way to encapsulate WebSocket logic, managing connection states, message handling, and cleanup.
When working with advanced architectures, always be mindful of common pitfalls such as dependency mismatches, CSS conflicts, connection stability, and security, and apply best practices like Error Boundaries and reconnection logic.

By mastering Microfrontends and WebSockets, you’re now equipped to design and build highly resilient, scalable, and interactive React applications that meet the demands of modern enterprise environments.

References

Webpack Module Federation Official Documentation: https://webpack.js.org/concepts/module-federation/
MDN Web Docs - WebSockets API: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
React.lazy and Suspense Official Documentation: https://react.dev/reference/react/lazy
React Error Boundaries Official Documentation: https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.

Chapter 15: Advanced Architectures: Microfrontends and WebSockets

Table of Contents

Core Concepts

Microfrontends: Scaling Your Frontend Development

What are Microfrontends?

Why Microfrontends? (The Problem Solved)

What Happens if Ignored? (The Failures)

How Microfrontends Work with Module Federation

WebSockets: Real-time Communication Powerhouse

What are WebSockets?

Why WebSockets? (The Problem Solved)

What Happens if Ignored? (The Failures)

How WebSockets Work

Integrating WebSockets in React

Step-by-Step Implementation

3.1. Setting up a Microfrontend with Module Federation

Step 1: Create the Host Application (app-host)

Step 2: Create the Remote Application (app-remote-products)

Step 3: Run the Applications

3.2. Implementing WebSockets in React

Step 1: Create a Custom useWebSocket Hook

Step 2: Create a Simple WebSocket Server (for testing)

Step 3: Integrate useWebSocket into a React Component

Mini-Challenge

Challenge 1: Extend Microfrontend Communication

Challenge 2: Enhance WebSocket Chat with User Typing Indicators

Common Pitfalls & Troubleshooting

Microfrontends (Module Federation)

WebSockets

Summary

References

Step 1: Create the Host Application (`app-host`)

Step 2: Create the Remote Application (`app-remote-products`)

Step 1: Create a Custom `useWebSocket` Hook

Step 3: Integrate `useWebSocket` into a React Component