Micro Frontends là gì? Từ kiến trúc đến triển khai thực tế

Khi website ngày càng mở rộng về tính năng, duy trì một hệ thống frontend nguyên khối có thể khiến quá trình phát triển, kiểm thử và triển khai trở nên phức tạp. Micro Frontends ra đời như một hướng tiếp cận giúp chia nhỏ frontend thành các phần độc lập, cho phép nhiều nhóm phát triển cùng làm việc trên một website mà vẫn duy trì tính linh hoạt. Kiến trúc này đặc biệt phù hợp với các dự án có quy mô lớn, nhiều tính năng hoặc cần phát hành thay đổi liên tục. Vậy Micro Frontends là gì, hoạt động như thế nào và có những nguyên tắc nào cần lưu ý khi triển khai website? Cùng tìm hiểu trong bài viết sau đây!

 

 

Micro Frontends là gì?

Micro Frontends là kiến trúc phát triển website trong đó giao diện frontend được chia thành nhiều phần nhỏ, độc lập tương đối với nhau và có thể do các nhóm khác nhau phụ trách. Mỗi micro frontend thường đảm nhiệm một nghiệp vụ hoặc khu vực cụ thể, chẳng hạn trang sản phẩm, giỏ hàng, tài khoản người dùng hoặc hệ thống quản trị. Các phần này sau đó được tích hợp để tạo thành một website hoàn chỉnh nhưng vẫn có thể phát triển, kiểm thử và triển khai tương đối độc lập. Cách tiếp cận này mở rộng tư duy của Microservices từ backend sang frontend, thay vì xây dựng toàn bộ giao diện như một hệ thống nguyên khối.

Ví dụ, một website thương mại điện tử có thể tách frontend thành 4 micro frontend gồm Product, Cart, Checkout và Account. Mỗi phần có thể được quản lý bởi một team riêng, sử dụng quy trình phát triển phù hợp với phạm vi nghiệp vụ của mình. Khi cần cập nhật giao diện thanh toán, team Checkout có thể thay đổi và triển khai khu vực này mà không nhất thiết phải build lại toàn bộ website. Tuy nhiên, các micro frontend vẫn cần tuân thủ những quy ước chung về giao tiếp, thiết kế giao diện, bảo mật và trải nghiệm người dùng để tránh tạo ra một hệ thống rời rạc.

 

 

Nguyên nhân ra đời của Micro Frontend architecture

Sự phát triển của các website quy mô lớn kéo theo số lượng tính năng, codebase và đội ngũ tham gia ngày càng tăng. Khi toàn bộ frontend được xây dựng trong một kiến trúc nguyên khối, việc phát triển, kiểm thử và triển khai có thể trở nên phức tạp hơn. Micro Frontend architecture ra đời nhằm giải quyết những hạn chế này bằng cách chia frontend thành các phần độc lập theo từng nghiệp vụ hoặc chức năng. Một số nguyên nhân chính thúc đẩy kiến trúc này gồm:

- Codebase ngày càng lớn: Khi website tích hợp nhiều tính năng, số lượng component, dependency và logic nghiệp vụ tăng nhanh, khiến việc quản lý một frontend nguyên khối trở nên khó khăn.

- Nhiều team cùng phát triển: Các team có thể cùng làm việc trên một website nhưng phụ trách những nghiệp vụ khác nhau. Tách micro frontend giúp mỗi team chủ động phát triển và triển khai phần mình phụ trách.

- Giảm phụ thuộc khi triển khai: Với frontend nguyên khối, một thay đổi nhỏ có thể yêu cầu build và deploy toàn bộ hệ thống. Micro Frontends cho phép cập nhật từng khu vực mà không nhất thiết tác động đến toàn bộ website.

- Nhu cầu sử dụng nhiều công nghệ: Doanh nghiệp có thể cần duy trì hệ thống cũ bằng Angular trong khi phát triển module mới bằng React. Vì vậy, các mô hình như micro frontend Angular và ReactJS micro frontend giúp từng phần lựa chọn công nghệ phù hợp hơn.

- Tăng tốc độ phát triển website: Khi phạm vi trách nhiệm được chia rõ ràng, các team có thể phát triển, kiểm thử và phát hành tính năng song song, rút ngắn thời gian đưa thay đổi lên môi trường thực tế.

- Hỗ trợ hiện đại hóa hệ thống: Micro Frontends cho phép doanh nghiệp từng bước thay thế các module frontend cũ thay vì phải xây dựng lại toàn bộ website trong một lần. Đây là hướng tiếp cận phù hợp với những hệ thống đang cần chuyển đổi công nghệ nhưng vẫn phải duy trì hoạt động liên tục.

 

 

4 triết lý nền tảng của Micro Frontends

Micro Frontends không chỉ tập trung vào việc chia nhỏ giao diện thành nhiều module mà còn đặt ra các nguyên tắc giúp những phần frontend độc lập có thể phối hợp trong cùng một website. Bốn triết lý nền tảng thường được nhắc đến gồm technology agnostic, isolate team code, establish team boundaries và resilient web design. Mỗi triết lý giải quyết một khía cạnh khác nhau, từ lựa chọn công nghệ, tổ chức code đến cách phân chia trách nhiệm giữa các team. Khi triển khai thực tế, doanh nghiệp nên xem đây là những nguyên tắc định hướng thay vì áp dụng máy móc cho mọi dự án.

1. Technology agnostic

Technology agnostic là triết lý cho phép mỗi micro frontend lựa chọn công nghệ phù hợp với yêu cầu của từng module mà không bị phụ thuộc hoàn toàn vào framework được sử dụng trên toàn website. Chẳng hạn, doanh nghiệp có thể triển khai micro frontend Angular cho một module cần tận dụng hệ sinh thái Angular, trong khi sử dụng ReactJS micro frontend để phát triển một tính năng mới bằng React. Các module vẫn có thể được tích hợp vào cùng một website thông qua những cơ chế giao tiếp và tiêu chuẩn chung đã được thống nhất. Nhờ đó, đội ngũ phát triển có thể linh hoạt lựa chọn công nghệ mà không phải xây dựng lại toàn bộ frontend chỉ vì muốn thay đổi framework.

Tuy nhiên, technology agnostic không đồng nghĩa với sử dụng càng nhiều framework càng tốt. Khi triển khai website thực tế, doanh nghiệp cần cân nhắc số lượng công nghệ, khả năng tích hợp, hiệu suất và năng lực của đội ngũ phát triển. Duy trì quá nhiều framework có thể làm tăng kích thước bundle, chi phí vận hành và độ phức tạp khi bảo trì. Vì vậy, mỗi công nghệ nên được lựa chọn dựa trên nhu cầu cụ thể của micro frontend và khả năng duy trì lâu dài của website.

2. Isolate team code

Isolate team code là nguyên tắc yêu cầu code của mỗi team được cô lập trong phạm vi micro frontend mà họ phụ trách, hạn chế tối đa sự phụ thuộc trực tiếp vào mã nguồn của team khác. Chẳng hạn, team phát triển module Product có thể tự quản lý component, state và dependency của mình mà không cần truy cập vào code nội bộ của module Checkout. Các team chỉ nên giao tiếp thông qua những interface, API hoặc event đã được thống nhất từ trước. Cách tổ chức này giúp từng team có thể thay đổi hoặc nâng cấp phần frontend của mình mà ít ảnh hưởng đến các module còn lại. 

Khi phát triển website, cô lập code cũng giúp giảm xung đột trong quá trình làm việc và kiểm soát phạm vi thay đổi tốt hơn. Một team có thể triển khai phiên bản mới cho micro frontend của mình mà không cần chờ toàn bộ frontend hoàn tất. Tuy nhiên, các quy ước chung về coding, bảo mật, giao tiếp giữa module và trải nghiệm người dùng vẫn cần được thống nhất. Nhờ đó, website vừa duy trì được tính độc lập giữa các team vừa đảm bảo các micro frontend hoạt động như một hệ thống thống nhất.

3. Establish team boundaries

Establish team boundaries là nguyên tắc xác định ranh giới trách nhiệm rõ ràng giữa các team dựa trên từng nghiệp vụ hoặc khu vực chức năng của website. Thay vì nhiều team cùng chỉnh sửa một codebase, mỗi team sẽ chịu trách nhiệm xuyên suốt cho một micro frontend cụ thể, chẳng hạn Product, Cart, Checkout hoặc Account. Phạm vi này có thể bao gồm phát triển giao diện, xử lý logic, kiểm thử và triển khai module tương ứng. Cách phân chia giúp mỗi team chủ động hơn trong quá trình phát triển và giảm sự chồng chéo về trách nhiệm.

Khi xây dựng website theo Micro Frontends, ranh giới giữa các team cần được xác định ngay từ giai đoạn thiết kế kiến trúc. Các team cũng cần thống nhất rõ cách giao tiếp, dữ liệu được chia sẻ và những phần nào không được can thiệp vào nhau. Nếu nhiều team cùng phụ trách một nghiệp vụ hoặc thường xuyên phải chỉnh sửa code của nhau, tính độc lập của Micro Frontends sẽ bị suy giảm. Ngược lại, ranh giới rõ ràng giúp quá trình phát triển, kiểm thử và triển khai từng module diễn ra nhanh chóng, dễ kiểm soát hơn.

4. Resilient web design

Resilient web design là triết lý hướng đến khả năng website vẫn hoạt động ổn định khi một micro frontend gặp lỗi, tải chậm hoặc tạm thời không khả dụng. Thay vì để sự cố của một module làm ảnh hưởng đến toàn bộ giao diện, hệ thống cần có cơ chế fallback, loading state và error handling phù hợp. Ví dụ, nếu module đề xuất sản phẩm không thể tải, người dùng vẫn có thể xem sản phẩm chính, thêm vào giỏ hàng và thực hiện các thao tác quan trọng khác. Điều này giúp giới hạn phạm vi ảnh hưởng của lỗi và duy trì trải nghiệm sử dụng trên website.

Khi triển khai Micro Frontends, mỗi module nên được thiết kế với khả năng hoạt động độc lập ở mức nhất định và có phương án xử lý khi dependency bên ngoài gặp sự cố. Các chức năng quan trọng cần được ưu tiên tải trước, trong khi những thành phần phụ có thể sử dụng nội dung thay thế hoặc được tải sau. Cách tiếp cận này đặc biệt hữu ích với website thương mại điện tử, booking hoặc các nền tảng có nhiều chức năng tương tác đồng thời. Nhờ đó, một lỗi cục bộ không dễ dàng trở thành sự cố ảnh hưởng đến toàn bộ website.

 

 

Cách thức hoạt động của Micro Frontend architecture

Micro Frontend architecture vận hành bằng cách chia frontend của website thành nhiều cấu trúc nhỏ, mỗi micro frontend phụ trách một nhóm chức năng hoặc nghiệp vụ riêng. Các micro frontend có thể được phát triển, kiểm thử và triển khai độc lập nhưng vẫn cần phối hợp để tạo thành một giao diện thống nhất.

1. Application Shell (Host App) -Tầng điều phối trung tâm

Application Shell (Host App) là lớp nền đóng vai trò như bộ khung chính của website, chịu trách nhiệm kết nối và điều phối các micro frontend. Thay vì trực tiếp xử lý toàn bộ nghiệp vụ, Host App thường quản lý những thành phần dùng chung như routing, navigation, layout, authentication và cơ chế tải các module. Khi người dùng truy cập một URL cụ thể, Application Shell xác định micro frontend tương ứng và đưa module đó vào vị trí cần thiết trên giao diện.

Ví dụ với website thương mại điện tử, Host App có thể quản lý header, menu điều hướng và hệ thống định tuyến, sau đó tải Product Micro Frontend khi người dùng mở trang sản phẩm hoặc Cart Micro Frontend khi truy cập giỏ hàng. Cách tổ chức này giúp các module nghiệp vụ được tách biệt nhưng vẫn nằm trong cùng một trải nghiệm website. Host App cũng có thể kiểm soát trạng thái tải, xử lý lỗi và cung cấp các dịch vụ dùng chung cho micro frontend. Nhờ đó, Application Shell trở thành tầng kết nối trung tâm nhưng không cần can thiệp sâu vào logic bên trong từng module.

2. Phân rã thành các remote apps (micro-apps) độc lập

Sau khi Application Shell đảm nhiệm vai trò điều phối, frontend được phân rã thành nhiều remote apps (micro-apps), mỗi app phụ trách một nhóm chức năng hoặc nghiệp vụ cụ thể. Chẳng hạn, website thương mại điện tử có thể tách thành Product App, Cart App, Checkout App và Account App. Mỗi micro-app có thể sở hữu codebase, dependency và quy trình triển khai riêng, đồng thời được một team chịu trách nhiệm xuyên suốt. Cách phân rã này giúp các phần của website có thể phát triển và cập nhật tương đối độc lập mà không cần tác động đến toàn bộ hệ thống.

Các remote apps sau đó được Host App tải và tích hợp vào giao diện khi người dùng truy cập chức năng tương ứng. Tùy kiến trúc, micro-app có thể được tích hợp thông qua Module Federation, Web Components, iframe hoặc các cơ chế JavaScript khác. Mặc dù hoạt động độc lập, các app vẫn cần tuân thủ contract chung về API, routing, authentication và giao tiếp dữ liệu. Nhờ vậy, website vừa duy trì được tính module hóa vừa đảm bảo các chức năng liên kết với nhau trong một trải nghiệm thống nhất.

 

 

3. Cơ chế tải động và quản lý vòng đời (dynamic loading & lifecycle)

Dynamic loading cho phép website chỉ tải micro-app khi người dùng thực sự truy cập đến chức năng tương ứng, thay vì tải toàn bộ frontend ngay từ đầu. Ví dụ, khi người dùng mở trang thanh toán, Application Shell có thể tải Checkout App và đưa module này vào giao diện tại thời điểm cần thiết. Cách tiếp cận này giúp giảm lượng JavaScript phải tải ban đầu, cải thiện thời gian hiển thị và hạn chế tài nguyên tiêu thụ không cần thiết. Với website có nhiều micro-app, cơ chế tải động cũng giúp phân bổ tài nguyên theo từng chức năng thay vì xử lý tất cả module cùng lúc.

Bên cạnh tải module, hệ thống cần quản lý lifecycle để kiểm soát trạng thái của từng micro-app trong suốt quá trình hoạt động. Một vòng đời cơ bản có thể gồm các bước load → mount → update → unmount, tương ứng với tải module, đưa vào giao diện, cập nhật và loại bỏ khi không còn cần thiết. Khi người dùng chuyển từ trang Product sang Cart, Product App có thể được unmount trong khi Cart App được load và mount. Quản lý vòng đời rõ ràng giúp giải phóng tài nguyên, hạn chế xung đột trạng thái và đảm bảo các micro-app hoạt động ổn định trong quá trình sử dụng website.

4. Cơ chế tối ưu phụ thuộc dùng chung (shared dependencies)

Shared dependencies là cơ chế cho phép các micro-app dùng chung những thư viện hoặc tài nguyên phổ biến thay vì mỗi module tự tải một bản riêng. Ví dụ, nếu Product App, Cart App và Checkout App đều sử dụng React, việc tải React nhiều lần có thể làm tăng kích thước JavaScript và thời gian tải website. Với cơ chế shared dependencies, Host App có thể cung cấp một phiên bản thư viện dùng chung để các remote apps tái sử dụng khi được tải vào hệ thống. Điều này giúp giảm mã JavaScript trùng lặp và tối ưu tài nguyên trong quá trình phát triển website.

Khi triển khai, đội ngũ cần xác định rõ những dependency nào được phép chia sẻ và kiểm soát version giữa các micro-app. Các thư viện phổ biến như React, React DOM hoặc một số UI components có thể được cấu hình dùng chung, trong khi những dependency đặc thù của từng module vẫn được đóng gói riêng. Nếu các module sử dụng những phiên bản không tương thích, việc chia sẻ dependency có thể gây lỗi runtime hoặc hành vi không ổn định. Vì vậy, cơ chế này cần đi kèm quy ước quản lý phiên bản và kiểm thử để cân bằng giữa hiệu suất tải trang và khả năng bảo trì của website.

5. Luồng giao tiếp & chia sẻ dữ liệu (inter-app communication)

Inter-app communication là cơ chế giúp các micro-app trao đổi dữ liệu và phản hồi với nhau trong khi vẫn duy trì sự độc lập về code. Ví dụ, khi người dùng thêm sản phẩm vào giỏ hàng, Product App có thể gửi một event để Cart App cập nhật số lượng sản phẩm trên giao diện. Một số phương thức phổ biến gồm Custom Events, shared state, API, message passing hoặc các thư viện quản lý trạng thái dùng chung. Lựa chọn cơ chế phù hợp giúp các micro-app phối hợp với nhau mà không cần truy cập trực tiếp vào code nội bộ của module khác.

Khi xây dựng website, dữ liệu được chia sẻ cần có phạm vi và quy tắc rõ ràng để hạn chế sự phụ thuộc giữa các micro-app. Những thông tin dùng chung như trạng thái đăng nhập, mã người dùng hoặc giỏ hàng có thể được truyền thông qua một contract thống nhất thay vì để từng app tự quản lý theo cách khác nhau. Với dữ liệu nghiệp vụ quan trọng, API hoặc các event có cấu trúc rõ ràng thường giúp kiểm soát luồng dữ liệu tốt hơn. Nhờ đó, các micro-app vẫn có thể giao tiếp linh hoạt nhưng không làm mất đi tính độc lập vốn là nền tảng của Micro Frontend architecture.

Các mô hình kiến trúc & phương pháp triển khai Micro Frontends

Trong phát triển web, Micro Frontends có thể được triển khai theo nhiều cách tùy thuộc vào yêu cầu về khả năng độc lập, hiệu suất, công nghệ và quy trình release của từng dự án. Các phương pháp phổ biến gồm run-time integration, server-side integration và build-time integration, route-based routing. Lựa chọn mô hình thích hợp giúp website dễ mở rộng, đồng thời kiểm soát tốt khả năng điều hướng, hiệu suất và bảo trì frontend.

1. Triển khai ở thời điểm Run-time (run-time integration)

Run-time integration là phương pháp tích hợp trong đó các micro frontend được tải và kết nối khi hệ thống đang chạy thay vì phải hợp nhất toàn bộ mã nguồn trong một bước build. Host App chịu trách nhiệm xác định micro-app cần sử dụng, tải tài nguyên và hiển thị module tương ứng theo route hoặc hành động của người dùng. Nhờ đó, mỗi micro-app có thể được phát triển, build và deploy tương đối độc lập với các phần còn lại của frontend. Một số kỹ thuật thường được sử dụng gồm:

- Module Federation (Webpack 5/ Vite): Cho phép một website cung cấp các module để website khác tải và sử dụng tại runtime. Host App có thể tải các remote module khi cần, đồng thời hỗ trợ chia sẻ những dependency như React hoặc React DOM để hạn chế việc tải trùng lặp. Đây là một trong những phương án phổ biến khi xây dựng Micro Frontends ReactJS, Angular hoặc Vue.

- Web Components: Sử dụng các custom elements theo chuẩn Web Components để đóng gói một phần giao diện thành component có thể được sử dụng bên ngoài framework ban đầu. Ví dụ, một micro frontend được xây dựng bằng Angular có thể được đóng gói thành custom element và tích hợp vào React. Phương pháp này phù hợp khi cần tạo các thành phần frontend có khả năng tái sử dụng và giảm sự phụ thuộc giữa các framework.

- JavaScript Integration (Single-SPA / SystemJS): Sử dụng JavaScript để tải, khởi tạo và quản lý nhiều micro-app trong cùng một frontend. Single-SPA cung cấp cơ chế điều phối vòng đời của các website và ứng dụng, chẳng hạn bootstrap, mount và unmount, dựa trên route hoặc trạng thái của ứng dụng. SystemJS có thể được sử dụng để hỗ trợ tải module động trong một số kiến trúc. Cách tiếp cận này phù hợp với website cần tích hợp nhiều dự án frontend hoặc framework khác nhau.

- iframe: Mỗi micro frontend được triển khai như một hệ thống độc lập và được nhúng vào trang thông qua iframe. Phương pháp này tạo ra mức độ cô lập cao giữa hệ thống chính và micro-app, đặc biệt về DOM, CSS và JavaScript runtime. Tuy nhiên, iframe có hạn chế về giao tiếp giữa các hệ thống, đồng bộ giao diện, responsive và trải nghiệm người dùng. Vì vậy, trong phát triển web hiện đại, iframe thường phù hợp với các trường hợp sandbox hoặc tích hợp hệ thống bên ngoài hơn là lựa chọn mặc định cho Micro Frontends.

2. Triển khai ở phía server (server-side integration / composition)

Server-side integration là phương pháp trong đó các micro frontend được kết hợp thành một trang hoàn chỉnh ở phía server trước khi gửi HTML về trình duyệt. Thay vì để trình duyệt tự tải và ghép tất cả micro-app, server hoặc một lớp composition sẽ xác định các fragment cần thiết rồi tổng hợp chúng thành response cuối cùng. Mỗi team vẫn có thể phát triển và triển khai micro frontend tương đối độc lập, trong khi người dùng nhận được HTML đã được cấu trúc sẵn. Cách tiếp cận này phù hợp với website cần ưu tiên SEO, thời gian hiển thị nội dung ban đầu và khả năng kiểm soát quá trình render.

Một số kiến trúc và kỹ thuật thường được sử dụng gồm:

- Edge Side Includes (ESI): Cho phép server hoặc CDN ghép nhiều HTML fragment thành một response hoàn chỉnh trước khi trả về trình duyệt. Các fragment có thể được cache riêng, giúp tối ưu hiệu suất cho những website có nhiều nội dung hoặc module độc lập.

- Server-Side Rendering (SSR): Mỗi micro frontend có thể được render thành HTML ở phía server, sau đó các phần giao diện được composition thành trang hoàn chỉnh. SSR giúp nội dung quan trọng xuất hiện sớm trên trình duyệt và hỗ trợ tốt cho SEO, đặc biệt với các website có nhiều trang nội dung.

- Server-Side Composition: Một lớp composition chịu trách nhiệm lấy và kết hợp các fragment từ nhiều micro-app thành một response HTML duy nhất. Cách này cho phép các team triển khai từng micro frontend độc lập nhưng vẫn tạo ra trải nghiệm frontend thống nhất cho người dùng.

- Edge Composition: Việc composition được thực hiện tại lớp edge gần người dùng thay vì chỉ ở origin server. Cách này có thể giảm độ trễ khi phân phối các fragment và tận dụng khả năng cache của CDN, phù hợp với website có lượng truy cập lớn hoặc người dùng phân bố ở nhiều khu vực.

 

3. Triển khai ở thời điểm build (build-time integration)

Build-time integration là phương pháp trong đó các micro frontend được tích hợp với nhau ngay trong quá trình build để tạo thành một dự án frontend hoàn chỉnh trước khi triển khai. Thay vì Host App tải remote module tại runtime, các package hoặc module của micro frontend được đóng gói vào app chính thông qua dependency hoặc package registry. Cách này giúp giảm độ phức tạp khi chạy dự án và phù hợp với những website không yêu cầu các micro-app phải release hoàn toàn độc lập. Tuy nhiên, khi một micro frontend thay đổi, website chính thường cần build và deploy lại để nhận phiên bản mới.

Một số cách triển khai build-time integration phổ biến gồm:

- Package-based integration: Mỗi team đóng gói micro frontend thành một npm package hoặc package nội bộ, sau đó frontend chính cài đặt và sử dụng package này như một dependency. Cách này phù hợp khi các module cần được kiểm soát version rõ ràng và có quy trình release tương đối ổn định.

- Shared component library: Các team xây dựng và duy trì thư viện component dùng chung, chẳng hạn button, form, modal hoặc layout. Host App tích hợp các component thông qua package trong quá trình build, giúp giao diện giữa các khu vực của website nhất quán hơn. Tuy nhiên, cách này phù hợp hơn với việc chia sẻ UI components và không mang lại mức độ độc lập hoàn toàn như một micro frontend runtime.

- Monorepo-based integration: Nhiều micro-app được quản lý trong cùng một monorepo, nhưng mỗi micro-app vẫn có phạm vi code và dependency tương đối riêng. Các công cụ như Nx hoặc Turborepo có thể hỗ trợ quản lý workspace, dependency graph và quy trình build. Mô hình này giúp các team chia sẻ code thuận tiện nhưng vẫn tổ chức frontend thành những package riêng.

4. Chiến lược điều hướng & routing (route-based routing)

Route-based routing là chiến lược phân chia frontend dựa trên URL hoặc nhóm chức năng, trong đó mỗi micro frontend chịu trách nhiệm cho một hoặc nhiều route cụ thể. Application Shell thường đóng vai trò điều phối route cấp cao và xác định micro-app nào sẽ được tải khi người dùng truy cập một URL. Ví dụ, website thương mại điện tử có thể phân chia /products/* cho Product App, /cart/* cho Cart App và /checkout/* cho Checkout App. Cách tổ chức này tạo ranh giới rõ ràng giữa các micro-app và giúp từng team dễ quản lý phạm vi phát triển.

Khi triển khai, cần thống nhất route ownership, quy tắc URL và cách xử lý điều hướng giữa các micro-app. Mỗi micro-app có thể quản lý các route con bên trong phạm vi được giao, trong khi Host App kiểm soát những route cấp cao. Chẳng hạn, Product App có thể quản lý /products, /products/:id và /products/:id/reviews mà không cần can thiệp vào routing của Cart App. Cách tiếp cận này giúp giảm xung đột routing, hỗ trợ triển khai độc lập và làm rõ trách nhiệm của từng team trong quá trình phát triển website.

 

 

Lợi ích và thách thức khi áp dụng Micro Frontend trong phát triển web

Micro Frontends mang lại nhiều thay đổi trong cách tổ chức và phát triển frontend, đặc biệt với website có quy mô lớn, nhiều tính năng và nhiều team cùng tham gia. Chia frontend thành các micro-app giúp doanh nghiệp tăng tính độc lập khi phát triển, kiểm thử và triển khai từng khu vực chức năng. Tuy nhiên, kiến trúc này cũng tạo thêm nhiều lớp quản lý về routing, giao tiếp dữ liệu, dependency và vận hành. Vì vậy, hiệu quả thực tế phụ thuộc vào lựa chọn phạm vi áp dụng và thiết kế kiến trúc phù hợp với website.

1. Những lợi ích thiết thực

Micro Frontends không chỉ giúp chia nhỏ codebase mà còn tác động trực tiếp đến quy trình phát triển và vận hành website. Khi ranh giới giữa các micro-app được xác định rõ, mỗi team có thể chủ động hơn trong phạm vi phụ trách. Những lợi ích đáng chú ý gồm:

- Phát triển và triển khai độc lập: Mỗi micro-app có thể được một team phát triển, kiểm thử và deploy riêng, giúp giảm sự phụ thuộc vào chu kỳ release của toàn bộ frontend.

- Dễ mở rộng website: Khi cần bổ sung một nghiệp vụ mới, doanh nghiệp có thể tạo thêm micro-app tương ứng thay vì mở rộng một codebase frontend nguyên khối. Cách này đặc biệt hữu ích với web có số lượng tính năng tăng liên tục.

- Linh hoạt công nghệ: Các micro-app có thể sử dụng những framework hoặc công nghệ khác nhau khi kiến trúc tích hợp cho phép. Điều này hỗ trợ doanh nghiệp hiện đại hóa từng phần mà không nhất thiết phải thay thế toàn bộ frontend cùng lúc.

- Giảm phạm vi ảnh hưởng khi thay đổi: Một team có thể cập nhật hoặc refactor micro-app của mình mà ít tác động trực tiếp đến các module khác. Điều này giúp kiểm soát rủi ro tốt hơn khi phát triển những website lớn.

- Tổ chức team rõ ràng: Mỗi team có thể sở hữu một domain hoặc nhóm chức năng cụ thể như Product, Cart, Checkout hay Account. Ranh giới trách nhiệm rõ ràng giúp giảm xung đột code và hỗ trợ quy trình phát triển song song.

- Hỗ trợ hiện đại hóa hệ thống: Doanh nghiệp có thể từng bước tách các phần frontend từ hệ thống monolithic hiện tại thành micro-app, thay vì phải viết lại toàn bộ website trong một lần.

2. Thách thức & cái giá phải trả 

Bên cạnh những lợi ích trên, Micro Frontends cũng làm tăng độ phức tạp của kiến trúc frontend. Khi một website được chia thành nhiều micro-app, những vấn đề trước đây được xử lý bên trong có thể trở thành bài toán tích hợp giữa nhiều hệ thống. Vì vậy, doanh nghiệp cần cân nhắc chi phí kỹ thuật và vận hành trước khi lựa chọn kiến trúc này.

- Tăng độ phức tạp kiến trúc: Hệ thống phải quản lý thêm Host App, remote apps, routing, lifecycle, giao tiếp giữa module và cơ chế xử lý lỗi. Số lượng micro-app càng lớn thì việc theo dõi toàn bộ kiến trúc càng khó.

- Khó đảm bảo trải nghiệm thống nhất: Mỗi team có thể phát triển UI theo cách riêng, dẫn đến khác biệt về component, typography, spacing hoặc hành vi tương tác. Website cần có design system và các quy chuẩn frontend chung để hạn chế tình trạng này.

- Giao tiếp và chia sẻ trạng thái khó hơn: Những dữ liệu như authentication, user state hoặc shopping cart có thể cần được chia sẻ giữa nhiều micro-app. Nếu thiết kế communication contract không tốt, các module sẽ dần phụ thuộc lẫn nhau và làm mất lợi thế của kiến trúc.

- Tăng chi phí kiểm thử và giám sát: Một thay đổi ở micro-app có thể ảnh hưởng đến cách các module khác tương tác với nó. Do đó, hệ thống cần chú trọng integration testing, monitoring, logging và theo dõi lỗi ở cả cấp micro-app lẫn toàn bộ website.

- Không phải website nào cũng cần Micro Frontends: Với website nhỏ, ít tính năng và chỉ có một team frontend, chia thành nhiều micro-app có thể tạo thêm overhead nhưng không mang lại lợi ích tương xứng. Trong trường hợp này, modular monolith thường đơn giản và dễ bảo trì hơn.

 

 

So sánh sự khác biệt giữa Monolithic Frontend và Micro Frontends

Monolithic Frontend và Micro Frontends khác nhau chủ yếu ở cách tổ chức codebase, phân chia trách nhiệm và triển khai các tính năng trên website. Với Monolithic Frontend, toàn bộ giao diện thường được phát triển và quản lý trong một hệ thống frontend thống nhất. Ngược lại, Micro Frontends chia frontend thành nhiều micro-app theo domain hoặc chức năng, cho phép các phần được phát triển và triển khai tương đối độc lập. Bảng dưới đây giúp làm rõ sự khác biệt giữa hai kiến trúc trong quá trình phát triển web.
 

 

Trường hợp nên sử dụng Micro Frontends cho hệ thống web

Micro Frontends phù hợp nhất với những hệ thống web có quy mô lớn, nhiều domain nghiệp vụ và được phát triển bởi nhiều team frontend. Thay vì xây dựng toàn bộ giao diện trong một codebase, doanh nghiệp có thể chia hệ thống thành các micro-app dựa trên từng chức năng và phân quyền sở hữu cho các team tương ứng. Cách triển khai này giúp các nhóm làm việc song song, giảm phụ thuộc và chủ động hơn trong quá trình release. Dưới đây là những trường hợp nên sử dụng Micro Frontends trong phát triển hệ thống web.

1. Dự án quy mô enterprise với đội ngũ phát triển đông đảo

Với hệ thống enterprise có hàng chục hoặc hàng trăm developer cùng tham gia, một frontend monolithic có thể trở thành điểm nghẽn khi nhiều team cùng chỉnh sửa codebase, dependency và quy trình release. Micro Frontends cho phép phân chia frontend theo từng domain nghiệp vụ, chẳng hạn Product, Order, Payment, Account hoặc Admin, sau đó giao quyền sở hữu từng micro-app cho team chuyên trách.Cách tổ chức này đặc biệt phù hợp khi doanh nghiệp có nhiều team frontend cần phát triển các khu vực khác nhau mà vẫn muốn duy trì phạm vi trách nhiệm rõ ràng.

2. Chu kỳ ra mắt tính năng bị nghẽn do luồng CI/CD quá tải

Khi website có quá nhiều tính năng được cập nhật cùng lúc, quy trình thay đổi lên website có thể trở nên chậm và mất nhiều thời gian. Với frontend monolithic, một chỉnh sửa nhỏ cũng có thể khiến toàn bộ hệ thống phải kiểm tra và triển khai lại. Khi đó, những tính năng đã hoàn thành có thể phải chờ các phần khác, đặc biệt với những website có tần suất cập nhật cao. Micro Frontends có thể giải quyết vấn đề này bằng cách chia frontend thành các phần nhỏ để từng phần có thể được kiểm tra và cập nhật độc lập.

Ví dụ, website bán hàng có thể chia thành các phần Sản phẩm, Giỏ hàng và Thanh toán. Khi team phụ trách Sản phẩm hoàn thành một tính năng mới, họ có thể kiểm tra và cập nhật riêng phần này mà không cần chờ team Giỏ hàng hoặc Thanh toán. Nhờ đó, tính năng mới có thể được đưa lên website nhanh hơn và giảm tình trạng chờ đợi giữa các nhóm phát triển. Cách này đặc biệt phù hợp với những website thường xuyên bổ sung, thay đổi hoặc cập nhật tính năng mới.

3. Hệ thống legacy cần nâng cấp từng phần (gradual modernization)

Với những website legacy đã được xây dựng từ lâu, thay thế toàn bộ frontend cùng một lúc thường tốn nhiều thời gian, chi phí và có thể ảnh hưởng đến hoạt động đang diễn ra. Micro Frontends cho phép doanh nghiệp chia hệ thống cũ thành từng khu vực chức năng và lần lượt thay thế từng phần bằng công nghệ mới. Trong quá trình này, những phần chưa được nâng cấp vẫn có thể tiếp tục hoạt động như trước. Đây là cách tiếp cận gradual modernization, giúp doanh nghiệp hiện đại hóa website theo từng giai đoạn thay vì phải xây dựng lại từ đầu.

Ví dụ, một website đang sử dụng frontend cũ có thể giữ nguyên trang quản trị và hệ thống tài khoản, đồng thời xây dựng lại trang sản phẩm bằng React hoặc Angular dưới dạng một micro-app mới. Sau khi phần này hoạt động ổn định, doanh nghiệp có thể tiếp tục thay thế giỏ hàng, thanh toán hoặc các khu vực khác. Nhờ đó, quá trình chuyển đổi diễn ra từng bước, dễ kiểm soát và giảm rủi ro ảnh hưởng đến website đang vận hành.

4. Các luồng nghiệp vụ mang tính độc lập cao (bounded contexts)

Bounded contexts là những khu vực nghiệp vụ có chức năng, dữ liệu và quy tắc xử lý tương đối độc lập với nhau. Khi website có nhiều luồng như Sản phẩm, Đơn hàng, Thanh toán, Tài khoản và mỗi luồng có cách vận hành riêng, Micro Frontends có thể được sử dụng để tách chúng thành các micro-app tương ứng. Mỗi team có thể tập trung phát triển một luồng nghiệp vụ mà không cần can thiệp sâu vào code của các khu vực khác.

Cách phân chia này giúp ranh giới giữa các phần của website rõ ràng hơn và dễ quản lý khi hệ thống mở rộng. Ngoài ra, các micro-app vẫn có thể trao đổi những dữ liệu cần thiết thông qua API hoặc các cơ chế giao tiếp đã thống nhất. Micro Frontends vì vậy đặc biệt phù hợp khi website có nhiều luồng nghiệp vụ rõ ràng và ít phụ thuộc trực tiếp vào nhau. 
 

 

Khi nào không nên sử dụng Micro Frontend architecture? 

Micro Frontends không phải lựa chọn phù hợp cho mọi hệ thống web. Nếu dự án có quy mô nhỏ, hạ tầng chưa sẵn sàng hoặc yêu cầu hiệu suất quá cao, kiến trúc này có thể tạo thêm nhiều phức tạp không cần thiết. Dưới đây là những trường hợp nên cân nhắc tránh sử dụng Micro Frontends.

 - Dự án startup, MVP hoặc hệ thống web quy mô nhỏ đến trung bình: Với startup, MVP hoặc website chỉ có một vài chức năng, chia frontend thành nhiều micro-app thường không cần thiết. Một frontend đơn giản có thể giúp đội ngũ phát triển nhanh hơn vì code dễ quản lý, ít cấu hình và không phải xử lý giao tiếp giữa nhiều hệ thống. Nếu ngay từ đầu đã sử dụng Micro Frontends, team có thể mất thêm thời gian thiết lập kiến trúc thay vì tập trung hoàn thiện sản phẩm. Trong trường hợp này, modular monolith thường là lựa chọn phù hợp hơn và vẫn có thể mở rộng khi website phát triển

- Hạ tầng DevOps & tự động hóa chưa đủ chín: Micro Frontends thường đi kèm nhiều hệ thống frontend nên yêu cầu quy trình build, kiểm thử và triển khai rõ ràng cho từng micro-app. Nếu doanh nghiệp chưa có hệ thống CI/CD ổn định, quản lý nhiều pipeline có thể khiến quá trình phát triển phức tạp hơn thay vì nhanh hơn. Ví dụ, thay vì triển khai một dự án, team có thể phải theo dõi nhiều phiên bản, môi trường và quá trình cập nhật khác nhau. Do đó, nếu hạ tầng DevOps chưa sẵn sàng, nên củng cố quy trình tự động hóa trước khi chuyển sang Micro Frontends.

 - Đội ngũ thiếu kinh nghiệm về system architecture & design system: Micro Frontends đòi hỏi đội ngũ có khả năng thiết kế kiến trúc frontend, quản lý dependency, routing, giao tiếp giữa các micro-app và xây dựng quy tắc dùng chung. Nếu team chưa có kinh nghiệm, chia nhỏ frontend có thể dẫn đến nhiều vấn đề như code trùng lặp, giao diện thiếu nhất quán hoặc các module phụ thuộc quá nhiều vào nhau. Design system cũng trở nên quan trọng để đảm bảo button, form, typography và các thành phần giao diện có trải nghiệm thống nhất trên toàn website.

 - Đòi hỏi khắt khe về tốc độ tải trang ban đầu: Với những website đặc biệt chú trọng thời gian tải trang ban đầu, Micro Frontends cần được cân nhắc kỹ. Việc chia frontend thành nhiều micro-app có thể làm phát sinh thêm JavaScript, request và dependency cần tải, đặc biệt nếu các module không được tối ưu tốt. Điều này có thể ảnh hưởng đến tốc độ hiển thị nội dung và trải nghiệm người dùng trên thiết bị hoặc mạng yếu. Nếu hiệu suất tải ban đầu là yêu cầu quan trọng, doanh nghiệp nên ưu tiên kiến trúc đơn giản hơn hoặc áp dụng các giải pháp như SSR, code splitting, lazy loading và caching trước khi lựa chọn Micro Frontends.
 

 

Lộ trình 5 bước chuyển đổi từ Monolith sang Micro Frontends cho website

Chuyển từ Monolithic Frontend sang Micro Frontends nên được thực hiện từng bước thay vì thay đổi toàn bộ website trong một lần. Doanh nghiệp cần xác định rõ phần nào nên tách, cách tích hợp và quy trình triển khai trước khi bắt đầu. Lộ trình dưới đây giúp quá trình chuyển đổi diễn ra có kiểm soát và hạn chế ảnh hưởng đến website đang vận hành.

Bước 1: Đánh giá hệ thống & phân rã domain

Đây là bước nền tảng giúp xác định phạm vi chuyển đổi, ranh giới giữa các micro-app và thứ tự ưu tiên. Phân tích kỹ frontend hiện tại trước khi tách giúp doanh nghiệp tránh tình trạng chia nhỏ hệ thống nhưng các module vẫn phụ thuộc chặt chẽ vào nhau.

Các hạng mục cần đánh giá:

- Kiểm kê frontend hiện tại: Xác định các chức năng chính như trang sản phẩm, giỏ hàng, thanh toán, tài khoản, quản trị và các thành phần đang được sử dụng chung. Đồng thời ghi nhận những dependency và mối liên kết giữa các khu vực.

- Phân rã theo domain nghiệp vụ: Chia hệ thống dựa trên chức năng và trách nhiệm nghiệp vụ thay vì chia theo các lớp kỹ thuật. Ví dụ, có thể xác định các domain như Product Catalog, Checkout, Order, User Account thay vì tách thành nhóm UI, API hay database.

- Xác định bounded context: Đánh giá xem mỗi domain có ranh giới rõ ràng đến đâu, dữ liệu nào thuộc phạm vi của domain và mức độ phụ thuộc với các domain khác. Những domain có thể phát triển, kiểm thử và triển khai tương đối độc lập thường là ứng viên tốt để chuyển thành micro-app.

- Xác định điểm nghẽn của hệ thống: Tìm những khu vực thường xuyên thay đổi, có nhiều team cùng chỉnh sửa, dễ xảy ra xung đột hoặc mất nhiều thời gian khi kiểm thử và triển khai, có thể là những module nên ưu tiên chuyển đổi trước.

- Đánh giá cách tổ chức team: Xác định team nào đang phụ trách từng domain và liệu có thể giao quyền sở hữu rõ ràng cho từng micro-app hay không. Micro Frontends sẽ hiệu quả hơn khi mỗi team có phạm vi trách nhiệm độc lập.

- Lập thứ tự ưu tiên chuyển đổi: Không nhất thiết phải tách toàn bộ hệ thống ngay từ đầu. Nên lựa chọn một domain có giá trị cao, ít phụ thuộc và khả năng chuyển đổi tốt để làm micro-app đầu tiên, sau đó dùng kinh nghiệm từ module này cho các bước tiếp theo.

Bước 2: Xây dựng nền tảng hạ tầng & application shell

Sau khi xác định được các domain và thứ tự ưu tiên chuyển đổi, bước tiếp theo là chuẩn bị hạ tầng kỹ thuật và Application Shell cho kiến trúc Micro Frontends. Application Shell đóng vai trò là khung chính, kết nối các micro-app và duy trì những thành phần dùng chung trên toàn website. Đây cũng là giai đoạn thiết lập các quy tắc kỹ thuật để những micro-app được phát triển sau đó có thể tích hợp và vận hành thống nhất.

Các hạng mục triển khai:

- Xây dựng Application Shell: Thiết lập khung chính cho website, quản lý các thành phần dùng chung như layout, header, footer, navigation và những chức năng nền tảng.

- Thiết lập routing: Xác định cách phân chia URL giữa Application Shell và từng micro-app. Ví dụ, /products/* có thể thuộc Product App, trong khi /checkout/* thuộc Checkout App.

- Lựa chọn cơ chế tích hợp: Xác định phương thức kết nối các micro-app như Module Federation, Web Components hoặc JavaScript Integration dựa trên công nghệ và yêu cầu của hệ thống hiện tại.

- Chuẩn hóa giao tiếp giữa các app: Xác định cách các micro-app trao đổi dữ liệu, chẳng hạn thông qua API, Custom Events hoặc shared state, đồng thời giới hạn những dữ liệu thực sự cần chia sẻ.

- Thiết lập CI/CD: Chuẩn bị quy trình build, kiểm thử và triển khai cho từng micro-app để các module có thể được cập nhật độc lập khi cần.

- Quản lý dependency dùng chung: Xác định những thư viện nên được chia sẻ giữa các micro-app và quy định phiên bản phù hợp để hạn chế tải trùng hoặc xung đột dependency.

- Thiết lập design system: Chuẩn hóa các thành phần giao diện như button, form, typography, màu sắc và spacing, giúp các micro-app có trải nghiệm nhất quán.

- Chuẩn bị môi trường kiểm thử: Tạo môi trường để kiểm tra từng micro-app độc lập cũng như kiểm tra khả năng tích hợp với Application Shell trước khi đưa lên production.

Bước 3: Tách dần từng module theo mô hình Strangler Fig Pattern

Sau khi Application Shell và hạ tầng đã sẵn sàng, doanh nghiệp bắt đầu tách từng module khỏi Monolithic Frontend theo mô hình Strangler Fig Pattern. Thay vì rewrite toàn bộ website, từng phần của hệ thống cũ sẽ được thay thế dần bằng micro frontend mới. Cách tiếp cận này giúp duy trì hoạt động của website trong suốt quá trình chuyển đổi và giảm rủi ro khi đưa kiến trúc mới vào vận hành.

Quy trình thực hiện:

- Chọn module ưu tiên: Bắt đầu với domain có mức độ độc lập cao, ít phụ thuộc vào Monolith và mang lại giá trị rõ ràng khi tách thành micro-app.

- Xây dựng micro-app mới: Phát triển chức năng tương ứng theo kiến trúc Micro Frontends, đồng thời đảm bảo micro-app có thể hoạt động độc lập và tích hợp với Application Shell.

- Kết nối với hệ thống hiện tại: Đưa micro-app mới vào website nhưng vẫn duy trì module cũ, tạo điều kiện để hai phần cùng tồn tại trong giai đoạn chuyển tiếp.

- Chuyển traffic từng bước: Sử dụng feature flag, canary release hoặc các cơ chế routing phù hợp để chuyển dần người dùng từ module cũ sang micro-app mới.

- Theo dõi và rollback: Giám sát lỗi, hiệu suất và hành vi người dùng sau khi triển khai. Nếu phát sinh vấn đề nghiêm trọng, có thể nhanh chóng chuyển người dùng trở lại module Monolith.

- Loại bỏ module cũ: Khi micro-app mới hoạt động ổn định, gỡ bỏ chức năng tương ứng khỏi Monolithic Frontend để tránh duy trì hai phiên bản của cùng một nghiệp vụ.

Bước 4: Quản lý phụ thuộc & tối ưu hóa hiệu năng

Khi website đã có nhiều micro-app hoạt động song song, quản lý dependency và hiệu năng trở nên quan trọng hơn so với frontend monolithic. Nếu mỗi micro-app tự tải một phiên bản React, Angular hoặc thư viện UI riêng, trình duyệt có thể phải tải nhiều mã JavaScript trùng lặp. Điều này làm tăng kích thước bundle và ảnh hưởng đến thời gian tải trang. Vì vậy, bước này tập trung vào việc giảm phần mã dư thừa và đảm bảo các micro-app hoạt động hiệu quả khi kết hợp trên cùng một website.

Các yếu tố cần triển khai bao gồm: 

- Xác định dependency dùng chung: Liệt kê các thư viện được nhiều micro-app sử dụng như React, React DOM, Angular hoặc các UI library để xác định những dependency nên được dùng chung.

- Kiểm soát phiên bản: Thống nhất phiên bản của các thư viện quan trọng, đặc biệt với những dependency được chia sẻ giữa nhiều micro-app. Việc này giúp hạn chế lỗi do các app sử dụng những phiên bản không tương thích.

- Giảm mã JavaScript trùng lặp: Tránh để mỗi micro-app tải lại cùng một thư viện hoặc component. Với các hệ thống sử dụng Module Federation, có thể cấu hình dependency dùng chung để giảm kích thước tài nguyên phải tải.

- Áp dụng lazy loading: Chỉ tải micro-app khi người dùng thực sự truy cập đến khu vực tương ứng. Ví dụ, Checkout App không cần được tải ngay khi người dùng mới mở trang chủ.

- Theo dõi hiệu năng: Sử dụng các chỉ số như LCP, INP và CLS để đánh giá trải nghiệm thực tế. Nếu một micro-app làm tăng đáng kể thời gian tải hoặc ảnh hưởng đến tương tác, cần xác định nguyên nhân và tối ưu riêng phần đó.

- Kiểm tra trên toàn hệ thống: Không chỉ đánh giá từng micro-app riêng lẻ mà cần kiểm tra cả website sau khi các module được tích hợp. Một micro-app có thể hoạt động tốt khi chạy độc lập nhưng vẫn gây ảnh hưởng đến hiệu năng khi kết hợp với nhiều app khác.

Bước 5: Hoàn tất chuyển đổi & khai tử Monolith cũ

Sau khi các micro-app đã được chuyển đổi và vận hành ổn định, doanh nghiệp tiến hành kiểm tra toàn bộ chức năng, routing, hiệu năng và các kết nối giữa các module. Những phần code, dependency và cấu hình không còn sử dụng sẽ được loại bỏ khỏi Monolithic Frontend để tránh phát sinh chi phí bảo trì không cần thiết. Đồng thời, cần cập nhật tài liệu kiến trúc và quy trình vận hành để đội ngũ có thể quản lý hệ thống mới hiệu quả. Khi toàn bộ chức năng quan trọng đã được chuyển sang Micro Frontends và hệ thống hoạt động ổn định, Monolith cũ có thể được ngừng triển khai và chính thức khai tử.

 

 

Cách triển khai Micro Frontends trên các framework phổ biến

Micro Frontends có thể được triển khai trên nhiều framework frontend phổ biến như React, Angular và Vue. Cách triển khai cụ thể sẽ phụ thuộc vào framework đang sử dụng, phương pháp tích hợp và quy mô của hệ thống web. Trong đó, React và Angular có hệ sinh thái hỗ trợ khá tốt cho việc xây dựng các micro-app độc lập và kết hợp chúng trong cùng một website.

1. Micro Frontends với React

Với React, Micro Frontends thường được triển khai bằng cách chia website thành nhiều React nhỏ, mỗi frontend phụ trách một domain hoặc nhóm chức năng riêng. Các micro-app này có thể được phát triển và triển khai độc lập, sau đó kết nối với Application Shell để tạo thành một website hoàn chỉnh.

Một số cách triển khai phổ biến gồm:

- Module Federation: Cho phép một React app tải component hoặc module từ một React app khác tại runtime. Đây là lựa chọn phù hợp khi cần các micro-app được phát triển và deploy độc lập.

- React + Web Components: Các phần giao diện React có thể được đóng gói thành Web Components để tích hợp vào Application Shell hoặc những dự án frontend khác.

- React + Single-SPA: Single-SPA đóng vai trò điều phối nhiều hệ thống frontend, cho phép các React app hoạt động như những micro-app riêng biệt và được tải dựa trên route.

- Route-based Micro Frontends: Chia website theo URL, chẳng hạn /products, /cart và /checkout, sau đó giao từng nhóm route cho một React micro-app phụ trách.

Khi triển khai React Micro Frontends, cần đặc biệt chú ý đến việc quản lý dependency, chia sẻ trạng thái và thống nhất design system. Không nên chia sẻ quá nhiều state hoặc logic giữa các micro-app vì điều này có thể tạo ra sự phụ thuộc ngược và làm mất tính độc lập của từng module.

2. Micro Frontends với Angular

Angular có kiến trúc khá phù hợp với Micro Frontends nhờ hệ thống module, routing và dependency injection được tổ chức tương đối rõ ràng. Khi triển khai, một Angular application có thể đóng vai trò Host, trong khi các hệ thống Angular khác đảm nhiệm từng domain như Product, Order hoặc Account. Các micro-app có thể được tải theo route và kết nối với Host thông qua Module Federation, từ đó cho phép từng team phát triển và triển khai khu vực mình phụ trách độc lập.

Các hướng triển khai phổ biến với Angular là:

- Angular Host + Remote Applications: Một Angular application đóng vai trò Host, chịu trách nhiệm layout, navigation và routing chính. Các hệ thống Angular khác được xây dựng thành Remote Application và được Host tải khi người dùng truy cập đến domain tương ứng.

- Angular Router: Tận dụng hệ thống routing của Angular để phân chia phạm vi cho từng micro-app. Ví dụ, /products/* có thể được giao cho Product App, còn /orders/* thuộc Order App.

- Module Federation: Cho phép Host tải các module hoặc thành phần từ Remote Application tại runtime. Đây là hướng phù hợp khi các team cần build và deploy từng Angular application độc lập.

- Angular Elements: Cho phép chuyển component Angular thành custom element, từ đó có thể nhúng component này vào những phần frontend khác mà không cần toàn bộ hệ thống phải sử dụng Angular.

Angular thường phù hợp với các hệ thống enterprise có quy mô lớn, nơi cần cấu trúc rõ ràng và quy chuẩn thống nhất giữa nhiều team. Tuy nhiên, Angular có thể tạo ra bundle tương đối lớn nếu mỗi micro-app tự mang theo toàn bộ framework và dependency. Vì vậy, cần có chiến lược chia sẻ dependency, lazy loading và tối ưu bundle ngay từ đầu. 

3. Micro Frontends với Vue

Vue có thể triển khai Micro Frontends bằng cách chia website thành nhiều hệ thống Vue nhỏ, mỗi micro frontend phụ trách một nhóm chức năng hoặc domain riêng. Nhờ cấu trúc tương đối linh hoạt, Vue có thể được tích hợp vào hệ thống Micro Frontends mà không cần biến toàn bộ website thành một hệ thống duy nhất. Với các dự án đang sử dụng Vue, có thể bắt đầu bằng việc tách một khu vực độc lập rồi từng bước mở rộng sang các phần khác.

Một số hướng triển khai phù hợp với Vue gồm:

- Vue Host + Micro-app: Một Vue application đóng vai trò Host, quản lý layout và điều hướng chính, trong khi các Vue micro-app đảm nhiệm từng khu vực như Product, Order hoặc Account.

- Vue Router: Có thể phân chia micro-app theo từng nhóm URL. Ví dụ, Product App phụ trách /products/*, còn Order App phụ trách /orders/*. Cách này giúp mỗi team có phạm vi phát triển rõ ràng và hạn chế can thiệp vào nhau.

- Web Components: Các thành phần Vue có thể được đóng gói thành custom elements để sử dụng trong những khu vực frontend khác. Hướng này hữu ích khi hệ thống có nhiều công nghệ frontend khác nhau nhưng vẫn muốn chia sẻ một số thành phần giao diện.

4. Kết hợp nhiều framework trên cùng một website

Khi kết hợp nhiều framework, mỗi micro-app được xây dựng bằng một framework phù hợp với domain mà team phụ trách, sau đó tích hợp vào cùng một Application Shell. Các micro-app không cần dùng chung framework nhưng phải tuân theo một số quy tắc tích hợp để có thể hoạt động như một website thống nhất.

Cách triển khai như sau:

- Xác định framework cho từng micro-app: Ví dụ, Product App sử dụng React, Account App sử dụng Vue, còn Admin App sử dụng Angular.

- Tạo Application Shell: Xây dựng một hệ thống trung tâm chịu trách nhiệm về layout, navigation, authentication và routing cấp cao.

- Tích hợp các micro-app: Sử dụng Module Federation, Web Components hoặc Single-SPA để đưa các hệ thống React, Vue và Angular vào cùng một website.

- Phân chia theo route: Giao từng nhóm URL cho một micro-app, chẳng hạn /products/* cho React, /account/* cho Vue và /admin/* cho Angular. Nhờ đó, mỗi framework hoạt động trong phạm vi tương đối độc lập.

- Chuẩn hóa giao tiếp: Các micro-app có thể trao đổi dữ liệu thông qua API, Custom Events hoặc các cơ chế giao tiếp chung, thay vì phụ thuộc trực tiếp vào code của framework khác.

- Thống nhất giao diện: Xây dựng design system hoặc bộ UI components dùng chung để React, Vue và Angular vẫn tạo ra trải nghiệm nhất quán.

- Quản lý và triển khai độc lập: Mỗi micro-app có thể có repository, quy trình build và pipeline CI/CD riêng, sau đó được tích hợp vào Application Shell khi triển khai.

Ví dụ, một website thương mại điện tử có thể dùng React cho Product, Vue cho Account và Angular cho Admin. Người dùng vẫn trải nghiệm đây là một website duy nhất, trong khi phía sau mỗi khu vực được phát triển và vận hành như một hệ thống frontend riêng.

 

 

Ví dụ thực tế về kiến trúc Micro Frontends cho website thương mại điện tử

Một website thương mại điện tử có nhiều nghiệp vụ như sản phẩm, giỏ hàng, đơn hàng, thanh toán và tài khoản nên là ví dụ phù hợp để minh họa cách Micro Frontends hoạt động. Thay vì xây dựng toàn bộ frontend thành một kiến trúc duy nhất, hệ thống có thể được chia thành các micro-app theo từng domain. Application Shell đóng vai trò kết nối các phần này và đảm bảo người dùng vẫn có trải nghiệm thống nhất.

(1) Phân chia các micro-app theo chức năng

Website có thể được tổ chức thành các micro-app độc lập như:

- Product App: Quản lý danh mục, tìm kiếm, bộ lọc và trang chi tiết sản phẩm.

- Cart App: Quản lý giỏ hàng, số lượng sản phẩm và tổng tiền.

- Checkout App: Xử lý địa chỉ giao hàng, phương thức vận chuyển và thanh toán.

- Order App: Hiển thị lịch sử đơn hàng, trạng thái giao hàng và chi tiết đơn.

- Account App: Quản lý thông tin cá nhân, địa chỉ và các thiết lập tài khoản.

- Admin App: Cung cấp giao diện quản trị sản phẩm, đơn hàng, khách hàng và khuyến mãi.

(2) Application Shell đóng vai trò trung tâm

Application Shell là lớp giao diện chính, chịu trách nhiệm duy trì những thành phần dùng chung như header, footer, navigation, authentication và routing cấp cao. Khi người dùng truy cập từng khu vực, Shell sẽ xác định và tải micro-app tương ứng.

Ví dụ:

/products → Product App

/cart → Cart App

/checkout → Checkout App

/orders → Order App

/account → Account App

Nhờ cách tổ chức này, mỗi team có thể tập trung phát triển một domain mà không cần can thiệp vào toàn bộ frontend.

(3) Cách các micro-app giao tiếp với nhau

Các micro-app vẫn cần trao đổi một số dữ liệu để tạo thành quy trình mua hàng liền mạch. Chẳng hạn, khi người dùng thêm sản phẩm vào giỏ, Product App có thể gửi thông tin cần thiết cho Cart App thông qua API hoặc cơ chế giao tiếp đã thống nhất. Khi người dùng chuyển sang thanh toán, Checkout App lấy dữ liệu giỏ hàng và thông tin tài khoản cần thiết để hoàn tất đơn hàng.

Điểm quan trọng là chỉ chia sẻ những dữ liệu thực sự cần thiết, tránh để các micro-app phụ thuộc trực tiếp vào code hoặc state nội bộ của nhau.

(4) Ví dụ luồng hoạt động

Một luồng mua hàng có thể diễn ra như sau:

Product App → Cart App → Checkout App → Order App

Người dùng tìm kiếm và chọn sản phẩm → thêm vào giỏ hàng → nhập thông tin giao hàng và thanh toán → đặt hàng thành công → theo dõi đơn hàng.

Trong quá trình này, mỗi micro-app chịu trách nhiệm cho một phần nghiệp vụ nhưng vẫn được kết nối thông qua Application Shell, routing và các cơ chế giao tiếp chung. Đây chính là cách Micro Frontends giúp một website thương mại điện tử lớn có thể được phát triển bởi nhiều team mà vẫn duy trì một trải nghiệm thống nhất.
 

 

Những sai lầm thường gặp khi triển khai Micro Frontend architecture 

Micro Frontends giúp tổ chức frontend linh hoạt hơn nhưng cũng làm tăng độ phức tạp của hệ thống nếu triển khai không đúng cách. Những sai lầm dưới đây có thể khiến website khó phát triển, tốn chi phí vận hành và thậm chí kém hiệu quả hơn frontend monolithic. Vì vậy, doanh nghiệp nên xác định rõ ranh giới và nguyên tắc triển khai ngay từ đầu.

- Chia micro-app quá nhỏ: Việc tách từng component, trang hoặc chức năng nhỏ thành một micro-app riêng có thể làm số lượng app tăng nhanh nhưng không mang lại nhiều lợi ích. Mỗi micro-app lại cần được build, kiểm thử, triển khai và theo dõi riêng, khiến hệ thống trở nên phức tạp. Thay vì chia theo từng thành phần giao diện, nên phân rã theo domain nghiệp vụ có chức năng và trách nhiệm tương đối độc lập.

- Các micro-app vẫn phụ thuộc chặt chẽ vào nhau: Micro Frontends chỉ phát huy hiệu quả khi các phần có thể phát triển tương đối độc lập. Nếu Product App phải liên tục sử dụng state, component hoặc logic nội bộ của Cart App, chỉ cần một bên thay đổi cũng có thể ảnh hưởng đến bên còn lại. Vì vậy, cần xác định rõ dữ liệu nào được chia sẻ, cách giao tiếp và giới hạn phụ thuộc giữa các micro-app.

- Không thống nhất giao diện và quy chuẩn chung: Mỗi team tự lựa chọn cách xây dựng button, form, typography, màu sắc hoặc cách xử lý tương tác có thể khiến các khu vực trên website thiếu nhất quán. Design system, coding convention và các quy tắc frontend chung nên được thiết lập trước khi nhiều team cùng phát triển. Điều này giúp mỗi micro-app vẫn có tính độc lập nhưng người dùng vẫn cảm nhận đó là một website thống nhất.

- Bỏ qua hiệu năng khi tích hợp nhiều micro-app: Mỗi micro-app có thể tải framework, thư viện và tài nguyên riêng, dẫn đến JavaScript bị lặp và làm tăng thời gian tải trang. Tình trạng này đặc biệt đáng chú ý với website có nhiều micro-app cùng xuất hiện trên một trang. Do đó, cần kiểm soát shared dependencies, lazy loading, code splitting, caching và theo dõi các chỉ số như LCP, INP để đảm bảo hiệu năng.

- Chuyển đổi toàn bộ Monolith cùng một lúc: Việc rewrite toàn bộ frontend để chuyển sang Micro Frontends có thể làm tăng đáng kể thời gian, chi phí và rủi ro. Nếu hệ thống cũ vẫn đang vận hành, một lỗi trong quá trình chuyển đổi có thể ảnh hưởng đến toàn bộ website. Thay vào đó, nên áp dụng Strangler Fig Pattern, chọn một domain phù hợp để chuyển đổi trước, theo dõi kết quả rồi tiếp tục mở rộng sang các phần còn lại.
 

 

Một số câu hỏi thường gặp về Micro Frontends

Micro Frontends là kiến trúc có nhiều ưu điểm nhưng cũng đặt ra không ít câu hỏi về hiệu suất, cách tổ chức hệ thống và khả năng ứng dụng thực tế. Dưới đây là một số câu hỏi thường gặp giúp làm rõ hơn cách Micro Frontends hoạt động và khi nào nên sử dụng.

1. Micro Frontends có ảnh hưởng đến hiệu suất website không?

Micro Frontends có thể có ảnh hưởng đến hiệu suất trang web nếu các micro-app được triển khai và tối ưu không tốt. Chia frontend thành nhiều module có thể làm tăng số lượng JavaScript, dependency và tài nguyên mà trình duyệt phải tải. Tuy nhiên, có thể hạn chế vấn đề này bằng cách sử dụng lazy loading, code splitting, shared dependencies, caching và chỉ tải micro-app khi người dùng thực sự cần. Vì vậy, Micro Frontends không mặc định làm website chậm mà hiệu suất phụ thuộc nhiều vào cách thiết kế và triển khai kiến trúc.

2. Micro Frontends khác gì so với Microservices?

Micro Frontends và Microservices đều chia một hệ thống lớn thành những phần nhỏ hơn nhưng tập trung vào hai lớp khác nhau. Micro Frontends chủ yếu áp dụng cho frontend, chia giao diện và chức năng người dùng thành các micro-app độc lập. Trong khi đó, Microservices tập trung vào backend, chia hệ thống thành các service xử lý những nghiệp vụ riêng như quản lý đơn hàng, thanh toán hoặc người dùng. Hai kiến trúc có thể được sử dụng cùng nhau, trong đó mỗi micro frontend có thể giao tiếp với một hoặc nhiều microservices thông qua API.

3. Micro Frontend architecture có phải tương lai của frontend không?

Không nên xem Micro Frontends là hướng phát triển bắt buộc cho mọi website. Kiến trúc này phù hợp hơn với hệ thống lớn, nhiều domain nghiệp vụ, nhiều team phát triển và nhu cầu triển khai các tính năng tương đối độc lập. Với website nhỏ hoặc đội ngũ ít người, frontend monolithic hoặc modular monolith thường đơn giản và hiệu quả hơn. Vì vậy, Micro Frontends có thể là một hướng quan trọng trong phát triển frontend quy mô lớn, nhưng việc lựa chọn vẫn cần dựa trên quy mô, nhu cầu và vấn đề thực tế của từng hệ thống.
 

 

Qua bài viết của Phương Nam Vina, có thể thấy Micro Frontends mang đến một cách tiếp cận linh hoạt để tổ chức và phát triển các hệ thống web lớn bằng cách chia frontend thành những micro-app theo từng domain nghiệp vụ. Kiến trúc này giúp các team phát triển độc lập, dễ mở rộng và cập nhật từng phần của website mà không nhất thiết phải thay đổi toàn bộ hệ thống. Để triển khai hiệu quả, doanh nghiệp nên bắt đầu từ việc đánh giá hệ thống, xác định domain phù hợp, xây dựng Application Shell và chuyển đổi từng phần thay vì rewrite toàn bộ. Khi được áp dụng đúng bối cảnh, Micro Frontends có thể trở thành nền tảng giúp website quy mô lớn dễ phát triển, bảo trì và thích ứng với nhu cầu thay đổi trong dài hạn. 

Tham khảo thêm:

 MVC là gì? Tất tần tật về mô hình MVC trong lập trình web

 AI Agent là gì? Kiến trúc cốt lõi và cách triển khai cho website

 Xây dựng hệ thống web linh hoạt với event-driven architecture