রানটাইম ক্যাশিং বলতে বোঝায় ধীরে ধীরে একটি ক্যাশে প্রতিক্রিয়া যোগ করা "যেমন আপনি যান"। যদিও রানটাইম ক্যাশিং বর্তমান অনুরোধের নির্ভরযোগ্যতার সাথে সাহায্য করে না, এটি একই URL এর জন্য ভবিষ্যতের অনুরোধগুলিকে আরও নির্ভরযোগ্য করতে সাহায্য করতে পারে।
ব্রাউজারের HTTP ক্যাশে রানটাইম ক্যাশিংয়ের একটি উদাহরণ; এটি শুধুমাত্র একটি প্রদত্ত URL এর জন্য একটি অনুরোধের পরে জনবহুল হয়৷ কিন্তু পরিষেবা কর্মীরা আপনাকে রানটাইম ক্যাশিং প্রয়োগ করার অনুমতি দেয় যা শুধুমাত্র HTTP ক্যাশে যা অফার করতে পারে তার বাইরে যায়।
কৌশলগত হচ্ছে
precaching এর বিপরীতে (যা সর্বদা একটি ক্যাশে থেকে পূর্বনির্ধারিত ফাইলগুলির একটি সেট পরিবেশন করার চেষ্টা করে), রানটাইম ক্যাশিং একাধিক উপায়ে নেটওয়ার্ক এবং ক্যাশে অ্যাক্সেসকে একত্রিত করতে পারে। প্রতিটি সংমিশ্রণকে সাধারণত ক্যাশিং কৌশল হিসাবে উল্লেখ করা হয়। মূল ক্যাশিং কৌশলগুলির মধ্যে রয়েছে:
- নেটওয়ার্ক- প্রথম
- ক্যাশে-প্রথম
- বাসি-যখন-পুনর্বিচার করা
নেটওয়ার্ক- প্রথম
এই পদ্ধতিতে, আপনার পরিষেবা কর্মী প্রথমে নেটওয়ার্ক থেকে একটি প্রতিক্রিয়া পুনরুদ্ধার করার চেষ্টা করে। নেটওয়ার্ক অনুরোধ সফল হলে, মহান! প্রতিক্রিয়াটি আপনার ওয়েব অ্যাপে ফেরত দেওয়া হয়, এবং প্রতিক্রিয়াটির একটি অনুলিপি ক্যাশে স্টোরেজ API ব্যবহার করে সংরক্ষণ করা হয়—হয় একটি নতুন এন্ট্রি তৈরি করে, অথবা একই URL-এর জন্য একটি পূর্ববর্তী এন্ট্রি আপডেট করে৷
যদি নেটওয়ার্ক অনুরোধ সম্পূর্ণরূপে ব্যর্থ হয়, বা একটি প্রতিক্রিয়া ফেরত দিতে খুব বেশি সময় নেয় , তাহলে ক্যাশে থেকে সাম্প্রতিক প্রতিক্রিয়াটি এর পরিবর্তে ফেরত দেওয়া হয়।
ক্যাশে-প্রথম
একটি ক্যাশে-প্রথম কৌশল কার্যকরভাবে নেটওয়ার্ক-প্রথম এর বিপরীত। এই পদ্ধতিতে, যখন আপনার পরিষেবা কর্মী একটি অনুরোধে বাধা দেয়, তখন এটি প্রথমে ক্যাশে স্টোরেজ API ব্যবহার করে একটি ক্যাশ করা প্রতিক্রিয়া উপলব্ধ আছে কিনা তা দেখতে। যদি থাকে, সেই প্রতিক্রিয়াটি ওয়েব অ্যাপে ফেরত দেওয়া হয়।
যদিও ক্যাশে মিস হয়, তবে পরিষেবা কর্মী নেটওয়ার্কে যাবে এবং সেখানে একটি প্রতিক্রিয়া পুনরুদ্ধার করার চেষ্টা করবে। ধরে নিই যে নেটওয়ার্ক অনুরোধ সফল হয়েছে, এটি আপনার ওয়েব অ্যাপে ফিরে এসেছে এবং একটি কপি একটি ক্যাশে সংরক্ষণ করা হয়েছে। পরের বার একই ইউআরএলগুলির জন্য অনুরোধ করা হলে এই ক্যাশড কপিটি নেটওয়ার্ক বাইপাস করতে ব্যবহার করা হবে।
বাসি-যখন-পুনর্বিচার করা
Stale-while-revalidate একটি হাইব্রিড কিছু। এটি ব্যবহার করার সময়, আপনার পরিষেবা কর্মী অবিলম্বে একটি ক্যাশে করা প্রতিক্রিয়া পরীক্ষা করবে এবং, যদি একটি পাওয়া যায়, এটি আপনার ওয়েব অ্যাপে ফেরত পাঠাবে৷
ইতিমধ্যে, একটি ক্যাশে মিল ছিল কিনা তা নির্বিশেষে, আপনার পরিষেবা কর্মী একটি "নতুন" প্রতিক্রিয়া ফিরে পাওয়ার জন্য একটি নেটওয়ার্ক অনুরোধও বন্ধ করে দেয়৷ এই প্রতিক্রিয়া পূর্বে ক্যাশ করা প্রতিক্রিয়া আপডেট করতে ব্যবহৃত হয়। যদি প্রাথমিক ক্যাশে চেকটি মিস হয়ে থাকে, তাহলে নেটওয়ার্ক প্রতিক্রিয়ার একটি অনুলিপিও আপনার ওয়েব অ্যাপে ফেরত পাঠানো হবে।
কেন আপনি ওয়ার্কবক্স ব্যবহার করা উচিত?
এই ক্যাশিং কৌশলগুলি রেসিপিগুলির পরিমাণ যা আপনাকে সাধারণত আপনার নিজের পরিষেবা কর্মীতে বারবার লিখতে হবে। এটি অবলম্বন করার পরিবর্তে, ওয়ার্কবক্স তাদের কৌশল লাইব্রেরির অংশ হিসাবে প্যাকেজ করা অফার করে, যা আপনার পরিষেবা কর্মীর কাছে যাওয়ার জন্য প্রস্তুত।
ওয়ার্কবক্স সংস্করণ সমর্থনও প্রদান করে, আপনাকে স্বয়ংক্রিয়ভাবে ক্যাশে করা এন্ট্রির মেয়াদ শেষ করার অনুমতি দেয়, অথবা পূর্বে ক্যাশে করা এন্ট্রির আপডেটগুলি ঘটলে আপনার ওয়েব অ্যাপকে অবহিত করে।
আপনার সম্পদের কোনটি ক্যাশে করা উচিত, কোন কৌশলগুলির সাথে?
রানটাইম ক্যাশিংকে প্রিক্যাচিংয়ের পরিপূরক হিসাবে দেখা যেতে পারে। যদি আপনার সমস্ত সম্পদ ইতিমধ্যেই প্রিক্যাচ করা হয়ে থাকে, তাহলে আপনি সম্পন্ন করেছেন—রানটাইমে ক্যাশে করার দরকার নেই এমন কিছুই নেই৷ সম্ভাবনা আছে, যে কোনো তুলনামূলকভাবে জটিল ওয়েব অ্যাপের জন্য, আপনি যদিও সবকিছুই প্রিক্যাচিং করতে যাচ্ছেন না।
বৃহত্তর মিডিয়া ফাইল, সম্পদ যেগুলি একটি CDN-এর মতো তৃতীয়-পক্ষের হোস্ট থেকে পরিবেশিত হয়, বা API প্রতিক্রিয়াগুলি, সেই ধরনের সম্পদের কয়েকটি উদাহরণ যা কার্যকরভাবে প্রিক্যাচ করা যায় না৷ এই বিভাগের মধ্যে পড়ে এমন অনুরোধগুলি সনাক্ত করতে DevTools-এ নেটওয়ার্ক প্যানেল ব্যবহার করুন এবং তাদের প্রত্যেকের জন্য, নতুনত্ব বনাম নির্ভরযোগ্যতার কোন ট্রেডঅফ উপযুক্ত তা নিয়ে ভাবুন৷
সতেজতার চেয়ে নির্ভরযোগ্যতাকে অগ্রাধিকার দিতে stale-while-revalidate ব্যবহার করুন
যেহেতু একটি স্থির-যখন-পুনঃপ্রমাণ কৌশল প্রায় অবিলম্বে একটি ক্যাশে প্রতিক্রিয়া প্রদান করে-প্রথম অনুরোধের মাধ্যমে ক্যাশে পপুলেট হওয়ার পরে-আপনি এই কৌশলটি ব্যবহার করার সময় নির্ভরযোগ্যভাবে দ্রুত কর্মক্ষমতা দেখতে পাবেন। এটি নেটওয়ার্ক থেকে পুনরুদ্ধার করা হত তার তুলনায় বাসি হতে পারে এমন প্রতিক্রিয়া ডেটা ফিরে পাওয়ার ট্রেডঅফের সাথে আসে। এই কৌশলটি ব্যবহার করা ব্যবহারকারীর প্রোফাইল চিত্র বা একটি ভিউ তৈরি করতে ব্যবহৃত প্রাথমিক API প্রতিক্রিয়াগুলির মতো সম্পদগুলির জন্য সবচেয়ে ভাল কাজ করে, যখন আপনি জানেন যে কিছু অবিলম্বে দেখানো গুরুত্বপূর্ণ, এমনকি এটি একটি পুরানো মান হলেও।
নির্ভরযোগ্যতার চেয়ে সতেজতাকে অগ্রাধিকার দিতে নেটওয়ার্ক-প্রথম ব্যবহার করুন
কিছু অর্থে, নেটওয়ার্ক-প্রথম কৌশল ব্যবহার করা নেটওয়ার্কের বিরুদ্ধে আপনার যুদ্ধে পরাজয় স্বীকার করছে—এটিকে অগ্রাধিকার দেওয়া হয়েছে, কিন্তু এটি নির্ভরযোগ্যতা সম্পর্কে অনিশ্চয়তা নিয়ে আসে। নির্দিষ্ট ধরণের সম্পদের জন্য, পুরানো তথ্য ফেরত পাওয়ার চেয়ে নতুন প্রতিক্রিয়া দেখা বাঞ্ছনীয়৷ উদাহরণস্বরূপ, ঘন ঘন আপডেট করা নিবন্ধের পাঠ্যের জন্য API অনুরোধ করার সময় আপনি সতেজতা পছন্দ করতে পারেন।
একটি পরিষেবা কর্মীর ভিতরে নেটওয়ার্ক-প্রথম কৌশল ব্যবহার করে, সরাসরি নেটওয়ার্কের বিরুদ্ধে যাওয়ার পরিবর্তে, আপনি কিছুতে ফিরে যেতে সক্ষম হওয়ার সুবিধা পাবেন, এমনকি এটি একটি সম্ভাব্য বাসি প্রতিক্রিয়া হলেও। আপনি নির্ভরযোগ্যভাবে দ্রুত হবেন না, তবে অফলাইনে থাকাকালীন অন্তত আপনি নির্ভরযোগ্য হবেন।
সংস্করণযুক্ত URL-এর জন্য ক্যাশে-প্রথম ব্যবহার করুন
একটি ক্যাশে-প্রথম কৌশলে, একবার একটি এন্ট্রি ক্যাশে করা হলে, এটি কখনই আপডেট হয় না। সেই কারণে, নিশ্চিত করুন যে আপনি এটি শুধুমাত্র এমন সম্পদের সাথে ব্যবহার করছেন যা আপনি জানেন যে পরিবর্তনের সম্ভাবনা নেই। বিশেষ করে, এটি এমন ইউআরএলগুলির জন্য সবচেয়ে ভালো কাজ করে যেখানে ভার্সনিং তথ্য রয়েছে—একই ধরনের ইউআরএল যা Cache-Control: max-age=31536000 প্রতিক্রিয়া শিরোনাম।