stale-while-revalidate দিয়ে জিনিসগুলিকে তাজা রাখা

আপনার ওয়েব অ্যাপ পরিবেশন করার সময় তাত্ক্ষণিকতা এবং সতেজতা ভারসাম্য বজায় রাখতে সাহায্য করার জন্য একটি অতিরিক্ত টুল।

জেফ পসনিক

কি পাঠানো হয়েছে?

stale-while-revalidate ডেভেলপারদের তাৎক্ষণিকতার মধ্যে ভারসাম্য বজায় রাখতে সাহায্য করে —এখনই ক্যাশ করা বিষয়বস্তু লোড হচ্ছে —এবং সতেজতা— নিশ্চিত করে যে ক্যাশে করা সামগ্রীর আপডেট ভবিষ্যতে ব্যবহার করা হবে ৷ আপনি যদি একটি তৃতীয় পক্ষের ওয়েব পরিষেবা বা লাইব্রেরি বজায় রাখেন যা নিয়মিত সময়সূচীতে আপডেট হয়, অথবা আপনার প্রথম-পক্ষের সম্পদের জীবনকাল সংক্ষিপ্ত থাকে, তাহলে stale-while-revalidate আপনার বিদ্যমান ক্যাশিং নীতিতে একটি দরকারী সংযোজন হতে পারে।

আপনার Cache-Control রেসপন্স max-age stale-while-revalidate সেট করার জন্য সমর্থন Chrome 75 এবং Firefox 68- এ পাওয়া যাচ্ছে।

যে ব্রাউজারগুলি stale-while-revalidate সমর্থন করে না তারা নীরবে সেই কনফিগারেশন মানকে উপেক্ষা করবে, এবং max-age ব্যবহার করবে, আমি শীঘ্রই ব্যাখ্যা করব...

এটার মানে কি?

চলুন stale-while-revalidate দুটি ভাগে বিভক্ত করা যাক: ধারণা যে একটি ক্যাশে করা প্রতিক্রিয়া বাসি হতে পারে, এবং পুনরায় বৈধকরণের প্রক্রিয়া।

প্রথমত, ব্রাউজার কীভাবে জানতে পারে যে একটি ক্যাশে করা প্রতিক্রিয়া "বাসি" কিনা? একটি Cache-Control প্রতিক্রিয়া শিরোনাম যা stale-while-revalidate ধারণ করে max-age ও থাকা উচিত এবং max-age মাধ্যমে নির্দিষ্ট করা সেকেন্ডের সংখ্যা যা অচলতা নির্ধারণ করে। max-age চেয়ে নতুন যে কোনও ক্যাশে করা প্রতিক্রিয়াকে তাজা হিসাবে বিবেচনা করা হয় এবং পুরোনো ক্যাশে করা প্রতিক্রিয়াগুলি পুরানো।

যদি স্থানীয়ভাবে ক্যাশে করা প্রতিক্রিয়া এখনও তাজা থাকে, তাহলে এটি ব্রাউজারের অনুরোধ পূরণ করার জন্য ব্যবহার করা যেতে পারে। stale-while-revalidate এর দৃষ্টিকোণ থেকে, এই দৃশ্যে করার কিছু নেই।

কিন্তু যদি ক্যাশে করা প্রতিক্রিয়া বাসি হয়, তাহলে আরেকটি বয়স-ভিত্তিক চেক করা হয়: stale-while-revalidate সেটিং দ্বারা প্রদত্ত অতিরিক্ত সময় উইন্ডোর মধ্যে ক্যাশ করা প্রতিক্রিয়ার বয়স কি?

যদি একটি বাসি প্রতিক্রিয়ার বয়স এই উইন্ডোতে পড়ে, তাহলে এটি ব্রাউজারের অনুরোধ পূরণ করতে ব্যবহার করা হবে। একই সময়ে, নেটওয়ার্কের বিরুদ্ধে একটি "পুনর্বিচার" অনুরোধ এমনভাবে করা হবে যাতে ক্যাশে করা প্রতিক্রিয়া ব্যবহারে দেরি না হয়। প্রত্যাবর্তিত প্রতিক্রিয়াতে পূর্বে ক্যাশ করা প্রতিক্রিয়ার মতো একই তথ্য থাকতে পারে বা এটি ভিন্ন হতে পারে। যেভাবেই হোক, নেটওয়ার্ক প্রতিক্রিয়া স্থানীয়ভাবে সংরক্ষণ করা হয়, যা পূর্বে ক্যাশে ছিল তা প্রতিস্থাপন করে এবং ভবিষ্যতের max-age তুলনার সময় ব্যবহৃত "ফ্রেশনেস" টাইমার রিসেট করে।

যাইহোক, যদি বাসি ক্যাশে করা প্রতিক্রিয়াটি যথেষ্ট পুরানো হয় যে এটি stale-while-revalidate উইন্ডোর বাইরে পড়ে, তাহলে এটি ব্রাউজারের অনুরোধ পূরণ করবে না। ব্রাউজার পরিবর্তে নেটওয়ার্ক থেকে একটি প্রতিক্রিয়া পুনরুদ্ধার করবে, এবং প্রাথমিক অনুরোধটি পূরণ করতে এবং একটি নতুন প্রতিক্রিয়া সহ স্থানীয় ক্যাশে পূরণ করার জন্য এটি ব্যবহার করবে।

লাইভ উদাহরণ

নীচে বর্তমান সময় ফেরত দেওয়ার জন্য একটি HTTP API-এর একটি সাধারণ উদাহরণ রয়েছে—আরও নির্দিষ্টভাবে, ঘণ্টার পরের মিনিটের বর্তমান সংখ্যা।

এই পরিস্থিতিতে, ওয়েব সার্ভার তার HTTP প্রতিক্রিয়াতে এই Cache-Control হেডার ব্যবহার করে:

Cache-Control: max-age=1, stale-while-revalidate=59

এই সেটিং এর অর্থ হল, যদি পরবর্তী 1 সেকেন্ডের মধ্যে সময়ের জন্য একটি অনুরোধ পুনরাবৃত্তি করা হয়, তবে পূর্বে ক্যাশে করা মানটি এখনও তাজা থাকবে এবং কোনো পুনর্বিবেচনা ছাড়াই ব্যবহার করা হবে।

যদি একটি অনুরোধ 1 থেকে 60 সেকেন্ডের মধ্যে পুনরাবৃত্তি হয়, তাহলে ক্যাশে করা মানটি পুরানো হবে, কিন্তু API অনুরোধটি পূরণ করতে ব্যবহার করা হবে। একই সময়ে, "ব্যাকগ্রাউন্ডে," ভবিষ্যতে ব্যবহারের জন্য একটি নতুন মান সহ ক্যাশে পপুলেট করার জন্য একটি পুনর্বিবেচনার অনুরোধ করা হবে৷

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

এখানে সেই তিনটি স্বতন্ত্র অবস্থার একটি ব্রেকডাউন রয়েছে, সেই সাথে সময়ের উইন্ডো যেখানে তাদের প্রত্যেকটি আমাদের উদাহরণের জন্য আবেদন করে:

পূর্ববর্তী বিভাগ থেকে তথ্য চিত্রিত একটি চিত্র।

সাধারণ ব্যবহারের ক্ষেত্রে কি কি?

যদিও উপরের উদাহরণটি "ঘন্টা পরের মিনিট" API পরিষেবার জন্য তৈরি করা হয়েছে, এটি প্রত্যাশিত ব্যবহারের ক্ষেত্রে চিত্রিত করে - পরিষেবাগুলি যা তথ্য প্রদান করে যা রিফ্রেশ করা প্রয়োজন, কিন্তু যেখানে কিছু মাত্রায় অচলতা গ্রহণযোগ্য।

কম কল্পিত উদাহরণগুলি বর্তমান আবহাওয়ার অবস্থার জন্য একটি API হতে পারে, বা গত ঘন্টায় লেখা শীর্ষ সংবাদ শিরোনাম হতে পারে।

সাধারণত, পরিচিত ব্যবধানে আপডেট হওয়া যেকোনো প্রতিক্রিয়া একাধিকবার অনুরোধ করা হতে পারে, এবং সেই ব্যবধানের মধ্যে স্থির থাকলে max-age মাধ্যমে স্বল্প-মেয়াদী ক্যাশিংয়ের জন্য একটি ভাল প্রার্থী। max-age ছাড়াও stale-while-revalidate ব্যবহার করার ফলে ভবিষ্যতের অনুরোধগুলি নেটওয়ার্ক প্রতিক্রিয়ায় ব্লক না করেই নতুন কন্টেন্ট সহ ক্যাশে থেকে পূরণ হওয়ার সম্ভাবনা বেড়ে যায়।

এটা কিভাবে সেবা কর্মীদের সাথে যোগাযোগ করে?

আপনি যদি stale-while-revalidate এর কথা শুনে থাকেন তবে এটি একটি পরিষেবা কর্মীর মধ্যে ব্যবহৃত রেসিপিগুলির প্রসঙ্গে ছিল।

একটি Cache-Control শিরোলেখের মাধ্যমে stale-while-revalidate ব্যবহার করা একটি পরিষেবা কর্মীতে এর ব্যবহারের সাথে কিছু মিল শেয়ার করে, এবং সতেজতা ট্রেড-অফ এবং সর্বাধিক জীবনকালের ক্ষেত্রে একই বিবেচনার অনেকগুলি প্রযোজ্য। যাইহোক, পরিষেবা কর্মী-ভিত্তিক পদ্ধতির প্রয়োগ করতে হবে কিনা বা Cache-Control হেডার কনফিগারেশনের উপর নির্ভর করতে হবে কিনা তা সিদ্ধান্ত নেওয়ার সময় আপনার কয়েকটি বিবেচনা বিবেচনা করা উচিত।

একটি পরিষেবা কর্মী পদ্ধতি ব্যবহার করুন যদি...

  • আপনি ইতিমধ্যেই আপনার ওয়েব অ্যাপে একজন পরিষেবা কর্মী ব্যবহার করছেন৷
  • আপনার ক্যাশেগুলির বিষয়বস্তুর উপর আপনার সূক্ষ্ম-দানাযুক্ত নিয়ন্ত্রণ প্রয়োজন, এবং একটি ন্যূনতম-সম্প্রতি ব্যবহৃত মেয়াদ শেষ হওয়ার নীতির মতো কিছু বাস্তবায়ন করতে চান। ওয়ার্কবক্সের ক্যাশে মেয়াদোত্তীর্ণ মডিউল এটিতে সহায়তা করতে পারে।
  • পুনর্বিবেচনার পদক্ষেপের সময় পটভূমিতে একটি পুরানো প্রতিক্রিয়া পরিবর্তন হলে আপনি বিজ্ঞপ্তি পেতে চান। ওয়ার্কবক্সের ব্রডকাস্ট ক্যাশে আপডেট মডিউল এটিতে সহায়তা করতে পারে।
  • সমস্ত আধুনিক ব্রাউজারে আপনার এই stale-while-revalidate আচরণ প্রয়োজন।

একটি ক্যাশে-কন্ট্রোল পদ্ধতি ব্যবহার করুন যদি...

  • আপনি বরং আপনার ওয়েব অ্যাপের জন্য একজন পরিষেবা কর্মী স্থাপন এবং রক্ষণাবেক্ষণের ওভারহেডের সাথে মোকাবিলা করবেন না।
  • আপনি ব্রাউজারের স্বয়ংক্রিয় ক্যাশে পরিচালনাকে আপনার স্থানীয় ক্যাশেগুলিকে খুব বড় হওয়া থেকে আটকাতে দিয়ে ঠিক আছেন৷
  • আপনি এমন একটি পদ্ধতির সাথে ভাল আছেন যা বর্তমানে সমস্ত আধুনিক ব্রাউজারে সমর্থিত নয় (জুলাই 2019 অনুসারে; ভবিষ্যতে সমর্থন বাড়তে পারে)।

আপনি যদি কোনও পরিষেবা কর্মী ব্যবহার করেন এবং একটি Cache-Control শিরোনামের মাধ্যমে কিছু প্রতিক্রিয়ার জন্য stale-while-revalidate সক্ষম করা থাকে, তাহলে পরিষেবা কর্মী, সাধারণভাবে, একটি অনুরোধের প্রতিক্রিয়া জানাতে "প্রথম ক্র্যাক" হবে৷ যদি পরিষেবা কর্মী সাড়া না দেওয়ার সিদ্ধান্ত নেয়, অথবা যদি প্রতিক্রিয়া তৈরি করার প্রক্রিয়ায় এটি fetch() ব্যবহার করে একটি নেটওয়ার্ক অনুরোধ করে, তাহলে Cache-Control হেডারের মাধ্যমে কনফিগার করা আচরণটি কার্যকর হবে।

আরও জানুন

স্যামুয়েল জেলারের হিরো ছবি।