Một mô hình mới cho Jamstack: Kết xuất phân đoạn

[theanh]

Nếu bạn nghĩ rằng kết xuất tĩnh chỉ giới hạn ở nội dung chung, công khai giống nhau cho mọi người dùng trang web của bạn, bạn chắc chắn nên đọc bài viết này.

Kết xuất phân đoạn là một mẫu mới cho Jamstack cho phép bạn cá nhân hóa nội dung tĩnh, không cần bất kỳ loại kết xuất phía máy khách hoặc Kết xuất phía máy chủ theo yêu cầu nào. Có nhiều trường hợp sử dụng: cá nhân hóa, quốc tế hóa, tạo chủ đề, đa thuê bao, thử nghiệm A/B…

Hãy tập trung vào một kịch bản rất hữu ích cho chủ sở hữu blog: xử lý nội dung trả phí.

Chúc mừng bạn đã có công việc mới​

Ồ, bạn vừa được thăng chức! Bây giờ bạn là "Trưởng phòng Hiệu suất" tại Repairing Magazine, đối thủ cạnh tranh nghiêm túc nhất của Smashing Magazine. Repairing Magazine có một mô hình kinh doanh rất kỳ lạ. Những câu chuyện cười dí dỏm trong mỗi bài viết chỉ hiển thị với người dùng trả phí.

"Tại sao lập trình viên lại băng qua đường?"

Tôi cá là bạn sẽ trả tiền để biết câu trả lời.

Công việc của bạn hôm nay là triển khai tính năng này với hiệu suất tốt nhất có thể. Chúng ta hãy xem bạn có thể làm được điều đó như thế nào. Gợi ý: chúng tôi sẽ giới thiệu một mẫu mới có tên là “Segmented Rendering”.

Nhiều cách để render trang web bằng các framework JavaScript hiện đại​

Next.js trở nên phổ biến nhờ khả năng làm chủ “Triforce of Rendering”: khả năng kết hợp render phía máy khách, render máy chủ theo yêu cầu và render tĩnh trong một framework duy nhất.

CSR, SSR, SSG… Hãy cùng làm rõ chúng là gì​

Sửa chữa giao diện người dùng của Tạp chí dựa trên thư viện JavaScript hiện đại, React. Giống như các thư viện UI tương tự khác, React cung cấp hai cách render nội dung: phía máy khách và phía máy chủ.

Client-Side Rendering (CSR) diễn ra trong trình duyệt của người dùng. Trước đây, chúng ta sẽ sử dụng jQuery để thực hiện CSR.

Kết xuất phía máy chủ diễn ra trên máy chủ của riêng bạn, tại thời điểm yêu cầu (SSR) hoặc tại thời điểm xây dựng (tĩnh hoặc SSG). SSR và SSG cũng tồn tại bên ngoài hệ sinh thái JavaScript. Ví dụ, hãy nghĩ đến PHP hoặc Jekyll.

Hãy xem các mẫu đó áp dụng như thế nào vào trường hợp sử dụng của chúng ta.

CSR: Vấn đề về trình tải xấu xí​

Kết xuất phía máy khách (CSR) sẽ sử dụng JavaScript trong trình duyệt để thêm các câu chuyện cười dí dỏm sau khi trang được tải. Chúng ta có thể sử dụng "fetch" để lấy nội dung câu chuyện cười, sau đó chèn chúng vào DOM.

// server.jsconst wittyJoke = "Tại sao lập trình viên băng qua đường?\ Có điều gì đó anh ta muốn C.";app.get("/api/witty-joke", (req) => { if (isPaidUser(req)) { return { wittyJoke }; } else { return { wittyJoke: null }; }});// client.jsconst ClientArticle = () => { const { wittyJoke, loadingJoke } = customFetch("/api/witty-jokes"); // TÔI KHÔNG THÍCH ĐIỀU NÀY... if (loadingJoke) return 
Bộ tải xấu xí
; return ( 
 {wittyJoke ? wittyJoke : "Bạn phải trả tiền để xem truyện cười.\ Hài hước là một công việc nghiêm túc."} 
 );};

CSR liên quan đến các tính toán dư thừa ở phía máy khách và rất nhiều trình tải xấu xí.

Nó hiệu quả, nhưng liệu đó có phải là cách tiếp cận tốt nhất không? Máy chủ của bạn sẽ phải phục vụ những câu chuyện cười dí dỏm cho mỗi người đọc. Nếu bất cứ điều gì khiến mã JavaScript bị lỗi, người dùng trả phí sẽ không được vui vẻ và có thể tức giận. Nếu người dùng có mạng chậm hoặc máy tính chậm, họ sẽ thấy một trình tải xấu xí trong khi trò đùa của họ đang được tải xuống. Hãy nhớ rằng hầu hết khách truy cập duyệt qua thiết bị di động!

Vấn đề này chỉ trở nên tồi tệ hơn khi số lượng lệnh gọi API tăng lên. Hãy nhớ rằng trình duyệt chỉ có thể chạy một số ít yêu cầu song song (thường là 6 yêu cầu trên mỗi máy chủ/proxy). Kết xuất phía máy chủ không bị giới hạn này và sẽ nhanh hơn khi truy xuất dữ liệu từ các dịch vụ nội bộ của riêng bạn.

SSR theo yêu cầu: Bitten By The First Byte​

Kết xuất phía máy chủ (SSR) theo yêu cầu tạo nội dung theo yêu cầu, trên máy chủ. Nếu người dùng được trả tiền, máy chủ sẽ trả về toàn bộ bài viết trực tiếp dưới dạng HTML. Nếu không, nó sẽ trả về bài viết nhạt nhẽo không có bất kỳ sự thú vị nào trong đó.

// page.js: server-codeasync function getServerSideProps(req) { if (isPaidUser(req)) { const { wittyJoke } = getWittyJoke(); return { wittyJoke }; } else { return { wittyJoke: null }; }}// page.js: mã máy kháchconst SSRArticle = ({ wittyJoke }) => { // Không còn trình tải nữa! Nhưng... // chúng ta cần đợi "getServerSideProps" chạy trên mọi yêu cầu trả về ( 
 {wittyJoke ? wittyJoke : "Bạn phải trả tiền để xem truyện cười. Hài hước là một công việc nghiêm túc."} 
 );};

SSR xóa các tính toán phía máy khách, nhưng không xóa thời gian tải.

Chúng tôi không còn dựa vào JavaScript phía máy khách nữa. Tuy nhiên, việc hiển thị bài viết cho từng yêu cầu không hiệu quả về mặt năng lượng. Thời gian đến byte đầu tiên (TTFB) cũng tăng lên vì chúng tôi phải đợi máy chủ hoàn tất công việc trước khi chúng tôi bắt đầu thấy một số nội dung.

Chúng tôi đã thay thế trình tải phía máy khách xấu xí bằng một màn hình trống thậm chí còn xấu hơn! Và bây giờ chúng tôi thậm chí còn phải trả tiền cho nó!

Chiến lược kiểm soát bộ đệm "stale-while-revalidate" có thể giảm sự cố TTFB bằng cách phục vụ phiên bản bộ đệm của trang cho đến khi nó được cập nhật. Nhưng nó sẽ không hoạt động ngay lập tức đối với nội dung được cá nhân hóa, vì nó chỉ có thể lưu trữ đệm một phiên bản của trang trên mỗi URL mà không tính đến cookie và không thể xử lý các kiểm tra bảo mật cần thiết để phục vụ nội dung trả phí.

Kết xuất tĩnh: Chìa khóa cho vấn đề Khách giàu/Khách hàng nghèo​

Lúc này, bạn đang gặp phải vấn đề mà tôi gọi là "khách giàu/khách hàng nghèo": người dùng cao cấp của bạn có hiệu suất kém nhất thay vì có hiệu suất tốt nhất.

Theo thiết kế, kết xuất phía máy khách và kết xuất phía máy chủ theo yêu cầu liên quan đến nhiều phép tính nhất so với kết xuất tĩnh, chỉ xảy ra một lần tại thời điểm xây dựng.

99% các trang web mà tôi biết sẽ chọn CSR hoặc SSR và gặp phải vấn đề khách giàu/khách hàng nghèo.

Đi sâu vào kết xuất phân đoạn​

Kết xuất phân đoạn chỉ là một cách thông minh hơn để thực hiện kết xuất tĩnh. Khi bạn hiểu rằng tất cả là về việc lưu trữ kết xuất bộ nhớ đệm và sau đó nhận được kết xuất bộ nhớ đệm phù hợp cho mỗi yêu cầu, mọi thứ sẽ trở nên dễ dàng.

Kết xuất tĩnh mang lại hiệu suất tốt nhất nhưng kém linh hoạt hơn​

Tạo trang web tĩnh (SSG) tạo nội dung tại thời điểm dựng. Đó là cách tiếp cận hiệu suất nhất vì chúng tôi kết xuất bài viết một lần cho tất cả. Sau đó, nó được phục vụ dưới dạng HTML thuần túy.

Điều này giải thích tại sao kết xuất trước tại thời điểm dựng là một trong những nền tảng của triết lý Jamstack. Với tư cách là "Trưởng phòng Hiệu suất" mới được thăng chức, đó chắc chắn là điều bạn muốn!

Tính đến năm 2022, tất cả các khuôn khổ Jamstack đều có cách tiếp cận kết xuất tĩnh gần giống nhau:

• bạn tính toán danh sách tất cả các URL có thể;
• bạn kết xuất một trang cho mỗi URL.

const myWittyArticles = [ "/how-to-repair-a-smashed-magazine", "/segmented-rendering-makes-french-web-dev-famous", "/jamstack-is-so-2022-discover-haystack",];

Kết quả của bước đầu tiên của kết xuất tĩnh: tính toán một loạt các URL mà bạn sẽ kết xuất trước. Đối với blog, thường là danh sách tất cả các bài viết của bạn. Ở bước 2, bạn chỉ cần hiển thị từng bài viết, mỗi bài viết một URL.

Điều này có nghĩa là một URL chỉ tương đương với một phiên bản của trang. Bạn không thể có phiên bản trả phí và phiên bản miễn phí của bài viết trên cùng một URL ngay cả đối với những người dùng khác nhau. URL /how-to-repair-a-smashed-magazine sẽ cung cấp cùng một nội dung HTML cho mọi người, mà không có bất kỳ tùy chọn cá nhân hóa nào. Không thể tính đến cookie yêu cầu.

Kết xuất phân đoạn có thể tiến xa hơn một bước và hiển thị các biến thể khác nhau cho cùng một URL. Hãy cùng tìm hiểu cách thực hiện.

Tách URL và Biến thể Trang​

Giải pháp ngây thơ nhất để cho phép nội dung được cá nhân hóa là thêm một tham số tuyến đường mới vào URL, ví dụ, "with-jokes" so với "bland".

const premiumUrl = "/with-jokes/how-to-repair-a-smashed-magazine";const freeUrl = "/bland/how-to-repair-a-smashed-magazine";

Một triển khai với Next.js sẽ trông giống như thế này:

async function getStaticPaths() { return [ // cho người dùng trả phí "/with-jokes/how-to-repair-a-smashed-magazine", // cho người dùng miễn phí "/bland/how-to-repair-a-smashed-magazine", ];}async function getStaticProps(routeParam) { if (routeParam === "with-jokes") { const { wittyJoke } = getWittyJoke(); return { wittyJoke }; } else if (routeParam === "bland") { return { wittyJoke: null }; }}

Hàm đầu tiên tính toán 2 URL cho cùng một bài viết, một bài vui và một bài nhạt nhẽo. Hàm thứ hai nhận được trò đùa, nhưng chỉ dành cho phiên bản trả phí.

Tuyệt, bạn có 2 phiên bản bài viết của mình. Chúng ta có thể bắt đầu thấy "Segments" trong "Segmented Rendering" — người dùng trả phí so với người dùng miễn phí, với một phiên bản được hiển thị cho mỗi phân đoạn.

Nhưng bây giờ, bạn có một vấn đề mới: làm thế nào để chuyển hướng người dùng đến đúng trang? Dễ thôi: chuyển hướng người dùng đến đúng trang, theo đúng nghĩa đen! Với một máy chủ và tất cả!

Lúc đầu nghe có vẻ kỳ lạ khi bạn cần một máy chủ web để đạt được hiệu suất hiển thị tĩnh hiệu quả. Nhưng hãy tin tôi về điều này: cách duy nhất để đạt được hiệu suất tốt nhất cho một trang web tĩnh là thực hiện một số tối ưu hóa máy chủ.

Lưu ý về máy chủ "tĩnh"​

Nếu bạn đến từ hệ sinh thái Jamstack, bạn có thể yêu thích lưu trữ tĩnh. Còn gì tuyệt vời hơn việc đẩy một vài tệp và đưa trang web của bạn lên và chạy trên GitHub Pages? Hoặc lưu trữ một ứng dụng hoàn chỉnh trực tiếp trên Mạng phân phối nội dung (CDN)?

Tuy nhiên, "lưu trữ tĩnh" không có nghĩa là không có máy chủ. Nó có nghĩa là bạn không thể kiểm soát máy chủ. Vẫn có một máy chủ chịu trách nhiệm trỏ từng URL đến đúng tệp tĩnh.

Lưu trữ tĩnh nên được coi là tùy chọn hạn chế nhưng rẻ và hiệu quả để lưu trữ trang web cá nhân hoặc trang đích của công ty. Nếu bạn muốn tiến xa hơn thế, bạn sẽ cần kiểm soát máy chủ, ít nhất là để xử lý những thứ như chuyển hướng dựa trên cookie yêu cầu hoặc tiêu đề.

Tuy nhiên, không cần gọi cho chuyên gia về phần phụ trợ. Chúng ta không cần bất kỳ loại tính toán phức tạp nào. Một máy chủ chuyển hướng rất cơ bản có thể kiểm tra xem người dùng đã trả phí hay chưa là đủ.

Tin tuyệt vời: các máy chủ hiện đại như Vercel hoặc Netlify triển khai Edge Handlers, chính xác là những gì chúng ta cần ở đây. Next.js triển khai các Edge Handler đó dưới dạng "phần mềm trung gian", do đó bạn có thể mã hóa chúng bằng JavaScript.

"Edge" có nghĩa là các phép tính diễn ra càng gần người dùng cuối càng tốt, trái ngược với việc có một vài máy chủ tập trung lớn. Bạn có thể coi chúng như những bức tường bên ngoài của cơ sở hạ tầng cốt lõi của mình. Chúng rất tuyệt vời cho việc cá nhân hóa, thường liên quan đến vị trí địa lý thực tế của người dùng.

Chuyển hướng dễ dàng với phần mềm trung gian Next.js​

Phần mềm trung gian Next.js cực kỳ nhanh và cực kỳ đơn giản để mã hóa. Ngược lại với các proxy đám mây như AWS Gateway hoặc các công cụ nguồn mở như Nginx, phần mềm trung gian được viết bằng JavaScript, sử dụng các tiêu chuẩn Web, cụ thể là fetch API.

Trong kiến trúc “Segmented Rendering”, phần mềm trung gian chỉ chịu trách nhiệm chỉ định từng yêu cầu của người dùng đến đúng phiên bản của trang:

import { NextResponse } from "next/server";import type { NextRequest } from "next/server";async function middleware(req: NextRequest) { // isPaidFromReq có thể đọc cookie, lấy mã xác thực // và xác minh xem người dùng có thực sự là thành viên trả phí hay không const isPaid = await isPaidFromReq(req); const routeParam = isPaid ? "with-jokes" : "bland"; return NextResponse.redirect( `/${routeParam}/how-to-repair-a-smashed-magazine` );}

Một phần mềm trung gian triển khai Segmented Rendering cho người dùng trả phí và miễn phí.

Vâng, thế là xong. Ngày đầu tiên của bạn với tư cách là "Trưởng phòng Hiệu suất" đã kết thúc. Bạn có mọi thứ cần thiết để đạt được hiệu suất tốt nhất có thể cho mô hình kinh doanh kỳ lạ của mình!

Tất nhiên, bạn có thể áp dụng mô hình này cho nhiều trường hợp sử dụng khác: nội dung quốc tế hóa, thử nghiệm A/B, chế độ sáng/tối, cá nhân hóa… Mỗi biến thể của trang của bạn tạo nên một “Phân khúc” mới: người dùng Pháp, những người thích chủ đề tối hoặc người dùng trả phí.

Cherry On The Top: Viết lại URL​

Nhưng này, bạn là “Trưởng nhóm Hiệu suất”, chứ không phải “Hiệu suất trung bình”! Bạn muốn ứng dụng web của mình hoàn hảo, chứ không chỉ tốt! Trang web của bạn chắc chắn rất nhanh trên mọi số liệu, nhưng giờ URL bài viết của bạn trông như thế này:

/bucket-A/fr/light/with-jokes/3-tips-to-make-an-url-shorter

Trông không đẹp mắt cho lắm… Kết xuất phân đoạn rất tuyệt, nhưng người dùng cuối không cần phải biết về các "phân đoạn" của riêng nó. Hình phạt cho công việc tốt là phải làm nhiều việc hơn, vì vậy hãy thêm một nét chấm phá cuối cùng: thay vì sử dụng chuyển hướng URL, hãy sử dụng viết lại URL. Chúng hoàn toàn giống nhau, ngoại trừ việc bạn sẽ không thấy các tham số trong URL.

// Viết lại sẽ không thay đổi URL mà người dùng cuối nhìn thấy// => họ sẽ không thấy "routeParam"return NextResponse.rewrite(`/${routeParam}/how-to-repair-a-smashed-magazine`);

URL /how-to-make-an-url-shorter, không có bất kỳ tham số tuyến đường nào, giờ đây sẽ hiển thị đúng phiên bản của trang tùy thuộc vào cookie của người dùng. Tham số tuyến đường vẫn "tồn tại" trong ứng dụng của bạn, nhưng người dùng cuối không thể nhìn thấy nó và URL vẫn sạch. Hoàn hảo.

Tóm tắt​

Để triển khai Kết xuất phân đoạn:

1. Xác định "phân đoạn" của bạn cho một trang.
   Ví dụ: người dùng trả phí so với người dùng miễn phí, người dùng từ công ty A so với người dùng từ công ty B hoặc C, v.v.
2. Kết xuất nhiều biến thể tĩnh của một trang tùy theo nhu cầu, với một URL cho mỗi phân đoạn.
   Ví dụ: /with-jokes/my-article, /bland/my-article. Mỗi biến thể phù hợp với một phân khúc, ví dụ, người dùng trả phí hoặc miễn phí.
3. Thiết lập một máy chủ chuyển hướng rất nhỏ, kiểm tra nội dung yêu cầu HTTP và chuyển hướng người dùng đến đúng biến thể, tùy thuộc vào phân khúc của họ.
   Ví dụ: người dùng trả phí được chuyển hướng đến /with-jokes/my-article. Chúng tôi có thể biết người dùng đã trả phí hay chưa bằng cách kiểm tra cookie yêu cầu của họ.

Tiếp theo là gì? Hiệu suất thậm chí còn cao hơn!​

Bây giờ bạn có thể có nhiều biến thể của cùng một trang tùy ý. Bạn đã giải quyết vấn đề của mình với người dùng trả phí một cách khéo léo. Tốt hơn, bạn đã triển khai một mẫu mới, Segmented Rendering, mang lại tính cá nhân hóa cho Jamstack mà không làm giảm hiệu suất.

Câu hỏi cuối cùng: điều gì xảy ra nếu bạn có nhiều kết hợp khả thi? Như 5 tham số với 10 giá trị cho mỗi tham số? Bạn không thể kết xuất vô số trang tại thời điểm xây dựng — điều đó sẽ mất quá nhiều thời gian. Và có thể bạn không thực sự có bất kỳ người dùng trả phí nào ở Pháp chọn chủ đề sáng và thuộc nhóm B để thử nghiệm A/B. Một số biến thể thậm chí không đáng để kết xuất.

Hy vọng rằng các khuôn khổ giao diện người dùng hiện đại sẽ giúp bạn giải quyết vấn đề này. Bạn có thể sử dụng một mẫu trung gian như Tái tạo tĩnh gia tăng từ Next hoặc Tái tạo tĩnh trì hoãn từ Gatsby, để chỉ hiển thị các biến thể theo yêu cầu.

Cá nhân hóa trang web là một chủ đề nóng, đáng buồn là lại trái ngược với hiệu suất và mức tiêu thụ năng lượng. Kết xuất phân đoạn giải quyết xung đột này một cách tinh tế và cho phép bạn hiển thị tĩnh bất kỳ nội dung nào, dù là nội dung công khai hay được cá nhân hóa cho từng phân khúc người dùng.

Thêm tài nguyên về chủ đề này​

• “Hãy mang Jamstack đến SaaS: Giới thiệu Rainbow Rendering,” Eric Burel
  Bài viết đầu tiên của tôi mô tả kiến trúc lý thuyết chung cho Segmented Rendering (hay còn gọi là “Rainbow Rendering”)
• “Đối xử đúng mực với người dùng của bạn bằng bộ đệm HTTP và Segmented Rendering,” Eric Burel
  Bài viết thứ hai của tôi trình bày về một triển khai với phần mềm trung gian Next.js
• “Kết xuất mọi thứ theo dạng tĩnh với Next.js và Megaparam,” Eric Burel
  Bài viết thứ ba của tôi, Kết xuất phân đoạn chỉ với bộ đệm HTTP (nếu bạn sử dụng Remix, bạn sẽ thích nó
• “Tạo tĩnh gia tăng cho nhiều đường dẫn kết xuất,” Eric Burel
  Vé GitHub trên Next.js đã bắt đầu tất cả.
• “Nền tảng lý thuyết cho kết xuất phía máy chủ và kết xuất tĩnh,” Eric Burel
  Bản thảo bài nghiên cứu của tôi mô tả toán học đằng sau SSR. Nó chứng minh rằng Segmented Rendering đạt được số lượng kết xuất tối ưu trong mọi tình huống. Bạn không thể vượt qua điều đó!
• “Cá nhân hóa hiệu suất cao với Next.js Middleware,” Raymond Cheng
  Một trường hợp sử dụng và minh họa tuyệt vời với Plasmic.
• “Kiểm tra A/B với Next.js Middleware,” Raymond Cheng
  Cũng từ Plasmic, Segmented Rendering đang được áp dụng cho các thử nghiệm A/B.
• “Sử dụng Eleventy Edge để cung cấp các trang web động trên Edge,” Blog Eleventy Edge
  Eleventy Edge, tích hợp sâu giữa 11ty và Netlify Edge Handlers để đạt được tính cá nhân hóa.
• “Vercel/Platforms,” Steven Tey
  Vercel Platforms, một ví dụ về kết xuất phân đoạn cho nhiều thuê bao.
• “Tránh thác truy vấn trong Remix Loaders,” Sergio Xalambrí
  Cách song song hóa đúng các yêu cầu truy xuất dữ liệu của bạn (trên ví dụ về Remix).

Đọc thêm​

• “Jamstack Rendering Patterns: The Evolution,” Ekene Eze
• “State Management In Next.js,” Átila Fassina
• “Jamstack CMS: The Past, The Present and The Future,” Mike Neumegen
• “A Complete Guide To Tái tạo tĩnh gia tăng (ISR) với Next.js,” Lee Robinson