Tổng hợp 22 câu hỏi phỏng vấn Micro-frontend kèm đáp án chi tiết, song ngữ Việt–Anh — sắp xếp từ cơ bản đến nâng cao. Ôn luyện miễn phí, tự động lưu tiến độ.
Đây là câu hỏi kinh nghiệm — người phỏng vấn muốn biết bạn đã làm thật hay chỉ đọc lý thuyết, nên trả lời theo trải nghiệm thật và có cấu trúc. Nếu công ty bạn có dùng: kể theo mạch — (1) bối cảnh:…
Micro-frontend là kiến trúc chia giao diện thành nhiều ứng dụng frontend độc lập, mỗi ứng dụng do một team sở hữu trọn vẹn (từ code tới deploy), rồi tích hợp lại thành một sản phẩm. Nó áp ý tưởng microservices lên phía frontend. Ví…
Monolith frontend là một codebase và một lần deploy duy nhất cho toàn bộ UI; micro-frontend là nhiều app deploy độc lập, chia theo team. Lợi ích chính của micro-frontend: team tự chủ, deploy độc lập (không phải release đồng bộ), mở rộng được khi…
Chia làm hai nhóm. Build-time: mỗi micro-frontend publish thành package, app container cài vào như thư viện — đơn giản nhưng container phải rebuild và redeploy mỗi khi một mảnh thay đổi, nên mất tính độc lập. Run-time (được ưa dùng hơn): container nạp các…
Module Federation là tính năng của Webpack 5 cho phép một app (host) nạp code từ app khác (remote) ngay lúc runtime, kèm cơ chế chia sẻ dependency — đây là nền tảng phổ biến nhất để dựng micro-frontend hiện nay. Remote khai báo những…
single-spa là một framework điều phối (orchestrator): một root-config đăng ký các micro-frontend và quyết định mảnh nào active theo route hiện tại, còn mỗi micro-frontend export các lifecycle bootstrap / mount / unmount để root-config gọi khi vào/rời route. Nhờ vậy bạn có thể…
Nguyên tắc: ưu tiên coupling lỏng. Ba cách thường dùng: (1) gửi sự kiện/message — browser CustomEvent hoặc một event bus (pub/sub) nhỏ, các mảnh không gọi thẳng nhau; (2) shell truyền props và callback xuống từng micro-frontend (contract rõ ràng nhất); (3) đồng bộ…
Mô hình thường gặp: shell/container giữ routing cấp cao — quyết định path nào thì kích hoạt micro-frontend nào — còn mỗi micro-frontend tự quản các sub-route bên trong nó. Ví dụ shell map /checkout/ cho app Checkout, rồi bên trong app Checkout có route…
Vì CSS mặc định là global, style của một mảnh dễ rò rỉ và ghi đè mảnh khác ngoài ý muốn. Các cách tách biệt: đặt tiền tố/quy ước BEM cho class, dùng CSS Modules (hash tên class), CSS-in-JS (scope theo component), hoặc Shadow DOM…
Đổi lấy team autonomy, micro-frontend kéo theo nhiều chi phí: payload lớn hơn vì duplicate dependency (mỗi mảnh có thể mang theo bản thư viện riêng nếu không chia sẻ tốt); độ phức tạp vận hành tăng (nhiều pipeline CI/CD, nhiều artifact, nhiều môi trường);…
iframe cô lập triệt để nhất — CSS và JavaScript của mỗi mảnh tách biệt hoàn toàn, không xung đột với nhau — và dễ nhúng app cũ hoặc app khác stack. Nhưng đổi lại UX kém: routing và deep-link khó đồng bộ, chia sẻ…
Mỗi micro-frontend được đóng gói thành một custom element (ví dụ <team-cart), shell chỉ cần đặt thẻ đó vào DOM là xong — đây là cách chuẩn hoá interface giữa các framework khác nhau. Custom Elements cộng Shadow DOM tự động tách biệt style, và…
Hai thứ giải quyết hai vấn đề khác nhau và bổ trợ nhau, không loại trừ nhau. Module Federation lo việc NẠP và CHIA SẺ code lúc runtime (qua webpack/rspack) — host nạp module từ remote và dùng chung dependency. single-spa lo việc ĐIỀU PHỐI…
Test theo tầng đúng với tinh thần độc lập: mỗi micro-frontend tự chạy unit và integration test như một app bình thường; phần khó là chỗ tích hợp, nên thêm contract test cho phần giao tiếp giữa các mảnh (event/props) và một ít end-to-end cho…
Tóm tắt: đổi "tốc độ tổ chức" lấy "độ phức tạp kỹ thuật". Ưu điểm: (1) team tự chủ — mỗi team sở hữu một mảnh từ đầu đến cuối; (2) deploy độc lập — release riêng, không chờ nhau; (3) mở rộng được khi…
Chia làm hai nhóm, cộng thêm tooling cho monorepo. Thư viện tích hợp: - Module Federation (webpack 5, có bản cho Rspack/Vite): nạp và chia sẻ code lúc runtime — phổ biến nhất hiện nay. - single-spa: orchestrator điều phối và quản vòng đời app…
