Nền tảng & Trade-offs

Trong phỏng vấn kỹ năng Senior/Lead, câu hỏi không phải là "Microfrontend là gì?" mà là "Tại sao bạn chọn MFE thay vì Monorepo?".

1. Phân tích thiết kế: Phân rã theo chiều dọc (Vertical Slicing)

Bản chất của MFE không phải là chia nhỏ file JS, mà là chia nhỏ trách nhiệm (Ownership).

Cách làm truyền thống: Horizontal Slicing (Layered)

Chia team theo tầng chuyên môn: Team UI/UX, Team Logic, Team Data. Hoặc chia theo component: Team Header, Team Footer.

Nhược điểm:

• Nghẽn cổ chai Giao diện: Khi Team Catalog đổi logic sản phẩm, Team Header phải update code theo để hiển thị số lượng giỏ hàng. Hai team phải sync deploy cùng lúc.
• Tight Coupling: Ranh giới giữa các phần bị mờ nhạt, dẫn đến việc "sửa chỗ này hỏng chỗ kia" rất thường xuyên.

Cách làm mới: Vertical Slicing (Domain-Driven Design)

Chia theo luồng giá trị (Value Stream). Team Checkout sở hữu toàn bộ từ giao diện, logic đến việc gọi API thanh toán.

Ưu điểm & Vấn đề giải quyết:

• Tính tự trị (Autonomy): Team Checkout có thể deploy 10 lần một ngày mà không cần quan tâm Team Catalog đang làm gì.
• Bối cảnh giới hạn (Bounded Context): Mỗi module chỉ quan tâm đến nghiệp vụ của nó. Dữ liệu được trao đổi qua các "hợp đồng" (API/Events) thay vì dùng chung biến toàn cục.

2. Đánh đổi kỹ thuật (Trade-offs)

MFE không phải là "viên đạn bạc". Nó đi kèm với chi phí cực lớn:

• Operational Complexity: Cần hệ thống CI/CD cực mạnh để quản lý hàng chục repo.
• Payload Overhead: Nếu không quản lý tốt, người dùng sẽ phải tải nhiều bản React trùng lặp.
• Visual Inconsistency: Dễ dẫn đến việc mỗi module có một phong cách hiển thị khác nhau.

3. Code minh họa: Phân rã ranh giới

Cách truyền thống (Monolith - Mọi thứ trộn lẫn):

// main-app.tsx
import { Header } from './components/Header';
import { ProductList } from './features/catalog';
import { CartProvider } from './context/CartContext'; // Shared state cồng kềnh

const App = () => (
  <CartProvider>
    <Header />
    <ProductList />
  </CartProvider>
);

Cách hiện đại (Microfrontends - Phân rã Domain):

// App Shell - Chỉ đóng vai trò điều phối (Orchestrator)
import React, { Suspense } from 'react';

const CatalogMFE = React.lazy(() => import('catalog/App'));
const CheckoutMFE = React.lazy(() => import('checkout/App'));

const App = () => (
  <Layout>
    <Suspense fallback={<Skeleton />}>
      <Router>
        <Route path="/shop" component={CatalogMFE} />
        <Route path="/cart" component={CheckoutMFE} />
      </Router>
    </Suspense>
  </Layout>
);

Bài tập: Viết ADR

Hãy viết 1 bản ADR dài 1 trang cho dự án Shopee Clone:

• Bối cảnh: Hệ thống hiện tại mất 45 phút để build và deploy. Một lỗi ở trang Profile làm sập luôn trang Thanh toán.
• Quyết định: Áp dụng Microfrontends bằng Webpack Module Federation.
• Hệ quả: Chấp nhận tốn thêm 20% thời gian ban đầu để xây dựng hạ tầng CI/CD và Design System.

Câu hỏi phỏng vấn

Q: Tại sao lại nói Microfrontends là một bài toán về con người hơn là kỹ thuật?

• Trả lời: Theo định luật Conway, cấu trúc hệ thống sẽ phản ánh cấu trúc giao tiếp của tổ chức. MFE sinh ra để giải quyết việc quá nhiều team (50-100 người) dẫm chân lên nhau trong một codebase. Kỹ thuật (Module Federation, v.v.) chỉ là công cụ để hiện thực hóa việc chia ranh giới sở hữu (Ownership). Nếu team nhỏ, dùng MFE sẽ chỉ làm chậm quy trình do chi phí quản lý hạ tầng tăng vọt.

Q: Phân biệt Vertical Slicing và Horizontal Slicing. Tại sao Horizontal lại thường được coi là Anti-pattern?

• Trả lời:
  • Horizontal: Chia theo layer (Team Header, Team Footer). Nhược điểm là các team phụ thuộc chặt chẽ vào nhau khi logic thay đổi (Tight coupling).
  • Vertical: Chia theo nghiệp vụ (Team Search, Team Checkout). Mỗi team sở hữu từ UI đến Logic.
  • Tại sao Horizontal là Anti-pattern: Vì nó không giải quyết được vấn đề "Độc lập Deployment". Khi Team Header đổi API, tất cả các page khác đều bị ảnh hưởng, dẫn đến việc phải phối hợp deploy cực kỳ phức tạp.

Q: Khi nào thì KHÔNG nên dùng Microfrontends?

• Trả lời:
  1. Khi quy mô team nhỏ (dưới 2-3 squads).
  2. Khi ứng dụng không có sự phân chia nghiệp vụ rõ ràng (nhu cầu chia sẻ state quá lớn).
  3. Khi tổ chức chưa có nền tảng DevOps và Design System vững chắc. Việc triển khai MFE lúc này sẽ tạo ra một mớ hỗn độn về giao diện và hạ tầng.