পরিষেবা কর্মীরা এবং ক্যাশে স্টোরেজ API

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

সৌভাগ্যবশত, জোয়ারকে আপনার পক্ষে চালু করতে সাহায্য করার জন্য দুটি নতুন টুল উপলব্ধ: পরিষেবা কর্মী এবং ক্যাশে স্টোরেজ API ৷ যেহেতু তারা প্রায়শই একসাথে ব্যবহার করা হয়, তাই একই সময়ে তাদের উভয় সম্পর্কে শেখার মূল্য।

সেবা কর্মীরা

একটি পরিষেবা কর্মী ব্রাউজারে তৈরি করা হয় এবং কিছু অতিরিক্ত জাভাস্ক্রিপ্ট কোড দ্বারা নিয়ন্ত্রিত হয় যা তৈরি করার জন্য আপনি দায়ী৷ আপনি অন্য ফাইলগুলির সাথে এটি স্থাপন করেন যা আপনার প্রকৃত ওয়েব অ্যাপ্লিকেশন তৈরি করে।

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

কিছু অনুরোধের জন্য, সর্বোত্তম পদক্ষেপ হতে পারে অনুরোধটিকে নেটওয়ার্কে চালিয়ে যাওয়ার অনুমতি দেওয়া, ঠিক তেমনই যদি কোনও পরিষেবা কর্মী না থাকে তবে কী ঘটত।

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

ক্যাশে স্টোরেজ API

ব্রাউজার সমর্থন

  • 43
  • 16
  • 41
  • 11.1

উৎস

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

অপেক্ষা করুন... এখন চিন্তা করার জন্য আরেকটি ক্যাশে আছে?

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

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

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

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

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

ক্যাশে API দেখুন: আরও জানতে একটি দ্রুত গাইড

API বাদাম এবং বল্টু

API এর ডিজাইন সম্পর্কে কিছু জিনিস মাথায় রাখতে হবে:

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

একটি দ্রুত পথচলা: প্রতিশ্রুতি এবং অ্যাসিঙ্ক/অপেক্ষা

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

সেই কোডটি স্থাপন করবেন না... এখনো

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