Micro-frontend là gì?

Giả sử bạn đang làm một shop online. Team catalog muốn đưa bộ lọc sản phẩm mới lên production, nhưng phải chờ team cart sửa xong lỗi giỏ hàng vì cả hai dùng chung một bản build và một đợt release. Code đã chia thành nhiều component; nhịp phát hành vẫn bị buộc vào nhau.

Micro-frontend nhắm đến bài toán đó: chia frontend theo những phần nghiệp vụ có thể phát triển và phát hành tương đối độc lập, rồi ghép chúng thành một sản phẩm thống nhất. Nó không phải cách gọi mới cho việc tách một component lớn thành nhiều component nhỏ.

Mục lụcCopy Anchor Link

• Micro-frontend là một ranh giới phát hành
• Ví dụ shop với shell, catalog và cart
  • Ai chịu trách nhiệm cho phần nào
  • Người dùng vẫn đi qua một luồng mua hàng
• Khác gì với chia component và package
• Deploy độc lập thực sự có nghĩa gì
  • Một lần release catalog
  • Độc lập không có nghĩa là không phụ thuộc
• Các phần frontend được ghép ở đâu
• Lợi ích và chi phí đi kèm
• Những điều micro-frontend không đảm bảo
• Khi nào nên bắt đầu bằng mô hình đơn giản hơn
• Tự kiểm tra cách hiểu
• Đọc tiếp
• Tài liệu tham khảo

Micro-frontend là một ranh giới phát hànhCopy Anchor Link

Micro-frontend là một kiểu kiến trúc trong đó các phần frontend có khả năng phát hành độc lập được ghép thành một ứng dụng hoặc trải nghiệm lớn hơn. Mỗi phần thường gắn với một phạm vi nghiệp vụ và có team chịu trách nhiệm từ phát triển, kiểm thử đến vận hành.

Định nghĩa này có ba ý cần giữ cùng nhau:

• Ranh giới nghiệp vụ: catalog quản lý trải nghiệm tìm và xem sản phẩm; cart quản lý trải nghiệm giỏ hàng. Ranh giới không chỉ là “đây là phần HTML, kia là phần CSS”.
• Khả năng phát hành độc lập: thay đổi bên trong catalog có thể tới production mà không bắt buộc build và deploy lại cart.
• Composition: các phần vẫn được ghép lại bằng routing, layout hoặc cơ chế tích hợp để người dùng sử dụng một sản phẩm có trải nghiệm nhất quán.

Bạn có thể hình dung một trung tâm thương mại: các cửa hàng quản lý hoạt động riêng, nhưng cùng dùng lối đi và tuân thủ quy định chung. Trong frontend, “quy định chung” là các thỏa thuận về URL, giao tiếp, thiết kế và phiên đăng nhập. Phép so sánh dừng ở đó: các micro-frontend chạy chung trang còn có thể ảnh hưởng nhau qua JavaScript, CSS và tài nguyên của trình duyệt.

Từ micro không đặt ra số dòng code, số component hay kích thước bundle cụ thể. Một trang nghiệp vụ đủ lớn vẫn có thể là một micro-frontend; một nút bấm rất nhỏ chưa chắc nên trở thành một đơn vị deploy riêng. Đơn vị chia nên đủ trọn vẹn để team hoàn thành phần lớn thay đổi mà không phải liên tục sửa phần của team khác.

Ví dụ shop với shell, catalog và cartCopy Anchor Link

Trong ví dụ xuyên suốt lộ trình này, bạn có một shop gồm ba phần:

direction: down
shop: "Shop trong trình duyệt"
shell: "Shell: layout và route"
catalog: "Catalog: /products"
cart: "Cart: /cart"
shop -> shell
shell -> catalog: "Chọn theo URL"
shell -> cart: "Chọn theo URL"

Sơ đồ này minh họa composition theo route: shell hiển thị catalog hoặc cart tùy URL, không bắt buộc tải và render cả hai cùng lúc. Một thiết kế khác có thể ghép catalog và mini-cart trên cùng trang; đó vẫn là micro-frontend nếu giữ được các ranh giới cần thiết.

Ai chịu trách nhiệm cho phần nàoCopy Anchor Link

Shell là ứng dụng vỏ bao quanh và phối hợp các phần bên trong. Trong một số công cụ, ứng dụng tải phần khác được gọi là host, còn phần được tải được gọi là remote. Đây là tên vai trò trong cơ chế tích hợp, không phải bằng chứng rằng kiến trúc đã có deploy độc lập.

Mỗi phần còn chứa nhiều component bình thường: catalog có ProductCard, FilterPanel, ProductList; cart có CartItem và CartSummary. Component là công cụ tổ chức code bên trong ranh giới đó, không bị micro-frontend thay thế.

Người dùng vẫn đi qua một luồng mua hàngCopy Anchor Link

Giả sử bạn mở /products, chọn sản phẩm và bấm “Thêm vào giỏ”. Catalog thực hiện hành động qua API hoặc một contract giao tiếp đã thống nhất; cart hoặc mini-cart lấy lại trạng thái giỏ khi cần. Sau đó bạn mở /cart để chỉnh số lượng.

Trong cách thiết kế này, catalog không cần biết cart dùng Redux, Zustand hay state nội bộ. Nó chỉ cần biết phần giao tiếp công khai: hành động nào được hỗ trợ, dữ liệu đầu vào là gì và kết quả được thông báo ra sao. State giỏ hàng có thể nằm ở backend; việc ghép UI không bắt buộc biến mọi dữ liệu thành một global store dùng chung.

Cả luồng vẫn cần cùng quy ước về URL, trạng thái đăng nhập và giao diện. Người dùng không nên phải biết nút mình vừa bấm thuộc team nào. Tự chủ của team có ích khi nó giúp giao sản phẩm tốt hơn, chứ không phải khi mỗi màn hình hoạt động theo một quy tắc khác nhau.

Khác gì với chia component và packageCopy Anchor Link

Hãy xét cùng một bộ lọc sản phẩm trong ba cách tổ chức:

Tách package rất có ích cho tái sử dụng và quản lý code. Nhưng publish package không đồng nghĩa với deploy tính năng tới người dùng. Nếu shell còn phải build lại để nhận package mới, chu kỳ phát hành của catalog vẫn phụ thuộc shell.

Tương tự, code splitting hay lazy() giúp trình duyệt tải code khi cần. Nếu các chunk vẫn sinh ra từ cùng một build và được deploy cùng nhau, đó chưa phải deploy độc lập.

Một modular frontend là một ứng dụng có các module và ranh giới nội bộ rõ ràng nhưng thường vẫn phát hành như một đơn vị. Nó không phải kiến trúc “kém trưởng thành”: khi team chưa cần các nhịp release riêng, giữ một đơn vị deploy thường làm tích hợp và debug dễ hơn.

Deploy độc lập thực sự có nghĩa gìCopy Anchor Link

Phép thử dễ hiểu nhất là: catalog sửa một chi tiết bên trong, giữ nguyên contract công khai; cart và shell có phải phát hành lại không? Nếu mọi lần sửa đều kéo theo release toàn bộ, mục tiêu deploy độc lập chưa đạt, dù bạn đã dùng công cụ nào.

“Độc lập” ở đây là giảm phối hợp bắt buộc cho các thay đổi tương thích. Nó không có nghĩa từng phần được thay đổi tùy ý mà không quan tâm sản phẩm chung.

Một lần release catalogCopy Anchor Link

Giả sử catalog thêm tùy chọn sắp xếp sản phẩm, không đổi route hay contract với shell. Hệ thống dùng runtime composition và một cấu hình để chọn artifact đang hoạt động. Luồng phát hành có thể như sau:

direction: down
catalog: Catalog {
  code: Sửa code
  build: Build / test
  deploy: Deploy artifact
  select: Chọn version mới
  code -> build -> deploy -> select
}
shell: "Shell: giữ artifact, đọc cấu\nhình tích hợp"
cart: "Cart: không đổi code, không\nbuild lại"
catalog.select -> shell: "Cập nhật selection"

Một cấu hình minh họa, không phải API của một framework cụ thể:

{
  "catalog": "/assets/catalog/1.5.0/entry.js",
  "cart": "/assets/cart/2.3.0/entry.js"
}

Khi catalog lên version 1.6.0, hệ thống chỉ đổi tham chiếu catalog sang artifact mới. Các số version ở đây là ví dụ; chúng không bắt buộc bằng nhau, vì catalog và cart có vòng đời khác nhau.

Cơ chế chọn version có thể nằm trong runtime config, manifest, import map hoặc cấu hình server. Điều quan trọng là không cần sửa source rồi build lại shell chỉ để thay version catalog. Việc publish một artifact và việc đưa người dùng sang artifact đó cũng có thể là hai bước riêng, phục vụ rollout có kiểm soát.

Nếu version mới lỗi, bạn có thể chọn lại artifact catalog trước đó mà không rollback cart, với điều kiện artifact cũ còn được giữ và API vẫn hỗ trợ nó. Người dùng đã mở trang có thể tiếp tục chạy code cũ cho đến khi reload hoặc điều hướng theo cơ chế tải của hệ thống. Vì vậy cache và khả năng nhiều version cùng tồn tại là phần của thiết kế release, không phải chi tiết để tính sau.

Độc lập không có nghĩa là không phụ thuộcCopy Anchor Link

Shell vẫn phải hiểu cách tải catalog. Catalog vẫn phải gọi API đúng. Cart vẫn phải hiểu những thông tin mà luồng thêm sản phẩm vào giỏ truyền sang. Các thỏa thuận đó được gọi là contract: giao diện công khai giữa các phần, thay vì chi tiết triển khai bên trong.

Ví dụ, nếu catalog đang truyền productId nhưng cart mới bắt buộc nhận sku, deploy riêng có thể làm hỏng luồng mua hàng. Cách xử lý không phải bỏ mọi contract để “tự chủ hơn”, mà là giữ tương thích trong giai đoạn chuyển đổi hoặc version hóa contract khi cần.

Mục tiêu hợp lý là phần lớn thay đổi nội bộ không cần release đồng bộ. Những thay đổi vượt qua ranh giới vẫn cần kế hoạch. Contract tests, kiểm thử tích hợp với version đang chạy và một số E2E cho luồng mua hàng giúp phát hiện lỗi trước khi rollout; deploy độc lập không cho phép bỏ kiểm thử toàn hệ thống.

Các phần frontend được ghép ở đâuCopy Anchor Link

Composition là bước đưa các phần riêng vào sản phẩm chung. Vị trí ghép ảnh hưởng trực tiếp đến việc phát hành:

Một số tài liệu dùng từ micro-frontend theo nghĩa rộng, bao gồm cả các module nghiệp vụ ghép lúc build. Trong lộ trình này, mình dùng khả năng phát hành độc lập làm tiêu chí chính để phân biệt với modular frontend. Build-time composition vẫn đáng học, nhưng cần nhìn rõ giới hạn của nó đối với mục tiêu đó.

Module Federation là một cơ chế chia sẻ và tải module giữa các ứng dụng; single-spa hỗ trợ điều phối vòng đời ứng dụng; iframe cung cấp một browsing context riêng; Web Components cung cấp giao diện custom element để tích hợp. Các công cụ này giải quyết những phần khác nhau của bài toán, và có thể kết hợp với nhau. Không công cụ nào tự quyết định ranh giới nghiệp vụ, ownership hay chiến lược release cho bạn.

Bài này chưa cần bạn chọn công cụ. Trước hết, hãy trả lời “phần nào cần phát hành độc lập, do ai chịu trách nhiệm?”; sau đó mới chọn cách ghép phù hợp.

Lợi ích và chi phí đi kèmCopy Anchor Link

Micro-frontend có thể giúp các team bớt chờ nhau, nhưng đổi lại hệ thống phải xử lý những điều trước đây được một bản build chung giải quyết hộ.

Đừng chỉ đo thành công bằng số lượng app đã tách. Nếu một tính năng vẫn cần sửa catalog, cart và shell cùng lúc, rồi ba team phải chờ nhau deploy, bạn đã thêm chi phí phân tán mà chưa giảm được phụ thuộc.

Hiệu năng cũng cần đo ở cấp sản phẩm. Hai app có bundle riêng có thể tải trùng framework; tải entry rồi mới phát hiện dependency có thể tạo thêm chuỗi request. Chia sẻ dependency có thể giảm tải trùng, nhưng lại thêm ràng buộc version. Không có lý do mặc định để kết luận micro-frontend sẽ nhanh hơn một app được tối ưu tốt.

Những điều micro-frontend không đảm bảoCopy Anchor Link

Có vài suy luận rất dễ mắc khi mới học mô hình này:

• Không bắt buộc dùng nhiều framework. Catalog và cart cùng dùng React vẫn có thể là micro-frontend. Khác framework là một khả năng phục vụ migration, không phải mục tiêu tự thân.
• Không bắt buộc backend là microservices. Các phần frontend có thể gọi chung một backend. Ranh giới backend và frontend cần hợp lý với nghiệp vụ, nhưng không nhất thiết ánh xạ một-một.
• Không đảm bảo cách ly lỗi. Nếu cùng chạy trong một JavaScript context, một remote có thể làm nghẽn main thread, sửa global hoặc gây xung đột CSS. Error boundary và fallback hữu ích cho một số lỗi, nhưng không giải quyết mọi kiểu lỗi.
• Không tạo security boundary chỉ nhờ tách bundle. Code bên thứ ba chạy cùng trang có thể có quyền truy cập rất rộng. Các cơ chế như iframe khác origin, sandbox và CSP cần được thiết kế theo threat model, không được suy ra từ tên “micro-frontend”.
• Không thay backend authorization. Shell có thể điều phối đăng nhập hoặc ẩn màn hình, nhưng backend vẫn phải kiểm tra quyền cho từng request.
• Không có nghĩa mỗi component đều nên deploy riêng. Button, Input hay typography thường hợp với design system dùng chung hơn là một remote độc lập.

Khi nào nên bắt đầu bằng mô hình đơn giản hơnCopy Anchor Link

Mặc định, mình sẽ bắt đầu bằng một frontend có module nghiệp vụ rõ ràng nếu chỉ có một team hoặc chưa có nhu cầu release riêng. Vì lúc đó, một build và một pipeline giúp bạn sửa, test và theo dõi lỗi với ít cơ chế hơn. Tách module tốt vẫn chuẩn bị cho việc tách đơn vị deploy sau này.

Micro-frontend đáng cân nhắc khi nhiều team thật sự bị chặn bởi chu kỳ release chung, có các domain tương đối tách biệt, hoặc cần migration một phần ứng dụng mà không thay toàn bộ. “Ứng dụng có nhiều component” hay “backend đã dùng microservices” không đủ để kết luận nên chọn nó.

Nếu mục đích chỉ là học, shop shell–catalog–cart là một phạm vi phù hợp để thử. Nhưng hãy giữ hai mục tiêu khác nhau: một demo giúp hiểu cơ chế tải remote; một kiến trúc production còn cần chứng minh lợi ích về phát hành, khả năng vận hành và trải nghiệm người dùng.

Tự kiểm tra cách hiểuCopy Anchor Link

Thử trả lời bốn tình huống trước khi đọc phần giải thích:

Với một hệ thống cụ thể, bạn có thể đi thêm một bước: vẽ ranh giới catalog và cart, ghi team sở hữu từng phần, contract giữa chúng và các bước cần làm để release riêng catalog. Nếu chưa chỉ ra được ai phải build hoặc deploy gì, bạn chưa có đủ thông tin để đánh giá khả năng độc lập.

Đọc tiếpCopy Anchor Link

Các trang dưới đây đi sâu vào quyết định áp dụng và thuật ngữ; nếu còn là trang khung, chúng cho biết phần tiếp theo của lộ trình.

Tài liệu tham khảoCopy Anchor Link

• Micro Frontends — Cam Jackson, trên martinfowler.com: định nghĩa kiến trúc, independent deployment và đánh đổi của các cách tích hợp.
• Micro Frontends — Michael Geers: tổ chức theo domain, team ownership và các nguyên tắc tích hợp frontend.