Mã dự phòng được gửi xuống đường ống với Micro-frontends

Sự hiểu biết của tôi về Micro-frontends là vấn đề chính mà họ giải quyết là trong việc giúp các doanh nghiệp có nhiều nhóm khác nhau, có thể làm việc trên các thành phần / ứng dụng nhỏ sẽ được sử dụng để soạn một ứng dụng web lớn.

Ở đây, vấn đề chính đang được giải quyết là khả năng của nhiều nhóm làm việc độc lập và vẫn có thể xây dựng một tổ hợp lớn. Vấn đề KHÔNG phải là có một gói phát hành nạc cho người dùng cuối . Sự hiểu biết đó có đúng không?

Có đúng là nếu chúng ta có nhiều ứng dụng nhỏ được sử dụng để soạn một ứng dụng web lớn, chúng ta có khả năng có nhiều ứng dụng nhỏ chuyển cùng thư viện Javascript ( như Lodash ) xuống các trình duyệt của người dùng cuối như một phần của trình duyệt gói nhà cung cấp riêng lẻ dẫn đến một số lượng mã trùng lặp / dự phòng được gửi xuống cho người dùng?

Đây không phải là một mối quan tâm chúng ta nên lo lắng trong khi kiến ​​trúc ứng dụng front-end?

Bạn hoàn toàn chính xác rằng có một sự đánh đổi liên quan ở đây: bạn đang giao dịch ở một số khía cạnh của trải nghiệm người dùng để có trải nghiệm tốt hơn cho nhà phát triển (điều này có thể cải thiện trải nghiệm người dùng theo những cách khác nhau). Điều này có đáng không? Nó phụ thuộc.

Ví dụ, tôi nghĩ Spotify sử dụng phương pháp này để phân chia UI của họ thành các thành phần riêng biệt ( nguồn ). Mỗi widget sống trong một iframe và do đó có thể có một bộ thư viện riêng, v.v. Chúng có ràng buộc tổ chức duy nhất mà công việc được thực hiện bởi các đội tự trị (một nhóm chức năng chéo). Điều này làm cho việc đồng ý về các tiêu chuẩn toàn công ty trở nên khó khăn hơn và sau đó thay đổi các tiêu chuẩn này. Vì vậy, đối với họ, micro-frontend giúp duy trì sự linh hoạt. Nhưng nếu không có cách tiếp cận này, có lẽ ứng dụng máy tính để bàn của họ sẽ ít hơn một bộ nhớ.

Bộ nhớ đệm HTTP sẽ không giúp được gì nhiều: mỗi micro-frontend có thể sử dụng các phiên bản khung khác nhau . Ngoài ra, chi phí sao chép không chỉ là truyền dữ liệu, mà là chi phí phía máy khách của (biên dịch lại) các thư viện và lưu trữ các cấu trúc dữ liệu trùng lặp.

Cá nhân, tôi nghĩ rằng các mặt trận vi mô như vậy có thể là một kiến ​​trúc hợp lệ nhưng có lẽ không thể truy cập được trừ khi

• bạn là một tổ chức rất lớn với các nhóm tự chủ cao, tất cả đều hoạt động trên giao diện người dùng và cần thực hiện các bản phát hành rất thường xuyên (ví dụ: hàng ngày) và
• ngân sách hiệu suất UX của bạn có chỗ cho sự trùng lặp này hoặc sản phẩm của bạn tốt đến mức UX không thành vấn đề. Lưu ý rằng hiệu suất nên được kiểm tra trên các thiết bị cấp thấp, không phải trên máy phát triển của bạn.

Nếu tổ chức của bạn không lớn hoặc nếu các nhóm của bạn chuyên sâu hơn một chút, mọi người có thể tham gia (quản lý, nhà phát triển và cuối cùng là người dùng) có thể có một quy trình xây dựng và triển khai chung để tránh trùng lặp không cần thiết. Ví dụ: nếu bạn chỉ có 4 nhóm làm việc trên UI, họ có thể có thể nói chuyện với nhau để thống nhất một bộ thư viện chung và cách tích hợp công việc của họ vào một kiến ​​trúc gắn kết.

Mặt trận vi mô dường như là một trong những điều thực sự tuyệt vời nhưng bạn không thực sự cần cho đến khi bạn hoạt động ở quy mô.