کارگران سرویس و API حافظه پنهان

شما درگیر مبارزه برای قابلیت اطمینان شبکه هستید. حافظه پنهان HTTP مرورگر اولین خط دفاعی شماست، اما همانطور که یاد گرفتید، فقط در هنگام بارگیری URL های نسخه ای که قبلاً بازدید کرده اید، واقعاً مؤثر است. کش HTTP به خودی خود کافی نیست.

خوشبختانه، دو ابزار جدیدتر برای کمک به تغییر جزر و مد به نفع شما در دسترس هستند: Service Workers و Cache Storage API . از آنجایی که آنها اغلب با هم استفاده می شوند، ارزش یادگیری در مورد هر دو را به طور همزمان دارد.

کارگران خدماتی

یک سرویس دهنده در مرورگر تعبیه شده است و توسط کمی کد جاوا اسکریپت اضافی که شما مسئول ایجاد آن هستید کنترل می شود. شما این را در کنار فایل های دیگری که برنامه وب واقعی شما را تشکیل می دهند، مستقر می کنید.

یک کارگر خدماتی دارای برخی اختیارات ویژه است. در میان وظایف دیگر، صبورانه منتظر می ماند تا برنامه وب شما درخواست خروجی را ارائه دهد و سپس با رهگیری آن وارد عمل می شود. کاری که کارمند خدمات با این درخواست رهگیری انجام می دهد به شما بستگی دارد.

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

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

Cache Storage API

پشتیبانی مرورگر

  • 43
  • 16
  • 41
  • 11.1

منبع

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

صبر کنید... کش دیگری برای فکر کردن در حال حاضر وجود دارد؟

احتمالاً از خود سؤالاتی مانند "آیا هنوز باید هدرهای HTTP خود را پیکربندی کنم؟" و "با این کش جدید که با کش HTTP امکان پذیر نبود، چه کاری می توانم انجام دهم؟" نگران نباشید - اینها واکنش های طبیعی هستند.

همچنان توصیه می‌شود که هدرهای Cache-Control روی سرور وب خود پیکربندی کنید، حتی زمانی که می‌دانید از Cache Storage API استفاده می‌کنید. معمولاً می‌توانید با تنظیم Cache-Control: no-cache برای URL‌های نسخه‌نشده و/یا Cache-Control: max-age=31536000 برای URL‌هایی که حاوی اطلاعات نسخه‌سازی هستند، مانند هش، کنار بیایید.

هنگام پر کردن حافظه پنهان API حافظه کش، مرورگر به طور پیش فرض ورودی های موجود در حافظه پنهان HTTP را بررسی می کند و در صورت یافتن از آنها استفاده می کند. اگر URL های نسخه شده را به حافظه پنهان API ذخیره سازی کش اضافه می کنید، مرورگر از درخواست شبکه اضافی جلوگیری می کند. طرف دیگر این است که اگر از هدرهای Cache-Control پیکربندی نادرست استفاده می‌کنید، مانند تعیین طول عمر حافظه پنهان برای URL بدون نسخه، می‌توانید با افزودن آن محتوای قدیمی به API حافظه پنهان، اوضاع را بدتر کنید . مرتب کردن رفتار حافظه پنهان HTTP شما یک پیش نیاز برای استفاده موثر از Cache Storage API است.

در مورد آنچه که اکنون با این API جدید امکان پذیر است، پاسخ این است: بسیار. برخی از کاربردهای رایج که فقط با حافظه پنهان HTTP دشوار یا غیرممکن است عبارتند از:

  • از رویکرد «بازخوانی در پس‌زمینه» برای محتوای کش استفاده کنید، که به عنوان stale-while-revalidate شناخته می‌شود.
  • محدودیتی برای حداکثر تعداد دارایی‌های ذخیره شده در حافظه پنهان اعمال کنید و یک خط‌مشی انقضا سفارشی برای حذف موارد پس از رسیدن به آن محدودیت اعمال کنید.
  • پاسخ‌های شبکه‌ای که قبلاً در حافظه پنهان و جدید ذخیره شده‌اند را مقایسه کنید تا ببینید آیا چیزی تغییر کرده است یا خیر، و کاربر را قادر می‌سازد تا زمانی که داده‌ها واقعاً به‌روزرسانی شده‌اند، محتوا را به‌روزرسانی کند (مثلاً با یک دکمه).

Cache API را بررسی کنید: راهنمای سریع برای کسب اطلاعات بیشتر.

مهره ها و پیچ های API

نکاتی وجود دارد که باید در مورد طراحی API در نظر داشت:

  • اشیاء Request به عنوان کلیدهای منحصر به فرد هنگام خواندن و نوشتن در این حافظه پنهان استفاده می شوند. برای راحتی، می‌توانید یک رشته URL مانند 'https://example.com/index.html' را به‌عنوان کلید به‌جای یک شی Request واقعی ارسال کنید، و API به‌طور خودکار آن را برای شما مدیریت می‌کند.
  • اشیاء Response به عنوان مقادیر در این کش استفاده می شود.
  • هدر Cache-Control در یک Response داده شده به طور موثر هنگام ذخیره داده ها نادیده گرفته می شود. هیچ بررسی خودکار، داخلی یا انقضا یا تازگی وجود ندارد، و هنگامی که یک مورد را در حافظه پنهان ذخیره می کنید، تا زمانی که کد شما به صراحت آن را حذف نکند، باقی می ماند. (کتابخانه هایی برای ساده سازی نگهداری حافظه پنهان از طرف شما وجود دارد. بعداً در این مجموعه به آنها پرداخته خواهد شد.)
  • برخلاف APIهای قدیمی‌تر و همزمان مانند LocalStorage ، همه عملیات API حافظه کش ناهمزمان هستند.

یک انحراف سریع: وعده ها و همگام سازی/انتظار

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

هنوز آن کد را نصب نکنید

در حالی که آنها پایه مهمی را ارائه می دهند و می توانند همانطور که هستند مورد استفاده قرار گیرند، هم سرویسکاران و هم API ذخیره سازی کش عملاً بلوک های ساختمانی سطح پایین تر هستند، با تعدادی از موارد لبه و "گوچا". ابزارهای سطح بالاتری وجود دارند که می‌توانند به هموارسازی بخش‌های دشوار آن APIها کمک کنند و تمام آنچه را که برای ساختن یک سرویس‌کار آماده تولید نیاز دارید، فراهم کنند. راهنمای بعدی یکی از این ابزارها را پوشش می‌دهد: Workbox .