Thuật ngữ cốt lõi

Bạn đọc một cấu hình thấy host tải remote, rồi đọc thiết kế thấy shell ghép các micro-frontend. Đó có phải cùng một thứ không? Nếu catalog đã có URL và pipeline riêng, nó đã deploy độc lập chưa?

Bài này giúp bạn gọi đúng tên từng vai trò và tránh suy ra khả năng của kiến trúc chỉ từ tên công cụ. Ví dụ xuyên suốt là một shop có shell quản lý khung trang, catalog hiển thị sản phẩm và cart hiển thị giỏ hàng.

Mục lụcCopy Anchor Link

• Tra nhanh các thuật ngữ chính
• Shell là vai trò trong sản phẩm
• Host và remote là vai trò tích hợp
  • Host tiêu thụ module
  • Remote cung cấp module
  • Vì sao host không đồng nghĩa với shell
• Composition là cách ghép các phần frontend
  • Ghép vào thời điểm nào
  • Ghép theo route hay trong cùng trang
• Isolation phải nói rõ cách ly điều gì
  • Các chiều cách ly
  • Giới hạn của các cơ chế phổ biến
• Independent deployment là khả năng phát hành riêng
  • Phân biệt build, deploy và release
  • Phép thử với một thay đổi catalog
• Những thuật ngữ đi cùng các ranh giới
  • Domain, ownership, contract và coupling
  • Entry, manifest và shared dependency
  • Lifecycle, fallback và rollback
• Đọc một mô tả kiến trúc cho đúng
• Đọc tiếp
• Tài liệu tham khảo

Tra nhanh các thuật ngữ chínhCopy Anchor Link

Sáu thuật ngữ này trả lời những câu hỏi khác nhau. Một hệ thống có thể có host và remote nhưng chưa đạt independent deployment; cũng có thể đạt independent deployment mà không dùng Module Federation.

Shell là vai trò trong sản phẩmCopy Anchor Link

Application shell là phần giữ khung và điều phối trải nghiệm chung. Với shop mẫu, shell có thể quản lý header, navigation, vùng hiển thị nội dung, route cấp cao và trạng thái loading hoặc fallback khi một phần chưa tải được.

direction: down
shell: "Shell: khung trang, navigation,\nchọn theo URL"
catalog: Catalog
cart: Cart
shell -> catalog: /products
shell -> cart: /cart

Sơ đồ này chỉ mô tả trách nhiệm, chưa quyết định shell tải nội dung bằng Module Federation, iframe hay cơ chế khác. Nó cũng không yêu cầu catalog và cart xuất hiện cùng lúc.

Shell có thể phối hợp ngữ cảnh đăng nhập và chuyển thông tin cần thiết qua contract, nhưng backend vẫn phải kiểm tra quyền của từng request. Shell không nên tính giá sản phẩm, sở hữu toàn bộ state giỏ hàng hoặc biết cấu trúc store nội bộ của mọi app. Vì nếu mọi thay đổi nghiệp vụ đều phải sửa shell, shell sẽ trở thành điểm buộc các team release cùng nhau.

Mình dùng “shell” cho vai trò tích hợp trải nghiệm trong lộ trình này. Trong các tài liệu về PWA, app shell còn thường chỉ phần khung UI có thể cache để tải nhanh; đừng tự suy ra kiến trúc micro-frontend hay deploy độc lập từ cách dùng đó.

Host và remote là vai trò tích hợpCopy Anchor Link

Trong Module Federation, các build có thể cung cấp và tiêu thụ module của nhau. Hai từ host và remote mô tả hai phía của quan hệ đó, không mô tả ownership nghiệp vụ hay mức cách ly.

Host tiêu thụ moduleCopy Anchor Link

Host là ứng dụng hoặc build tiêu thụ module từ remote. Ví dụ, shell muốn render trang danh sách sản phẩm và có một đoạn import như sau:

// Minh họa cách gọi sau khi đã cấu hình Module Federation.
const catalogModule = await import('catalog/ProductPage');

Trong quan hệ này, shell là host và catalog là remote. catalog là tên mà bên tiêu thụ dùng để tham chiếu remote; ProductPage là tên module công khai trong ví dụ. Đây không phải đường dẫn HTTP, cũng không phải cú pháp tự hoạt động trong một dự án chưa cấu hình federation.

Host chịu trách nhiệm cho cách sử dụng module: tải khi nào, đặt UI vào đâu và xử lý lỗi tích hợp ra sao. Tuy nhiên, tên “host” không có nghĩa nó luôn cung cấp toàn bộ framework hoặc shared dependency; điều đó phụ thuộc cấu hình.

Remote cung cấp moduleCopy Anchor Link

Remote là phía cung cấp module cho bên khác tiêu thụ. Catalog có thể expose một trang, một component hoặc một API lifecycle để host gọi. Phần được expose không nhất thiết là toàn bộ code của catalog.

Trong webpack Module Federation, container là cơ chế cung cấp quyền truy cập vào các module được expose. Một container entry, thường được đặt tên remoteEntry.js, giúp runtime truy cập container và tải module cần dùng. Entry không nhất thiết chứa toàn bộ code ứng dụng; runtime có thể tải thêm các chunk sau đó. Tên file remoteEntry.js là quy ước phổ biến, không phải tên bắt buộc.

“Remote” cũng không có nghĩa khác origin. Shell và catalog có thể phục vụ từ cùng một origin qua các đường dẫn khác nhau; ngược lại, JavaScript tải từ CDN khác origin nhưng chạy trong trang shell không vì thế có sandbox riêng.

Vì sao host không đồng nghĩa với shellCopy Anchor Link

Shell trả lời “ai giữ trải nghiệm chung?”, còn host trả lời “ai tiêu thụ module trong quan hệ này?”. Trong demo nhỏ, một app thường giữ cả hai vai trò nên hai từ dễ bị dùng thay nhau.

Nhưng catalog có thể vừa expose ProductPage cho shell, vừa tiêu thụ một module từ remote khác. Khi đó catalog là remote đối với shell và là host trong quan hệ tiêu thụ kia. Một build có thể vừa cung cấp vừa tiêu thụ module.

Ngược lại, shell ghép các app bằng iframe vẫn là shell, nhưng không phải host theo cơ chế Module Federation. Khi đọc thiết kế, hãy hỏi tên gọi đang mô tả trách nhiệm sản phẩm hay quan hệ tải module.

Composition là cách ghép các phần frontendCopy Anchor Link

Composition là việc ghép các phần frontend thành một ứng dụng hoặc trải nghiệm thống nhất. Nó bao gồm chọn phần cần hiển thị, đặt phần đó vào layout, kết nối các contract cần thiết và phối hợp navigation.

Ghép vào thời điểm nàoCopy Anchor Link

Các kiểu này có thể kết hợp. Một trang có HTML ghép ở server rồi tải phần tương tác trong trình duyệt vẫn dùng nhiều lớp composition.

SSR không tự đồng nghĩa với server-side composition của micro-frontend. Một server render toàn bộ React app từ một bản build chung là SSR, nhưng chưa chứng minh rằng có các đơn vị frontend phát hành riêng được ghép ở server.

Theo cách dùng trong lộ trình này, khả năng phát hành độc lập là tiêu chí chính để phân biệt micro-frontend với modular frontend. Vì thế build-time composition vẫn là cách tổ chức code đáng học, nhưng bạn cần nhận ra coupling ở bước release thay vì chỉ đếm số package.

Ghép theo route hay trong cùng trangCopy Anchor Link

Thời điểm ghép là một trục; phạm vi UI được ghép là trục khác:

• Route-level composition: shell hiển thị catalog ở /products, cart ở /cart. Đây thường là điểm bắt đầu dễ kiểm soát vì ranh giới màn hình và navigation rõ hơn.
• Fragment-level composition: cùng trang chứa danh sách sản phẩm của catalog và mini-cart của cart. Cách này cần thỏa thuận rõ hơn về layout, cập nhật dữ liệu và các trạng thái loading, lỗi của từng vùng.

Đừng dùng “runtime composition” để suy ra hai app phải render cùng lúc. Shell có thể chỉ tải remote khi route cần nó. Ngược lại, nhiều vùng UI trên cùng trang có thể được ghép từ một build chung và chưa có deploy riêng.

Isolation phải nói rõ cách ly điều gìCopy Anchor Link

Câu “catalog đã được isolate khỏi cart” chưa đủ để đánh giá thiết kế. Catalog không làm đè CSS của cart khác hoàn toàn với catalog không đọc được dữ liệu của shell.

Isolation là mức hạn chế ảnh hưởng giữa các phần trên một ranh giới cụ thể. Mình khuyên luôn gọi tên ranh giới đó khi trao đổi, chẳng hạn “CSS isolation”, “state isolation” hay “security boundary”.

Các chiều cách lyCopy Anchor Link

Tách code hoặc state theo convention giúp giảm phụ thuộc, nhưng không nhất thiết cưỡng chế được ranh giới khi chạy. Code cùng JavaScript context vẫn có thể chạm vào global hoặc làm nghẽn main thread.

Giới hạn của các cơ chế phổ biếnCopy Anchor Link

Iframe khác origin thường tạo ranh giới truy cập DOM tốt hơn nhờ same-origin policy, nhưng cấu hình sandbox và giao tiếp qua postMessage vẫn cần được thiết kế. Tăng isolation cũng thường tăng công việc tích hợp: đồng bộ chiều cao, focus, routing hoặc trải nghiệm accessibility.

Independent deployment là khả năng phát hành riêngCopy Anchor Link

Independent deployment nghĩa là một phần frontend có thể đưa thay đổi tương thích tới production mà không bắt buộc build và deploy lại các phần khác. Điều cần kiểm tra là đường đi của thay đổi tới người dùng, không chỉ việc artifact được upload riêng.

Phân biệt build, deploy và releaseCopy Anchor Link

Trong bài này, mình dùng ba từ theo quy ước sau; một số team gộp deploy và release thành một bước:

Artifact là đầu ra cụ thể của một build, không chỉ mỗi file entry. Muốn tải lại hoặc rollback một version, các chunk và asset mà version đó cần cũng phải còn khả dụng.

Một catalog đã deploy lên CDN nhưng shell vẫn trỏ tới version cũ thì người dùng chưa nhất thiết nhận bản mới. Nếu shell phải sửa source, build và deploy lại chỉ để dùng catalog mới, chu kỳ phát hành của catalog vẫn phụ thuộc shell.

Phép thử với một thay đổi catalogCopy Anchor Link

Giả sử catalog thêm bộ lọc, giữ nguyên contract công khai. Hệ thống dùng runtime config để chọn artifact:

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"

Đây là dấu hiệu đạt phát hành độc lập cho thay đổi đó. Để kết luận chắc hơn, bạn cần trả lời:

• Có thể cập nhật tham chiếu catalog mà không rebuild shell không?
• Catalog mới có chạy với shell, cart và backend hiện tại không?
• Hệ thống có xử lý người dùng vẫn đang chạy version cũ không?
• Nếu cần khôi phục version trước, artifact cũ và các API mà nó dùng còn hoạt động không?

Một monorepo có thể đáp ứng các điều này; nhiều repo cũng có thể không đáp ứng. Pipeline riêng giúp tổ chức build và deploy, nhưng nếu quy trình luôn bắt tất cả app release cùng nhau thì mục tiêu độc lập vẫn chưa đạt.

Độc lập không phải “không cần phối hợp”. Đổi tên route công khai hoặc bắt bên tiêu thụ truyền một field mới có thể là breaking change và cần kế hoạch chuyển đổi. Mục tiêu là thay đổi nội bộ tương thích không bị buộc release đồng bộ, không phải mọi thay đổi đều được làm tùy ý.

Những thuật ngữ đi cùng các ranh giớiCopy Anchor Link

Bạn sẽ gặp các từ dưới đây khi đọc những bài tiếp theo. Chúng giúp mô tả điều kiện để sáu khái niệm chính hoạt động cùng nhau.

Domain, ownership, contract và couplingCopy Anchor Link

Contract không chỉ là type. Ví dụ, một event cart:changed cần nói rõ nó có nghĩa “backend đã cập nhật giỏ thành công” hay chỉ “người dùng vừa bấm nút”. Hai cách hiểu có thể có cùng payload nhưng khiến UI hoạt động khác nhau.

Mình mặc định giữ chi tiết store và model nội bộ trong phần sở hữu nó. Chỉ chia sẻ dữ liệu tối thiểu qua contract, vì chia sẻ toàn bộ implementation khiến các bên khó thay đổi riêng dù đã có artifact riêng.

Entry, manifest và shared dependencyCopy Anchor Link

Shared dependency có thể giảm tải trùng, nhưng nó tạo thêm ràng buộc version. Đừng đồng nhất “dùng chung framework” với “hoàn toàn độc lập về dependency”; đó là một đánh đổi cần quản lý.

Lifecycle, fallback và rollbackCopy Anchor Link

Lifecycle là các giai đoạn tích hợp một phần frontend: tải code, chuẩn bị nếu cần, mount UI, cập nhật và unmount. Tên và thứ tự API cụ thể tùy công cụ; không có một interface bắt buộc cho mọi micro-frontend.

Ví dụ, tải xong catalog chưa đồng nghĩa catalog đã mount vào vùng nội dung. Khi rời /products, phần chịu trách nhiệm lifecycle cần dọn UI và các tài nguyên thuộc catalog, như event listener hoặc subscription. Module Federation cung cấp module; bản thân cơ chế đó không bắt mọi remote có sẵn mount và unmount.

Fallback là UI hoặc hành vi thay thế khi một phần chưa sẵn sàng hoặc lỗi, chẳng hạn vùng catalog hiện thông báo cùng nút thử lại. Fallback giúp người dùng còn sử dụng phần khả dụng; nó không sửa nguyên nhân và không tự rollback version.

Rollback là đưa hệ thống trở lại artifact hoặc cấu hình trước đó. Với runtime composition, rollback có thể là đổi tham chiếu về catalog cũ, nhưng còn phụ thuộc cache, asset cũ và backend compatibility. Người đã mở trang cũng không nhất thiết đổi code ngay khi tham chiếu được cập nhật.

Đọc một mô tả kiến trúc cho đúngCopy Anchor Link

Hãy xét mô tả giả định này:

Shop dùng shell làm host để tải catalog và cart qua Module Federation. Các app có pipeline riêng, dùng shared React và CSS Modules. Catalog được deploy độc lập.

Tách từng khẳng định ra, bạn sẽ biết điều gì đã rõ và điều gì cần hỏi thêm:

Trước khi chấp nhận câu “catalog deploy độc lập”, hãy yêu cầu mô tả một thay đổi nội bộ cụ thể đi tới production: artifact nào đổi, ai phải build lại, cấu hình nào chọn version và khi lỗi thì khôi phục bằng cách nào. Đó là cách biến thuật ngữ thành một điều có thể kiểm chứng.

Đọc tiếpCopy Anchor Link

Các trang dưới đây đi sâu vào từng phần; những trang còn là placeholder cho biết phạm vi dự kiến của lộ trình.

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

• Module Federation — webpack: local và remote modules, container, shared modules và các build vừa expose vừa consume.
• Micro Frontends — Cam Jackson, trên martinfowler.com: independent deployment và đánh đổi giữa các cách composition.
• Using shadow DOM — MDN: encapsulation của DOM, CSS và giới hạn bảo mật của Shadow DOM.