Micro-Frontend Frontend: Làm chủ Kiến trúc Module Federation

Trong bối cảnh phát triển web đang thay đổi nhanh chóng ngày nay, việc xây dựng và duy trì các ứng dụng frontend quy mô lớn có thể ngày càng trở nên phức tạp. Các kiến trúc nguyên khối (monolithic) truyền thống thường dẫn đến các thách thức như mã nguồn cồng kềnh, thời gian xây dựng chậm và khó khăn trong việc triển khai độc lập. Micro-frontend cung cấp một giải pháp bằng cách chia nhỏ frontend thành các phần nhỏ hơn, dễ quản lý hơn. Bài viết này đi sâu vào Module Federation, một kỹ thuật mạnh mẽ để triển khai micro-frontend, khám phá các lợi ích, kiến trúc và chiến lược triển khai thực tế của nó.

Micro-Frontend là gì?

Micro-frontend là một phong cách kiến trúc trong đó một ứng dụng frontend được phân tách thành các đơn vị nhỏ hơn, độc lập và có thể triển khai được. Mỗi micro-frontend thường thuộc sở hữu của một đội nhóm riêng biệt, cho phép quyền tự chủ cao hơn và chu kỳ phát triển nhanh hơn. Cách tiếp cận này phản ánh kiến trúc microservices thường được sử dụng ở backend.

Các đặc điểm chính của micro-frontend bao gồm:

• Khả năng triển khai độc lập: Mỗi micro-frontend có thể được triển khai độc lập mà không ảnh hưởng đến các phần khác của ứng dụng.
• Tự chủ của đội nhóm: Các đội nhóm khác nhau có thể sở hữu và phát triển các micro-frontend khác nhau bằng cách sử dụng công nghệ và quy trình làm việc ưa thích của họ.
• Đa dạng công nghệ: Micro-frontend có thể được xây dựng bằng các framework và thư viện khác nhau, cho phép các đội nhóm chọn công cụ tốt nhất cho công việc.
• Tính cô lập: Các micro-frontend nên được cô lập với nhau để ngăn ngừa lỗi dây chuyền và đảm bảo sự ổn định.

Tại sao nên sử dụng Micro-Frontend?

Việc áp dụng kiến trúc micro-frontend mang lại một số lợi ích đáng kể, đặc biệt đối với các ứng dụng lớn và phức tạp:

• Cải thiện khả năng mở rộng: Việc chia nhỏ frontend thành các đơn vị nhỏ hơn giúp dễ dàng mở rộng ứng dụng khi cần thiết.
• Chu kỳ phát triển nhanh hơn: Các đội nhóm độc lập có thể làm việc song song, dẫn đến chu kỳ phát triển và phát hành nhanh hơn.
• Tăng cường quyền tự chủ của đội nhóm: Các đội nhóm có quyền kiểm soát nhiều hơn đối với mã nguồn của mình và có thể đưa ra quyết định một cách độc lập.
• Bảo trì dễ dàng hơn: Các codebase nhỏ hơn dễ bảo trì và gỡ lỗi hơn.
• Không phụ thuộc công nghệ: Các đội nhóm có thể chọn công nghệ tốt nhất cho nhu cầu cụ thể của họ, cho phép đổi mới và thử nghiệm.
• Giảm thiểu rủi ro: Các lần triển khai nhỏ hơn và thường xuyên hơn, làm giảm nguy cơ xảy ra lỗi quy mô lớn.

Giới thiệu về Module Federation

Module Federation là một tính năng được giới thiệu trong Webpack 5 cho phép các ứng dụng JavaScript tải động mã nguồn từ các ứng dụng khác tại thời gian chạy. Điều này cho phép tạo ra các micro-frontend thực sự độc lập và có thể kết hợp. Thay vì xây dựng mọi thứ thành một gói (bundle) duy nhất, Module Federation cho phép các ứng dụng khác nhau chia sẻ và sử dụng các module của nhau như thể chúng là các phụ thuộc cục bộ.

Không giống như các cách tiếp cận micro-frontend truyền thống dựa vào iframe hoặc web component, Module Federation cung cấp trải nghiệm liền mạch và tích hợp hơn cho người dùng. Nó tránh được chi phí hiệu năng và sự phức tạp liên quan đến các kỹ thuật khác này.

Module Federation hoạt động như thế nào

Module Federation hoạt động dựa trên khái niệm "phơi bày" (exposing) và "tiêu thụ" (consuming) các module. Một ứng dụng ("host" hoặc "container") có thể phơi bày các module, trong khi các ứng dụng khác ("remotes") có thể tiêu thụ các module được phơi bày này. Dưới đây là phân tích quy trình:

1. Phơi bày Module: Một micro-frontend, được cấu hình là một ứng dụng "remote" trong Webpack, sẽ phơi bày một số module nhất định (component, hàm, tiện ích) thông qua một tệp cấu hình. Cấu hình này chỉ định các module sẽ được chia sẻ và các điểm vào (entry point) tương ứng của chúng.
2. Tiêu thụ Module: Một micro-frontend khác, được cấu hình là một ứng dụng "host" hoặc "container", sẽ khai báo ứng dụng remote là một phụ thuộc. Nó chỉ định URL nơi có thể tìm thấy tệp manifest của module federation của remote (một tệp JSON nhỏ mô tả các module được phơi bày).
3. Phân giải tại thời gian chạy: Khi ứng dụng host cần sử dụng một module từ ứng dụng remote, nó sẽ tự động nạp tệp manifest của module federation của remote. Webpack sau đó sẽ phân giải sự phụ thuộc của module và tải mã nguồn cần thiết từ ứng dụng remote tại thời gian chạy.
4. Chia sẻ mã nguồn: Module Federation cũng cho phép chia sẻ mã nguồn giữa ứng dụng host và remote. Nếu cả hai ứng dụng sử dụng cùng một phiên bản của một phụ thuộc được chia sẻ (ví dụ: React, lodash), mã nguồn sẽ được chia sẻ, tránh trùng lặp và giảm kích thước gói (bundle).

Thiết lập Module Federation: Một ví dụ thực tế

Hãy minh họa Module Federation bằng một ví dụ đơn giản liên quan đến hai micro-frontend: một "Danh mục sản phẩm" (Product Catalog) và một "Giỏ hàng" (Shopping Cart). Danh mục sản phẩm sẽ phơi bày một component danh sách sản phẩm, mà Giỏ hàng sẽ sử dụng để hiển thị các sản phẩm liên quan.

Cấu trúc dự án

  
  micro-frontend-example/
    product-catalog/
      src/
        components/
          ProductList.jsx
        index.js
        webpack.config.js
    shopping-cart/
      src/
        components/
          RelatedProducts.jsx
        index.js
        webpack.config.js
  

Danh mục sản phẩm (Remote)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'product_catalog',
        filename: 'remoteEntry.js',
        exposes: {
          './ProductList': './src/components/ProductList',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Giải thích:

• name: Tên duy nhất của ứng dụng remote.
• filename: Tên của tệp điểm vào sẽ được phơi bày. Tệp này chứa manifest của module federation.
• exposes: Định nghĩa các module sẽ được phơi bày bởi ứng dụng này. Trong trường hợp này, chúng ta đang phơi bày component `ProductList` từ `src/components/ProductList.jsx` dưới tên `./ProductList`.
• shared: Chỉ định các phụ thuộc nên được chia sẻ giữa ứng dụng host và remote. Điều này rất quan trọng để tránh mã nguồn trùng lặp và đảm bảo tính tương thích. `singleton: true` đảm bảo rằng chỉ có một phiên bản của phụ thuộc được chia sẻ được tải. `eager: true` tải phụ thuộc được chia sẻ ngay từ đầu, điều này có thể cải thiện hiệu suất. `requiredVersion` định nghĩa phạm vi phiên bản chấp nhận được cho phụ thuộc được chia sẻ.

src/components/ProductList.jsx

  
  import React from 'react';

  const ProductList = ({ products }) => (
    

      {products.map((product) => (
        
{product.name} - ${product.price}
      ))}
    
  );

  export default ProductList;
  

Giỏ hàng (Host)

webpack.config.js

  
  const { ModuleFederationPlugin } = require('webpack').container;
  const path = require('path');

  module.exports = {
    // ... other webpack configurations
    plugins: [
      new ModuleFederationPlugin({
        name: 'shopping_cart',
        remotes: {
          product_catalog: 'product_catalog@http://localhost:3001/remoteEntry.js',
        },
        shared: {
          react: { singleton: true, eager: true, requiredVersion: '^17.0.0' },
          'react-dom': { singleton: true, eager: true, requiredVersion: '^17.0.0' },
        },
      }),
    ],
  };
  

Giải thích:

• name: Tên duy nhất của ứng dụng host.
• remotes: Định nghĩa các ứng dụng remote mà ứng dụng này sẽ tiêu thụ module từ đó. Trong trường hợp này, chúng ta đang khai báo một remote có tên là `product_catalog` và chỉ định URL nơi có thể tìm thấy tệp `remoteEntry.js` của nó. Định dạng là `remoteName: 'remoteName@remoteEntryUrl'`.
• shared: Tương tự như ứng dụng remote, ứng dụng host cũng định nghĩa các phụ thuộc được chia sẻ của nó. Điều này đảm bảo rằng ứng dụng host và remote sử dụng các phiên bản tương thích của các thư viện được chia sẻ.

src/components/RelatedProducts.jsx

  
  import React, { useEffect, useState } from 'react';
  import ProductList from 'product_catalog/ProductList';

  const RelatedProducts = () => {
    const [products, setProducts] = useState([]);

    useEffect(() => {
      // Lấy dữ liệu sản phẩm liên quan (ví dụ: từ API)
      const fetchProducts = async () => {
        // Thay thế bằng endpoint API thực tế của bạn
        const response = await fetch('https://fakestoreapi.com/products?limit=3');
        const data = await response.json();
        setProducts(data);
      };

      fetchProducts();
    }, []);

    return (
      

        
Related Products
        {products.length > 0 ?  : 
Loading...
}
      
    );
  };

  export default RelatedProducts;
  

Giải thích:

• import ProductList from 'product_catalog/ProductList'; Dòng này nhập component `ProductList` từ remote `product_catalog`. Cú pháp `remoteName/moduleName` yêu cầu Webpack lấy module từ ứng dụng remote được chỉ định.
• Component sau đó sử dụng component `ProductList` đã nhập để hiển thị các sản phẩm liên quan.

Chạy ví dụ

1. Khởi động cả hai ứng dụng Danh mục sản phẩm và Giỏ hàng bằng máy chủ phát triển tương ứng của chúng (ví dụ: `npm start`). Đảm bảo chúng đang chạy trên các cổng khác nhau (ví dụ: Danh mục sản phẩm trên cổng 3001 và Giỏ hàng trên cổng 3000).
2. Truy cập ứng dụng Giỏ hàng trong trình duyệt của bạn.
3. Bạn sẽ thấy phần Sản phẩm liên quan, được hiển thị bởi component `ProductList` từ ứng dụng Danh mục sản phẩm.

Các khái niệm nâng cao của Module Federation

Ngoài thiết lập cơ bản, Module Federation cung cấp một số tính năng nâng cao có thể cải thiện kiến trúc micro-frontend của bạn:

Chia sẻ mã nguồn và quản lý phiên bản

Như đã trình bày trong ví dụ, Module Federation cho phép chia sẻ mã nguồn giữa ứng dụng host và remote. Điều này đạt được thông qua tùy chọn cấu hình `shared` trong Webpack. Bằng cách chỉ định các phụ thuộc được chia sẻ, bạn có thể tránh mã nguồn trùng lặp và giảm kích thước gói. Việc quản lý phiên bản đúng cách cho các phụ thuộc được chia sẻ là rất quan trọng để đảm bảo tính tương thích và ngăn ngừa xung đột. Semantic versioning (SemVer) là một tiêu chuẩn được sử dụng rộng rãi để quản lý phiên bản phần mềm, cho phép bạn xác định các phạm vi phiên bản tương thích (ví dụ: `^17.0.0` cho phép bất kỳ phiên bản nào lớn hơn hoặc bằng 17.0.0 nhưng nhỏ hơn 18.0.0).

Remote động

Trong ví dụ trước, URL của remote được mã hóa cứng trong tệp `webpack.config.js`. Tuy nhiên, trong nhiều trường hợp thực tế, bạn có thể cần xác định động URL của remote tại thời gian chạy. Điều này có thể đạt được bằng cách sử dụng cấu hình remote dựa trên promise:

  
  // webpack.config.js
  remotes: {
    product_catalog: new Promise(resolve => {
      // Lấy URL của remote từ một tệp cấu hình hoặc API
      fetch('/config.json')
        .then(response => response.json())
        .then(config => {
          const remoteUrl = config.productCatalogUrl;
          resolve(`product_catalog@${remoteUrl}/remoteEntry.js`);
        });
    }),
  },
  

Điều này cho phép bạn cấu hình URL của remote dựa trên môi trường (ví dụ: development, staging, production) hoặc các yếu tố khác.

Tải module bất đồng bộ

Module Federation hỗ trợ tải module bất đồng bộ, cho phép bạn tải các module theo yêu cầu. Điều này có thể cải thiện thời gian tải ban đầu của ứng dụng bằng cách trì hoãn việc tải các module không quan trọng.

  
  // RelatedProducts.jsx
  import React, { Suspense, lazy } from 'react';

  const ProductList = lazy(() => import('product_catalog/ProductList'));

  const RelatedProducts = () => {
    return (
      

        
Related Products
        Loading...
}>
          
        
      
    );
  };
  

Sử dụng `React.lazy` và `Suspense`, bạn có thể tải bất đồng bộ component `ProductList` từ ứng dụng remote. Component `Suspense` cung cấp một giao diện người dùng dự phòng (ví dụ: chỉ báo đang tải) trong khi module đang được tải.

Styles và Asset liên kết

Module Federation cũng có thể được sử dụng để chia sẻ style và asset giữa các micro-frontend. Điều này có thể giúp duy trì một giao diện nhất quán trên toàn bộ ứng dụng của bạn.

Để chia sẻ style, bạn có thể phơi bày các CSS module hoặc styled component từ một ứng dụng remote. Để chia sẻ asset (ví dụ: hình ảnh, phông chữ), bạn có thể cấu hình Webpack để sao chép các asset đến một vị trí được chia sẻ và sau đó tham chiếu đến chúng từ ứng dụng host.

Các phương pháp hay nhất cho Module Federation

Khi triển khai Module Federation, điều quan trọng là phải tuân theo các phương pháp hay nhất để đảm bảo một kiến trúc thành công và dễ bảo trì:

• Xác định ranh giới rõ ràng: Xác định rõ ràng ranh giới giữa các micro-frontend để tránh sự ghép nối chặt chẽ và đảm bảo khả năng triển khai độc lập.
• Thiết lập giao thức giao tiếp: Xác định các giao thức giao tiếp rõ ràng giữa các micro-frontend. Cân nhắc sử dụng event bus, các thư viện quản lý trạng thái chia sẻ, hoặc các API tùy chỉnh.
• Quản lý cẩn thận các phụ thuộc được chia sẻ: Quản lý cẩn thận các phụ thuộc được chia sẻ để tránh xung đột phiên bản và đảm bảo tính tương thích. Sử dụng semantic versioning và cân nhắc sử dụng một công cụ quản lý phụ thuộc như npm hoặc yarn.
• Triển khai xử lý lỗi mạnh mẽ: Triển khai xử lý lỗi mạnh mẽ để ngăn ngừa các lỗi dây chuyền và đảm bảo sự ổn định của ứng dụng.
• Theo dõi hiệu suất: Theo dõi hiệu suất của các micro-frontend của bạn để xác định các điểm nghẽn và tối ưu hóa hiệu suất.
• Tự động hóa triển khai: Tự động hóa quy trình triển khai để đảm bảo các lần triển khai nhất quán và đáng tin cậy.
• Sử dụng phong cách viết mã nhất quán: Thực thi một phong cách viết mã nhất quán trên tất cả các micro-frontend để cải thiện khả năng đọc và bảo trì. Các công cụ như ESLint và Prettier có thể giúp ích trong việc này.
• Tài liệu hóa kiến trúc của bạn: Tài liệu hóa kiến trúc micro-frontend của bạn để đảm bảo rằng tất cả các thành viên trong nhóm hiểu hệ thống và cách nó hoạt động.

Module Federation so với các cách tiếp cận Micro-Frontend khác

Mặc dù Module Federation là một kỹ thuật mạnh mẽ để triển khai micro-frontend, nhưng đó không phải là cách tiếp cận duy nhất. Các phương pháp phổ biến khác bao gồm:

• Iframes: Iframes cung cấp sự cô lập mạnh mẽ giữa các micro-frontend, nhưng chúng có thể khó tích hợp một cách liền mạch và có thể gây ra chi phí hiệu năng.
• Web Components: Web component cho phép bạn tạo các phần tử UI có thể tái sử dụng trên các micro-frontend khác nhau. Tuy nhiên, chúng có thể phức tạp hơn để triển khai so với Module Federation.
• Tích hợp tại thời điểm xây dựng (Build-Time): Cách tiếp cận này liên quan đến việc xây dựng tất cả các micro-frontend thành một ứng dụng duy nhất tại thời điểm xây dựng. Mặc dù nó có thể đơn giản hóa việc triển khai, nhưng nó làm giảm quyền tự chủ của đội nhóm và tăng nguy cơ xung đột.
• Single-SPA: Single-SPA là một framework cho phép bạn kết hợp nhiều ứng dụng trang đơn (single-page application) thành một ứng dụng duy nhất. Nó cung cấp một cách tiếp cận linh hoạt hơn so với tích hợp tại thời điểm xây dựng nhưng có thể phức tạp hơn để thiết lập.

Việc lựa chọn cách tiếp cận nào để sử dụng phụ thuộc vào các yêu cầu cụ thể của ứng dụng của bạn và quy mô cũng như cấu trúc của đội nhóm của bạn. Module Federation cung cấp một sự cân bằng tốt giữa tính linh hoạt, hiệu suất và dễ sử dụng, khiến nó trở thành một lựa chọn phổ biến cho nhiều dự án.

Ví dụ thực tế về Module Federation

Mặc dù việc triển khai cụ thể của các công ty thường là bí mật, các nguyên tắc chung của Module Federation đang được áp dụng trong nhiều ngành công nghiệp và kịch bản khác nhau. Dưới đây là một số ví dụ tiềm năng:

• Nền tảng thương mại điện tử: Một nền tảng thương mại điện tử có thể sử dụng Module Federation để tách các phần khác nhau của trang web, chẳng hạn như danh mục sản phẩm, giỏ hàng, quy trình thanh toán và quản lý tài khoản người dùng, thành các micro-frontend riêng biệt. Điều này cho phép các đội nhóm khác nhau làm việc trên các phần này một cách độc lập và triển khai các bản cập nhật mà không ảnh hưởng đến phần còn lại của nền tảng. Ví dụ, một đội nhóm ở *Đức* có thể tập trung vào danh mục sản phẩm trong khi một đội nhóm ở *Ấn Độ* quản lý giỏ hàng.
• Ứng dụng dịch vụ tài chính: Một ứng dụng dịch vụ tài chính có thể sử dụng Module Federation để cô lập các tính năng nhạy cảm, chẳng hạn như nền tảng giao dịch và quản lý tài khoản, thành các micro-frontend riêng biệt. Điều này tăng cường bảo mật và cho phép kiểm toán độc lập các thành phần quan trọng này. Hãy tưởng tượng một đội nhóm ở *Luân Đôn* chuyên về các tính năng của nền tảng giao dịch và một đội nhóm khác ở *New York* xử lý việc quản lý tài khoản.
• Hệ thống quản lý nội dung (CMS): Một CMS có thể sử dụng Module Federation để cho phép các nhà phát triển tạo và triển khai các module tùy chỉnh dưới dạng micro-frontend. Điều này cho phép sự linh hoạt và tùy biến cao hơn cho người dùng CMS. Một đội nhóm ở *Nhật Bản* có thể xây dựng một module thư viện hình ảnh chuyên biệt, trong khi một đội nhóm ở *Brazil* tạo ra một trình soạn thảo văn bản nâng cao.
• Ứng dụng chăm sóc sức khỏe: Một ứng dụng chăm sóc sức khỏe có thể sử dụng Module Federation để tích hợp các hệ thống khác nhau, chẳng hạn như hồ sơ sức khỏe điện tử (EHRs), cổng thông tin bệnh nhân và hệ thống thanh toán, dưới dạng các micro-frontend riêng biệt. Điều này cải thiện khả năng tương tác và cho phép tích hợp các hệ thống mới dễ dàng hơn. Ví dụ, một đội nhóm ở *Canada* có thể tích hợp một module telehealth mới, trong khi một đội nhóm ở *Úc* tập trung vào việc cải thiện trải nghiệm cổng thông tin bệnh nhân.

Kết luận

Module Federation cung cấp một cách tiếp cận mạnh mẽ và linh hoạt để triển khai micro-frontend. Bằng cách cho phép các ứng dụng tải động mã nguồn từ nhau tại thời gian chạy, nó cho phép tạo ra các kiến trúc frontend thực sự độc lập và có thể kết hợp. Mặc dù đòi hỏi phải lập kế hoạch và triển khai cẩn thận, những lợi ích về khả năng mở rộng tăng lên, chu kỳ phát triển nhanh hơn và quyền tự chủ của đội nhóm lớn hơn khiến nó trở thành một lựa chọn hấp dẫn cho các ứng dụng web lớn và phức tạp. Khi bối cảnh phát triển web tiếp tục phát triển, Module Federation được định vị để đóng một vai trò ngày càng quan trọng trong việc định hình tương lai của kiến trúc frontend.

Bằng cách hiểu các khái niệm và phương pháp hay nhất được nêu trong bài viết này, bạn có thể tận dụng Module Federation để xây dựng các ứng dụng frontend có khả năng mở rộng, dễ bảo trì và sáng tạo, đáp ứng nhu cầu của thế giới kỹ thuật số có nhịp độ nhanh ngày nay.