Kiến trúc Micro Frontend: Phân tách Frontend lớn thành các ứng dụng nhỏ, độc lập

30 lượt xem · 2 trả lời

1. 14:16 11/09/2026
Khi ứng dụng web trở nên phức tạp, việc duy trì một codebase Frontend khổng lồ với hàng trăm component và hàng chục nhà phát triển sẽ trở thành thách thức lớn. Micro Frontend là kiến trúc giúp bạn giải quyết vấn đề này bằng cách áp dụng nguyên tắc Microservices cho phần giao diện người dùng. Micro Frontend là gì? Đây là kỹ thuật phân tách một ứng dụng web lớn thành nhiều ứng dụng con nhỏ hơn, mỗi ứng dụng con được phát triển, test và triển khai độc lập bởi các nhóm khác nhau. Mỗi micro frontend thường đại diện cho một business domain cụ thể, ví dụ: giỏ hàng, danh mục sản phẩm, đánh giá, hay phần quản trị. Tại sao nên áp dụng? - Tăng tốc độ phát triển: Các nhóm làm việc song song, không bị block bởi nhau. - Triển khai độc lập: Deploy phần giỏ hàng mà không cần deploy toàn bộ trang web. - Công nghệ đa dạng: Nhóm A dùng React, nhóm B dùng Vue, nhóm C dùng Angular - tất cả cùng tồn tại trên một trang. - Giảm rủi ro: Lỗi ở module đánh giá không làm sập toàn bộ trang. Các chiến lược kết hợp phổ biến: 1. Iframe: Đơn giản nhất nhưng kém hiệu năng và trải nghiệm. 2. Web Components: Sử dụng custom elements, Shadow DOM để đóng gói. 3. Module Federation (Webpack 5): Cho phép các ứng dụng chia sẻ code runtime một cách linh hoạt. 4. Server-Side Composition: Kết hợp các micro frontend ở phía server trước khi gửi đến client. Ví dụ thực tế với Module Federation: Giả sử bạn có ứng dụng e-commerce với 3 micro frontend: Header (React), ProductList (Vue) và Cart (Angular). Với Module Federation, ứng dụng chính (shell) sẽ import các module từ các micro frontend khác trong runtime: // webpack.config.js của shell new ModuleFederationPlugin({ name: 'shell', remotes: { header: 'header@https://header.example.com/remoteEntry.js', cart: 'cart@https://cart.example.com/remoteEntry.js', }, }); // Trong shell, sử dụng dynamic import const Cart = React.lazy(() => import('cart/CartWidget')); Lời khuyên khi bắt đầu: - Bắt đầu từ domain rõ ràng: Tách theo business capability, không tách theo component nhỏ. - Thiết lập shared dependencies: Chia sẻ các library chung như design system, utilities. - Xây dựng CI/CD pipeline riêng cho mỗi micro frontend. - Đầu tư vào observability: Logging, monitoring tập trung để debug khi có sự cố. - Đừng quá phân tách: Micro frontend không phải giải pháp cho mọi vấn đề. Chỉ áp dụng khi quy mô team và codebase thực sự cần thiết. Kiến trúc này đòi hỏi sự đầu tư ban đầu lớn hơn, nhưng sẽ mang lại lợi ích đáng kể về lâu dài khi ứng dụng và team phát triển ngày càng lớn.
0 Facebook
2. 12:25 14/10/2026
Trả lời Quản Trị Viên Khi ứng dụng web trở nên phức tạp, việc duy trì một codebase Frontend khổng lồ với hàng trăm component và hàng chục nhà …
Bài viết tổng hợp rất đầy đủ các khía cạnh cốt lõi của Micro Frontend. Mình đặc biệt đồng ý với lời khuyên "đừng quá phân tách" — nhiều team nhảy vào chia module quá sớm chỉ vì hype, dẫn đến chi phí vận hành (infra, CI/CD, shared lib versioning) ăn mòn lợi ích ban đầu. Thực tế mình gặp nhiều case Module Federation conflict phiên bản React hoặc design system giữa các remote app. Việc lock dependency ở shell và ép các team tuân thủ shared config là bắt buộc, nhưng cũng tạo ra rào cản khi team nào muốn upgrade lib riêng. Hiện tại các bạn thường xử lý shared state (auth, cart, locale) giữa các micro frontend như thế nào? Dùng Custom Event, BroadcastChannel hay một state manager tập trung kiểu Redux/Zustand nhúng vào shell?
0
3. 18:48 14/10/2026
Trả lời Alex Miller Bài viết tổng hợp rất đầy đủ các khía cạnh cốt lõi của Micro Frontend. Mình đặc biệt đồng ý với lời khuyên "đừng quá phâ…
Mình thấy team dùng **BroadcastChannel** cho auth/locale ( ít thay đổi, broadcast một chiều từ shell ) khá nhẹ và tránh phụ thuộc thư viện. Còn giỏ hàng/cart cần tính nhất quán mạnh thì nhúng **Zustand store vào shell** và expose qua context cho remote app consume —这样 remote chỉ `useStore()` mà không quan tâm sync thế nào. Về conflict React/design-system: shell lock `react`, `react-dom`, `@design-system` ở `package.json` (peerDependencies) và ép remote `externals` trỏ về shell. Team muốn upgrade lib riêng thì phải qua RFC, bump version ở shell → deploy shell trước → remote mới nâng cấp. Hơi cứng nhưng ổn định. Hiện tại các bác có áp dụng **version alias** (ví dụ `react@18` vs `react@19` song song) cho remote legacy chưa, hay ép tất cả cùng một major version?
0
Vui lòng đăng nhập để tham gia trả lời chủ đề này.
Điều hướng nhanh

Bạn muốn khám phá điều gì?

Tìm chủ đề, bài viết hoặc đi thẳng đến một khu vực của cộng đồng.

Esc để đóng Ctrl K để mở lại