Các mẫu kết xuất Jamstack: Sự phát triển

[theanh]

Vào những ngày đầu của Jamstack, các nhà phát triển chủ yếu sử dụng nó cho các trang web tĩnh và lựa chọn một khuôn khổ giao diện người dùng chi tiết hơn như Vue và React khi họ cần thực hiện các hoạt động phức tạp hơn như kết xuất phía máy chủ trong các ứng dụng web. Nhu cầu thêm các chức năng động vào các ứng dụng web không bao giờ biến mất, nhưng điều đó không khiến chúng tôi đánh giá thấp Jamstack. Chúng tôi thích những gì nó đề xuất và giá trị mà nó cung cấp. Các trang web có sẵn ngay lập tức cho người dùng và các nhà phát triển có thể xây dựng trang web dễ dàng và triển khai chúng nhanh hơn. Người dùng hài lòng, các nhà phát triển cũng hài lòng; đây là một chiến thắng đôi bên cùng có lợi.

Sau đó, các trình tạo trang web tĩnh xuất hiện giúp mọi thứ tốt hơn bằng cách thêm quy trình xây dựng vào luồng trước đó của một trang web tĩnh, nghĩa là tất cả các tài sản của trang web đều được tạo trước bởi một máy chủ xây dựng (không phải trên máy cục bộ) và sau đó được triển khai. Đây là một bước tiến trong việc cải thiện trải nghiệm của nhà phát triển Jamstack và do đó là sự phổ biến của mô hình này. Các nhà phát triển có thể xây dựng các trang Jamstack bằng trình tạo trang tĩnh như Gatsby, đẩy dự án lên hệ thống kiểm soát phiên bản như Github và triển khai lên dịch vụ lưu trữ như Netlify cung cấp quy trình làm việc sẽ xây dựng lại trang khi có bản cập nhật cho dự án.

Mọi thứ có vẻ tuyệt vời và tất cả chúng tôi đều tốt hơn vì điều đó.

Nhưng giống như mọi công nghệ khác, Jamstack bắt đầu phát triển khi nhu cầu về các chức năng phức tạp hơn tiếp tục tăng. Là một "trang tĩnh", trang Jamstack bị hạn chế về những thứ nó có thể làm và mọi người không giữ im lặng về điều đó. Đột nhiên, có vẻ như Jamstack là một mô hình chưa hoàn chỉnh và không thể sử dụng ở quy mô lớn. Những lo ngại nêu ra chủ yếu xoay quanh việc không thể thực hiện các hoạt động phía máy chủ và thời gian xây dựng dài trong các trang Jamstack lớn hơn. Điều này không phù hợp với cộng đồng Jamstack và chúng tôi bắt đầu "mở rộng" Jamstack để giải quyết thách thức mới này, mà ban đầu nó không có ý định giải quyết.

Chức năng động trong Jamstack​

Trong khi Gatsby đã có nhiều tiến bộ trong cách chúng tôi xây dựng và cập nhật các trang web Jamstack với các tính năng như bản dựng gia tăng, Next.js đã giới thiệu kết xuất phía máy chủ với getServerSideProps():

function Page({ data }) { // Kết xuất dữ liệu...}// Điều này được gọi trong mọi yêu cầuexport async function getServerSideProps() { const res = await fetch(`https://.../data`) const data = await res.json() // Truyền dữ liệu đến trang thông qua props return { props: { data } }}export default Page

Trong khi vẫn duy trì thế hệ tĩnh cũ tốt với getStaticProps():

// các bài đăng sẽ được điền vào thời điểm xây dựng bởi getStaticProps()function Blog({ posts }) { return ( [LIST] {posts.map((post) => ( 
[*] {post.title}))} [/LIST])}export async function getStaticProps() { const res = await fetch('https://.../posts') const posts = await res.json( return { props: { posts, }, }}export default Blog

Điều này đã mang đến cho các nhà phát triển ý tưởng về một phương pháp tiếp cận kết hợp để xây dựng các trang Jamstack. Đột nhiên, bạn có thể xây dựng các trang Jamstack có thể hiển thị các trang khác nhau với các mẫu hiển thị khác nhau. Ví dụ, trang /about của bạn có thể được tạo tĩnh trong khi trang /cart của bạn được hiển thị phía máy chủ. Tuy nhiên, vấn đề về thời gian xây dựng lâu vẫn còn. Nhưng không lâu nữa.

Với Incremental Static Regeneration (ISR), Next.js cũng cho phép tạo các trang theo yêu cầu và lưu vào bộ nhớ đệm cho các yêu cầu tiếp theo. Điều này có nghĩa là các nhà phát triển có thể có một trang web với 10.000 trang và chỉ tạo 100 trang tại thời điểm xây dựng. Tất cả các trang khác sẽ được tạo động theo yêu cầu và lưu vào bộ nhớ đệm cho các yêu cầu tiếp theo, giúp loại bỏ mối lo ngại về thời gian xây dựng lâu.

function Blog({ posts }) { return ( [LIST] {posts.map((post) => ( 
[*] {post.title}))} [/LIST])}export async function getStaticProps() { const res = await fetch('https://.../posts') const posts = await res.json() return { props: { posts, }, revalidate: 10, // In seconds }}export async function getStaticPaths() { const res = await fetch('https://.../posts', {limit: 100}) const posts = await res.json() // Lấy các đường dẫn chúng ta muốn pre-render dựa trên các bài đăng const paths = posts.map((post) => ({ params: { id: post.id }, })) return { paths, fallback: 'blocking' }}export default Blog

Kết xuất liên tục phân tán (DPR)​

Vào tháng 4 năm 2021, Netlify đã công bố một mẫu kết xuất mới có tên là Kết xuất liên tục phân tán. Ý tưởng là xóa bit xác thực lại của ISR và biến bất kỳ trang nào được kết xuất sau lần dựng ban đầu thành một phần cố định của bản dựng đó. Không xác thực lại. Nếu bạn muốn kết xuất lại trang đó trong tương lai, bạn sẽ cần kích hoạt một bản dựng mới. Theo bài đăng thông báo, mô hình này sẽ không làm ảnh hưởng đến nguyên tắc triển khai nguyên tử bất biến của Jamstack.

Cùng với thông báo DPR, Netlify cũng đã ra mắt trình xây dựng theo yêu cầu — Một loại hàm không có máy chủ đặc biệt tạo nội dung theo yêu cầu, lưu trữ đệm tại biên và hoạt động trên mọi khuôn khổ. Điều này mang lại khả năng giống như ISR cho mọi trình tạo trang web tĩnh và siêu khuôn khổ khác.

const { builder } = require('@netlify/functions');async function myfunction(event, context) { // logic để tạo nội dung cần thiết}exports.handler = builder(myfunction);

Điều này mở ra nhiều cơ hội hơn cho các trình tạo trang web tĩnh như Gatsby tham gia vào mô hình cung cấp các trang web với sự điều chỉnh riêng của họ về khái niệm được gọi là Deferred Static Generation (DSG). Eleventy cũng đã phát hành Plugin Eleventy Serverless xây dựng dựa trên khái niệm DPR để hỗ trợ mẫu kết xuất này cho các nhà phát triển.

Deferred Static Generation (DSG)​

Như đã đề cập, Gatsby đã điều chỉnh khái niệm DPR để tạo ra mẫu kết xuất DSG tùy chỉnh cho phép các nhà phát triển trì hoãn các trang không quan trọng và chỉ tạo nội dung cần thiết tại thời điểm xây dựng. Giống như ISR, các trang trì hoãn được tạo theo yêu cầu và được lưu vào bộ nhớ đệm. Sau đó, tất cả các yêu cầu tiếp theo đối với các trang đó được phục vụ từ bộ nhớ đệm.

// Phần còn lại của trang của bạn, bao gồm các mục nhập, thành phần trang & truy vấn trang, v.v.export async function config() { // Tùy chọn sử dụng GraphQL tại đây return ({ params }) => { return { defer: true, } }}

Mục tiêu của bài đăng này là xem xét sự phát triển của các mẫu kết xuất Jamstack, nơi chúng ta bắt đầu và nơi chúng ta đang ở. Hiện tại, chúng ta đã đi rất xa so với nơi chúng ta bắt đầu và có lý do chính đáng. Nhưng cá nhân tôi đang nghĩ, chúng ta có nên gắn bó với ý tưởng ban đầu về một trang web Jamstack không? Một trang web mà chúng ta không cần phải lo lắng về các chức năng động. Bây giờ là năm 2022 và có rất nhiều sắc thái xung quanh sự khác biệt giữa trang Jamstack và ứng dụng React thông thường.

Tóm tắt​

Jamstack đã biến đổi từ việc chỉ tạo và triển khai các tài sản tĩnh sang xử lý các chức năng cực kỳ năng động với các mẫu kết xuất nâng cao và các hàm không có máy chủ.

Đúng vậy, đã có những tiến bộ trong các mẫu kết xuất Jamstack và nó vẫn tiếp tục được cải thiện cho đến nay. Nhưng những cải tiến này do đó đã làm tăng thêm độ phức tạp cho một quy trình vốn đơn giản. Khi tiếp tục mở rộng Jamstack để tính đến nhiều trường hợp sử dụng hơn, chúng tôi có nguy cơ làm phức tạp quá mức.

Nhưng giống như mọi không gian khác, chúng tôi mong đợi sẽ thấy những cải tiến liên tục. Năm 2021 chứng kiến sự xuất hiện và thống trị của các meta framework như Astro, Slinkity và Remix — tất cả đều cố gắng đưa ít JavaScript hơn vào trình duyệt.

Đây có vẻ là hướng đi mà web đang thực hiện vào năm 2022 và chúng tôi hy vọng sẽ thấy nhiều giải pháp hơn xuất hiện trong hệ sinh thái để cải thiện đáng kể trải nghiệm Jamstack. Sự xuất hiện của React Server Components trong React, Vite như một giải pháp thay thế nhanh hơn cho Webpack và Babel, điện toán biên được sử dụng bởi những công ty như Remix, HTML Streaming, v.v., tất cả đều là những giải pháp đầy hứa hẹn đang tiếp tục trở nên phổ biến và được áp dụng rộng rãi. Và chúng ta chỉ có thể suy đoán rằng mọi thứ sẽ trở nên tốt hơn và thú vị hơn khi những công nghệ này thâm nhập vào cơ sở hạ tầng web hiện có. Có thể nói rằng những ngày tươi đẹp nhất của Jamstack vẫn còn ở phía trước.

Thực hành theo xu hướng web hiện đại để xây dựng các trang web được tối ưu hóa cao là đưa ít JavaScript hơn. Đây là nơi các công nghệ như Remix khẳng định sự thống trị. Thật thú vị khi theo dõi không gian Jamstack tiếp tục phát triển như thế nào và cá nhân tôi đang mong chờ bước tiếp theo sẽ là gì.

Nếu bạn đang xây dựng một trang web Jamstack ngày hôm nay, đây là các mẫu kết xuất hiện có sẵn cho bạn:

• Tạo tĩnh
  Các trang được kết xuất một lần tại thời điểm xây dựng.
• Kết xuất phía máy chủ
  Các trang được tạo theo từng yêu cầu.
• Kết xuất trì hoãn (ISR/DPR/DSG)
  Các trang quan trọng được tạo trước tại thời điểm xây dựng và các trang không quan trọng được tạo theo yêu cầu và được lưu vào bộ nhớ đệm.

Đọc thêm​

• Hướng dẫn đầy đủ về ISR với Next.js, Lee Robinson
• Jamstack CMS: Quá khứ, Hiện tại và Tương lai, Mike Neumegen
• Công cụ học tập tương tác dành cho nhà phát triển giao diện người dùng, Louis Lazaris
• Cách tạo trang web WordPress không có giao diện trên JAMstack, Sarah Drasner & Geoff Graham