Các cách tích hợp khác

Giả sử shell của shop dùng React, catalog cần release riêng, còn cart vẫn chạy bằng framework cũ. Bạn muốn giữ một trải nghiệm liền mạch, nhưng không chắc phải dùng Module Federation, single-spa, import maps hay Web Components. Nếu đặt tất cả lên cùng một bảng rồi chọn một cái tên, bạn dễ bỏ sót việc chúng giải quyết những phần khác nhau của bài toán.

Nhóm Các cách tích hợp khác giúp bạn xác định phần nào cần một cơ chế tải code, phần nào cần điều phối lifecycle và phần nào cần ranh giới DOM hoặc bảo mật mạnh hơn. Các cơ chế này có thể kết hợp; “không dùng federation” không có nghĩa phải viết lại mọi thứ từ đầu.

Mục lụcCopy Anchor Link

• Bắt đầu từ điểm ghép cần thiết
• Bốn trách nhiệm cần tách
• Bản đồ các cơ chế tích hợp
  • single-spa điều phối lifecycle
  • ES modules và import maps tìm và tải module
  • Web Components công khai giao diện DOM
  • iframe tạo document riêng
• Các cơ chế có thể kết hợp như thế nào
• Chọn hướng theo tình huống
• Contract tối thiểu ở điểm ghép
  • Lifecycle và quyền sở hữu DOM
  • Giao tiếp và quyền sở hữu state
• Release độc lập cần nhiều hơn một loader
• Những giới hạn cần kiểm chứng
• Lộ trình đọc trong nhóm
• Bài tập chọn một boundary
• Checklist trước khi chốt cách tích hợp
• Đọc tiếp
• Tài liệu tham khảo

Bắt đầu từ điểm ghép cần thiếtCopy Anchor Link

Trước khi chọn thư viện, hãy trả lời: bạn muốn ghép một trang, một vùng UI hay một ứng dụng có document riêng? Cùng là catalog, nhưng ghép toàn bộ trải nghiệm /products khác nhiều với nhúng một product card vào mọi trang.

Nếu catalog và cart chỉ cần xuất hiện ở các route khác nhau, mình bắt đầu từ ranh giới theo route. Mỗi app có vùng DOM và router con rõ ràng, nên ít phải chia sẻ state UI hơn việc tách từng widget. Nếu chấp nhận navigation tải lại trang, route có thể trỏ đến những ứng dụng riêng qua reverse proxy hoặc cấu hình server; chưa chắc cần runtime composition trong browser.

Nếu cần catalog và cart cùng hiện trên một màn hình, bạn phải xử lý thêm layout, loading từng vùng, focus và giao tiếp giữa chúng. Tách càng nhỏ không mặc nhiên càng độc lập: một widget hỏi shell về mọi thay đổi state có thể tạo coupling chặt hơn một trang nghiệp vụ tự quản lý phần lớn hành vi.

Có thật sự cần release riêng không? Nếu một team vẫn phát hành toàn bộ sản phẩm cùng lúc và chưa có điểm nghẽn cụ thể, mình giữ modular frontend hoặc package dùng chung. Build-time integration thường đơn giản hơn về runtime; đổi lại, consumer thường phải build và deploy lại để nhận code package mới. Đó là đánh đổi hợp lý nếu deploy độc lập chưa phải yêu cầu.

Bốn trách nhiệm cần táchCopy Anchor Link

Một điểm ghép runtime có thể hình dung như sau:

direction: down
n0: "Chọn release / URL"
n1: "Resolve và tải code"
n2: "Kích hoạt và mount UI"
n3: "Giao tiếp trong boundary"
n4: "Unmount và cleanup"
n0 -> n1 -> n2 -> n3 -> n4

Đây là mô hình trách nhiệm, không phải thứ tự API bắt buộc. Với iframe, browser tải cả document thay vì shell import một module rồi gọi mount; với custom element, việc thêm hoặc tháo element kích hoạt lifecycle của nó.

Release policy, observability và compatibility đi xuyên cả bốn trách nhiệm. Không có một ô nào trong bảng tự chứng minh catalog có thể release độc lập.

Bản đồ các cơ chế tích hợpCopy Anchor Link

single-spa điều phối lifecycleCopy Anchor Link

single-spa chọn ứng dụng active theo điều kiện như URL, gọi hàm tải app rồi điều phối bootstrap, mount và unmount. Root config đăng ký app; mỗi app cung cấp lifecycle, trực tiếp hoặc thông qua adapter cho framework.

Với shop, shell có thể kích hoạt catalog ở /products và cart ở /cart. Khi chuyển route, cart mount vào vùng được giao, còn catalog phải dọn DOM và side effect thuộc lifecycle của nó. Nếu catalog quên xóa listener trên window, việc gọi unmount không tự sửa được implementation đó.

Mình cân nhắc single-spa khi có nhiều ứng dụng theo route, đặc biệt trong migration giữa các framework. Với một vùng UI nhỏ và lifecycle đơn giản, một adapter rõ ràng có thể đủ; thêm orchestrator chưa chắc giảm công việc.

single-spa không quyết định toàn bộ cách resolve module hoặc chia sẻ dependency. Hàm tải app có thể dùng native import(), SystemJS hoặc một loader khác phù hợp với output của build. Nó cũng không tạo CSS sandbox hay security boundary cho các app cùng trang.

ES modules và import maps tìm và tải moduleCopy Anchor Link

Native ES modules cung cấp import/export và module loading trong browser. Import map ánh xạ specifier như @shop/catalog sang URL; shell giữ tên import ổn định trong khi cấu hình phục vụ trang chọn release tương ứng.

Hình dung import map như sổ địa chỉ: bạn gọi một tên quen thuộc, browser tra ra nơi lấy module. Nhưng sổ địa chỉ không quyết định module phải mount vào đâu, không cleanup UI và không kiểm tra hai bên có hiểu cùng API hay không.

Mình chọn hướng này khi build output thực sự là browser-compatible ESM và team muốn một đường resolve module minh bạch, ít phụ thuộc runtime riêng. Import map phải có hiệu lực trước những import cần dùng nó. Nếu bundler đã gói catalog vào shell hoặc chuyển import thành cơ chế riêng, một map trong HTML không tự biến output đó thành runtime loading.

Import maps không có cơ chế thương lượng version như federation share scope. Nếu nhiều phần cần cùng một dependency instance, bạn phải thiết kế URL resolution và build externals tương ứng; trỏ tên về cùng URL không sửa được incompatibility giữa các consumer. Browser support, CORS, MIME type và CSP vẫn cần được kiểm tra theo môi trường triển khai.

Web Components công khai giao diện DOMCopy Anchor Link

Web Components cho phép công khai UI bằng custom element, chẳng hạn <shop-product-card>. Shell làm việc với attributes, properties, methods và DOM events thay vì phải hiểu component API của framework bên trong.

Custom element là giao diện tích hợp; Shadow DOM là cơ chế encapsulation có thể dùng bên trong nó. Hai thứ không đồng nghĩa: một custom element không bắt buộc có shadow root, và chỉ đăng ký tag không làm CSS được cô lập.

Mình cân nhắc hướng này khi một vùng UI cần được nhúng vào các shell khác stack, hoặc cần public contract không bám vào React/Vue component API. Với các phần đều dùng cùng framework và cần Context/router chung sâu, wrapper có thể tạo thêm adapter mà không đem lại lợi ích tương xứng.

Shadow DOM hạn chế selector CSS xuyên boundary và encapsulate DOM nội bộ, nhưng vẫn có các đường thiết kế như inherited properties, CSS custom properties, slots và parts. Overlay portal ra document.body có thể rời boundary đó. Quan trọng hơn, code của element vẫn là JavaScript chạy trong trang: Shadow DOM không phải security sandbox.

iframe tạo document riêngCopy Anchor Link

iframe nhúng một document với browsing context riêng. Cart legacy có thể tiếp tục chạy như một ứng dụng tương đối nguyên vẹn, thay vì phải chuyển ngay sang API mount/unmount của shell.

CSS của hai document không tự áp dụng chéo như khi dùng chung DOM. Với iframe khác origin, same-origin policy hạn chế truy cập trực tiếp giữa hai phía; sandbox và Permissions Policy bổ sung các giới hạn theo nhu cầu. Đó là một hướng cần đánh giá khi trust boundary quan trọng hơn khả năng dùng chung component tree.

Đổi lại, bạn phải thiết kế message protocol, resize, navigation, focus, accessibility và session flow. Modal trong frame không tự trở thành modal toàn trang; đăng nhập dựa vào cookies/storage có thể chịu chính sách browser trong ngữ cảnh nhúng. Mình không chọn iframe mặc định cho các vùng UI tin cậy cần tương tác sát nhau, trừ khi lợi ích isolation hoặc migration đủ rõ.

Các cơ chế có thể kết hợp như thế nàoCopy Anchor Link

Điểm dễ nhầm nhất là nghĩ phải chọn giữa single-spa và import maps. Một tổ hợp hoàn toàn hợp lý là:

direction: right
n0: "Import map: @shop/catalog → URL\nrelease"
n1: "single-spa: route, load, mount,\nunmount"
n2: "Catalog: render và cleanup trong\ncontainer"
n0 -> n1 -> n2

Trong tổ hợp này, import map giúp browser resolve module, single-spa điều phối khi nào app xuất hiện, còn app chịu trách nhiệm implementation lifecycle. Không thành phần nào tự tạo CSS isolation.

Một tổ hợp khác là native ESM tải bundle đăng ký custom element, shell tạo element rồi truyền properties. Shadow DOM có thể giữ CSS nội bộ, còn shell vẫn phải quản lý loading, lỗi đăng ký và fallback. Bạn không bắt buộc thêm single-spa nếu đây chỉ là một vùng UI với lifecycle dễ quản lý.

Module Federation cũng có thể cung cấp module lifecycle cho single-spa hoặc bundle triển khai một custom element. Ngược lại, iframe không cần federation để nhúng document. Vấn đề không phải “stack nào nhiều công cụ hơn”, mà là mỗi công cụ có giải quyết một trách nhiệm còn thiếu hay đang làm trùng trách nhiệm với công cụ khác?

Đừng tạo hai owner cho cùng vùng DOM hoặc cùng bước mount. Nếu adapter tạo element và element tự mount framework root, orchestrator chỉ nên quản lý adapter theo contract đã thống nhất, không mount lại framework đó từ bên ngoài.

Chọn hướng theo tình huốngCopy Anchor Link

Bảng này là điểm xuất phát cho thử nghiệm, không phải xếp hạng công cụ. Một hệ thống có thể dùng các hướng khác nhau cho những boundary khác nhau.

Nếu đang phân vân, mình ưu tiên ranh giới nghiệp vụ đủ lớn và cơ chế đơn giản nhất đáp ứng yêu cầu thật. Ví dụ, không cần iframe chỉ để chống một selector CSS sai; nhưng cũng không dùng Shadow DOM làm biện pháp chạy script không tin cậy.

Yêu cầu SSR hoặc SEO cần được đánh giá riêng. Có một custom tag trong HTML không chứng minh nội dung đã SSR; tải module client-side không chứng minh server biết render remote. Hãy kiểm tra HTML trả về, hydration và ownership dữ liệu theo framework/pipeline thực tế.

Contract tối thiểu ở điểm ghépCopy Anchor Link

Chọn loader xong mới là biết lấy code ở đâu. Trước khi tích hợp, cần thống nhất điều shell có thể yêu cầu và điều app cam kết làm.

Lifecycle và quyền sở hữu DOMCopy Anchor Link

Với app cùng document, một contract có thể quy định: shell giao container, app mount trong container đó và trả lại cách cleanup. Ví dụ TypeScript dưới đây chỉ minh họa hình dạng public API, không phải API của single-spa hay implementation cho site Next.js:

type CartCommand = {
  sku: string;
  quantity: number;
};

type CatalogContext = {
  locale: string;
  navigate: (path: string) => void;
  addItem: (command: CartCommand) => Promise<void>;
};

export type MountedCatalog = {
  unmount: () => Promise<void>;
};

export type CatalogModule = {
  mount: (
    container: HTMLElement,
    context: CatalogContext,
  ) => Promise<MountedCatalog>;
};

Contract còn phải nói rõ những điều type signature không thể hiện: nếu mount thất bại giữa chừng, app phải cleanup phần đã tạo; nếu người dùng rời route khi mount còn pending, shell không được để kết quả muộn chiếm lại outlet. Listeners ngoài container, timers, subscriptions và framework roots cũng cần dọn, không chỉ xóa HTML.

Với single-spa, chuyển các trách nhiệm này vào lifecycle của ứng dụng. Với Web Components, gắn chúng vào lifecycle kết nối/ngắt kết nối, có tính đến reconnect. Với iframe, parent quản lý phần tử frame và các listener giao tiếp phía parent; hai document trao đổi qua protocol thay vì truyền function như ví dụ trên.

Giao tiếp và quyền sở hữu stateCopy Anchor Link

Catalog cần yêu cầu thêm sản phẩm, không cần quyền sửa trực tiếp store của cart. addItem là command; cart owner xử lý thao tác và backend xác nhận dữ liệu hợp lệ. Badge của shell nên đọc snapshot hoặc subscription từ cart owner, không tự tăng số lượng chỉ vì một nút catalog đã được bấm.

Command và notification có ý nghĩa khác nhau. “Hãy thêm SKU này” không phải “SKU này đã được thêm thành công”. Nếu lẫn hai loại, shell có thể hiển thị giỏ hàng đã đổi dù request thất bại.

Với iframe, message payload phải là dữ liệu có thể truyền qua structured clone, không phải callback hoặc React Context. Receiver cần kiểm tra sender, schema và quyền thực hiện command. Trong thiết kế dùng origin cụ thể, kiểm tra event.origin, event.source và dùng targetOrigin cụ thể khi gửi; sandbox tạo opaque origin cần một thiết kế channel riêng, không chỉ bỏ kiểm tra origin cho tiện.

TypeScript giúp kiểm tra consumer khi build, nhưng không validation message từ document khác hoặc artifact được release sau đó. Public contract cần runtime validation ở boundary thích hợp, version policy và tests cho những tổ hợp version còn được hỗ trợ.

Release độc lập cần nhiều hơn một loaderCopy Anchor Link

Shell tải code lúc chạy chưa chứng minh catalog có thể release riêng. Nếu mỗi thay đổi URL vẫn buộc shell sửa source, build và deploy lại, bạn chưa đạt mục tiêu không rebuild shell cho thay đổi tương thích của catalog.

Một đường release có kiểm soát thường cần:

1. Publish artifact mới và toàn bộ assets liên quan trước khi chọn nó cho người dùng.
2. Kiểm thử contract với consumer đang được hỗ trợ, không chỉ test catalog riêng lẻ.
3. Cập nhật mapping, manifest hoặc cấu hình route để chọn release đã kiểm chứng.
4. Ghi nhận release identity để phân biệt lỗi của artifact với lỗi tải hoặc tích hợp.
5. Giữ artifact cũ và cách chọn lại nó nếu vẫn tương thích với backend và dữ liệu hiện tại.

Cấu hình chọn release có thể nằm trong HTML import map, runtime manifest, root config hoặc route policy. Đường cập nhật đó phải có owner và cơ chế rollout; không nên biến việc thay một entry thành hàng chờ thủ công mới cho mọi team.

Những giới hạn cần kiểm chứngCopy Anchor Link

Đừng lấy việc “UI render được” làm bằng chứng toàn bộ boundary hoạt động. Một lần chuyển route, một request thất bại hoặc một tab cũ đủ để lộ những phụ thuộc mà happy path không cho thấy.

Không suy ra iframe sẵn sàng chỉ từ event load; cần tín hiệu readiness của ứng dụng nếu shell phụ thuộc vào nó. Cũng không suy ra unmount đã hủy network request hoặc rollback command; việc ngừng hiển thị và kết quả nghiệp vụ là hai chuyện khác nhau.

Với JavaScript cùng document, một error boundary hoặc try/catch chỉ xử lý được một số loại lỗi. Chúng không cô lập vòng lặp chặn main thread hay code tùy tiện sửa global state. Chọn cách giới hạn ảnh hưởng phải dựa vào loại lỗi cần ngăn, không chỉ dựa vào tên framework.

Lộ trình đọc trong nhómCopy Anchor Link

Bạn không cần đọc tất cả theo thứ tự nếu đã biết boundary cần giải quyết. Với người mới, mình đọc về module loading trước, rồi lifecycle, UI contract và isolation.

Đây là bản đồ nội dung của nhóm; một số trang liên kết có thể còn là trang khung. Trang tổng quan này không thay thế hướng dẫn implementation hay khẳng định mọi bài đã có lab hoàn chỉnh.

Bài tập chọn một boundaryCopy Anchor Link

Giả sử catalog muốn thêm bộ lọc thương hiệu trong khi shell và cart giữ nguyên artifact. Hãy viết một bản quyết định ngắn trước khi cài thêm thư viện:

Đây là một lựa chọn minh họa, không phải stack mặc định cho mọi shop. Nếu full navigation chấp nhận được, hãy thử route-level integration đơn giản hơn. Nếu yêu cầu chính là nhúng product card vào nhiều shell, thay điểm xuất phát bằng Web Components; nếu code không tin cậy, hãy xem lại trust boundary trước khi quyết định dùng chung document.

Sau đó kiểm chứng bốn ca: release catalog tương thích mà shell/cart không rebuild, chặn URL catalog để quan sát fallback, chuyển route khi catalog còn đang tải, và mount/unmount lặp lại để phát hiện side effect còn sót. Thêm một lượt với tab mở từ release cũ để kiểm tra chính sách version thực tế.

Checklist trước khi chốt cách tích hợpCopy Anchor Link

• Bạn đã nêu một thay đổi cần release riêng và lý do modular frontend chưa đủ.
• Điểm ghép là route, vùng UI hoặc document, với owner cụ thể.
• Loading, lifecycle, communication và isolation không bị giao trùng hoặc bỏ trống.
• Public contract không phụ thuộc DOM, router hoặc store nội bộ của app khác.
• Loading có deadline, fallback và cách xử lý kết quả muộn sau navigation.
• Cleanup đã được kiểm thử cho mount lỗi, unmount và reconnect nếu có.
• CSS, overlays, accessibility và auth được thử trên browser mục tiêu.
• Release selection, compatibility, rollback và tab cũ có policy rõ ràng.
• Log giúp nhận diện app, release và phase lỗi mà không lộ dữ liệu nhạy cảm.

Bước tiếp theo là chọn một boundary trong bảng quyết định, đọc bài tương ứng rồi kiểm chứng nó trong project thử nghiệm riêng. Chỉ thêm cơ chế thứ hai khi bạn chỉ ra được trách nhiệm mà cơ chế đầu tiên chưa giải quyết.

Đọc tiếpCopy Anchor Link

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

• single-spa — Getting Started: root config, application registration và lifecycle.
• MDN — Import maps: module specifier resolution và phạm vi áp dụng của map.
• MDN — Using custom elements: registration và lifecycle của custom elements.
• MDN — Using Shadow DOM: DOM/CSS encapsulation và giới hạn bảo mật.
• MDN — iframe: browsing context, sandbox, same-origin access và hành vi load event.
• MDN — Window.postMessage: giao tiếp cross-origin và kiểm tra sender.