‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

کارگران خدمات و Cache Storage API

Jeff Posnick

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

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

عامل‌های خدماتی

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

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

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

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

The Cache Storage API

Browser Support

Source

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

صبر کنید… حالا باید به حافظه پنهان دیگری فکر کنیم؟

احتمالاً از خودتان می‌پرسید: «آیا هنوز باید سرایندهای HTTP را پیکربندی کنم؟» و «با این حافظه پنهان جدید چه کاری می‌توانم انجام دهم که با حافظه پنهان HTTP امکان‌پذیر نبود؟» نگران نباشید—این‌ها واکنش‌های طبیعی هستند.

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

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

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

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

برای کسب اطلاعات بیشتر، The Cache API: A quick guide را بررسی کنید.

جزئیات API

چند نکته را باید درباره طراحی میانای برنامه‌سازی کاربردی به‌خاطر بسپارید:

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

یک انحراف سریع: Promises و async/await

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

آن کد را مستقر نکنید… هنوز نه

While they provide an important foundation, and can be used as-is, both service workers and the Cache Storage API are effectively lower-level building blocks, with a number of edge cases and "gotchas". برخی ابزارهای سطح بالاتر وجود دارند که می‌توانند به هموار کردن بخش‌های دشوار این میاناهای برنامه‌سازی کاربردی کمک کنند و هرآنچه را که برای ساختن یک سرویس‌ورکر آماده تولید نیاز دارید فراهم کنند. راهنمای بعدی یکی از این ابزارها را پوشش می‌دهد: Workbox.