Nền tảng

Giả sử team catalog đã làm xong bộ lọc sản phẩm, nhưng chưa thể đưa lên production vì phải chờ team cart hoàn tất thay đổi giỏ hàng trong cùng một bản release. Bạn đã chia code thành component và folder riêng; việc phát hành vẫn bị buộc vào nhau. Đây là loại vấn đề cần xem xét trước khi hỏi “cấu hình Module Federation thế nào?”.

Nhóm Nền tảng giúp bạn phân biệt vấn đề tổ chức code với vấn đề phát hành, hiểu cái giá của việc tách frontend và chọn một điểm bắt đầu phù hợp. Mình khuyên bạn bắt đầu bằng một frontend có module nghiệp vụ rõ ràng; chỉ thêm ranh giới deploy khi có nhu cầu cụ thể để kiểm chứng.

Mục lụcCopy Anchor Link

• Bắt đầu từ điểm nghẽn thực tế
• Mô hình shop để cùng hình dung
• Lợi ích luôn đi cùng chi phí
• Những điều không nên đánh đồng
• Lộ trình đọc trong nhóm
• Kiến thức cần chuẩn bị
• Bài tập trước khi chọn công cụ
  • Viết giả thuyết cho một ranh giới
  • Tự kiểm tra trước khi đi tiếp
• Bước tiếp theo
• Tài liệu tham khảo

Bắt đầu từ điểm nghẽn thực tếCopy Anchor Link

“Frontend lớn quá” chưa cho bạn biết cần thay đổi kiến trúc ở đâu. Một component khó đọc, một pipeline chậm và một team phải chờ release của team khác là ba vấn đề khác nhau. Nếu dùng cùng một giải pháp cho cả ba, bạn có thể chỉ chuyển sự phức tạp từ source code sang runtime và vận hành.

Modular frontend tổ chức code thành các module có ranh giới rõ, nhưng vẫn có thể build và deploy như một đơn vị. Micro-frontend đi thêm một bước: các phần frontend có khả năng phát hành độc lập được ghép thành một trải nghiệm lớn hơn. Vì thế, tách module thường là bước có ích ngay cả khi cuối cùng bạn không chọn micro-frontend.

Câu hỏi đáng giữ trong suốt nhóm bài này là: thay đổi nào cần tới người dùng mà không buộc những phần không liên quan phải phát hành lại? Nếu chưa nêu được một thay đổi như vậy, mình chưa vội tạo remote.

Mô hình shop để cùng hình dungCopy Anchor Link

Trong shop minh họa, shell giữ khung trải nghiệm và ghép phần nội dung theo URL. Catalog phụ trách tìm, lọc và xem sản phẩm; cart phụ trách trải nghiệm giỏ hàng.

direction: down
shop: "Shop: một trải nghiệm"
shell: "Shell: layout, navigation,\ncomposition"
catalog: "Catalog: tìm, lọc, xem sản phẩm"
cart: "Cart: xem và cập nhật giỏ hàng"
shop -> shell
shell -> catalog
shell -> cart

Đây là sơ đồ trách nhiệm, không phải cấu trúc folder hay yêu cầu rằng cả hai phần luôn xuất hiện cùng lúc. Shell có thể chọn catalog ở /products và cart ở /cart; cách ghép cụ thể sẽ được học ở nhóm Kiến trúc.

Giả sử catalog thêm một cách sắp xếp sản phẩm mà không đổi giao diện tích hợp. Mục tiêu là team catalog có thể kiểm thử, phát hành và theo dõi thay đổi đó trong khi artifact của shell và cart giữ nguyên. Shell có thể cần cập nhật cấu hình chọn phiên bản catalog; điều đó không nhất thiết yêu cầu build lại shell, nhưng đường cập nhật phải có kiểm soát và không trở thành một hàng chờ thủ công mới.

Vậy catalog và cart có hoàn toàn độc lập không? Không. Luồng “xem sản phẩm → thêm vào giỏ → mở cart” vẫn đi qua nhiều ranh giới, nên cần contract: thỏa thuận về giao diện, dữ liệu và hành vi mà các bên sử dụng. Thay đổi contract có thể cần phối hợp; mục tiêu là giảm phối hợp bắt buộc cho thay đổi nội bộ, không phải loại bỏ mọi trao đổi giữa các team.

Backend vẫn phải kiểm tra quyền, giá, tồn kho và thao tác cập nhật giỏ. Tách frontend không biến UI thành nơi có thể tự quyết các quy tắc đó, cũng không bắt buộc mỗi phần frontend phải có một microservice riêng.

Lợi ích luôn đi cùng chi phíCopy Anchor Link

Bạn không chỉ tách một bundle. Bạn tạo thêm các ranh giới cần duy trì qua nhiều phiên bản, nhiều lần release và nhiều tình huống lỗi.

Chi phí không chỉ nằm trong pipeline. Nếu các phần tải riêng khi chạy, bạn cần xử lý lỗi tải code và trạng thái chờ. Khi nhiều artifact cùng tồn tại, cần biết người dùng đang chạy tổ hợp phiên bản nào; khi dùng chung trang, CSS, dependency và main thread vẫn có thể gây ảnh hưởng chéo.

Ngoài kiểm thử từng phần, bạn vẫn cần kiểm chứng contract và những luồng người dùng quan trọng xuyên ứng dụng. Catalog render đúng và cart render đúng không đủ chứng minh nút “Thêm vào giỏ” hoạt động đúng khi ghép chúng lại.

Bài Khi nào nên và không nên dùng? sẽ đi sâu vào cách cân nhắc những chi phí này. Ở đây, bạn chỉ cần nhớ: lợi ích cần gắn với một hành vi có thể kiểm chứng, không phải số lượng repository hay công cụ đã cài.

Những điều không nên đánh đồngCopy Anchor Link

Có vài dấu hiệu nhìn giống micro-frontend nhưng không đủ để kết luận hệ thống đã có ranh giới phát hành tốt:

• Component riêng không đồng nghĩa với đơn vị deploy riêng. Nó có thể vẫn thuộc cùng một bản build và release.
• Lazy loading không đồng nghĩa với deploy độc lập. Một chunk được tải muộn vẫn có thể được tạo và phát hành cùng shell.
• Nhiều repo hoặc nhiều pipeline không chứng minh tính độc lập. Nếu version phải tăng đồng bộ, các phần vẫn ràng buộc ở khâu tích hợp.
• Micro-frontend không đồng nghĩa với Module Federation. Federation là một cách cung cấp và tiêu thụ module giữa các build, không phải toàn bộ kiến trúc.
• Shell không luôn đồng nghĩa với host. Shell là vai trò điều phối trải nghiệm; host và remote là vai trò tích hợp, thường được dùng trong ngữ cảnh federation.
• Một team không bắt buộc tương ứng với một remote. Ranh giới nên bám vào phạm vi nghiệp vụ và nhu cầu thay đổi, không bám máy móc vào sơ đồ tổ chức.

Bạn cũng không cần nhiều framework để áp dụng micro-frontend. Mặc định, mình giữ stack quen thuộc và nhất quán để giảm chi phí tooling, dependency và hỗ trợ vận hành; chỉ thêm khác biệt khi có lý do rõ, chẳng hạn migration từng phần từ ứng dụng cũ.

Khi gặp tên gọi mới, dùng Thuật ngữ cốt lõi để tra nghĩa và giới hạn của nó. Đừng suy ra khả năng cách ly hoặc phát hành chỉ từ chữ remote trong cấu hình.

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

Nếu mới bắt đầu, bạn có thể đi theo thứ tự dưới đây. Mỗi bài trả lời một câu hỏi khác nhau; trang tổng quan này không thay thế các phần giải thích chi tiết đó.

Thứ tự này không phải điều kiện cứng. Nếu còn yếu về modules, HTTP hoặc lifecycle, hãy đọc Kiến thức cần có sớm hơn. Nếu đang đánh giá một dự án thật và đã quen mô hình, bắt đầu từ Khi nào nên và không nên dùng?, rồi đọc Team ownership để kiểm tra nhu cầu kỹ thuật có khớp với khả năng tổ chức hay không.

Kiến thức cần chuẩn bịCopy Anchor Link

Để đọc nhóm Nền tảng, bạn chưa cần thuộc cấu hình bundler. Nhưng trước khi chuyển sang thực hành tích hợp, nên tự giải thích được những việc sau:

• import/export nối module như thế nào; import() trả về Promise và có thể thất bại ra sao.
• Build tạo artifact JavaScript/CSS nào, và trình duyệt tải chúng từ URL nào.
• HTTP status, origin, CORS và cache ảnh hưởng thế nào đến việc tải code hoặc gọi API.
• Component hoặc ứng dụng được mount, unmount và cleanup ra sao; CSS và side effect có thể vượt ranh giới như thế nào.
• TypeScript kiểm tra code trước khi chạy, nhưng không tự validation dữ liệu hoặc contract của artifact khác version tại runtime.

Bạn chỉ cần một framework quen thuộc để bắt đầu. Kubernetes, nhiều framework hay kinh nghiệm microservices không phải điều kiện tiên quyết; hiểu DevTools, request mạng và lifecycle thường giúp bạn tiến nhanh hơn việc học thêm công cụ ở giai đoạn này.

Bài Kiến thức cần có có ví dụ và checklist để bạn ôn đúng chỗ, thay vì học toàn bộ toolchain trước khi thử một ranh giới nhỏ.

Bài tập trước khi chọn công cụCopy Anchor Link

Viết giả thuyết cho một ranh giớiCopy Anchor Link

Chọn một thay đổi nội bộ trong shop, chẳng hạn thêm cách sắp xếp sản phẩm. Chưa viết cấu hình federation; trước hết, thử ghi một bản đề xuất ngắn:

Đây là giả thuyết để thử nghiệm, không phải khẳng định shop trong repository đã có những năng lực đó. Khi triển khai, bạn cần kiểm chứng cả cách chọn version, compatibility, tín hiệu lỗi và phương án khôi phục.

Nếu bản đề xuất cho thấy hầu hết thay đổi catalog vẫn cần sửa cart và shell, hãy xem lại ranh giới trước khi chọn công cụ. Nếu lý do chờ là một chính sách phê duyệt chung, tách artifact có thể bỏ phụ thuộc kỹ thuật nhưng không tự bỏ được thời gian chờ tổ chức.

Tự kiểm tra trước khi đi tiếpCopy Anchor Link

• Bạn mô tả được điểm nghẽn bằng một tình huống cụ thể, không chỉ nói “frontend lớn”.
• Bạn phân biệt được tách component, tách module và tách đơn vị deploy.
• Bạn nêu được một thay đổi tương thích có thể phát hành riêng và một thay đổi contract cần phối hợp.
• Bạn xác định được owner của phần muốn tách và đầu mối cho luồng người dùng xuyên ứng dụng.
• Bạn biết những contract nào cần giữ ổn định và những chi phí mới nào cần kiểm chứng.
• Bạn đã cân nhắc một modular frontend đơn giản hơn, thay vì mặc định phải có nhiều remote.

Nếu chưa trả lời được các câu trên, hãy quay lại bài tương ứng trong lộ trình. Một bản build host/remote chạy thành công không thay thế được các quyết định này.

Bước tiếp theoCopy Anchor Link

Nếu mới đến trang này, bắt đầu bằng Micro-frontend là gì?. Khi đã đọc các bài Nền tảng và viết được giả thuyết cho một ranh giới, bạn có thể sang nhóm Bắt đầu để chuẩn bị ví dụ nhỏ, hoặc nhóm Kiến trúc để xem cách chia domain và composition.

Các nhóm phía sau có thể còn trang khung; liên kết dưới đây chỉ hướng đọc tiếp, không khẳng định đã có lab chạy được.

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, autonomous teams và các đánh đổi về tích hợp, dependency và vận hành.