workbox-cacheable-response

রানটাইমে অ্যাসেট ক্যাশ করার সময়, প্রদত্ত প্রতিক্রিয়া "বৈধ" এবং সংরক্ষিত এবং পুনঃব্যবহারের জন্য যোগ্য কিনা তার জন্য কোনও এক-আকার-ফিট-সমস্ত নিয়ম নেই।

workbox-cacheable-response মডিউলটি তার সাংখ্যিক স্থিতি কোড , একটি নির্দিষ্ট মান সহ একটি শিরোনামের উপস্থিতি বা দুটির সংমিশ্রণের উপর ভিত্তি করে একটি প্রতিক্রিয়া ক্যাশে করা উচিত কিনা তা নির্ধারণ করার একটি আদর্শ উপায় প্রদান করে৷

স্ট্যাটাস কোডের উপর ভিত্তি করে ক্যাশিং

একটি কৌশলের plugins প্যারামিটারে একটি CacheableResponsePlugin ইন্সট্যান্স যোগ করে স্ট্যাটাস কোডের একটি সেটকে ক্যাশে করার যোগ্য হিসাবে বিবেচনা করার জন্য আপনি একটি ওয়ার্কবক্স কৌশল কনফিগার করতে পারেন:

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) =>
    url.origin === 'https://third-party.example.com' &&
    url.pathname.startsWith('/images/'),
  new CacheFirst({
    cacheName: 'image-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

এই কনফিগারেশন ওয়ার্কবক্সকে বলে যে https://third-party.example.com/images/ বিরুদ্ধে অনুরোধের প্রতিক্রিয়া প্রক্রিয়া করার সময়, 0 বা 200 এর স্ট্যাটাস কোড সহ যেকোনো অনুরোধ ক্যাশে করুন।

হেডারের উপর ভিত্তি করে ক্যাশিং

প্লাগইন তৈরি করার সময় headers অবজেক্ট সেট করে ক্যাশে যোগ করার মানদণ্ড হিসাবে নির্দিষ্ট হেডার মানগুলির উপস্থিতি পরীক্ষা করার জন্য আপনি একটি ওয়ার্কবক্স কৌশল কনফিগার করতে পারেন:

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

/path/to/api/ ধারণকারী অনুরোধ URL-এর জন্য প্রতিক্রিয়া প্রক্রিয়া করার সময়, X-Is-Cacheable নামের শিরোনামটি দেখুন (যা সার্ভারের দ্বারা প্রতিক্রিয়াতে যোগ করা হবে)। যদি সেই শিরোনামটি উপস্থিত থাকে, এবং যদি এটি 'সত্য'-এর একটি মান সেট করা হয়, তবে প্রতিক্রিয়াটি ক্যাশে করা যেতে পারে।

যদি একাধিক শিরোনাম নির্দিষ্ট করা হয়, তাহলে শুধুমাত্র একটি শিরোনাম সংশ্লিষ্ট মানগুলির সাথে মেলে।

হেডার এবং স্ট্যাটাস কোডের উপর ভিত্তি করে ক্যাশিং

আপনি স্ট্যাটাস এবং হেডার কনফিগারেশন উভয়ই একসাথে মিশ্রিত করতে পারেন। একটি প্রতিক্রিয়া ক্যাশেযোগ্য হিসাবে বিবেচিত হওয়ার জন্য উভয় শর্ত অবশ্যই পূরণ করতে হবে; অন্য কথায়, প্রতিক্রিয়াটিতে অবশ্যই কনফিগার করা স্ট্যাটাস কোডগুলির একটি থাকতে হবে এবং এটিতে অবশ্যই প্রদত্ত হেডারগুলির মধ্যে একটি থাকতে হবে।

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

registerRoute(
  ({url}) => url.pathname.startsWith('/path/to/api/'),
  new StaleWhileRevalidate({
    cacheName: 'api-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [200, 404],
        headers: {
          'X-Is-Cacheable': 'true',
        },
      }),
    ],
  })
);

ডিফল্ট কি?

আপনি যদি একটি cacheableResponse.CacheableResponsePlugin স্পষ্টভাবে কনফিগার না করে ওয়ার্কবক্সের অন্তর্নির্মিত কৌশলগুলির একটি ব্যবহার করেন, তাহলে নেটওয়ার্ক থেকে প্রাপ্ত প্রতিক্রিয়া ক্যাশে করা উচিত কিনা তা নির্ধারণ করতে নিম্নলিখিত ডিফল্ট মানদণ্ড ব্যবহার করা হয়:

• staleWhileRevalidate এবং networkFirst: 0 (যেমন অস্বচ্ছ প্রতিক্রিয়া ) বা 200 এর স্থিতি সহ প্রতিক্রিয়াগুলি ক্যাশেযোগ্য বলে বিবেচিত হয়।
• cacheFirst: 200 স্থিতি সহ প্রতিক্রিয়া ক্যাশেযোগ্য বলে বিবেচিত হয়।

ডিফল্টরূপে, ক্যাশেবিলিটি নির্ধারণ করতে প্রতিক্রিয়া শিরোনাম ব্যবহার করা হয় না।

কেন বিভিন্ন ডিফল্ট আছে?

ডিফল্টগুলি 0 এর স্থিতি সহ প্রতিক্রিয়াগুলি (যেমন অস্বচ্ছ প্রতিক্রিয়াগুলি ) ক্যাশে শেষ হবে কিনা তা পরিবর্তিত হয়৷ অস্বচ্ছ প্রতিক্রিয়াগুলির "ব্ল্যাক বক্স" প্রকৃতির কারণে, পরিষেবা কর্মীর পক্ষে প্রতিক্রিয়াটি বৈধ কিনা বা এটি ক্রস-অরিজিন সার্ভার থেকে প্রত্যাবর্তিত ত্রুটির প্রতিক্রিয়া প্রতিফলিত করে কিনা তা জানা সম্ভব নয়৷

কৌশলগুলির জন্য যেগুলি ক্যাশ করা প্রতিক্রিয়া আপডেট করার কিছু উপায় অন্তর্ভুক্ত করে, যেমন staleWhileRevalidate এবং networkFirst, একটি ক্ষণস্থায়ী ত্রুটির প্রতিক্রিয়া ক্যাশ করার ঝুঁকি এই সত্য দ্বারা প্রশমিত হয় যে পরের বার ক্যাশে আপডেট করা হলে, একটি সঠিক, সফল প্রতিক্রিয়া আশা করি ব্যবহার করা হবে৷

প্রাপ্ত প্রথম প্রতিক্রিয়া ক্যাশ করা এবং অনির্দিষ্টকালের জন্য সেই ক্যাশে করা প্রতিক্রিয়া পুনঃব্যবহারের সাথে জড়িত কৌশলগুলির জন্য, ক্যাশে করা এবং পুনরায় ব্যবহার করা ক্ষণস্থায়ী ত্রুটির প্রতিক্রিয়া আরও গুরুতর। ডিফল্টভাবে নিরাপদে ভুল করতে, ক্যাশফার্স্ট একটি প্রতিক্রিয়া সংরক্ষণ করতে অস্বীকার করবে যদি না এটির 200 এর স্ট্যাটাস কোড থাকে।

উন্নত ব্যবহার

আপনি যদি ওয়ার্কবক্স কৌশলের বাইরে একই ক্যাশিং যুক্তি ব্যবহার করতে চান তবে আপনি সরাসরি CacheableResponse ক্লাস ব্যবহার করতে পারেন।

import {CacheableResponse} from 'workbox-cacheable-response';

const cacheable = new CacheableResponse({
  statuses: [0, 200],
  headers: {
    'X-Is-Cacheable': 'true',
  },
});

const response = await fetch('/path/to/api');

if (cacheable.isResponseCacheable(response)) {
  const cache = await caches.open('api-cache');
  cache.put(response.url, response);
} else {
  // Do something when the response can't be cached.
}