Công ty CNTT Minh Quân

Single Page Application – SPA là thuật ngữ đã xuất hiện cách đây từ nhiều năm về trước. SPA đem đến người dùng sự trải nghiệm web tuyệt vời nhất không khác gì mobile. Chính vì vậy ngay từ khi mới ra đời, SPA đã được các chuyên gia đánh giá đây là một xu hướng lập trình web trong tương lai. Vậy điều đó có thành sự thật, Single Page Application mang đến những lợi ích như thế nào cho lập trình viên và người dùng? Tại bài viết này, hãy cùng chúng tôi đi giải đáp xem rốt cuộc Single Page Application là gì mà được ca tụng nhiều đến vậy nhé.

Single Page Application là gì? Những ưu và nhược điểm khi tạo web theo SPA

Single Page Application là gì?

Trước khi có sự xuất hiện của Single Page Application hay được viết tắt là SPA, việc lập trình web chủ yếu được thực hiện theo mô hình MVC (Model – View – Controller). Tuy nhiên, nguyên lý hoạt động của kiểu cấu trúc này chỉ tập trung ở xử lý server mà không đáp ứng được những trải nghiệm người dùng. Chính vì vậy, rất cần đến một mô hình mới có thể đáp ứng được các yêu cầu của server và client. Và đó cũng chính là lý do mà Single Page Application được ra đời.Xem thêm: dịch vụ vận chuyển hàng không là gì

SPA là một kiểu lập trình web mà ở đó người dùng có thể truy cập vào nhiều trang web con khác nhau mà không làm ảnh hưởng đến trang web gốc. Khi người dùng truy cập vào bất kỳ thành phần nào trên trang, SPA sẽ chỉ chạy nội dung của thành phần đó mà không tải lại toàn bộ trang như các web truyền thống. Các thành phần chung như header, footer, thanh menu sẽ được giữ nguyên.

SPA sẽ tập trung xử lý ở client, đẩy mạnh hơn vai trò của frontend. Frontend chính là phần mà người dùng có thể nhìn thấy và tiếp nhận request của người dùng từ đó xác định được những tính năng và dữ liệu cần thiết, sau đó mới gửi yêu cầu đến backend. Backend nhận yêu cầu và trả về dữ liệu ra bên ngoài website. Từ đó làm tăng trải nghiệm người dùng, giúp người dùng có cảm giác như đang sử dụng trên mobile chứ không phải là một trang web.

Ví dụ một số mẫu website bạn vẫn sử dụng hàng ngày được lập trình theo kiểu SPA như Facebook, Youtube, Twitter, Shopee,…

Rất nhiều trang web nổi tiếng được lập trình theo SPA như Youtube, Facebook, Twitter,…

Web SPA hoạt động khác gì một trang web truyền thống?

Có hai đặc điểm nổi bật nhất tạo nên sự khác biệt giữa trang web sử dụng SPA và trang web truyền thống là:

• Web SPA có sự phân chia rõ ràng giữa backend và frontend
• Web SPA đẩy mạnh xử lý ở frontend

Sự phân chia rõ ràng giữa backend và frontend

Nếu lập trình theo kiểu truyền thống sẽ khó phân chia được ranh giới cụ thể giữa frontend và backend. Chẳng hạn như Laravel Framework, bạn vẫn có thể thực hiện code PHP trong phần View. Tuy nhiên đối với SPA lại hoàn toàn khác, backend và frontend được tách bạch tới nỗi chúng có thể nằm ở 2 dự án khác nhau mặc dù chúng sinh ra là để dành cho nhau. Việc trao đổi dữ liệu giữa frontend, backend trong SPA thường qua các Restful API và định dạng của chúng  thường là JSON.

Cách hoạt động của frontend và backend theo SPA có thể được mô tả như sau:

• Khi người dùng truy cập trang web, frontend sẽ tiếp nhận request chứ không phải backend. Hiểu đơn giản, web SPA thực hiện routing ở frontend chứ không phải backend như kiểu lập trình truyền thống.
• Sau khi tiếp nhận request, frontend sẽ xác nhận người dùng muốn sử dụng tính năng nào và cần những dữ liệu gì sau đó mới gửi request tới backend. Cuối cùng, backend sẽ thực hiện yêu cầu và trả về những dữ liệu mong muốn.
• Frontend nhận dữ liệu từ backend và dựa vào dữ liệu này để render ra nội dung trang web một cách hoàn chỉnh.

SPA có sự tách bạch rõ ràng giữa Frontend và Backend

Web SPA đẩy mạnh xử lý về frontend

Đối với những trang web được lập trình theo kiểu SPA, vai trò của frontend sẽ được đẩy mạnh hơn. Frontend sẽ đảm nhiệm hoàn toàn việc render giao diện và xử lý những thay đổi, trong khi đó, backend chỉ cần ngồi chờ xem frontend có yêu cầu gì thì trả về cái đó. Web SPA yêu cầu xử phức tạp ở frontend, vì vậy mà nó sẽ áp dụng một framework hay thư viện nào đó về SPA để xử lý. Dựa vào framework hay thư viện này mà các nhà lập trình viên dễ dàng hơn trong việc phát triển một web SPA.Xem thêm: vận chuyển hàng không quốc tế

Ưu và nhược điểm khi sử dụng Single Page Application

Ưu điểm của web SPA

Single Page Application mang lại rất nhiều những điểm nổi bật như:

• Hỗ trợ target dễ dàng: Mọi thông tin sẽ được đặt trên cùng một trang, đây là phương án hiệu quả đối với SEO bởi nó sẽ hướng đến bộ từ khóa. Với Single Page Application, nội dung sẽ được dàn trải trong một trang do đó có thể người dùng phải kéo đến những dòng cuối cùng mới tìm thấy được. Do vậy, hãy suy nghĩ cẩn thận để đưa ra được những nội dung phù hợp nhất, hấp dẫn người đọc nhé.
• Độ tin cậy của SPA: đối với SPA, đường link đóng vai trò quan trọng, nó quyết định xem trang web của bạn đang nằm ở thứ hạng bao nhiêu. Những link trỏ tới sẽ đều di chuyển đến trang chủ của bạn, do vậy độ tin cậy của SPA vô cùng cao.
• Thích hợp cho các dòng điện thoại: Single Page Application trang web của bạn sẽ được load nhanh hơn rất nhiều khi sử dụng mobile, tránh trường hợp load lâu dẫn đến mất đi lượng khách hàng.

Nhờ có SPA trang web của bạn sẽ được load nhanh hơn rất nhiều khi sử dụng mobile

Ngoài ra còn rất nhiều những ưu điểm cho cả lập trình viên và người dùng.

Đối với lập trình viên

• Lập trình viên sẽ không cần phải viết code HTML để render trên server mà thay vào đó việc render HTML cho request của người dùng sẽ được thực hiện bởi chính thiết bị truy cập xử lý.
• Sự tách biệt giữa frontend và backend cho phép việc thực hiện song song giúp đẩy nhanh tiến độ xử lý.
• Tiết kiệm băng thông do chỉ có sự chuyển giao dữ liệu giữa server và client, còn đối với các tài nguyên tĩnh thì chỉ cần tải một lần duy nhất là được.
• Sử dụng SPA giúp tận dụng được các lợi thế từ framework của JavaScript.
• Tận dụng code một cách dễ dàng để phát triển mobile app.

Đối với người dùng

Trang web được thiết kế theo SPA sẽ mang đến những trải nghiệm tốt hơn cho người dùng khi truy cập trang. Với mô hình này, thời gian tải trang sẽ được rút ngắn hơn, nội dung trang tập trung vào nội dung mà người dùng muốn xem. Chính vì vậy mà các trang web này trở nên linh hoạt hơn và thu hút đối với người dùng hơn.Xem thêm: vận chuyển hàng không nội địa

Một vài hạn chế của SPA

• SPA đòi hỏi các nhà lập trình phải thông thạo các ngôn ngữ HTML, CSS, JS, ajax, es6 và có kinh nghiệm với frontend.
• Mô hình SPA kém phù hợp với những thiết bị có hiệu năng thấp do mọi thao tác đều được xử lý trên cùng một trang web. 
• Tốc độ tải trang lần đầu cũng kém hơn so với các trang web truyền thống.
• Các kỹ thuật SEO nâng cao như cấu trúc Silo sẽ không thể áp dụng được.
• Nội dung trên trang bị giới hạn do vậy nhiều vấn đề không thể chi tiết được.
• Không phải dự án nào cũng phù hợp: SPA chỉ thích hợp sử dụng với những dự án cần maintain, dự án có định hướng phát triển lâu dài, các phần mềm dịch vụ hay những dự án tập trung nhiều vào trải nghiệm người dùng UX.

Ở thời điểm hiện tại, SPA đã là một kiểu lập trình web có chỗ đứng vững chắc và trở thành sự lựa chọn lý tưởng của nhiều dự án công nghệ mới. Tuy nhiên vẫn còn quá sớm để kết luận được sự hùng mạnh của Single Page Application trong giới lập trình tương lai. Với những chia sẻ trên, chắc hẳn đã giúp các bạn đã hiểu hơn về Single Page Application là gì cũng như các thông tin hữu ích khác về SPA. Hy vọng rằng trong tương lai, SPA sẽ càng được đổi mới và hoàn thiện hơn nữa để phù hợp với người dùng.

Trong bài “Backend for frontend (BFF) pattern(1)” tôi đã nêu ra những vấn đề mà khi triển khai một hệ thống “Genneral Purpose Backend Server-Side” sẽ gặp phải.

Một giải pháp để giải quyết những vấn đề nêu trên đó là “Backend For Fontend“. Mô hình này lần đầu được mô tả bởi Sam NewMan

Kiến trúc BFF là một biến thể của API Gateway Pattern giữ cho phần xử lý dữ liệu được đặt tách biệt khỏi giao diện hoặc giảm thiểu nhất có thể . Với đề xuất một thành phần phía máy chủ đảm nhiệm cho mỗi nền tảng giao diện người dùng, mục đính để nâng cao trải nghiệm người dùng. Lớp BFF được thiết kế với nhiều Backend để đáp ứng yêu cầu của từng nền tảng giao diện khác nhau, nhờ mỗi Backend được thiết kế để đáp ứng yêu cầu riêng giúp cho trải nghiệm người dùng trở nên mượt mà, tối ưu cho từng giao diện.

Trước khi đi thiết kế một hệ thống sử dụng BFF chúng ta thử cân nhắc tới một số vấn đề sau:

• Thứ nhất BFF sẽ làm tăng độ trễ của hệ thống có phải không ? Đúng vậy dữ liệu sẽ cần đi qua BFF và được xử lý tại đó điều này sẽ làm tăng độ trễ nhưng điều đó có thể chấp nhận được khi mà BFF sẽ tiêu thụ tài nguyên ở máy chủ nơi có tài nguyên mạnh mẽ hơn thay vì ở phía máy khách có tài nguyên giới hạn.
• Thứ hai: Cần bao nhiều BFF cho hệ thống ?. Nhà triển khai có thể dựa vào việc phân loại nền tảng giao diện phục vụ thành các nhóm. Ví dụ: Nhà triển khai có thể xây dựng một BFF cho các giao diện mobile hoặc có thể phân chia thành hai BFF, một phục vụ cho Android, cái khác phục vụ cho IOS. Điều này dựa vào yêu cầu của các nền tảng giao diện có quá khác biết nhau không hay có thể gộp thành một nhóm.
• Thứ ba: Vấn đề trùng lặp code trong BFF, việc có mỗi BFF cho từng giao diện sẽ không tránh khỏi việc trùng lặp code cho những logic chung. Nhưng việc này cũng không phải là một vấn đề quả đáng ngại vì chúng được đặt tại máy chủ nơi mà tài nguyên hiện nay vô cùng mạnh và cũng không quá hạn hẹp.

Kết luận lại: Sử dụng mẫu BFF không chi giúp cải thiện đáng kể trải nghiệm người dùng giao diện mà con giúp nhà triển khai dễ dàng tối ưu về hiệu năng và mở rộng khả năng hỗ trợ giao diện mà không lo lắng ảnh hưởng tới những giao diện đã được hỗ trợ trước đó.

Introduction

Xuất phát từ mong muốn hỗ trợ giao diện trên nhiều nền tảng thì ở phía backend tạo ra các API genneric để dễ dàng tích hợp sau này, ở phía góc độ người triển khai thấy rằng điều đó sẽ làm tiết kiệm thời gian và giảm đi chi phí triển khai hỗ trợ nền tảng mới.

Nhưng càng phát triển thì chúng ta càng nhồi nhét nhiều thứ vào một nơi. Vì lúc này hệ thống đòi hỏi phải hỗ trợ được nhiều nền tảng hơn, mà mỗi nền tảng lại yêu cầu đặc điểm dữ liệu trả về có những yêu cầu cụ thể Ví dụ: Trên thiết bị di động không cần thiết trả về nhiều dữ liệu giống như trên nền tảng web desktop vì điều đó đơn giản là tài nguyên trên thiết bị di động không có nhiều giống như trên desktop.

Backend For Fontend pattern(BFF)

Thông thường ý tưởng của người phát triển ban đầu sẽ xuất phát sử dụng “A genneral purpose API backend”

Đối với những hệ thống được xác định từ trước với những nền tảng sẽ hỗ trợ thì cách tiếp cận này cũng sẽ thành công bởi vì

• Thứ nhất: Tách riêng backend và đưa phần xử lý đặt tại đó làm cho phần hiển thị trở nên nhẹ và tốn ít tài nguyên hơn. Ở phía giao diện chỉ có nhiệm vụ là hiện thị dữ liệu và thu thập tương tác của người dùng.
• Thứ hai: Tiết kiệm được thời gian và chi phí phát triển những chức năng sử dụng chung cho các nền tảng thay vì tách riêng và sẽ bị trùng lặp “hight coupling“.
• Thứ ba: Cách tiếp cận này có thể định tuyến các yêu cầu của ứng dụng khách(client) và xử lý xuyên suốt (bảo mật, auth, cached) điều này có thể làm giảm độ trễ và tài nguyên máy chủ(server).

Tuy nhiên từng nền tảng giao diện(User Interface) thì rất khác chưa kể logic được thiết kế riêng cho từng giao diện mà không phải chỉ đơn thuần là sắp xếp và trả về dữ liệu thông thường. Như tôi đã đề cập trước đó, ví dụ như đối với thiết bị di động sẽ rất khác về kích thước màn hình hiện thị, giới hạn hiện thị, dung lượng pin, bộ nhớ. Các khác biệt sẽ diện ra thường xuyên dẫn tới người phát triển cần cập nhật thay đổi đó trong khi vẫn phải giữ không làm ảnh hưởng tới nhưng giao diện khác.

Thông thường thì người phát triển sẽ cố gắng điều chỉnh những yêu câu cụ thể từ phía giao diện bằng cách tạo ra những đoạn code đặc biệt để xử lý. Nhưng cách này làm vấn đề càng thêm nghiêm trọng hơn bởi lúc này hệ thống sẽ cần phải cân bằng cả những ưu tiên cho những yêu cầu đặc biết và những yêu cầu chung từ các giao diện. Thêm vào đó các service phía dưới cũng sẽ bị ảnh hưởng theo để đáp ứng được những logic đặc biệt.

Một vấn đề khác mà “genneral purpose backedn server-side” sẽ gặp phải đó là sẽ xảy ra hiện tượng thắt cổ trai “bottleneck” khi có quá nhiều yêu cầu trên cùng một cấu trúc hạ tầng.

Một giải pháp cho những vấn đề trên mà hiện được sử dụng bởi SoundCloud thay “genneral purpose backedn server-side” đó là Backend For Frontend(BFF)(2)

Tại sao bạn cần biết đến Micro frontend

Vấn đề cần giải quyết:

• Ứng dụng càng lúc càng phình ra về quy mô, cũng như độ phức tạp
• Một codebase FE duy nhất mà muốn maintain thì chỉ có gặp ác mộng hằng đêm
• Bạn có nhiều team FE khác nhau, mỗi team chỉ làm việc chính trên một phần tính năng nào đó rất cụ thể, chỉ 1 codebase mà hơn 5 team vào làm việc trên đó thì thôi xong
• Bạn muốn có 1 codebase viết bằng typescript, một codebase viết js, một feature được build bằng React, feature khác được build Vue

Micro frontend là cái gì

Đây là cách tiếp cận cũng na ná như microservice, thay vì 1, chúng ta có nhiều codebase, và trên từng codebase chỉ quản lý một tính năng cụ thể mà thôi.

Có thể xem một ứng dụng web là một bộ kết hợp của nhiều tính năng, mỗi một tính năng như vậy được quản lý bởi một team

Thuật ngữ này được giới thiệu lần đầu vào 2016 bởi Thourghtworks Tech Radar

An architectural style where independently deliverable frontend applications are composed into a greater whole

Một cách trực quan hơn bạn có thể tham khảo hình sau

Còn đây là demo của trang microfrontends.com https://demo.microfrontends.com/

Hiện thực hóa như thế nào

Để có thể hiện thực hóa hoàn chỉnh micro frontend sẽ bao gồm rất nhiều thứ, ở đây chỉ tóm tắt một số vấn đề cơ bản cần giải quyết

Tương tác giữa các ứng dụng

Một câu hỏi được đặt ra đầu tiên là nếu tách ra thành nhiều bộ source như vậy, làm sao chúng có thể nói chuyện được với nhau? Một cách tổng quát, nên hạn chế việc trao đổi thông tin qua lại ít chừng nào tốt chừng đó, bởi vì nếu bạn làm ngược lại, nghĩa là bạn đang lặp lại vấn đề chúng ta muốn giải quyết ngay từ đâu: decoupling các tính năng với nhau.

Nhưng việc trao đổi giữa các ứng dụng với nhau là không tránh khỏi và cần thiết, chúng ta chỉ tiết chế chứ không loại bỏ hết, Custom event là một cách, cách khác, lấy mô hình truyền callback và data từ trên xuống trong React để làm kênh trao đổi thông tin, làm như thế nó sẽ rất tường minh, cách thứ 3 là thông qua thanh đường dẫn trên trình duyệt, chút nữa nói kỹ hơn.

Tựa chung, chúng ta không share state, mà chỉ share dữ liệu trong database như microservice.

Thư viện component dùng chung

Nó chung, ý tưởng re-use lại những component UI không có gì mới, nghe cũng rất hợp lý, mặc dù ai cũng biết việc đó khó làm.

Sai lầm thường thấy là việc tạo các component như vậy quá sớm, việc hào hứng quá mức vào xây dựng một Framework UI chuẩn không cần chỉnh, viết một lần xài mãi mãi, thống nhất giao diện trên mọi mặt trận là điều thường thấy ở mọi team. Tuy nhiên, trong thực tế, kinh nghiệm cho biết rằng việc đó rất khó, nếu không muốn nói là không thể, không thể ngồi nghĩ ra một bộ Framework với tất cả các API cần thiết rồi đưa cho tất cả các team xài, chắc gì API đó đã đáp ứng đúng nhu cầu cho tất cả các team? Lời khuyên là các team cứ tạo ra những component riêng trong codebase nếu họ thấy cần, dù cho nó có bị duplicate đây nữa cũng chẳng sao. Và khi đã chín mùi, những API nào cần thiết sẽ hiện nguyên hình, chúng ta đưa những cho đang bị duplicate vào trong thư viện dùng chung.

Tất nhiên cũng có những ngoại lệ, những component mà nhìn vào chúng ta biết ngay là cần đưa vào share component, như icon, label, button, autocomplete, drop-down, search, table. Và nhớ là chỉ đưa đúng UI logic, đừng đưa bất kỳ business logic và domain logic vào đây. Ví dụ như một component ProductTable cho riêng cái domain Product là không nên, chỉ nên làm một cái component Table.

Thoạt nghe làm một share component có vẻ đơn giản, nhưng nó lại là công việc đòi hỏi kỹ thuật phải rất cứng tay, và người có nhúng tay vào tất cả các team.

Styling

Styling 2020 là một câu chuyện dài, như mình đã kể trong một bài viết, tựa chung mà nói bạn có thể dùng BEM, dùng SASS, dùng CSS module, dùng CSS-in-JS, dùng Styled Component, dùng Tailwind, kiểu gì cũng được, miễn đảm bảo được style không chồng chéo lên nhau, thằng nào độc lập thằng đó, và tự tin đoạn code nó sẽ chạy như đúng như lường trước.

Các cách để integrate

Để hiện thực hóa ý tưởng của micro frontend, cũng có nhiều cách làm, cách nào cũng có đánh đổi. Tựu chung, nếu xét theo hướng giao diện, chúng ta có thể tổ chức nó theo dạng một ứng dụng dạng container, bao gồm những thành phần chung như header, menu, và các micro frontend sẽ nhúng vào phần ruột của trang

Cách 1: composition dùng server side template

Với một cách không chính thống lắm cho việc phát triển code FE, chúng ta render HTML ở phía server, với nhiều bộ template khác nhau. Chúng ta có một file index.html với các phần tử chung, server sẽ quyết định phần ruột trả về cho từng trang

<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>Feed me</title>
  </head>
  <body>
    <h1>🍽 Feed me</h1>
    <!--# include file="$PAGE.html" -->
  </body>
</html>

Ở ví dụ này đang dùng với Nginx, biến $PAGE sẽ ứng với URL đang được request

server {
    listen 8080;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;
    ssi on;

    # Redirect / đến /browse
    rewrite ^/$ http://localhost:8080/browse redirect;

    # Dùng HTML nào để insert dựa vào URL
    location /browse {
      set $PAGE 'browse';
    }
    location /order {
      set $PAGE 'order';
    }
    location /profile {
      set $PAGE 'profile'
    }

    # Cho phép render ở index.html
    error_page 404 /index.html;
}

Kỹ thuật này mình không nắm lắm, nên cũng chỉ để đây cho các bạn tham khảo, trong thực tế mình gặp và làm việc với những cách làm bên dưới nhiều hơn.

Integrate lúc build

Cách này sẽ publish cái micro frontend ở dạng package, container sẽ khai báo những micro frontend này ở dạng dependency. File package.json nó sẽ trông như thế này:

{
  "name": "@feed-me/container",
  "version": "1.0.0",
  "description": "A food delivery web app",
  "dependencies": {
    "@feed-me/browse-restaurants": "^1.2.3",
    "@feed-me/order-food": "^4.5.6",
    "@feed-me/user-profile": "^7.8.9"
  }
}

Thoạt nhìn, cũng khá hợp lý, tuy nhiên nếu để ý, bạn sẽ thấy chúng ta phải re-compile và release trên từng cục dependency, rồi sao đó lại phải release tiếp container. Đây vẫn không phải là cách làm được khuyến khích.

Integrate lúc run-time bằng iframe

Đây cũng là cách mà dự án mình đang dùng, một cách tiếp cận đơn giản nhất để compose nhiều ứng dụng với nhau trong trình duyệt đã có từ rất rất lâu. Lợi ích có thể kể thêm của cách làm này là phần styling và biến global đều độc lập và không bị đụng độ lẫn nhau

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <iframe id="micro-frontend-container"></iframe>

    <script type="text/javascript">
      const microFrontendsByRoute = {
        '/': 'https://browse.example.com/index.html',
        '/order-food': 'https://order.example.com/index.html',
        '/user-profile': 'https://profile.example.com/index.html',
      };

      const iframe = document.getElementById('micro-frontend-container');
      iframe.src = microFrontendsByRoute[window.location.pathname];
    </script>
  </body>
</html>

Nhược điểm của cách này là việc tích hợp giữa các phần của ứng dụng, như route, history, deep-link sẽ rất phức tạp, responsive cũng sẽ gặp nhiều vấn đề cần xử lý hơn.

Integrate lúc run-time bằng JavaScript

Đây là cách linh hoạt nhất, và được nhiều team chọn làm. Mỗi một micro frontend sẽ được nhét vào trong trang bằng thẻ <script />. Container sẽ làm nhiệm vụ cho mount micro frontend nào và thực thi các hàm liên quan để báo cho các micro frontend sẽ render ở đâu và khi nào.

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <!-- Nó không render bất cứ gì cả -->
    <!-- Nó sẽ đưa vào hàm entry-point vào `window` -->
    <script src="https://browse.example.com/bundle.js"></script>
    <script src="https://order.example.com/bundle.js"></script>
    <script src="https://profile.example.com/bundle.js"></script>

    <div id="micro-frontend-root"></div>

    <script type="text/javascript">
      // Những global function này được nhét vào window bằng các đoạn script include ở trên
      const microFrontendsByRoute = {
        '/': window.renderBrowseRestaurants,
        '/order-food': window.renderOrderFood,
        '/user-profile': window.renderUserProfile,
      };
      const renderFunction = microFrontendsByRoute[window.location.pathname];

      // Sau khi đã có các hàm cần thiết,
      // đưa id của element sẽ dùng để render
      renderFunction('micro-frontend-root');
    </script>
  </body>
</html>

Trên đây chỉ là ví dụ cơ bản nhất để mô tả kỹ thuật sẽ làm, thật tế có thể phải thêm thắt một số thứ khác. Không giống với cách integrate lúc build, bundle.js có thể được deploy một cách độc lập. Và khác iframe, chúng ta có thể linh động chọn lựa việc render micro frontend nào chúng ta thích.

Nếu có hứng thú với cách làm này, có thể tham khảo thêm ví dụ chi tiết hơn

Integrate lúc run-time bằng Web Component

Một lựa chọn khác cũng tương tự như cách làm trên, mỗi một micro frontend sẽ được link với element

<html>
  <head>
    <title>Feed me!</title>
  </head>
  <body>
    <h1>Welcome to Feed me!</h1>

    <!-- Chưa render gì cả -->
    <script src="https://browse.example.com/bundle.js"></script>
    <script src="https://order.example.com/bundle.js"></script>
    <script src="https://profile.example.com/bundle.js"></script>

    <div id="micro-frontend-root"></div>

    <script type="text/javascript">
      // Những element type này được định nghĩa ở các script trên
      const webComponentsByRoute = {
        '/': 'micro-frontend-browse-restaurants',
        '/order-food': 'micro-frontend-order-food',
        '/user-profile': 'micro-frontend-user-profile',
      };
      const webComponentType = webComponentsByRoute[window.location.pathname];

      // Tạo instance và đưa vào document ứng với từng loại phù hợp
      const root = document.getElementById('micro-frontend-root');
      const webComponent = document.createElement(webComponentType);
      root.appendChild(webComponent);
    </script>
  </body>
</html>

Khác nhau duy nhất so với cách trên có lẽ chỉ là việc dùng web component thay vì một interface chúng ta tự định nghĩa.

Trao đổi giữa Backend

Cái này chưa biết, không dám chém.

Kết

Micro frontend có thể không lạ với một số người và khá mới với số còn lại, thực tế mà nói đã có rất nhiều dự án đang áp dụng kiến trúc này (dự án mình đang làm).

Cùng hy vọng với bài viết này bạn đã thấy công việc của những lập trình viên frontend không còn đơn thuần là việc làm sao cho trang web bay, lượn, responsive mượt mà, nếu bạn muốn tiến xa hơn, giới hạn là chân trời.

Các bài viết đã tham khảo

• https://martinfowler.com/articles/micro-frontends.html
• https://microfrontends.com/
• https://micro-frontends.org/