একজন সেবাকর্মীর জীবন, একজন সেবাকর্মীর জীবন

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

ওয়ার্কবক্সে ডাইভিং করার আগে, পরিষেবা কর্মী লাইফসাইকেলটি বোঝা গুরুত্বপূর্ণ যাতে ওয়ার্কবক্স কী করে তা বোঝা যায়।

সংজ্ঞায়িত পদ

পরিষেবা কর্মী জীবনচক্রে প্রবেশ করার আগে, সেই জীবনচক্র কীভাবে কাজ করে তার চারপাশে কিছু শর্তাদি সংজ্ঞায়িত করা মূল্যবান।

নিয়ন্ত্রণ এবং সুযোগ

পরিষেবা কর্মীরা কীভাবে কাজ করে তা বোঝার জন্য নিয়ন্ত্রণের ধারণা অত্যন্ত গুরুত্বপূর্ণ। একটি পরিষেবা কর্মী দ্বারা নিয়ন্ত্রিত হিসাবে বর্ণিত একটি পৃষ্ঠা হল একটি পৃষ্ঠা যা একটি পরিষেবা কর্মীকে তার পক্ষ থেকে নেটওয়ার্ক অনুরোধগুলিকে বাধা দেওয়ার অনুমতি দেয়৷ পরিষেবা কর্মী উপস্থিত এবং একটি নির্দিষ্ট সুযোগের মধ্যে পৃষ্ঠাটির জন্য কাজ করতে সক্ষম।

ব্যাপ্তি

একটি ওয়েব সার্ভারে তার অবস্থান দ্বারা একটি পরিষেবা কর্মীর সুযোগ নির্ধারিত হয়। যদি কোনও পরিষেবা কর্মী /subdir/index.html এ অবস্থিত একটি পৃষ্ঠায় চলে এবং /subdir/sw.js এ অবস্থিত থাকে, তাহলে পরিষেবা কর্মীর সুযোগ হল /subdir/ । কর্মক্ষেত্রের ধারণাটি দেখতে, এই উদাহরণটি দেখুন:

  1. https://service-worker-scope-viewer.glitch.me/subdir/index.html- এ নেভিগেট করুন। একটি বার্তা প্রদর্শিত হবে যা বলে যে কোনও পরিষেবা কর্মী পৃষ্ঠাটি নিয়ন্ত্রণ করছে না। যাইহোক, সেই পৃষ্ঠাটি https://service-worker-scope-viewer.glitch.me/subdir/sw.js থেকে একজন পরিষেবা কর্মীকে নিবন্ধন করে।
  2. পৃষ্ঠাটি পুনরায় লোড করুন। কারণ পরিষেবা কর্মী নিবন্ধিত হয়েছে এবং এখন সক্রিয়, এটি পৃষ্ঠা নিয়ন্ত্রণ করছে। পরিষেবা কর্মীর সুযোগ, বর্তমান অবস্থা এবং এর URL সম্বলিত একটি ফর্ম দৃশ্যমান হবে৷ দ্রষ্টব্য: পৃষ্ঠাটি পুনরায় লোড করার সুযোগের সাথে কিছু করার নেই, বরং পরিষেবা কর্মীর জীবনচক্র, যা পরে ব্যাখ্যা করা হবে।
  3. এখন https://service-worker-scope-viewer.glitch.me/index.html- এ নেভিগেট করুন। যদিও এই মূলে একজন পরিষেবা কর্মী নিবন্ধিত হয়েছিল, তবুও একটি বার্তা রয়েছে যে কোনও বর্তমান পরিষেবা কর্মী নেই৷ কারণ এই পৃষ্ঠাটি নিবন্ধিত পরিষেবা কর্মীর সুযোগের মধ্যে নেই৷

পরিধি পরিষেবা কর্মী কোন পৃষ্ঠাগুলি নিয়ন্ত্রণ করে তা সীমিত করে৷ এই উদাহরণে, এর অর্থ হল /subdir/sw.js থেকে লোড করা পরিষেবা কর্মী শুধুমাত্র /subdir/ বা এর সাবট্রিতে অবস্থিত পৃষ্ঠাগুলি নিয়ন্ত্রণ করতে পারে।

ডিফল্টরূপে স্কোপিং কীভাবে কাজ করে তা উপরে উল্লেখ করা হয়েছে, তবে Service-Worker-Allowed প্রতিক্রিয়া শিরোনাম সেট করে এবং সেইসাথে register পদ্ধতিতে একটি scope বিকল্প পাস করে সর্বাধিক অনুমোদিত সুযোগ ওভাররাইড করা যেতে পারে।

পরিষেবা কর্মীদের সুযোগকে একটি উৎপত্তির উপসেটে সীমিত করার খুব ভাল কারণ না থাকলে, ওয়েব সার্ভারের রুট ডিরেক্টরি থেকে একজন পরিষেবা কর্মীকে লোড করুন যাতে এর পরিধি যতটা সম্ভব বিস্তৃত হয়, এবং Service-Worker-Allowed সম্পর্কে চিন্তা করবেন না Service-Worker-Allowed হেডার। এইভাবে প্রত্যেকের জন্য এটি অনেক সহজ।

ক্লায়েন্ট

যখন বলা হয় যে একজন পরিষেবা কর্মী একটি পৃষ্ঠা নিয়ন্ত্রণ করছে, এটি সত্যিই একটি ক্লায়েন্টকে নিয়ন্ত্রণ করছে। একটি ক্লায়েন্ট হল যে কোনও খোলা পৃষ্ঠা যার URL সেই পরিষেবা কর্মীর সুযোগের মধ্যে পড়ে৷ বিশেষত, এগুলি একটি WindowClient এর উদাহরণ।

একজন নতুন সেবা কর্মীর জীবনচক্র

একটি পৃষ্ঠাকে নিয়ন্ত্রণ করার জন্য একজন পরিষেবা কর্মীকে, প্রথমে এটিকে অস্তিত্বে আনতে হবে, তাই বলতে হবে। চলুন শুরু করা যাক যখন একজন নতুন পরিষেবা কর্মীকে কোনো সক্রিয় পরিষেবা কর্মী ছাড়াই একটি ওয়েবসাইটের জন্য নিযুক্ত করা হয় তখন কী ঘটে।

নিবন্ধন

নিবন্ধন হল পরিষেবা কর্মী জীবনচক্রের প্রাথমিক ধাপ:

<!-- In index.html, for example: -->
<script>
  // Don't register the service worker
  // until the page has fully loaded
  window.addEventListener('load', () => {
    // Is service worker available?
    if ('serviceWorker' in navigator) {
      navigator.serviceWorker.register('/sw.js').then(() => {
        console.log('Service worker registered!');
      }).catch((error) => {
        console.warn('Error registering service worker:');
        console.warn(error);
      });
    }
  });
</script>

এই কোডটি প্রধান থ্রেডে চলে এবং নিম্নলিখিতগুলি করে:

  1. যেহেতু একটি ওয়েবসাইটে ব্যবহারকারীর প্রথম পরিদর্শন একটি নিবন্ধিত পরিষেবা কর্মী ছাড়াই ঘটে, তাই একটি নিবন্ধন করার আগে পৃষ্ঠাটি সম্পূর্ণ লোড হওয়া পর্যন্ত অপেক্ষা করুন৷ এটি ব্যান্ডউইথ বিতর্ক এড়ায় যদি পরিষেবা কর্মী কিছু প্রচার করে।
  2. যদিও পরিষেবা কর্মী ভালভাবে সমর্থিত , একটি দ্রুত চেক ব্রাউজারগুলির ত্রুটিগুলি এড়াতে সাহায্য করে যেখানে এটি সমর্থিত নয়৷
  3. যখন পৃষ্ঠাটি সম্পূর্ণ লোড হয়, এবং যদি পরিষেবা কর্মী সমর্থিত হয়, /sw.js নিবন্ধন করুন।

বোঝার জন্য কিছু মূল বিষয় হল:

  • পরিষেবা কর্মীরা শুধুমাত্র HTTPS বা লোকালহোস্টে উপলব্ধ
  • যদি কোনও পরিষেবা কর্মীর বিষয়বস্তুতে সিনট্যাক্স ত্রুটি থাকে, নিবন্ধন ব্যর্থ হয় এবং পরিষেবা কর্মীকে বাতিল করা হয়।
  • অনুস্মারক: পরিষেবা কর্মীরা একটি সুযোগের মধ্যে কাজ করে। এখানে, স্কোপ হল সম্পূর্ণ মূল, কারণ এটি রুট ডিরেক্টরি থেকে লোড করা হয়েছিল।
  • রেজিস্ট্রেশন শুরু হলে, সার্ভিস ওয়ার্কার স্টেট 'installing' এ সেট করা থাকে।

একবার নিবন্ধন শেষ হলে, ইনস্টলেশন শুরু হয়।

ইনস্টলেশন

একজন পরিষেবা কর্মী নিবন্ধনের পরে তার install ইভেন্টটি বরখাস্ত করেন। প্রতি পরিষেবা কর্মীকে শুধুমাত্র একবার install বলা হয়, এবং আপডেট না হওয়া পর্যন্ত এটি আর ফায়ার হবে না। install ইভেন্টের জন্য একটি কলব্যাক addEventListener এর সাথে কর্মীর সুযোগে নিবন্ধিত হতে পারে:

// /sw.js
self.addEventListener('install', (event) => {
  const cacheKey = 'MyFancyCacheName_v1';

  event.waitUntil(caches.open(cacheKey).then((cache) => {
    // Add all the assets in the array to the 'MyFancyCacheName_v1'
    // `Cache` instance for later use.
    return cache.addAll([
      '/css/global.bc7b80b7.css',
      '/css/home.fe5d0b23.css',
      '/js/home.d3cc4ba4.js',
      '/js/jquery.43ca4933.js'
    ]);
  }));
});

এটি একটি নতুন Cache ইনস্ট্যান্স তৈরি করে এবং সম্পদগুলিকে প্রাক-ক্যাচে করে। আমরা পরে প্রিক্যাচিং সম্পর্কে কথা বলার প্রচুর সুযোগ পাব, তাই আসুন event.waitUntil এর ভূমিকার উপর ফোকাস করি। event.waitUntil পর্যন্ত একটি প্রতিশ্রুতি গ্রহণ করে, এবং সেই প্রতিশ্রুতির সমাধান না হওয়া পর্যন্ত অপেক্ষা করে। এই উদাহরণে, সেই প্রতিশ্রুতি দুটি অ্যাসিঙ্ক্রোনাস জিনিস করে:

  1. 'MyFancyCache_v1' নামে একটি নতুন Cache উদাহরণ তৈরি করে।
  2. ক্যাশে তৈরি হওয়ার পরে, অ্যাসিঙ্ক্রোনাস addAll পদ্ধতি ব্যবহার করে অ্যাসেট ইউআরএলগুলির একটি অ্যারে প্রিক্যাচ করা হয়।

event.waitUntil দেওয়া প্রতিশ্রুতি(গুলি) প্রত্যাখ্যাত হলে ইনস্টলেশন ব্যর্থ হয়। এটি ঘটলে, পরিষেবা কর্মী বাতিল করা হয়।

প্রতিশ্রুতিগুলি সমাধান হলে, ইনস্টলেশন সফল হয় এবং পরিষেবা কর্মীর অবস্থা 'installed' এ পরিবর্তিত হবে এবং তারপর সক্রিয় হবে৷

সক্রিয়করণ

নিবন্ধন এবং ইনস্টলেশন সফল হলে, পরিষেবা কর্মী সক্রিয় হয়, এবং তার অবস্থা 'activating' হয়ে যায় পরিষেবা কর্মীর activate ইভেন্টে অ্যাক্টিভেশনের সময় কাজ করা যেতে পারে। এই ইভেন্টের একটি সাধারণ কাজ হল পুরানো ক্যাশে ছাঁটাই করা, কিন্তু একজন একেবারে নতুন পরিষেবা কর্মীদের জন্য, এটি এই মুহূর্তে প্রাসঙ্গিক নয়, এবং যখন আমরা পরিষেবা কর্মী আপডেটগুলি সম্পর্কে কথা বলব তখন এটি প্রসারিত হবে৷

নতুন পরিষেবা কর্মীদের জন্য, install সফল হওয়ার সাথে সাথে আগুন activate ৷ একবার সক্রিয়করণ শেষ হয়ে গেলে, পরিষেবা কর্মীর অবস্থা 'activated' হয়ে যায়। লক্ষ্য করুন যে, ডিফল্টরূপে, নতুন পরিষেবা কর্মী পরবর্তী নেভিগেশন বা পৃষ্ঠা রিফ্রেশ না হওয়া পর্যন্ত পৃষ্ঠাটি নিয়ন্ত্রণ করা শুরু করবে না।

পরিষেবা কর্মী আপডেটগুলি পরিচালনা করা

একবার প্রথম পরিষেবা কর্মী মোতায়েন করা হলে, এটি সম্ভবত পরে আপডেট করা দরকার। উদাহরণস্বরূপ, রিকোয়েস্ট হ্যান্ডলিং বা প্রিক্যাচিং লজিক এ পরিবর্তন ঘটলে একটি আপডেটের প্রয়োজন হতে পারে।

যখন আপডেট হয়

যখন:

  • ব্যবহারকারী পরিষেবা কর্মীর সুযোগের মধ্যে একটি পৃষ্ঠায় নেভিগেট করে।
  • navigator.serviceWorker.register() কে বর্তমানে ইনস্টল করা সার্ভিস ওয়ার্কার থেকে আলাদা একটি URL দিয়ে ডাকা হয়— কিন্তু কোনো সার্ভিস ওয়ার্কারের URL পরিবর্তন করবেন না !
  • navigator.serviceWorker.register() কে ইনস্টল করা সার্ভিস ওয়ার্কারের মতো একই ইউআরএল দিয়ে কল করা হয়, কিন্তু ভিন্ন সুযোগের সাথে। আবার, সম্ভব হলে একটি উত্সের মূলে সুযোগ রেখে এটি এড়িয়ে চলুন।
  • যখন গত 24 ঘন্টার মধ্যে 'push' বা 'sync' এর মতো ইভেন্টগুলি ট্রিগার করা হয়েছে—কিন্তু এখনও এই ইভেন্টগুলি নিয়ে চিন্তা করবেন না৷

কিভাবে আপডেট হয়

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

ব্রাউজারগুলি কয়েকটি উপায়ে পরিবর্তনগুলি সনাক্ত করে:

  • যদি প্রযোজ্য হয়, importScripts দ্বারা অনুরোধ করা স্ক্রিপ্টে বাইট-ফর-বাইট পরিবর্তন।
  • পরিষেবা কর্মীর শীর্ষ-স্তরের কোডে যেকোনো পরিবর্তন, যা ব্রাউজার দ্বারা তৈরি করা আঙ্গুলের ছাপকে প্রভাবিত করে।

ব্রাউজার এখানে অনেক ভারী উত্তোলন করে। ব্রাউজারে একটি পরিষেবা কর্মীর বিষয়বস্তুর পরিবর্তনগুলি নির্ভরযোগ্যভাবে সনাক্ত করার জন্য প্রয়োজনীয় সমস্ত কিছু আছে তা নিশ্চিত করতে, HTTP ক্যাশেকে এটি ধরে রাখতে বলবেন না এবং এর ফাইলের নাম পরিবর্তন করবেন না। ব্রাউজার স্বয়ংক্রিয়ভাবে আপডেট চেক সম্পাদন করে যখন একটি পরিষেবা কর্মীর সুযোগের মধ্যে একটি নতুন পৃষ্ঠায় নেভিগেশন থাকে।

ম্যানুয়ালি আপডেট চেক ট্রিগার করছে

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

navigator.serviceWorker.ready.then((registration) => {
  registration.update();
});

প্রথাগত ওয়েবসাইটগুলির জন্য, বা যে কোনও ক্ষেত্রে যেখানে ব্যবহারকারীর সেশনগুলি দীর্ঘস্থায়ী হয় না, ম্যানুয়াল আপডেটগুলি ট্রিগার করা সম্ভবত প্রয়োজনীয় নয়৷

ইনস্টলেশন

স্ট্যাটিক সম্পদ তৈরি করতে একটি বান্ডলার ব্যবহার করার সময়, সেই সম্পদগুলিতে তাদের নামে হ্যাশ থাকবে, যেমন framework.3defa9d2.js । ধরুন সেই সম্পদগুলির কিছু পরে অফলাইন অ্যাক্সেসের জন্য প্রিক্যাচ করা হয়েছে৷ আপডেট করা সম্পদগুলিকে প্রাক্যাশে করার জন্য এটির জন্য একটি পরিষেবা কর্মী আপডেটের প্রয়োজন হবে:

self.addEventListener('install', (event) => {
  const cacheKey = 'MyFancyCacheName_v2';

  event.waitUntil(caches.open(cacheKey).then((cache) => {
    // Add all the assets in the array to the 'MyFancyCacheName_v2'
    // `Cache` instance for later use.
    return cache.addAll([
      '/css/global.ced4aef2.css',
      '/css/home.cbe409ad.css',
      '/js/home.109defa4.js',
      '/js/jquery.38caf32d.js'
    ]);
  }));
});

দুটি জিনিস আগের থেকে প্রথম install ইভেন্ট উদাহরণ থেকে ভিন্ন:

  1. 'MyFancyCacheName_v2' এর একটি কী সহ একটি নতুন Cache ইনস্ট্যান্স তৈরি করা হয়েছে।
  2. প্রিক্যাচ করা সম্পদের নাম পরিবর্তিত হয়েছে।

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

ডিফল্টরূপে, একটি নতুন পরিষেবা কর্মী সক্রিয় হবে যখন কোনও ক্লায়েন্ট পুরানোটির দ্বারা নিয়ন্ত্রিত হচ্ছে না। এটি ঘটে যখন প্রাসঙ্গিক ওয়েবসাইটের জন্য সমস্ত খোলা ট্যাব বন্ধ থাকে।

সক্রিয়করণ

যখন একটি আপডেট করা পরিষেবা কর্মী ইনস্টল করা হয় এবং অপেক্ষার পর্যায় শেষ হয়, তখন এটি সক্রিয় হয় এবং পুরানো পরিষেবা কর্মীকে বাতিল করা হয়। একটি আপডেট করা পরিষেবা কর্মীর activate ইভেন্টে সম্পাদন করার একটি সাধারণ কাজ হল পুরানো ক্যাশে ছাঁটাই করা। caches.keys সহ সমস্ত খোলা Cache ইনস্ট্যান্সের জন্য কীগুলি পেয়ে এবং caches.delete এর সাথে সংজ্ঞায়িত অনুমতি তালিকায় না থাকা ক্যাশেগুলি মুছে ফেলার মাধ্যমে পুরানো ক্যাশেগুলি সরান:

self.addEventListener('activate', (event) => {
  // Specify allowed cache keys
  const cacheAllowList = ['MyFancyCacheName_v2'];

  // Get all the currently active `Cache` instances.
  event.waitUntil(caches.keys().then((keys) => {
    // Delete all caches that aren't in the allow list:
    return Promise.all(keys.map((key) => {
      if (!cacheAllowList.includes(key)) {
        return caches.delete(key);
      }
    }));
  }));
});

পুরানো ক্যাশে নিজেদের পরিপাটি না. আমাদের নিজেরাই তা করতে হবে বা স্টোরেজ কোটা অতিক্রম করার ঝুঁকি নিতে হবে। যেহেতু প্রথম পরিষেবা কর্মীর 'MyFancyCacheName_v1' পুরানো, 'MyFancyCacheName_v2' নির্দিষ্ট করার জন্য ক্যাশে অনুমতির তালিকা আপডেট করা হয়েছে, যা একটি ভিন্ন নামের ক্যাশে মুছে দেয়৷

পুরানো ক্যাশে সরানোর পরে activate ইভেন্টটি শেষ হবে। এই মুহুর্তে, নতুন পরিষেবা কর্মী পৃষ্ঠার নিয়ন্ত্রণ নেবে, অবশেষে পুরানোটিকে প্রতিস্থাপন করবে!

জীবনচক্র চলতে থাকে

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

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