Tham gia hành trình chuyển đổi Micro-frontend - Phần 1: Thiết kế

Trong thế giới kỹ thuật số có nhịp độ nhanh ngày nay, nơi tính linh hoạt và khả năng mở rộng là rất quan trọng, các doanh nghiệp không ngừng tìm cách cải thiện hiệu suất và khả năng bảo trì của các ứng dụng web của họ.

Một cách tiếp cận phổ biến để đạt được những mục tiêu này là chuyển từ kiến trúc nguyên khối sang kiến trúc phân tán (hoặc vi giao diện người dùng). Chuỗi bài viết này, "Hành trình di chuyển micro-frontend", chia sẻ kinh nghiệm cá nhân của tôi khi thực hiện quá trình di chuyển như vậy trong thời gian làm việc tại AWS.

TUYÊN BỐ TUYÊN BỐ TRÁCH NHIỆM : Trước khi bắt đầu, điều quan trọng cần lưu ý là mặc dù bài viết này chia sẻ trải nghiệm cá nhân của tôi nhưng tôi không thể tiết lộ bất kỳ chi tiết nội bộ hoặc sở hữu độc quyền nào về các công cụ, công nghệ hoặc quy trình cụ thể tại AWS hoặc bất kỳ tổ chức nào khác.

Tôi cam kết tôn trọng các nghĩa vụ pháp lý và đảm bảo rằng bài viết này chỉ tập trung vào các khái niệm và chiến lược chung liên quan đến hành trình di chuyển giao diện người dùng vi mô.

Mục đích là để cung cấp thông tin chi tiết và bài học kinh nghiệm có thể áp dụng trong bối cảnh rộng hơn mà không tiết lộ bất kỳ thông tin bí mật nào.

Động cơ di cư

Tôi đã tìm hiểu về giao diện người dùng vi mô (tôi đoán là nhiều người trong số các bạn) từ bài viết trên blog của Martin Fowler. Nó trình bày các cách khác nhau để soạn kiến trúc giao diện người dùng vi mô theo cách không thể tin được vào khung.

Khi tìm hiểu sâu hơn về chủ đề này, tôi nhận ra rằng kiến trúc nguyên khối hiện tại của chúng tôi đang trở thành nút cổ chai đáng kể đối với năng suất của nhóm chúng tôi và cản trở hiệu suất tổng thể của ứng dụng của chúng tôi.

Một trong những yếu tố chính thúc đẩy tôi cân nhắc di chuyển là kích thước gói ngày càng tăng của ứng dụng của chúng tôi.

Sau khi tiến hành phân tích gói kỹ lưỡng vào mùa hè năm 2020, tôi phát hiện ra rằng kể từ lần ra mắt đầu tiên vào đầu năm 2019, kích thước gói (gzipped) đã tăng từ 450 KB lên 800 KB (gần 4 MB được phân tích cú pháp) - gần gấp đôi kích thước ban đầu.

Xem xét sự thành công của dịch vụ của chúng tôi và dự đoán sự tăng trưởng liên tục của nó, rõ ràng là xu hướng này sẽ tiếp tục ảnh hưởng đến hiệu suất và khả năng bảo trì của ứng dụng của chúng tôi.

Mặc dù rất hào hứng với khái niệm giao diện vi mô, nhưng tôi cũng nhận ra rằng chúng tôi chưa sẵn sàng áp dụng chúng do những thách thức cụ thể mà chúng tôi gặp phải:

1. Cơ cấu tổ chức nhỏ: Vào thời điểm tôi phân tích, tổ chức của chúng tôi tương đối nhỏ và tôi là kỹ sư giao diện người dùng toàn thời gian duy nhất trong nhóm. Việc di chuyển sang kiến trúc giao diện người dùng vi mô cần một khoản đầu tư đáng kể về cơ cấu tổ chức và nền tảng hoạt động.

   
   

   Điều quan trọng là phải có một cấu trúc trưởng thành có thể xử lý hiệu quả kiến trúc phân tán và phản ánh sự phụ thuộc giữa các thành phần giao diện người dùng khác nhau.

   
   

2. Miền kinh doanh hạn chế: Mặc dù giao diện người dùng vi mô có thể được phân chia dựa trên bối cảnh giới hạn và khả năng kinh doanh (tìm hiểu thêm trong bài đăng “ Thiết kế theo hướng miền trong kiến trúc giao diện người dùng vi mô” ) miền kinh doanh cốt lõi của chúng tôi không đủ rộng để biện minh cho việc tách hoàn toàn thành nhiều giao diện vi mô. Tuy nhiên, có những ranh giới có thể nhìn thấy được trong ứng dụng nên cần phải khắc phục và chuyển đổi sang kiến trúc phân tán.

Xem xét các yếu tố này, tôi nhận ra rằng một cách tiếp cận dần dần là cần thiết. Thay vì di chuyển hoàn toàn sang giao diện người dùng vi mô, tôi nhằm mục đích xác định các khu vực cụ thể trong ứng dụng của chúng tôi có thể hưởng lợi từ kiến trúc phân tán.

Điều này sẽ cho phép chúng tôi giải quyết các vấn đề về hiệu suất và khả năng mở rộng mà không làm gián đoạn cấu trúc tổ chức tổng thể hoặc ảnh hưởng đến tính toàn vẹn của miền kinh doanh của chúng tôi. Nó cũng sẽ cho chúng tôi một khoảng thời gian để phát triển nhóm và quan sát các hướng kinh doanh.

Xin lưu ý rằng nếu bạn chỉ muốn giải quyết vấn đề về hiệu suất (kích thước gói) của ứng dụng thông qua việc sử dụng kiến trúc mciro-frontend, thì đó có thể không phải là ý tưởng hay nhất. Thay vào đó, sẽ tốt hơn nếu bắt đầu với kiến trúc nguyên khối phân tán sẽ tận dụng tải chậm (nhập động).

Hơn nữa, tôi nghĩ rằng nó sẽ xử lý các vấn đề về kích thước gói một cách nhẹ nhàng hơn so với kiến trúc giao diện người dùng vi mô vì kiến trúc giao diện người dùng vi mô rất có thể có một số mã được chia sẻ sẽ không được tách thành các khối của nhà cung cấp và nó sẽ được tích hợp vào gói ứng dụng ( đó là một trong những nhược điểm của kiến trúc phân tán như vậy — bạn cần phải đánh đổi giữa nội dung chia sẻ, thời điểm và cách thức chia sẻ).

Tuy nhiên, kiến trúc nguyên khối phân tán sẽ không mở rộng quy mô cũng như giao diện người dùng vi mô. Khi tổ chức của bạn phát triển nhanh chóng, nhóm của bạn cũng sẽ phát triển với tốc độ tương tự.

Sẽ có một nhu cầu thiết yếu là chia cơ sở mã thành các khu vực sở hữu khác nhau do các nhóm khác nhau kiểm soát.

Và mỗi nhóm sẽ cần có các chu kỳ phát hành riêng độc lập với các nhóm khác, mỗi nhóm sẽ đánh giá cao nếu cơ sở mã của họ hoàn toàn tập trung vào miền của họ và sẽ xây dựng nhanh (cách ly mã -> khả năng bảo trì tốt hơn/ít mã hơn để duy trì và build -> khả năng kiểm tra tốt hơn/ít kiểm tra hơn để duy trì và thực thi).

Bắt đầu

Để thu hút sự hỗ trợ từ ban lãnh đạo, tôi đã soạn thảo một tài liệu tầm nhìn kỹ thuật thuyết phục bao gồm phân tích hiệu suất toàn diện, bao gồm các số liệu quan trọng về web và phác thảo các giai đoạn khác nhau của quá trình di chuyển sang giao diện người dùng phân tán.

Một trong những giai đoạn trung gian của quá trình di chuyển này là thiết lập kiến trúc nguyên khối phân tán, trong đó nhiều mô-đun/tiện ích con có thể được phân phối không đồng bộ thông qua các kỹ thuật tải chậm trong khi tận dụng cơ sở hạ tầng dùng chung, chẳng hạn như bộ chứa S3 và CDN, giữa dịch vụ cốt lõi và tiện ích con .

Như tôi đã trình bày trong bài viết trước, ý tưởng chính của loại tài liệu này là mô tả tương lai mà bạn mong muốn sau khi các mục tiêu đã đạt được và các vấn đề lớn nhất được giải quyết. Nó không phải là về kế hoạch thực hiện!

Gần 1 năm sau, cuối cùng đã đến lúc thực hiện kế hoạch di chuyển micro-frontend của tôi. Với việc sắp mở rộng sang một miền mới và một nhóm lớn hơn theo ý của chúng tôi, chúng tôi đã được trang bị đầy đủ để thực hiện việc di chuyển.

Nó giống như một cơ hội vàng mà chúng tôi không thể bỏ lỡ.

Xét cho cùng, việc bị giới hạn trong kiến trúc nguyên khối có nghĩa là phải vật lộn vĩnh viễn với những hạn chế của nó.

Dòng thời gian hạn chế để mở rộng sang một miền mới đóng vai trò là chất xúc tác, thúc đẩy chúng tôi hướng tới việc xây dựng một kiến trúc có thể mở rộng và dễ bảo trì hơn ngay lập tức thay vì thực hiện các bước lặp lại ngắn và chậm!

Để thực hiện quá trình di chuyển và đồng thời xử lý công việc trong miền mới, chúng tôi đã chia các nhóm thành hai nhóm chuyên biệt. Tính năng hoạt động, có mức độ ưu tiên cao hơn, cần nhiều tài nguyên hơn và cần lặp lại với tốc độ nhanh hơn.

Để đảm bảo tính toàn vẹn và hiểu biết toàn diện về quy trình di chuyển, nên chỉ định một nhóm nhỏ chuyên trách chịu trách nhiệm cụ thể về việc xử lý quá trình di chuyển.

Tuy nhiên, chúng tôi không thể tiến hành công việc tính năng mà không đảm bảo trước rằng khái niệm giao diện người dùng vi mô sẽ chứng tỏ thành công.

Để giảm thiểu rủi ro và cung cấp một lộ trình rõ ràng, điều quan trọng là tạo ra một tài liệu thiết kế cấp thấp bao gồm các ước tính chính xác và đánh giá rủi ro kỹ lưỡng. Tài liệu này phục vụ như một kế hoạch chi tiết, vạch ra các bước cần thiết và cân nhắc cho việc di chuyển.

Cột mốc quan trọng trong quá trình này là sự phát triển của một bằng chứng về khái niệm sẽ chứng minh sự tích hợp thành công của tất cả các thành phần theo thiết kế.

Cột mốc quan trọng này, được đặt tên một cách khéo léo là “Điểm không thể quay lại”, nhằm mục đích xác thực tính khả thi và hiệu quả của kiến trúc giao diện người dùng vi mô.

Mặc dù tôi rất lạc quan về sự thành công của việc di chuyển, nhưng điều cần thiết là phải chuẩn bị cho các tình huống bất ngờ. Do đó, tôi nghĩ ra một Kế hoạch B, hoạt động như một chiến lược dự phòng trong trường hợp ý tưởng ban đầu không mang lại kết quả mong muốn.

Điều này bao gồm việc phân bổ thêm bảy ngày trong ước tính cụ thể để khiến tôi phải ôm gối khóc cộng thêm vài ngày để có một mục nhập mô-đun tính năng mới được kết nối với lõi thông qua quá trình tải chậm (bạn có nhớ nguyên khối được phân phối không?).

thiết kế

Khi thiết kế giao diện người dùng vi mô, nhìn chung có 3 cách tiếp cận bố cục, mỗi cách tập trung vào vị trí diễn ra quá trình phân giải ứng dụng thời gian chạy. Cái hay của những cách tiếp cận này là chúng không loại trừ lẫn nhau và có thể được kết hợp khi cần thiết.

Thành phần phía máy chủ

Ý tưởng cơ bản là tận dụng một máy chủ proxy ngược để phân chia các gói giao diện người dùng vi mô trên mỗi trang và thực hiện tải lại trang cứng dựa trên URL tuyến đường.

Ưu điểm:

• Đơn giản để thực hiện

Nhược điểm:

• Trạng thái chung sẽ không được đồng bộ hóa giữa các ứng dụng giao diện người dùng vi mô. Đây rõ ràng là một điểm không nên làm đối với chúng tôi vì chúng tôi đã thực hiện các hoạt động chạy nền lâu dài ở phía máy khách.

  
  

  Bạn có thể lập luận rằng chúng tôi có thể duy trì ảnh chụp nhanh "hàng đợi" của thao tác này vào bộ nhớ cục bộ và đọc từ nó sau khi tải lại cứng, nhưng vì lý do bảo mật, chúng tôi không thể triển khai điều này.

  
  

  Đây chỉ là một ví dụ về trạng thái toàn cầu, nhưng đây là một ví dụ khác về cách nó có thể trông như thế nào: trạng thái của bảng sidenav (mở rộng/thu gọn), thông báo bánh mì nướng, v.v.

• Việc làm mới khó khăn khi điều hướng qua các ứng dụng vi mô không thân thiện với khách hàng lắm. Có một cách để lưu vào bộ đệm HTML được chia sẻ bằng cách sử dụng nhân viên dịch vụ nhưng việc bảo trì sẽ phức tạp hơn.

• Chi phí vận hành và bảo trì bổ sung cho cơ sở hạ tầng: máy chủ proxy cho từng ứng dụng giao diện người dùng vi mô (điều này có thể tránh được nếu đọc trực tiếp từ CDN), cơ sở hạ tầng riêng biệt để triển khai các phụ thuộc (nhà cung cấp) chung được sử dụng lại bởi nhiều trang và đúng cách được lưu trữ bởi các trình duyệt.

Thành phần cạnh

Một cách tiếp cận khác đối với bố cục giao diện người dùng vi mô là bố cục bên cạnh, bao gồm việc kết hợp các giao diện người dùng vi mô ở lớp biên, chẳng hạn như CDN. Chẳng hạn, Amazon CloudFront hỗ trợ tích hợp Lambda@Edge , cho phép sử dụng CDN dùng chung để đọc và phân phát nội dung vi giao diện người dùng.

Ưu điểm:

• Ít phần cơ sở hạ tầng hơn để duy trì: không cần phải có máy chủ proxy, CDN riêng cho từng ứng dụng vi mô

• Mở rộng quy mô gần như vô hạn bằng cách sử dụng công nghệ không có máy chủ

• Độ trễ tốt hơn so với máy chủ proxy độc lập

Nhược điểm:

• Thời gian bắt đầu lạnh có thể trở thành một vấn đề

• Lambda@Edge không được hỗ trợ ở tất cả các khu vực AWS nếu bạn cần có cơ sở hạ tầng đa khu vực (tách biệt)

Thành phần phía khách hàng

Thành phần phía máy khách là một cách tiếp cận khác đối với kiến trúc giao diện người dùng vi mô sử dụng các kỹ thuật điều phối giao diện người dùng vi mô phía máy khách, được tách rời khỏi triển khai máy chủ.

Trình phát chính trong kiến trúc này là một ứng dụng chứa (vỏ) có các trách nhiệm sau:

• Giải quyết các mối quan tâm xuyên suốt: Ứng dụng vùng chứa xử lý bố cục ứng dụng tập trung, điều hướng trang web, chân trang và bảng trợ giúp. Việc tích hợp với các giao diện vi mô có mối quan tâm xuyên suốt xảy ra thông qua Xe buýt sự kiện, nơi các sự kiện tổng hợp được gửi và xử lý trong phạm vi cửa sổ toàn cầu.

• Điều phối giao diện người dùng vi mô: Ứng dụng bộ chứa xác định gói giao diện người dùng vi mô nào sẽ tải và thời điểm tải dựa trên yêu cầu của ứng dụng và tương tác của người dùng.

• Soạn các phụ thuộc toàn cầu: Ứng dụng vùng chứa tổng hợp tất cả các phụ thuộc toàn cầu, chẳng hạn như thư viện React, SDK và UI, đồng thời hiển thị chúng dưới dạng một gói riêng biệt (vendor.js) có thể được chia sẻ giữa các giao diện người dùng vi mô.

Ý tưởng chung là mỗi gói micro-frontend sẽ tạo ra 2 loại tệp nội dung:

• {hash}/index.js: Đây đóng vai trò là điểm vào cho ứng dụng giao diện người dùng vi mô, với hàm băm đại diện cho một mã định danh duy nhất cho toàn bộ bản dựng.

  
  

  Hàm băm hoạt động như một khóa tiền tố cho mỗi gói trong bộ chứa S3. Điều quan trọng cần lưu ý là có thể tồn tại nhiều điểm vào, nhưng hàm băm vẫn giữ nguyên cho tất cả chúng.

• manifest.json: Đây là tệp kê khai chứa đường dẫn đến tất cả các điểm nhập cho ứng dụng giao diện người dùng vi mô. Tệp này sẽ luôn nằm trong thư mục gốc của bộ chứa S3, vì vậy bộ chứa có thể dễ dàng phát hiện ra nó.

  
  

  Tôi khuyên bạn nên bật phiên bản của tệp này trong bộ chứa S3 để có thể quan sát các thay đổi tốt hơn. Nếu bạn đang sử dụng Webpack để xây dựng dự án của mình, tôi thực sự khuyên bạn nên sử dụng WebpackManifestPlugin để thực hiện tất cả các công việc nặng nhọc cho bạn.

Vùng chứa chỉ biết URL miền nguồn nội dung giao diện vi mô (nguồn gốc CDN) dựa trên giai đoạn và khu vực. Trong quá trình tải trang ban đầu, vùng chứa tải xuống tệp kê khai cho từng ứng dụng giao diện người dùng vi mô.

Tệp kê khai có kích thước rất nhỏ (~100 byte) để tránh ảnh hưởng đến thời gian tải trang và chia tỷ lệ tốt ngay cả khi tổng hợp nhiều giao diện người dùng vi mô trong một vùng chứa. Điều quan trọng là phải coi tệp kê khai là bất biến trong bộ lưu trữ bộ đệm của trình duyệt để ngăn bộ nhớ đệm tích cực.

Chọn đúng thư viện điều phối là thách thức lớn nhất trong thành phần này và sẽ được thảo luận trong chương sau.

Ưu điểm:

• Bất khả tri đối với việc triển khai máy chủ: Cách tiếp cận này có thể được triển khai mà không cần bất kỳ yêu cầu máy chủ cụ thể nào, mang lại sự linh hoạt trong công nghệ phụ trợ được sử dụng. Như trong hình trên, bạn thậm chí có thể không có bất kỳ máy chủ nào

• Duy trì trạng thái chung: Bằng cách sử dụng ứng dụng vùng chứa (shell), trạng thái chung có thể được duy trì khi chuyển đổi giữa các giao diện vi mô. Điều này đảm bảo trải nghiệm người dùng liền mạch và tránh mất ngữ cảnh trong quá trình chuyển đổi.

• Cách tiếp cận phi tập trung: Mỗi giao diện người dùng vi mô có thể quyết định độc lập dữ liệu nào sẽ gửi đến trình duyệt để tự khởi động. Ứng dụng vùng chứa chỉ đơn giản tuân theo một hợp đồng được xác định rõ ràng, cho phép tự chủ và mô đun hóa nhiều hơn.

• Thiết lập cục bộ đơn giản: Có thể dễ dàng điều chỉnh nguồn nội dung giữa URL sản xuất và URL cục bộ dựa trên nhu cầu phát triển. Tệp kê khai giúp ứng dụng vùng chứa khám phá và tải các giao diện vi mô cần thiết. Các nhà phát triển có thể tập trung vào việc chỉ chạy vùng chứa và các giao diện người dùng vi mô cụ thể mà họ đang làm việc.

Nhược điểm:

• Nhiều bước nhảy mạng hơn để tìm nạp tệp kê khai: Vì vùng chứa cần truy xuất tệp kê khai cho mỗi giao diện người dùng vi mô, nên có thể có các yêu cầu mạng bổ sung và độ trễ tiềm ẩn so với các phương pháp tổng hợp khác. Điều này có thể được giảm thiểu bằng cách tải trước tất cả tệp kê khai trong lần tải trang đầu tiên hoặc bằng cách giới thiệu một số kỹ thuật tải trước.

• Tuân thủ hợp đồng chung: Mọi giao diện người dùng vi mô cần tuân thủ một hợp đồng chung để sản xuất các bản dựng. Điều này có thể được hỗ trợ thông qua các cấu hình được chia sẻ và các phương pháp phát triển được tiêu chuẩn hóa để đảm bảo tính nhất quán trên các giao diện vi mô (thêm về điều này trong các phần sau).

Thành phần lai

Như tôi đã đề cập trước đó trong chương này, tất cả các mẫu bố cục này có thể được kết hợp và kết hợp trong cùng một ứng dụng trình bao. Đây là một ví dụ về những gì nó có thể trông giống như:

Sự giới thiệu

Tôi khuyên bạn nên bắt đầu với cách tiếp cận đồng nhất ngay từ đầu — chọn một mẫu bố cục phù hợp với bạn hơn và bắt đầu xây dựng cơ sở hạ tầng xung quanh nó.

Đối với chúng tôi, bố cục phía máy khách là lựa chọn tốt nhất, nhưng trong tương lai, chúng tôi đã cân nhắc việc chuyển đổi một số khu vực sang điều phối phía biên (dựa trên tính khả dụng của Lambda@Edge).

Chọn thư viện dàn nhạc

Khi nói đến việc triển khai thành phần phía máy khách trong kiến trúc giao diện người dùng vi mô, việc chọn thư viện điều phối phù hợp là một quyết định quan trọng.

Thư viện được chọn sẽ đóng một vai trò quan trọng trong việc quản lý tải động và điều phối các giao diện vi mô trong ứng dụng vùng chứa.

Một số thư viện phối hợp phổ biến tồn tại, mỗi thư viện có điểm mạnh và cân nhắc riêng.

spa đơn

Single-spa là một thư viện phối hợp được áp dụng rộng rãi, cung cấp cách tiếp cận linh hoạt và có thể mở rộng cho thành phần giao diện người dùng vi mô. Nó cho phép các nhà phát triển tạo một ứng dụng shell phối hợp tải và dỡ nhiều giao diện người dùng vi mô.

Single-SPA cung cấp khả năng kiểm soát chi tiết đối với các sự kiện trong vòng đời và hỗ trợ các khuôn khổ và công nghệ khác nhau.

Ưu điểm:

• Framework bất khả tri: Thư viện hoạt động tốt với nhiều framework giao diện người dùng khác nhau như React, Angular, Vue.js, v.v.

• Cấu hình linh hoạt: Nó cung cấp các tùy chọn cấu hình mạnh mẽ để định tuyến, tải chậm và phụ thuộc chia sẻ.

• Hệ sinh thái mạnh mẽ: Single-SPA có một cộng đồng tích cực và một hệ sinh thái phong phú gồm các plugin và tiện ích mở rộng.

Nhược điểm:

• Đường cong học tập: Bắt đầu với spa đơn lẻ có thể yêu cầu một số kiến thức và hiểu biết ban đầu về các khái niệm và API của nó.

• Độ phức tạp của tùy chỉnh: Khi kiến trúc giao diện người dùng vi mô ngày càng phức tạp, việc định cấu hình và quản lý điều phối có thể trở nên khó khăn.

càn khôn

Qiankun là một thư viện phối hợp mạnh mẽ được phát triển bởi nhóm Ant Financial (Alibaba). Nó sử dụng cách tiếp cận HTML một phần để sáng tác. Về phía ứng dụng giao diện người dùng vi mô, nó tạo ra một đoạn mã HTML đơn giản với tất cả các điểm nhập sẽ được tải.

Sau khi sử dụng tệp HTML này, bộ chứa sẽ thực hiện tất cả việc điều phối và gắn kết ứng dụng. Trong cấu hình này, một phần HTML đóng vai trò của tệp kê khai mà tôi đã nói ở chương trước.

Ưu điểm:

• Bất khả tri về khung: Qiankun hỗ trợ nhiều khung giao diện người dùng khác nhau, bao gồm React, Vue.js, Angular, v.v.

• Tích hợp đơn giản: Qiankun cung cấp một bộ API và công cụ dễ sử dụng để tạo và quản lý giao diện người dùng vi mô.

• Khả năng mở rộng và hiệu suất: Qiankun cung cấp các cơ chế hiệu quả cho hộp cát mã, cách ly trạng thái và giao tiếp giữa các giao diện vi mô.

Nhược điểm:

• Xung đột phụ thuộc: Quản lý các phụ thuộc được chia sẻ và đảm bảo khả năng tương thích trên các giao diện vi mô có thể yêu cầu cấu hình và xem xét cẩn thận.

• Lộ trình học tập: Mặc dù Qiankun cung cấp tài liệu phong phú, nhưng việc áp dụng một thư viện mới có thể liên quan đến lộ trình học tập cho nhóm phát triển của bạn.

• Dữ liệu dự phòng được gửi qua mạng: Một phần đoạn mã HTML chứa dữ liệu dự phòng (thẻ body, meta, DOCTYPE) cần được gửi qua mạng.

Liên kết mô-đun

Liên kết mô-đun , một tính năng do Webpack cung cấp, đã thu hút được sự chú ý và quảng cáo rầm rộ trong cộng đồng phát triển web. Công nghệ này cho phép các nhà phát triển chia sẻ mã giữa nhiều ứng dụng trong thời gian chạy, làm cho nó trở thành một tùy chọn hấp dẫn để xây dựng giao diện người dùng vi mô.

Với khả năng tích hợp liền mạch với Webpack và tính linh hoạt trong thời gian chạy, Liên kết mô-đun đã trở thành một lựa chọn phổ biến để quản lý và điều phối các giao diện người dùng vi mô.

Ưu điểm:

• Tích hợp liền mạch với Webpack: Nếu bạn đã sử dụng Webpack làm công cụ xây dựng của mình, việc tận dụng Liên kết mô-đun sẽ đơn giản hóa quy trình thiết lập và tích hợp.

• Tính linh hoạt trong thời gian chạy: Liên kết mô-đun cho phép tải động và chia sẻ các phần phụ thuộc, mang lại sự linh hoạt trong việc quản lý các giao diện vi mô.

Nhược điểm:

• Hỗ trợ khung hạn chế: Mặc dù Liên kết mô-đun tương thích với nhiều khung giao diện người dùng, nhưng nó có thể yêu cầu cấu hình hoặc giải pháp thay thế bổ sung cho các trường hợp sử dụng cụ thể.

• Hỗ trợ cộng đồng: Liên kết mô-đun là một công nghệ tương đối mới, được phát hành dưới dạng plugin cốt lõi trong Webpack 5 (và sau đó được chuyển ngược lại sang v4 ). Thư viện Next.js cũng mới hơn, được phát hành dưới dạng mã nguồn mở gần đây. Như với tất cả các công cụ mới, có thể có một cộng đồng nhỏ hơn và ít hỗ trợ hơn. Điều quan trọng là phải xem xét yếu tố này nếu bạn có thời hạn chặt chẽ hoặc dự đoán gặp phải các câu hỏi mà không có sẵn câu trả lời.

Phần kết luận

Trong phần đầu tiên của loạt bài “Hành trình di chuyển giao diện người dùng vi mô”, chúng ta đã thảo luận về động lực đằng sau việc di chuyển từ một trang web nguyên khối sang một kiến trúc phân tán và các bước ban đầu được thực hiện để bán ý tưởng cho ban lãnh đạo.

Chúng tôi đã khám phá tầm quan trọng của tài liệu tầm nhìn kỹ thuật trình bày phân tích hiệu suất chi tiết và vạch ra các giai đoạn khác nhau của quá trình di chuyển.

Sau đó, chúng tôi đi sâu vào các cân nhắc thiết kế cho giao diện người dùng vi mô, thảo luận về ba cách tiếp cận: bố cục phía máy chủ, bố cục phía biên và bố cục phía máy khách.

Mỗi cách tiếp cận đều có ưu và nhược điểm và sự lựa chọn phụ thuộc vào nhiều yếu tố khác nhau như đồng bộ hóa trạng thái toàn cầu, trải nghiệm của khách hàng, độ phức tạp của cơ sở hạ tầng và bộ nhớ đệm.

Ngoài ra, chúng tôi đã khám phá các thư viện điều phối phổ biến, chẳng hạn như spa đơn, qiankun và Liên kết mô-đun, làm nổi bật các tính năng, lợi ích và thách thức tiềm năng của chúng.

Hãy tham gia cùng tôi trong các phần tiếp theo của loạt bài này khi chúng ta tiếp tục hành trình di chuyển đến giao diện người dùng vi mô, khám phá những thông tin chi tiết thú vị và có giá trị hơn trong suốt hành trình!

Được xuất bản lần đầu tại https://thesametech.com vào ngày 18 tháng 4 năm 2023.

Bạn cũng có thể theo dõi tôi trên Twitter và kết nối trên LinkedIn để nhận thông báo về các bài đăng mới!