Micro Frontends for Large Applications — React Explained, Day 10

• A growing codebase can make builds slower.
• Even a small change may require testing and deploying the entire application.
• Teams sharing one codebase face more merge conflicts and have a harder time choosing or upgrading their tools.
• A bug or performance problem in one area can affect the whole application.

• Independent development and deployment
  Each micro app has its own codebase and can be developed, tested, built, and deployed separately. This can speed up development and releases.
• Greater team autonomy
  Each team owns a micro app that corresponds to a business feature or domain. Teams have more freedom to choose their tools and working methods, while still coordinating across the product.
• Gradual upgrades and technology choices
  Teams can introduce new technology or upgrade an existing stack in one micro app at a time. In principle, different micro apps can even use different frameworks, such as React, Vue, or Angular.
• Manageable codebases
  Splitting a large codebase into smaller ones makes each part easier to manage.

Monolithic and micro frontend architectures

• iframe
  The oldest and simplest approach loads each micro app in a separate iframe. It is easy to implement, but communication between apps gets complicated, and URL handling and the user experience can feel awkward. These trade-offs make it less popular today.
• Web Components
  Use standard Web Components to encapsulate each micro app as a custom HTML element. This works across frameworks, though browser support and ecosystem maturity are considerations.
• JavaScript integration
  JavaScript dynamically loads and mounts each micro app in a specific DOM element. Tools such as single-spa and Webpack Module Federation use this approach.

• Chooses which micro app to activate based on the URL and handles routing.
• Controls when each app loads, mounts on screen, and unmounts.
• Lets you combine apps built with different frameworks, including React, Angular, and Vue.

1. Container app (root app)
   The main application contains the single-spa configuration.
2. Application registration
   Register each micro app with single-spa and specify which URLs activate it and how to load its code.
3. Routing
   When the URL changes, single-spa activates the matching micro app and unmounts apps that are no longer needed.

single-spa architecture

• Host
  An application that imports and uses code from another application, called a remote. The container, or shell, typically acts as the host in a micro frontend.
• Remote
  An application that exposes its code to a host. Each micro app can act as a remote.
• Shared dependencies
  Libraries that hosts and remotes share. Module Federation considers library versions when managing these dependencies and can avoid duplicate loads. For example, if a host and remote are configured to share React v18, the browser can load that version once.
• Exposed modules
  Specific modules, such as components or functions, that a remote makes available to a host.

// Remote 앱 (예: 'profileApp')의 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
const deps = require('./package.json').dependencies; // 공유 의존성 버전 관리
 
module.exports = {
  // ... 기타 설정 ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'profileApp', // Remote 앱의 고유 이름
      filename: 'remoteEntry.js', // Host가 참조할 진입점 파일
      exposes: {
        // 외부에 노출할 모듈 경로 매핑 ('./UserProfile' 키로 접근)
        './UserProfile': './src/UserProfile',
      },
      shared: { // 공유할 의존성 설정
        ...deps, // package.json의 모든 의존성 공유 (간단 예시)
        react: { singleton: true, requiredVersion: deps.react },
        'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },
      },
    }),
  ],
};

// Host 앱 (예: 'containerApp')의 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
const deps = require('./package.json').dependencies;
 
module.exports = {
  // ... 기타 설정 ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'containerApp',
      remotes: {
        // 사용할 Remote 앱 정보 등록 (profileApp@http://localhost:3001/remoteEntry.js)
        profileApp: 'profileApp@http://localhost:3001/remoteEntry.js',
      },
      shared: { // 공유할 의존성 설정 (Remote와 동일하게)
        ...deps,
        react: { singleton: true, requiredVersion: deps.react },
        'react-dom': { singleton: true, requiredVersion: deps['react-dom'] },
      },
    }),
  ],
};

// Host 앱의 컴포넌트에서 Remote 컴포넌트 사용
import React, { lazy, Suspense } from 'react';
const RemoteUserProfile = lazy(() => import('profileApp/UserProfile'));
 
function App() {
  return (
    <div>
      <h1>컨테이너 앱</h1>
      <Suspense fallback="Loading Profile...">
        <RemoteUserProfile />
      </Suspense>
    </div>
  );
}

Q: What is Webpack Module Federation, and what problem does it solve in micro frontends?

A: It lets independently built Webpack applications share code dynamically at runtime. Micro apps can share components and avoid loading common libraries more than once.

• Initial setup
  Configuring tools such as Module Federation or single-spa and building the integration takes upfront work.
• Technology stack management
  Teams can use different stacks, but too much variety can complicate development, builds, and deployments, and increase bundle size. Agree on a reasonable level of standardization or set guidelines.
• Shared dependency versions
  Plan how teams will manage the versions of shared libraries across micro apps. Module Federation helps, but teams still need to coordinate versions.
• A consistent user experience
  Teams working independently can easily diverge in design and behavior. Build and use a shared design system, ideally distributed as a library.
• State and communication between apps
  If micro apps need to share state or communicate, define clear interfaces and choose how they will communicate. Options include custom events, the window object, router state, or a global state library. This can be one of the hardest parts of MFE.
• Team boundaries
  Decide how to divide the apps and teams. Business domains, user journeys, and features are possible boundaries. Aim to keep dependencies between teams low.
• Independent deployment pipelines
  Each micro app needs a CI/CD pipeline so it can be built, tested, and deployed independently.
• Operations and monitoring
  Managing and monitoring multiple deployment units can make operations more complex.

Module Federation uses a dependency graph to manage shared modules and versions. single-spa can map URLs to micro apps through routing rules, much like a routing table.

• They allow
  independent development and deployment
  , give teams
  more autonomy
  , and support
  gradual changes
  .
• Teams commonly assemble micro apps with
  runtime integration
  , using iframes, Web Components, or JavaScript.
• single-spa
  handles routing and lifecycles, while
  Webpack Module Federation
  helps share code and dependencies.
• The approach introduces challenges in
  setup
  ,
  user experience consistency
  ,
  communication between apps
  , and
  operations
  .

Next time, we'll cover frontend API communication and asynchronous work, from Axios and Fetch to AbortController and GraphQL clients.

• Micro Frontends (martinfowler.com): https://martinfowler.com/articles/micro-frontends.html↗
• Webpack documentation — Module Federation: https://webpack.js.org/concepts/module-federation/↗
• single-spa documentation: https://single-spa.js.org/↗