شکستن ساخت های حجیم با Netlify و Next.js – مجله سر و صدا

درباره نویسنده

اتیلا فاسینا مأموریت دارد که کد را ساده کند. هنگام ضبط برنامه های نمایش یا دوره های آموزشی ، ممکن است متوجه شوید که او در حال نوشتن و صحبت در مورد jamstack است ،… اطلاعات بیشتر در مورد Átila

یکی از بزرگترین دردسرهای کار با وب سایت هایی که از نظر آماری تولید شده اند ، ساختن تدریجی کند رشد برنامه شما است. این یک مشکل اجتناب ناپذیر است که هر پشته در بعضی مواقع با آن روبرو می شود و بسته به نوع محصولی که کار می کنید می تواند از نقاط مختلف ایجاد شود.

به عنوان مثال ، اگر برنامه شما هنگام تولید مصنوع استقرار چندین صفحه (نمایش ، مسیر) داشته باشد ، هر یک از این مسیرها به یک پرونده تبدیل می شوند. سپس ، هنگامی که به هزاران نفر رسیدید ، این سوال برای شما پیش می آید که چه زمانی می توانید بدون نیاز به برنامه ریزی قبلی ، مستقر شوید؟ این سناریو در سیستم عامل ها یا وبلاگ های تجارت الکترونیکی رایج است ، که در حال حاضر بخش بزرگی از وب هستند ، اما نه همه آن. مسیرها تنها گلوگاه ممکن نیستند.

یک برنامه سنگین از منابع نیز سرانجام به این نقطه عطف خواهد رسید. بسیاری از ژنراتورهای استاتیک برای اطمینان از بهترین تجربه کاربر ، بهینه سازی دارایی را انجام می دهند. بدون بهینه سازی ساخت (ایجاد افزایشی ، حافظه پنهان ، به زودی به سراغ مواردی خواهیم رفت) در نهایت نیز غیرقابل کنترل خواهد شد – در مورد مرور همه تصاویر در یک وب سایت فکر کنید: تغییر اندازه ، حذف و / یا ایجاد پرونده های جدید بارها و بارها. و پس از اتمام همه کارها: به یاد داشته باشید Jamstack از لبه های صفحه به برنامه های ما سرویس می دهد شبکه تحویل محتوا. بنابراین ما هنوز باید مواردی را از سروری که در آن جمع شده اند به لبه های شبکه منتقل کنیم.

علاوه بر این ، یک واقعیت دیگر نیز وجود دارد: داده ها اغلب پویا هستند ، به این معنی که وقتی برنامه خود را می سازیم و آن را مستقر می کنیم ، ممکن است چند ثانیه ، چند دقیقه یا حتی یک ساعت طول بکشد. در همین حال ، جهان مرتباً در حال چرخش است و اگر ما اطلاعاتی را از جای دیگر می آوریم ، برنامه ما منسوخ می شود. غیر قابل قبول! برای به روزرسانی دوباره بسازید!

یک بار بسازید ، در صورت لزوم آن را به روز کنید

حل کردن بزرگ ساخته می شود در واقع برای مدتی هر پلتفرم ، چارچوب یا سرویس Jamstack در ذهن همه قرار داشته است. بسیاری از راه حل ها حول ساخت های افزایشی می چرخند. در عمل ، این بدان معنی است که سازه ها به اندازه تفاوت هایی که در برابر استقرار فعلی دارند ، حجیم خواهند بود.

تعریف a تفاوت هرچند الگوریتم کار آسانی نیست. برای کاربر نهایی برای بهره مندی از این بهبود ، راهکارهای بی اعتبار کردن حافظه پنهان وجود دارد که باید مورد توجه قرار گیرند. داستان کوتاه کوتاه: ما نمی خواهیم حافظه پنهان را برای یک صفحه یا دارایی تغییر نکرده بی اعتبار کنیم.

Next.js با بازسازی استاتیک افزایشی (ISR) در اصل ، این راهی است که برای هر مسیر اعلام می کند که چند بار می خواهیم دوباره ساخته شود. زیر کاپوت ، کار بسیاری را در سمت سرور ساده می کند. از آنجا که هر مسیر (پویا یا نه) با توجه به یک بازه زمانی خاص ، خود را بازسازی می کند و کاملاً در اصل Jamstack از نامعتبر بودن حافظه پنهان در هر ساختاری جا می گیرد. به آن فکر کنید max-age عنوان اما برای مسیرهای موجود در برنامه Next.js شما.

برای شروع برنامه ، ISR فقط یک ویژگی پیکربندی را دارد. روی م routeلفه مسیر (در داخل) /pages فهرست) به قسمت خود بروید getStaticProps روش و اضافه کردن revalidate کلید شی object برگشتی:

export async function getStaticProps() {
  const { limit, count, pokemons } = await fetchPokemonList()
  
  return {
    props: {
      limit,
      count,
      pokemons,
    },
    revalidate: 3600 // seconds
  }
}

قطعه بالا اطمینان حاصل خواهد کرد که صفحه من هر ساعت دوباره ساخته می شود و برای نمایش Pokémon بیشتر واکشی می شود.

هنوز هم هر از چندگاهی (هنگام صدور استقرار جدید) حجم عمده را بدست می آوریم. اما این به ما امکان می دهد با انتقال محتوا به a ، محتوا را از کد جدا کنیم سیستم مدیریت محتوا (CMS) فارغ از اینکه برنامه کاربردی ما چقدر باشد ، می توانیم اطلاعات را در چند ثانیه به روز کنیم. برای به روزرسانی غلط نویسی خداحافظ وب بوک ها!

سازندگان درخواستی

Netlify اخیراً راه اندازی شده است سازندگان درخواستی که رویکرد آنها در حمایت از ISR برای Next.js است ، اما در چهارچوبهایی از جمله Eleveny و Nuxt نیز کار می کند. در جلسه قبلی ، متوجه شدیم که ISR گامی بزرگ در جهت ساخت زمان کوتاه تر است و بخش قابل توجهی از موارد استفاده را مورد بررسی قرار داد. با این وجود ، هشدارها در آنجا وجود داشت:

1. ساخت کامل بر روی استقرار مداوم.
   مرحله افزایشی فقط اتفاق می افتد بعد از استقرار و برای داده ها. ارسال کد به صورت افزایشی امکان پذیر نیست
2. ساخت های افزایشی محصول زمان است.
   حافظه پنهان بر اساس زمان نامعتبر است. بنابراین ممکن است ساخت غیرضروری رخ دهد یا بسته به دوره اعتبارسنجی تنظیم شده در کد ، به روزرسانی های مورد نیاز ممکن است طولانی تر شوند.

زیرساخت جدید استقرار Netlify به توسعه دهندگان این امکان را می دهد تا منطقی ایجاد کنند تا مشخص کنند چه قسمت هایی از برنامه آنها بر اساس استقرار ایجاد می شود و چه قطعاتی به تعویق می افتد (و چگونه آنها به تعویق خواهد افتاد)

• بحرانی
  هیچ اقدامی لازم نیست. هر آنچه را که مستقر می کنید ساخته می شود فشار دادن.
• به تعویق افتاده
  قطعه خاصی از برنامه هنگام استقرار ساخته نمی شود ، هر زمان که اولین درخواست رخ داد ، موکول به ساخت در صورت تقاضا می شود ، سپس به عنوان هر منبع دیگری از نوع خود ذخیره می شود.

ایجاد سازنده On-Demand

اول از همه ، یک را اضافه کنید netlify / توابع بسته به عنوان devDependency به پروژه شما:

yarn add -D @netlify/functions

پس از انجام این کار ، درست همان ایجاد یک جدید است عملکرد Netlify. اگر فهرست مشخصی برای آنها تنظیم نکرده اید ، به قسمت زیر بروید netlify/functions/ و یک فایل با هر نام برای سازنده خود ایجاد کنید.

import type { Handler } from '@netlify/functions'
import { builder } from '@netlify/functions'

const myHandler: Handler = async (event, context) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Built on-demand! 🎉' }),
  }
}
export const handler = builder(myHandler)

همانطور که از قطعه بالا مشاهده می کنید ، سازنده درخواستی از عملکرد Netlify معمولی جدا می شود زیرا هندلر خود را درون یک builder() روش. این روش عملکرد ما را به وظایف ساخت متصل می کند. و این تنها چیزی است که شما برای داشتن یک قطعه از برنامه خود فقط در صورت لزوم برای ساخت به تعویق انداخته اید. ساخت های افزایشی کوچک از حرکت!

Next.js در Netlify

برای ساختن برنامه Next.js در Netlify ، 2 مورد مهم وجود دارد افزونه ها که به طور کلی باید یک تجربه بهتر را اضافه کنید: افزونه Netlify افزونه Next.js و ضروری بعدی در Netlify. مورد اول با کارآیی بیشتری NextJS شما را ذخیره می کند و شما باید خودتان آن را اضافه کنید ، در حالی که مورد دوم چند تغییر جزئی در نحوه ساخت معماری Next.js ایجاد می کند ، بنابراین بهتر با Netlify متناسب است و به طور پیش فرض در دسترس است برای هر پروژه جدیدی که Netlify می تواند شناسایی کند. با استفاده از Next.js.

سازندگان درخواستی با Next.js

عملکرد ساختمان ، استقرار عملکرد ، ذخیره سازی ، تجربه توسعه دهنده. اینها همه موضوعات بسیار مهمی هستند ، اما بسیار زیاد است – و تنظیم آنها به زمان نیاز دارد. سپس به آن بحث قدیمی درباره تمرکز بر تجربه توسعه دهنده به جای تجربه کاربر می رسیم. در این زمان است که همه چیز به یک مکان پنهان در یک پس زمینه می رود تا فراموش شود. نه واقعا.

Netlify به شما برگردانده است. فقط در چند مرحله ، می توانیم از قدرت کامل Jamstack در برنامه Next.js خود استفاده کنیم. وقت آن است که آستین ها را بالا بزنیم و همه را کنار هم بگذاریم.

تعریف مسیرهای پیش رندر شده

اگر قبلاً در Next.js با نسل استاتیک کار کرده اید ، احتمالاً نام آن را شنیده اید getStaticPaths روش. این روش برای مسیرهای پویا (الگوهای صفحه ای که طیف وسیعی از صفحات را ارائه می دهند) در نظر گرفته شده است. بدون پرداختن زیاد به پیچیدگی های این روش ، توجه به این نکته مهم است که نوع بازگشتی یک شی با 2 کلید است ، مانند اثبات مفهوم ما این [Pokémon]مسیر پویا فایل:

export async function getStaticPaths() {
  return {
    paths: [],
    fallback: 'blocking',
  }
}

• paths هست یک array انجام دادن همه مسیرهای مطابق با این مسیر که از قبل ارائه می شوند
• fallback دارای 3 مقدار ممکن است: مسدود کردن ، true، یا false

در مورد ما ، ما getStaticPaths تعیین کننده است:

1. هیچ مسیری از قبل ارائه نخواهد شد.
2. هر زمان که این مسیر فراخوانی شود ، ما یک الگوی بازگشتی ارائه نمی دهیم ، ما صفحه را ارائه می دهیم بر اساس تقاضا و کاربر را منتظر نگه دارید ، مسدود کردن برنامه از انجام هر کار دیگری.

هنگام استفاده از سازندگان On-Demand ، مطمئن شوید که استراتژی جایگزین شما با اهداف برنامه شما مطابقت دارد اسناد Next.js: بازگشت اسناد بسیار مفید هستند.

قبل از سازندگان On-Demand ، ما getStaticPaths کمی متفاوت بود:

export async function getStaticPaths() {
  const { pokemons } = await fetchPkmList()
  return {
    paths: pokemons.map(({ name }) => ({ params: { pokemon: name } })),
    fallback: false,
  }
}

ما در حال جمع آوری لیستی از تمام صفحات پوکمون بودیم که قصد داشتیم داشته باشیم ، نقشه همه آنها را pokemon اشیا فقط به یک string با نام پوکمون ، و حمل و نقل بازگشت { params } شی object حمل آن به getStaticProps. ما fallback تنظیم شد false چون اگر مسیری مطابقت نداشت ، ما می خواهیم Next.js یک پرتاب کند 404: Not Found صفحه

می توانید هر دو نسخه مستقر در Netlify را بررسی کنید:

کد نیز هست منبع باز در Github و می توانید به راحتی خودتان آن را مستقر کنید تا زمان ساخت را بررسی کنید. و با این صف ، به موضوع بعدی خود اسلاید می کنیم.

بار بسازید

همانطور که در بالا ذکر شد ، نسخه ی نمایشی قبلی در واقع یک است اثبات مفهوم، اگر نتوانیم اندازه گیری کنیم ، هیچ چیز خوب یا بد نیست. برای مطالعه کوچک ما ، من به سراغ PokéAPI و تصمیم گرفت که همه پوکمون ها را بگیرد.

برای اهداف تولید مجدد ، درخواست ما را لغو کردم (به 1000) اینها واقعاً نیستند همه درون API ، اما تعداد صفحات را اعمال می کند برای همه ساختها یکسان خواهد بود ، بدون توجه به اینکه همه چیز در هر زمان به روز می شوند.

export const fetchPkmList = async () => {
  const resp = await fetch(`${API}pokemon?limit=${LIMIT}`)
  const {
    count,
    results,
  }: {
    count: number
    results: {
      name: string
      url: string
    }[]
  } = await resp.json()
  return {
    count,
    pokemons: results,
    limit: LIMIT,
  }
}

و سپس هر دو نسخه را در Netlify به شاخه های جدا شده اخراج کرد ، به لطف استقرار پیش نمایش ، آنها می توانند اساساً در یک محیط مشابه زندگی کنند. برای ارزیابی واقعی تفاوت بین هر دو روش ، رویکرد ODB بسیار شدید بود ، بدون صفحه برای آن مسیر پویا از قبل ارائه شده است. اگرچه برای سناریوهای واقعی توصیه نمی شود (شما می خواهید مسیرهای پرترافیک خود را از قبل ارائه دهید) ، اما به وضوح نشان دهنده طیف وسیعی از عملکرد زمان ساخت است که می توانیم با این روش به دست آوریم.

صفحات برنامه کوچک PokéDex بسیار کوچک هستند ، دارایی تصویر بسیار کم است ، اما سود حاصل از زمان استقرار بسیار چشمگیر است. اگر برنامه ای مسیرهای متوسط ​​تا زیادی داشته باشد ، قطعاً ارزش استراتژی ODB را دارد.

این باعث می شود سرعت استقرار شما سریعتر و در نتیجه قابل اعتمادتر باشد. ضربه عملکرد فقط در اولین درخواست اتفاق می افتد ، از درخواست بعدی و بعد صفحه ارائه شده درست در Edge ذخیره می شود و عملکرد را کاملاً مشابه Fully Static Generated می کند.

آینده: ارائه دائمی توزیع شده

در همان روز ، سازندگان On-Demand اعلام شدند و دسترسی زودهنگام را آغاز کردند ، Netlify نیز آنها را منتشر کرد درخواست نظرات در مورد توزیع مداوم ارائه (DPR).

DPR مرحله بعدی سازندگان On-Demand است. این کار با استفاده از مراحل ساخت ناهمگام و سپس ذخیره دارایی ها تا زمانی که در واقع به روز نشوند ، از ساخت سریعتر سود می برد. دیگر موارد کامل برای وب سایت یک صفحه 10k وجود ندارد. DPR به توسعه دهندگان این امکان را می دهد تا از طریق ذخیره سازی جامد و استفاده از سازندگان On-Demand ، کنترل کاملی در ساخت و استقرار سیستم ها داشته باشند.

این سناریو را تصویر کنید: یک وب سایت تجارت الکترونیکی دارای 10k صفحه محصولات است ، این بدان معنی است که ساخت کل برنامه برای استقرار حدود 2 ساعت طول می کشد. نیازی نیست بحث کنیم که این چقدر دردناک است.

با استفاده از DPR ، ما می توانیم 500 صفحه برتر را تنظیم کنیم تا در هر استقرار ایجاد شوند. سنگین ترین صفحات بازدید ما هستند همیشه آماده برای کاربران ما اما ، ما یک مغازه هستیم ، یعنی هر ثانیه حساب می شود. بنابراین برای 9500 صفحه دیگر ، می توانیم یک قلاب پس از ساخت ایجاد کنیم تا سازندگان آنها را فعال کنیم – بقیه صفحات خود را به صورت غیرهمزمان و بلافاصله در حافظه پنهان مستقر کنیم. هیچ کاربری صدمه ای ندید ، وب سایت ما با سریعترین ساخت ممکن به روز شد و هر چیز دیگری که در حافظه پنهان نبود ، ذخیره شد.

نتیجه

اگرچه بسیاری از نکات بحث در این مقاله مفهومی بوده و قرار است اجرا تعریف شود ، من از آینده Jamstack هیجان زده هستم. پیشرفت هایی که ما به عنوان یک جامعه انجام می دهیم حول تجربه کاربر نهایی می چرخد.

نظر شما در مورد ارائه دائمی توزیع شده چیست؟ آیا سازندگان On-Demand را در برنامه خود امتحان کرده اید؟ در مورد نظرات به من اطلاع دهید یا در توییتر با من تماس بگیرید. من واقعاً کنجکاوم!

منابع

(vf ، او)