عصر پلتفرم اولیه‌ها بالاخره اینجاست – مجله Smashing

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

به آرامی، ما به سمت نوعی اجماع در مورد آنچه به عنوان یک اکوسیستم نیاز داریم حرکت کردیم. اکنون TypeScript و Vite را به‌عنوان اولویت‌های واضح در اختیار داریم – که به معنای ایجاد تجربه‌های ثابت برای وب است. فریم ورک‌های کاربردی، اکوسیستم‌های کاملی را روی آن‌ها ساخته‌اند: SolidStart، Nuxt، Remix، و Analog نمونه‌هایی از ابزارهای باورنکردنی هستند که با چنین ابزارهای اولیه ساخته شده‌اند. می‌توان گفت که Vite و TypeScript ابزارهای اولیه‌ای هستند که به خلق دیگران در اکوسیستم‌های متنوع قدرت می‌دهند.

با تا حدودی نیازهای بسته‌بندی و تبدیل، طبیعی بود که نویسندگان چارچوب نگاه خود را به لایه بعدی که برای انتزاع نیاز داشتند سوق دهند: سرور.

سرورهای اولیه

مردم UnJS به طور مداوم در حال ساخت ابزار آگنوستیک هستند که می توانند در اکوسیستم های مختلف مورد استفاده مجدد قرار گیرند. به لطف آنها، اکنون فریمورک ها و کتابخانه هایی مانند H3 (یک چارچوب سرور Node.js حداقل ساخته شده با TypeScript) داریم که Nitro (کل زمان اجرای سرور توسط Vite و H3) را فعال می کند، که به نوبه خود Vinxi را فعال می کند. یک بسته نرم افزاری و زمان اجرا سرور که Nitro و Vite را خلاصه می کند).

Nitro قبلاً توسط سه فریمورک اصلی استفاده می شود: Nuxt، Analog و SolidStart. در حالی که Vinxi نیز توسط SolidStart استفاده می شود. این بدان معناست که هر پلتفرمی که یکی از اینها را پشتیبانی کند، قطعاً می‌تواند از بقیه پشتیبانی کند صفر تلاش اضافی.

این مربوط به برداشتن یک تکه بزرگتر از کیک نیست. اما بزرگتر کردن کیک برای همه.

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

بدون سرور به مکالمه می پیوندد

چنین ابتکاراتی احتمالاً توسط پلتفرم های بدون سرور مانند Netlify مورد توجه قرار گرفته است. با Platform Primitives، فریم‌ورک‌ها می‌توانند از راه‌حل‌های آگنوستیک برای نیازهای رایج مانند بازسازی استاتیک افزایشی (ISR)، بهینه‌سازی تصویر، و کلید/مقدار استفاده کنند.kv) ذخیره سازی.

همانطور که از نامش پیداست، Netlify Platform Primitives گروهی از انتزاع‌ها و کمک‌کننده‌ها هستند که در سطح پلت‌فرم برای فریم‌ورک‌ها یا توسعه‌دهندگان در دسترس قرار می‌گیرند تا هنگام استفاده از برنامه‌هایشان از آنها استفاده کنند. این کارکردهای اضافی را به طور همزمان برای هر فریم ورک به ارمغان می آورد. این یک تغییر بزرگ و قدرتمند است، زیرا تا به حال، هر فریم ورک باید راه‌حل‌های خاص خود را ایجاد کند و چنین استراتژی‌هایی را برای لایه‌های سازگاری در هر پلتفرم پشتیبانی کند.

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

بدون سرور یعنی توسعه دهندگان زیرساخت سرور نیازی به رسیدگی ندارند. این یک نام اشتباه نیست، بلکه قالبی از آن است زیرساخت به عنوان یک سرویس.

همانطور که قبلا ذکر شد، Netlify Platform Primitives سه ویژگی متفاوت دارد:

1. CDN تصویر
   یک شبکه تحویل محتوا برای تصاویر. این می تواند تبدیل فرمت و بهینه سازی اندازه را از طریق رشته های پرس و جو URL انجام دهد.
2. ذخیره سازی
   اولیه‌های اولیه برای زمان اجرا سرورشان که به مدیریت هموار دستورالعمل‌های کش برای مرورگر، سرور و زمان‌های اجرا CDN کمک می‌کنند.
3. حباب ها
   یک گزینه ذخیره‌سازی کلید/مقدار (KV) به‌طور خودکار از طریق SDK آن‌ها برای پروژه شما در دسترس است.

بیایید به بررسی هر یک از این ویژگی‌ها بپردازیم و بررسی کنیم که چگونه می‌توانند بهره‌وری ما را با یک تجربه Fullstack بدون سرور افزایش دهند.

CDN تصویر

هر تصویر در یک /public را می توان از طریق یک تابع Netlify ارائه کرد. این بدان معنی است که دسترسی به آن از طریق a امکان پذیر است /.netlify/images مسیر. بنابراین، بدون افزودن بسته‌های شارپ یا بهینه‌سازی تصویر به پشته‌تان، استقرار در Netlify به ما این امکان را می‌دهد تا بدون تغییر دارایی‌ها در زمان ساخت، با فرمت بهتری به کاربران خود خدمات ارائه دهیم. در SolidStart، در چند خط کد، می‌توانیم یک مؤلفه Image داشته باشیم که فرمت‌های دیگر را به .webp.

import { type JSX } from "solid-js";

const SITE_URL = "https://example.com";

interface Props extends JSX.ImgHTMLAttributes<HTMLImageElement> {
  format?: "webp" | "jpeg" | "png" | "avif" | "preserve";
  quality?: number | "preserve";
}

const getQuality = (quality: Props("quality")) => {
  if (quality === "preserve") return"";
  return `&q=${quality || "75"}`;
};

function getFormat(format: Props("format")) {
  switch (format) {
    case "preserve":
      return"  ";
    case "jpeg":
      return `&fm=jpeg`;
    case "png":
      return `&fm=png`;
    case "avif":
      return `&fm=avif`;
    case "webp":
    default:
      return `&fm=webp`;
  }
}

export function Image(props: Props) {
  return (
    <img
      {...props}
      src={`${SITE_URL}/.netlify/images?url=/${props.src}${getFormat(
        props.format
      )}${getQuality(props.quality)}`}
    />
  );
}

توجه داشته باشید که مولفه فوق حتی کمی پیچیده تر از موارد ضروری است زیرا ما در حال اجرای برخی بهینه سازی های پیش فرض هستیم. ما getFormat روش تبدیل تصاویر به .webp به صورت پیش فرض. این قالبی است که به طور گسترده پشتیبانی می شود که به طور قابل توجهی کوچکتر از رایج ترین و بدون افت کیفیت است. ما get quality عملکرد به طور پیش فرض کیفیت تصویر را به 75% کاهش می دهد. به عنوان یک قاعده کلی، هیچ افت قابل توجهی در کیفیت برای تصاویر بزرگ وجود ندارد، در حالی که هنوز بهینه سازی اندازه قابل توجهی را ارائه می دهد.

ذخیره سازی

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

با افزودن یک سربرگ کنترل کش، شما در حال حاضر 80 درصد از کار را در بهینه سازی منابع خود برای ارائه بهترین خدمات به کاربران انجام داده اید. برخی از دستورالعمل های رایج کنترل حافظه پنهان:

{
  "cache-control": "public, max-age=0, stale-while-revalidate=86400"

}

• public: در حافظه پنهان مشترک ذخیره کنید.
• max-age=0: منبع بلافاصله کهنه می شود.
• stale-while-revalidate=86400: اگر حافظه نهان برای کمتر از 1 روز قدیمی است، مقدار ذخیره شده را برگردانید و آن را مجدداً در پس‌زمینه تأیید کنید.

{
  "cache-control": "public, max-age=86400, must-revalidate"

}

• public: در حافظه پنهان مشترک ذخیره کنید.
• max-age=86400: منبع برای یک روز تازه است.
• must-revalidate: اگر درخواستی زمانی وارد می شود که منبع قبلاً قدیمی است، قبل از ارسال پاسخ به کاربر، حافظه پنهان باید مجدداً تأیید شود.

توجه داشته باشید: برای اطلاعات گسترده تر در مورد ترکیبات احتمالی از Cache-Control دستورالعمل ها، ورودی mdn را در Cache-Control بررسی کنید.

کش یک نوع است ذخیره سازی کلید/مقدار. بنابراین، هنگامی که پاسخ‌های ما با کنترل مناسب حافظه پنهان تنظیم شدند، پلتفرم‌ها دارای اکتشافاتی برای تعریف آنچه key برای منبع ما در حافظه پنهان خواهد بود. پلتفرم وب دومین هدر بسیار قدرتمندی دارد که می تواند نحوه رفتار کش ما را دیکته کند.

هدر پاسخ Vary از لیستی از سرفصل‌ها تشکیل شده است که بر اعتبار منبع تأثیر می‌گذارد (method و URL نقطه پایانی همیشه در نظر گرفته می شود. نیازی به اضافه کردن آنها نیست). این هدر به پلتفرم‌ها اجازه می‌دهد تا سرصفحه‌های دیگری را تعریف کنند که با مکان، زبان و الگوهای دیگر تعریف می‌شوند که مشخص می‌کنند چه مدت می‌توان یک پاسخ را تازه در نظر گرفت.

را متفاوت هدر پاسخ یک قطعه اساسی از یک هدر ویژه در Netlify Caching Primitive است. را Netlify-Vary مجموعه‌ای از دستورالعمل‌ها را می‌گیرد که یک کلید بر اساس کدام بخش‌های درخواست استوار باشد. تنظیم یک کلید پاسخ نه تنها توسط هدر بلکه توسط هدر نیز امکان پذیر است ارزش از هدر

• query: بر اساس مقدار برخی یا همه پارامترهای پرس و جو تغییر می کند.
• هدر: بر اساس مقدار یک یا چند سرصفحه درخواست تغییر می کند.
• زبان: بر اساس زبان‌های مختلف متفاوت است Accept-Language سرتیتر.
• کشور: براساس کشوری که از جستجوی GeoIP در آدرس IP درخواستی استنباط می شود، متفاوت است.
• کوکی: بر اساس مقدار یک یا چند کلید کوکی درخواستی تغییر می کند.

این هدر کنترل دقیقی بر نحوه ذخیره منابع شما ارائه می دهد. امکان برخی استراتژی‌های خلاقانه برای بهینه‌سازی عملکرد برنامه شما برای کاربران خاص.

ذخیره سازی Blob

این یک فروشگاه کلید/ارزش بسیار در دسترس است، برای خواندن مکرر و نوشتن نادر ایده آل است. آنها به طور خودکار در دسترس هستند و برای هر پروژه Netlify ارائه می شوند.

این امکان وجود دارد که روی یک حباب از زمان اجرا خود بنویسید یا داده ها را برای یک فروشگاه خاص استقرار فشار دهید. برای مثال، اینگونه است که یک Action Function تعدادی از را ثبت می کند دوست دارد در فروشگاه با SolidStart.

import { getStore } from "@netlify/blobs";
import { action } from "@solidjs/router";

export const upVote = action(async (formData: FormData) => {
  "use server";

  const postId = formData.get("id");
  const postVotes = formData.get("votes");

  if (typeof postId !== "string" || typeof postVotes !== "string") return;

  const store = getStore("posts");
  const voteSum = Number(postVotes) + 1)
    
  await store.set(postId, String(voteSum);

  console.log("done");
  return voteSum
  
});

افکار نهایی

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

در نظرات به من اطلاع دهید که نظر شما در مورد ابزارسازی بی طرفانه در مقابل تنظیمات نظری چیست!

(il)