আপনার পছন্দের ভাষায় কন্টেন্ট অনুবাদ করতে Google তার AI প্রযুক্তি ব্যবহার করে। AI-এর মাধ্যমে করা অনুবাদে ভুল থাকতে পারে।

সার্ভিস ওয়ার্কার এবং Cache Storage API

Jeff Posnick

আপনি নেটওয়ার্কের নির্ভরযোগ্যতা নিয়ে সমস্যায় পড়েছেন। ব্রাউজারের HTTP ক্যাশে হল আপনার প্রথম প্রতিরক্ষা লাইন, কিন্তু আপনি যেমন শিখেছেন, এটি শুধুমাত্র তখনই কার্যকর হয় যখন আপনি আগে ভিজিট করেছেন এমন ভার্সন করা URL লোড করেন। শুধু HTTP ক্যাশে যথেষ্ট নয়।

সৌভাগ্যবশত, পরিস্থিতি আপনার অনুকূলে আনতে সাহায্য করার জন্য দুটি নতুন টুল উপলভ্য আছে: সার্ভিস ওয়ার্কার এবং Cache Storage API। যেহেতু এগুলি প্রায়ই একসাথে ব্যবহার করা হয়, তাই একই সময়ে দুটি সম্পর্কেই জেনে নেওয়া ভাল।

সার্ভিস ওয়ার্কার্স

ব্রাউজারে একটি সার্ভিস ওয়ার্কার তৈরি করা হয় এবং অতিরিক্ত জাভাস্ক্রিপ্ট কোডের মাধ্যমে এটি নিয়ন্ত্রণ করা হয়। এই কোড তৈরি করার দায়িত্ব আপনার। আপনার আসল ওয়েব অ্যাপ্লিকেশন তৈরি করে এমন অন্যান্য ফাইলের সাথে আপনি এটি ডিপ্লয় করেন।

সার্ভিস ওয়ার্কারের কিছু বিশেষ ক্ষমতা আছে। অন্যান্য কাজের মধ্যে, এটি আপনার ওয়েব অ্যাপের আউটগোয়িং অনুরোধ করার জন্য ধৈর্য ধরে অপেক্ষা করে এবং তারপরে এটি ইন্টারসেপ্ট করে অ্যাকশনে নেমে পড়ে। এই ইন্টারসেপ্ট করা অনুরোধের সাথে সার্ভিস ওয়ার্কার কী করবে তা আপনার উপর নির্ভর করে।

কিছু অনুরোধের ক্ষেত্রে, সবচেয়ে ভালো উপায় হল অনুরোধটি নেটওয়ার্কে চালিয়ে যাওয়ার অনুমতি দেওয়া, ঠিক যেমনটি কোনও সার্ভিস ওয়ার্কার না থাকলে হত।

তবে অন্যান্য অনুরোধের জন্য, আপনি ব্রাউজারের HTTP ক্যাশের চেয়ে আরও নমনীয় কিছুর সুবিধা নিতে পারেন এবং নেটওয়ার্ক সম্পর্কে চিন্তা না করেই একটি নির্ভরযোগ্য দ্রুত প্রতিক্রিয়া ফেরত দিতে পারেন। তার মানে, ধাঁধার অন্য অংশটি ব্যবহার করতে হবে: Cache Storage API।

Cache Storage API

Browser Support

Source

Cache Storage API, ডেভেলপারদের ক্যাশের কন্টেন্টের উপর সম্পূর্ণ কন্ট্রোল প্রদান করে, সম্ভাবনার এক সম্পূর্ণ নতুন রেঞ্জ খুলে দেয়। HTTP হেডার এবং ব্রাউজারের বিল্ট-ইন হিউরিস্টিক-এর সমন্বয়ের উপর নির্ভর করার পরিবর্তে, Cache Storage API ক্যাশিংয়ের জন্য কোড-চালিত পদ্ধতি প্রকাশ করে। Cache Storage API বিশেষ করে আপনার সার্ভিস ওয়ার্কারের জাভাস্ক্রিপ্ট থেকে কল করার সময় কাজে লাগে।

দাঁড়ান… এখন কি অন্য কোনও ক্যাশে নিয়ে ভাবতে হবে?

আপনি হয়ত নিজেকে প্রশ্ন করছেন, "আমাকে কি এখনও HTTP হেডার কনফিগার করতে হবে?" এবং "এই নতুন ক্যাশে দিয়ে আমি কী করতে পারব যা HTTP ক্যাশে দিয়ে করা সম্ভব নয়?" চিন্তা করবেন না—এগুলি স্বাভাবিক প্রতিক্রিয়া।

আপনি Cache Storage API ব্যবহার করছেন তা জানলেও, আপনার ওয়েব সার্ভারে Cache-Control হেডার কনফিগার করার জন্য সাজেস্ট করা হয়। আপনি সাধারণত ভার্সন নেই এমন URL-এর জন্য Cache-Control: no-cache এবং/অথবা হ্যাশের মতো ভার্সন সংক্রান্ত তথ্য আছে এমন URL-এর জন্য Cache-Control: max-age=31536000 সেট করে কাজ চালাতে পারেন।

Cache Storage API ক্যাশে পপুলেট করার সময়, ব্রাউজার HTTP ক্যাশেতে আগে থেকে থাকা এন্ট্রি ডিফল্ট হিসেবে চেক করে এবং খুঁজে পেলে সেগুলি ব্যবহার করে। আপনি Cache Storage API ক্যাশেতে ভার্সনযুক্ত URL যোগ করলে, ব্রাউজার অতিরিক্ত নেটওয়ার্ক অনুরোধ এড়িয়ে যায়। এর বিপরীত দিকটি হল, আপনি যদি ভুলভাবে কনফিগার করা Cache-Control হেডার ব্যবহার করেন, যেমন, ভার্সন ছাড়া URL-এর জন্য দীর্ঘস্থায়ী ক্যাশে লাইফটাইম নির্দিষ্ট করা, তাহলে আপনি Cache Storage API-তে সেই পুরনো কন্টেন্ট যোগ করে পরিস্থিতি আরও খারাপ করে তুলতে পারেন। Cache Storage API কার্যকরভাবে ব্যবহার করার জন্য HTTP ক্যাশে ব্যবহারের ধরন ঠিক করা একটি পূর্বশর্ত।

এই নতুন API-এর মাধ্যমে এখন কী কী করা সম্ভব, তার উত্তর হল: অনেক কিছু। কিছু সাধারণ ব্যবহার যা শুধু HTTP ক্যাশের মাধ্যমে করা কঠিন বা অসম্ভব, তার মধ্যে রয়েছে:

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

আরও জানতে Cache API: একটি দ্রুত নির্দেশিকা দেখুন।

API-এর খুঁটিনাটি

API-এর ডিজাইন সম্পর্কে কিছু বিষয় মনে রাখতে হবে:

Request অবজেক্টগুলি এই ক্যাশে পড়ার এবং লেখার সময় অনন্য কী হিসাবে ব্যবহৃত হয়। সুবিধার জন্য, আপনি একটি URL স্ট্রিং পাস করতে পারেন যেমন 'https://example.com/index.html' একটি প্রকৃত Request অবজেক্টের পরিবর্তে কী হিসাবে, এবং API আপনার জন্য এটি স্বয়ংক্রিয়ভাবে পরিচালনা করবে।
Response অবজেক্টগুলি এই ক্যাশে ভ্যালু হিসেবে ব্যবহার করা হয়।
ডেটা ক্যাশে করার সময়, প্রদত্ত Response-এ Cache-Control হেডার কার্যত উপেক্ষা করা হয়। এতে কোনও অটোমেটিক, বিল্ট-ইন মেয়াদ শেষ হওয়া বা ফ্রেশনেস চেক করার সুবিধা নেই এবং আপনি একবার ক্যাশে কোনও আইটেম স্টোর করলে, আপনার কোড স্পষ্টভাবে এটি না সরানো পর্যন্ত এটি থেকে যাবে। (আপনার হয়ে ক্যাশে রক্ষণাবেক্ষণ সহজ করার জন্য লাইব্রেরি আছে। এই সিরিজের পরবর্তী ভিডিওতে সেগুলি কভার করা হবে।)
LocalStorage-এর মতো পুরনো, সিঙ্ক্রোনাস API-এর মতো নয়, সব Cache Storage API অপারেশন অ্যাসিঙ্ক্রোনাস হয়।

এক ঝলকে: Promises এবং async/await

সার্ভিস ওয়ার্কার ও Cache Storage API অ্যাসিঙ্ক্রোনাস প্রোগ্রামিং কনসেপ্ট ব্যবহার করে। বিশেষ করে, তারা অ্যাসিঙ্ক অপারেশনের ভবিষ্যৎ ফলাফল দেখানোর জন্য প্রমিজের উপর অত্যন্ত নির্ভরশীল। শুরু করার আগে, আপনাকে promises এবং সম্পর্কিত async/await সিনট্যাক্স সম্পর্কে পরিচিত হতে হবে।

সেই কোড ডিপ্লয় করবেন না… এখনও নয়

যদিও তারা একটি গুরুত্বপূর্ণ ভিত্তি প্রদান করে এবং যেমন আছে তেমন ব্যবহার করা যেতে পারে, উভয় পরিষেবা কর্মী এবং ক্যাশে স্টোরেজ API কার্যকরভাবে নিম্ন-স্তরের বিল্ডিং ব্লক, বেশ কয়েকটি প্রান্তের কেস এবং "গোটচাস" সহ। কিছু উচ্চ-স্তরের টুল আছে যা সেই API-এর কঠিন অংশগুলিকে মসৃণ করতে সাহায্য করতে পারে এবং প্রোডাকশন-রেডি সার্ভিস ওয়ার্কার তৈরি করার জন্য আপনার প্রয়োজনীয় সবকিছু প্রদান করতে পারে। পরবর্তী গাইডে এই ধরনের একটি টুল সম্পর্কে আলোচনা করা হয়েছে: Workbox।