Micro Frontends Architecture with Module Federation · 강의

모듈 연합 라우팅 구현

각 마이크로 프런트엔드가 자체 경로를 관리하고 이를 전역 라우터에 통합하는 라우팅을 구현합니다.

모듈 연합 라우팅 구현은(는) CoddyKit의 무료 Micro Frontends Architecture with Module Federation 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Micro Frontends Architecture with Module Federation 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Micro Frontends Architecture with Module Federation 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

What is Federated Routing?

In a Micro Frontend (MFE) architecture, federated routing means each individual MFE is responsible for managing its own specific routes. Instead of one central application dictating all routes, each MFE declares its own pathways.

This approach gives teams more autonomy, allowing them to develop and deploy routing logic independently without tightly coupling to a main host application's routing system.

Benefits of Federated Routes

Federated routing offers several key advantages:

Autonomy: MFE teams control their own navigation.
Independent Deployment: Changes to an MFE's routes don't require redeploying the entire host app.
Scalability: Easier to manage routing logic as the number of MFEs grows.
Technology Agnostic: Different MFEs can use different routing libraries.

Core Principle: Route Ownership

The fundamental idea behind federated routing is that each Micro Frontend publishes its own set of routes. Think of it like a mini-application within the larger system, responsible for its internal navigation structure.

The host application then acts as an aggregator, discovering and integrating these MFE-owned routes into a single, cohesive routing experience for the user.

MFE Defining Local Routes

Here's how a Micro Frontend (let's call it "MFE A") might define its internal routes. These are specific paths that MFE A is responsible for rendering.

We're using a simple array structure to represent routes, where each route has a path and a component or view it should render.

// mfe-a-routes.js
// This MFE owns routes starting with '/app-a'

export const mfeARoutes = [
  {
    path: '/app-a',
    component: 'MFE_A_Dashboard'
  },
  {
    path: '/app-a/profile',
    component: 'MFE_A_UserProfile'
  }
];

Another MFE's Routes

Similarly, another Micro Frontend ("MFE B") will define its own set of routes. Notice how its paths are distinct, often prefixed to avoid conflicts, ensuring clear ownership.

This separation allows MFE A and MFE B to evolve their navigation independently.

// mfe-b-routes.js
// This MFE owns routes starting with '/app-b'

export const mfeBRoutes = [
  {
    path: '/app-b',
    component: 'MFE_B_HomePage'
  },
  {
    path: '/app-b/settings',
    component: 'MFE_B_SettingsPage'
  }
];

Host Aggregates MFE Routes

The host application's role is to act as the central orchestrator. It needs to discover and import the route definitions provided by each Micro Frontend.

Using Module Federation, these route definitions can be exposed by remote MFEs and consumed by the host, effectively building a global route map from distributed sources.

Integrating into a Global Router

The host application then takes all the aggregated routes and integrates them into its own global router instance. This example simulates how a host app might load and process routes from different MFEs to handle navigation.

Try changing the currentPath variable in the code and run it!

// mfe-a-routes.js (Simulated Remote MFE)
export const mfeARoutes = [
  { path: '/app-a', component: 'MFE_A_Dashboard' },
  { path: '/app-a/profile', component: 'MFE_A_UserProfile' }
];

// mfe-b-routes.js (Simulated Remote MFE)
export const mfeBRoutes = [
  { path: '/app-b', component: 'MFE_B_HomePage' },
  { path: '/app-b/settings', component: 'MFE_B_SettingsPage' }
];

// host-app.js (Main Application Entry Point)
// In a real app, these would be dynamically imported
// via Module Federation.
const allFederatedRoutes = [
  ...mfeARoutes,
  ...mfeBRoutes
];

function globalRouter(currentPath) {
  console.log(`Attempting to navigate to: ${currentPath}`);
  const matchedRoute = allFederatedRoutes.find(
    route => route.path === currentPath
  );

  if (matchedRoute) {
    console.log(`Match found! Rendering: ${matchedRoute.component}`);
  } else {
    console.log(`No route found for: ${currentPath}. Showing 404.`);
  }
}

// Simulate user navigation
console.log("--- Global Routing Simulation ---");
globalRouter('/app-a');
globalRouter('/app-b/settings');
globalRouter('/app-a/profile');
globalRouter('/unknown-path');
globalRouter('/app-b');

Seamless Cross-MFE Navigation

Once the host's global router has integrated all federated routes, navigation between different Micro Frontends becomes seamless. From the user's perspective, it feels like a single, unified application.

When a user clicks a link to /app-b/settings, the global router identifies that this path belongs to MFE B and delegates the rendering or activation of MFE B accordingly.

Avoiding Route Conflicts

With multiple MFEs defining routes, conflicts can arise if two MFEs define the same path (e.g., both have a /dashboard route).

Common strategies to prevent this include:

Namespacing: Prefixing MFE routes (e.g., /mfea/dashboard, /mfeb/dashboard).
Unique Paths: Ensuring each MFE's routes are inherently unique.
Host Override: Allowing the host to prioritize or remap conflicting routes.

Check Your Understanding

Imagine you have a host application integrating routes from two Micro Frontends, MFE-A and MFE-B. MFE-A defines /products and /products/:id. MFE-B defines /cart and /checkout.

Which of the following best describes the host application's role in this federated routing setup?

Recap: Federated Routing

You've learned about federated routing, where each Micro Frontend owns and defines its own routes. We saw how a host application aggregates these routes to create a unified navigation experience.

Each MFE declares its own routes.
Host app collects and integrates MFE routes.
Ensures MFE autonomy and independent deployment.
Namespacing helps prevent conflicts.

This approach is crucial for large-scale MFE systems, balancing independence with a consistent user experience.

자주 묻는 질문

“모듈 연합 라우팅 구현” 강의는 무료인가요?

네 — “모듈 연합 라우팅 구현” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Micro Frontends Architecture with Module Federation 강의 전체를 잠금 해제할 수 있습니다. Micro Frontends Architecture with Module Federation 강의에는 총 4개의 강의가 포함되어 있습니다.

“모듈 연합 라우팅 구현”에서 뭘 배우나요?

각 마이크로 프런트엔드가 자체 경로를 관리하고 이를 전역 라우터에 통합하는 라우팅을 구현합니다. 브라우저에서 직접 실행하는 실습 코드로 Micro Frontends Architecture with Module Federation을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Micro Frontends Architecture with Module Federation을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Micro Frontends Architecture with Module Federation은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“모듈 연합 라우팅 구현” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Micro Frontends Architecture with Module Federation 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Micro Frontends Architecture with Module Federation 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Micro Frontends Architecture with Module Federation(으)로 돌아가기