ওয়েবের জন্য স্টোরেজ

ব্রাউজারে ডেটা স্টোর করার জন্য অনেক আলাদা আলাদা বিকল্প আছে। আপনার প্রয়োজনের জন্য কোনটি সবচেয়ে ভালো?

যাতায়াতের সময় ইন্টারনেট কানেকশন দুর্বল বা অনুপলভ্য হতে পারে, তাই অফলাইন সাপোর্ট ও নির্ভরযোগ্য পারফর্ম্যান্স হল প্রোগ্রেসিভ ওয়েব অ্যাপ-এর সাধারণ ফিচার। এমনকি নিখুঁত ওয়্যারলেস পরিবেশেও, ক্যাশিং এবং অন্যান্য স্টোরেজ কৌশলের বিচক্ষণ ব্যবহার ব্যবহারকারীর অভিজ্ঞতাকে যথেষ্ট উন্নত করতে পারে। আপনার স্ট্যাটিক অ্যাপ্লিকেশন রিসোর্স (HTML, JavaScript, CSS, ছবি ইত্যাদি) এবং ডেটা (ব্যবহারকারীর ডেটা, খবর সম্পর্কিত নিবন্ধ ইত্যাদি) ক্যাশে করার বিভিন্ন উপায় রয়েছে। কিন্তু এর মধ্যে সেরা সমাধান কোনটি? আপনি কতটা স্টোর করতে পারবেন? এটি যাতে উচ্ছেদ না হয় তা আপনি কীভাবে নিশ্চিত করবেন?

আমি কী ব্যবহার করব?

রিসোর্স স্টোর করার জন্য এখানে একটি সাধারণ সাজেশন দেওয়া হল:

IndexedDB, OPFS এবং Cache Storage API প্রতিটি আধুনিক ব্রাউজারে কাজ করে। এগুলি অ্যাসিঙ্ক্রোনাস এবং মূল থ্রেডকে ব্লক করবে না (তবে OPFS-এর একটি সিঙ্ক্রোনাস ভেরিয়েন্টও আছে যা শুধুমাত্র ওয়েব ওয়ার্কারদের জন্য উপলভ্য)। এগুলি window অবজেক্ট, ওয়েব ওয়ার্কার ও সার্ভিস ওয়ার্কার থেকে অ্যাক্সেস করা যায়, যার ফলে আপনার কোডের যেকোনও জায়গায় এগুলি ব্যবহার করা সম্ভব হয়।

অন্যান্য স্টোরেজ মেকানিজম সম্পর্কে কী বলা যায়?

ব্রাউজারে আরও বেশ কিছু স্টোরেজ মেকানিজম উপলভ্য আছে, তবে সেগুলির ব্যবহার সীমিত এবং এর ফলে পারফর্ম্যান্স সংক্রান্ত গুরুতর সমস্যা হতে পারে।

SessionStorage হল ট্যাব-নির্দিষ্ট এবং ট্যাবের লাইফটাইম পর্যন্ত স্কোপ করা থাকে। এটি সেশন সংক্রান্ত অল্প পরিমাণ তথ্য স্টোর করার জন্য উপযোগী হতে পারে, যেমন, IndexedDB কী। এটি সিঙ্ক্রোনাস এবং প্রধান থ্রেডকে ব্লক করবে বলে সতর্কতার সাথে ব্যবহার করা উচিত। এটি প্রায় ৫ এমবি পর্যন্ত সীমিত এবং এতে শুধু স্ট্রিং থাকতে পারে। এটি ট্যাব-নির্দিষ্ট হওয়ার কারণে, ওয়েব ওয়ার্কার বা সার্ভিস ওয়ার্কার থেকে এটি অ্যাক্সেস করা যায় না।

LocalStorage এড়িয়ে যাওয়া উচিত কারণ এটি সিঙ্ক্রোনাস এবং মূল থ্রেড ব্লক করবে। এটি প্রায় ৫ এমবি পর্যন্ত সীমিত এবং এতে শুধু স্ট্রিং থাকতে পারে। ওয়েব ওয়ার্কার বা সার্ভিস ওয়ার্কার থেকে LocalStorage অ্যাক্সেস করা যায় না।

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

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

FileSystem API এবং FileWriter API স্যান্ডবক্স করা ফাইল সিস্টেমে ফাইল পড়া এবং লেখার পদ্ধতি প্রদান করে। এটি অ্যাসিঙ্ক্রোনাস হলেও, এটি ব্যবহার করার সাজেশন দেওয়া হয় না কারণ এটি শুধুমাত্র Chromium-ভিত্তিক ব্রাউজারে উপলভ্য।

আমি কত স্টোর করতে পারব?

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

  • Chrome ব্রাউজারকে মোট ডিস্ক স্পেসের ৮০% পর্যন্ত ব্যবহার করার অনুমতি দেয়। একটি অরিজিন মোট ডিস্ক স্পেসের ৬০% পর্যন্ত ব্যবহার করতে পারে। উপলভ্য সর্বাধিক কোটা নির্ধারণ করতে আপনি StorageManager API ব্যবহার করতে পারেন। অন্যান্য Chromium-ভিত্তিক ব্রাউজার আলাদা হতে পারে।
    • ছদ্মবেশী মোডে, Chrome কোনও অরিজিনের ব্যবহার করা স্টোরেজের পরিমাণ কমিয়ে মোট ডিস্ক স্পেসের প্রায় ৫% করে দেয়।
    • ব্যবহারকারী Chrome-এ "সব উইন্ডো বন্ধ করার সময় কুকি ও সাইট ডেটা মুছে দিন" বিকল্প চালু করলে, স্টোরেজ কোটা উল্লেখযোগ্যভাবে কমে গিয়ে সর্বাধিক প্রায় ৩০০ এমবি হয়ে যায়।
  • Firefox ব্রাউজারকে ডিস্ক স্টোরেজের সর্বাধিক ৫০% খালি জায়গা ব্যবহার করার অনুমতি দেয়। একটি eTLD+1 গ্রুপ (যেমন, example.com, www.example.com এবং foo.bar.example.com) সর্বাধিক ২ জিবি ব্যবহার করতে পারে। কতটা জায়গা এখনও উপলভ্য আছে তা নির্ধারণ করতে আপনি StorageManager API ব্যবহার করতে পারেন।
  • Safari (ডেস্কটপ ও মোবাইল, দুটিতেই) প্রায় ১ জিবি ডেটা স্টোর করার অনুমতি দেয়। সীমা শেষ হয়ে গেলে, Safari ব্যবহারকারীকে প্রম্পট করবে, ২০০ এমবি করে সীমা বাড়াবে। আমি এই বিষয়ে কোনও অফিসিয়াল ডকুমেন্টেশন খুঁজে পাইনি।
    • মোবাইল Safari-তে হোম স্ক্রিনে PWA যোগ করা হলে, এটি একটি নতুন স্টোরেজ কন্টেনার তৈরি করে এবং PWA ও মোবাইল Safari-এর মধ্যে কিছুই শেয়ার করা হয় না। ইনস্টল করা PWA-এর জন্য কোটা শেষ হয়ে গেলে, অতিরিক্ত স্টোরেজের জন্য অনুরোধ করার কোনও উপায় আছে বলে মনে হয় না।

অতীতে, কোনও সাইট যদি স্টোর করা ডেটার একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করে, তাহলে ব্রাউজার ব্যবহারকারীকে আরও ডেটা ব্যবহার করার অনুমতি দেওয়ার জন্য প্রম্পট করবে। যেমন, অরিজিন ৫০ এমবি-র বেশি ব্যবহার করলে, ব্রাউজার ব্যবহারকারীকে ১০০ এমবি পর্যন্ত স্টোর করার অনুমতি দিতে বলবে, তারপর ৫০ এমবি করে বাড়ানোর জন্য আবার জিজ্ঞাসা করবে।

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

কতটা স্টোরেজ উপলভ্য আছে তা আমি কীভাবে চেক করব?

অনেক ব্রাউজারে, আপনি StorageManager API ব্যবহার করে নির্ধারণ করতে পারবেন যে অরিজিনের জন্য কতটা স্টোরেজ উপলভ্য আছে এবং এটি কতটা স্টোরেজ ব্যবহার করছে। এটি IndexedDB এবং Cache API-এর মাধ্যমে ব্যবহৃত মোট বাইটের সংখ্যা রিপোর্ট করে এবং আনুমানিক অবশিষ্ট স্টোরেজ স্পেস গণনা করা সম্ভব করে তোলে।

if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate();
  // quota.usage -> Number of bytes used.
  // quota.quota -> Maximum number of bytes available.
  const percentageUsed = (quota.usage / quota.quota) * 100;
  console.log(`You've used ${percentageUsed}% of the available storage.`);
  const remaining = quota.quota - quota.usage;
  console.log(`You can write up to ${remaining} more bytes.`);
}

আপনাকে অবশ্যই কোটা-অতিরিক্ত ত্রুটিগুলি ধরতে হবে (নিচে দেখুন)। কিছু ক্ষেত্রে, উপলভ্য কোটা, স্টোরেজের প্রকৃত পরিমাণের চেয়ে বেশি হতে পারে।

পরীক্ষা করুন

ডেভেলপমেন্টের সময়, বিভিন্ন ধরনের স্টোরেজ পরীক্ষা করতে এবং সেভ করা সব ডেটা মুছে দিতে, আপনি ব্রাউজারের DevTools ব্যবহার করতে পারবেন।

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

কোটা শেষ হয়ে গেলে কী করবেন?

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

IndexedDB এবং Cache API, উভয়ই QuotaExceededError নামের একটি DOMError থ্রো করে যখন আপনি উপলভ্য কোটা অতিক্রম করে যান।

IndexedDB

অরিজিন তার কোটা অতিক্রম করলে, IndexedDB-তে লেখার প্রচেষ্টা ব্যর্থ হবে। ট্রানজ্যাকশনের onabort() হ্যান্ডলারকে কল করা হবে, একটি ইভেন্ট পাস করা হবে। ইভেন্টের error প্রপার্টিতে DOMException অন্তর্ভুক্ত থাকবে। name ত্রুটি চেক করলে QuotaExceededError রিটার্ন করবে।

const transaction = idb.transaction(['entries'], 'readwrite');
transaction.onabort = function(event) {
  const error = event.target.error; // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
};

Cache API

অরিজিন তার কোটা অতিক্রম করলে, Cache API-তে লেখার চেষ্টা QuotaExceededError DOMException-এর মাধ্যমে প্রত্যাখ্যান করা হবে।

try {
  const cache = await caches.open('my-cache');
  await cache.add(new Request('/sample1.jpg'));
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}

উচ্ছেদ কীভাবে কাজ করে?

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

সাধারণত, কোনও সাইটের ডেটা (IndexedDB, Cache API ইত্যাদি সহ) বেস্ট এফর্ট ক্যাটেগরির মধ্যে পড়ে, যার অর্থ হল, কোনও সাইট পারসিস্টেন্ট স্টোরেজের অনুরোধ না করলে, ব্রাউজার নিজের ইচ্ছামতো সাইটের ডেটা মুছে দিতে পারে, যেমন, ডিভাইসের স্টোরেজ কম থাকলে।

সর্বোচ্চ প্রচেষ্টার জন্য উচ্ছেদ নীতি হল:

  • ব্রাউজারে জায়গা শেষ হয়ে গেলে Chromium-ভিত্তিক ব্রাউজার ডেটা মুছে ফেলা শুরু করবে, সবচেয়ে কম সম্প্রতি ব্যবহার করা অরিজিন থেকে শুরু করে সব সাইট ডেটা মুছে ফেলা হবে, তারপর পরবর্তী, যতক্ষণ না ব্রাউজার আর সীমার বাইরে থাকে।
  • ডিস্ক স্টোরেজে খালি জায়গা ভর্তি হয়ে গেলে Firefox ডেটা মুছে দিতে শুরু করবে, সবচেয়ে কম ব্যবহৃত সাইটের ডেটা প্রথমে মুছে দেওয়া হবে, তারপর পরেরটি, যতক্ষণ না ব্রাউজার সীমার মধ্যে চলে আসে।
  • Safari আগে ডেটা মুছে দিত না, কিন্তু সম্প্রতি সব রাইটেবল স্টোরেজের উপর সাত দিনের নতুন সীমা প্রয়োগ করেছে (নিচে দেখুন)।

iOS ও iPadOS 13.4 এবং macOS-এ Safari 13.1 থেকে শুরু করে, IndexedDB, সার্ভিস ওয়ার্কার রেজিস্ট্রেশন এবং Cache API সহ সব স্ক্রিপ্ট রাইটেবল স্টোরেজের উপর সাত দিনের সীমা আছে। এর অর্থ হল, ব্যবহারকারী সাইটের সাথে ইন্টার‍্যাক্ট না করলে, Safari ব্যবহার করার সাত দিন পরে Safari ক্যাশে থেকে সব কন্টেন্ট সরিয়ে দেবে। এই উচ্ছেদ নীতি ইনস্টল করা PWA-এর ক্ষেত্রে প্রযোজ্য নয়, যেগুলি হোম স্ক্রিনে যোগ করা হয়েছে। সম্পূর্ণ বিবরণ জানতে WebKit ব্লগে থার্ড-পার্টি কুকি সম্পূর্ণ ব্লক করা এবং আরও অনেক কিছু দেখুন।

স্টোরেজ বাকেট

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

বোনাস: IndexedDB-এর জন্য কেন র‍্যাপার ব্যবহার করবেন

IndexedDB হল একটি লো লেভেল API যা ব্যবহার করার আগে উল্লেখযোগ্য সেটআপের প্রয়োজন হয়, যা কম জটিল ডেটা স্টোর করার জন্য বিশেষভাবে কষ্টকর হতে পারে। বেশিরভাগ আধুনিক প্রমিস-ভিত্তিক API-এর মতো নয়, এটি ইভেন্ট-ভিত্তিক। IndexedDB-এর জন্য idb-এর মতো প্রমিস র‍্যাপার কিছু শক্তিশালী ফিচার লুকিয়ে রাখে, তবে আরও গুরুত্বপূর্ণভাবে, জটিল মেশিনারি (যেমন, ট্রানজ্যাকশন, স্কিমা ভার্সনিং) লুকিয়ে রাখে যা IndexedDB লাইব্রেরির সাথে আসে।

বোনাস: SQLite Wasm

Chrome থেকে Web SQL বন্ধ করে সরিয়ে দেওয়ার পরে, Google জনপ্রিয় SQLite ডেটাবেসের রক্ষণাবেক্ষণকারীদের সাথে কাজ করে SQLite-এর উপর ভিত্তি করে Web SQL-এর বিকল্প অফার করেছে। এটি কীভাবে ব্যবহার করতে হয় সেই সম্পর্কে বিস্তারিত জানতে অরিজিন প্রাইভেট ফাইল সিস্টেম দ্বারা ব্যাক-আপ করা ব্রাউজারে SQLite Wasm নিবন্ধটি পড়ুন।

উপসংহার

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

অতিরিক্ত রিসোর্স

ধন্যবাদ

এই গাইডটি পর্যালোচনা করার জন্য জ্যারাইড গুডম্যান, ফিল ওয়ালটন, ইজি কিতমুরা, ড্যানিয়েল মারফি, ডারউইন হুয়াং, জোশ বেল, মারিজিন ক্রুইসেলব্রিঙ্ক এবং ভিক্টর কস্টানকে বিশেষ ধন্যবাদ। এই নিবন্ধটি যে মূল নিবন্ধের উপর ভিত্তি করে লেখা হয়েছে, তার লেখক এইজি কিতামুরা, অ্যাডি ওসমানি এবং মার্ক কোহেনকে ধন্যবাদ। এজি Browser Storage Abuser নামে একটি সহায়ক টুল তৈরি করেছেন যা বর্তমান আচরণ যাচাই করার ক্ষেত্রে উপযোগী। এটি আপনাকে যতটা সম্ভব ডেটা স্টোর করতে এবং আপনার ব্রাউজারে স্টোরেজ সীমা দেখতে দেয়। ফ্রাঁসোয়া বিউফোর্টকে ধন্যবাদ, যিনি Safari-র স্টোরেজ সীমা খুঁজে বের করার জন্য গবেষণা করেছেন এবং থমাস স্টেইনারকে ধন্যবাদ, যিনি অরিজিন প্রাইভেট ফাইল সিস্টেম, স্টোরেজ বাকেট, SQLite Wasm এবং ২০২৪ সালে সামগ্রিক কন্টেন্ট আপডেট সম্পর্কে তথ্য যোগ করেছেন।