IndexedDB ব্যবহার করার জন্য সর্বোত্তম অভ্যাস

একটি জনপ্রিয় স্টেট ম্যানেজমেন্ট লাইব্রেরি IndexedDB-এর মধ্যে অ্যাপ্লিকেশান স্টেট সিঙ্ক করার জন্য সর্বোত্তম অনুশীলনগুলি শিখুন৷

Philip Walton

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

IndexedDB- তে অ্যাপ্লিকেশনের অবস্থা সংরক্ষণ করা পুনরাবৃত্তি ভিজিটের জন্য লোডের সময় দ্রুত করার একটি দুর্দান্ত উপায় হতে পারে। অ্যাপটি তখন ব্যাকগ্রাউন্ডে যেকোন এপিআই পরিষেবার সাথে সিঙ্ক করতে পারে এবং অলসভাবে নতুন ডেটা দিয়ে UI আপডেট করতে পারে, একটি অচল থাকাকালীন- পুনঃপ্রমাণ কৌশল ব্যবহার করে।

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

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

আপনার অ্যাপ্লিকেশন অনুমানযোগ্য রাখা

IndexedDB এর আশেপাশে অনেক জটিলতা এই সত্য থেকে উদ্ভূত হয় যে এমন অনেকগুলি কারণ রয়েছে যার উপর আপনার (ডেভেলপার) কোন নিয়ন্ত্রণ নেই। এই বিভাগটি IndexedDB এর সাথে কাজ করার সময় আপনাকে অবশ্যই মনে রাখতে হবে এমন অনেকগুলি বিষয় অন্বেষণ করে।

সমস্ত প্ল্যাটফর্মে IndexedDB-তে সবকিছু সংরক্ষণ করা যায় না

আপনি যদি ছবি বা ভিডিওর মতো বড়, ব্যবহারকারী-উত্পাদিত ফাইলগুলি সংরক্ষণ করেন, তাহলে আপনি সেগুলিকে File বা Blob অবজেক্ট হিসাবে সংরক্ষণ করার চেষ্টা করতে পারেন। এটি কিছু প্ল্যাটফর্মে কাজ করবে কিন্তু অন্যগুলিতে ব্যর্থ হবে। iOS-এ Safari, বিশেষ করে, IndexedDB-তে Blob s সঞ্চয় করতে পারে না।

সৌভাগ্যক্রমে একটি Blob একটি ArrayBuffer এ রূপান্তর করা খুব কঠিন নয় এবং এর বিপরীতে। IndexedDB-তে ArrayBuffer s সংরক্ষণ করা খুব ভালভাবে সমর্থিত।

মনে রাখবেন, তবে, একটি Blob একটি MIME টাইপ আছে যখন একটি ArrayBuffer এর নেই৷ সঠিকভাবে রূপান্তর করার জন্য আপনাকে বাফারের পাশাপাশি টাইপটি সংরক্ষণ করতে হবে।

একটি ArrayBuffer কে একটি Blob রূপান্তর করতে আপনি কেবল Blob কনস্ট্রাক্টর ব্যবহার করেন।

function arrayBufferToBlob(buffer, type) {
  return new Blob([buffer], { type: type });
}

অন্য দিকটি কিছুটা বেশি জড়িত এবং এটি একটি অ্যাসিঙ্ক্রোনাস প্রক্রিয়া। আপনি ArrayBuffer হিসাবে ব্লব পড়তে একটি FileReader অবজেক্ট ব্যবহার করতে পারেন। পড়া শেষ হলে পাঠকের উপর একটি loadend ইভেন্ট ট্রিগার হয়। আপনি এই প্রক্রিয়াটিকে একটি Promise মোড়ানো করতে পারেন:

function blobToArrayBuffer(blob) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.addEventListener('loadend', () => {
      resolve(reader.result);
    });
    reader.addEventListener('error', reject);
    reader.readAsArrayBuffer(blob);
  });
}

সঞ্চয়স্থানে লেখা ব্যর্থ হতে পারে

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

এই কারণে, এটি অত্যন্ত গুরুত্বপূর্ণ যে আপনি সর্বদা আপনার IndexedDB কোডে সঠিক ত্রুটি পরিচালনা করুন। এর মানে এটিও সাধারণত অ্যাপ্লিকেশনের অবস্থা মেমরিতে রাখা একটি ভাল ধারণা (এটি সঞ্চয় করার পাশাপাশি), তাই ব্যক্তিগত ব্রাউজিং মোডে চলাকালীন বা স্টোরেজ স্পেস উপলব্ধ না হলে UI ভেঙে যায় না (এমনকি যদি অন্য কিছু স্টোরেজ প্রয়োজন এমন অ্যাপ বৈশিষ্ট্য কাজ করবে না)।

আপনি যখনই একটি IDBDatabase , IDBTransaction বা IDBRequest অবজেক্ট তৈরি করেন তখনই আপনি error ইভেন্টের জন্য একটি ইভেন্ট হ্যান্ডলার যোগ করে IndexedDB অপারেশনে ত্রুটিগুলি ধরতে পারেন৷

const request = db.open('example-db', 1);
request.addEventListener('error', (event) => {
  console.log('Request error:', request.error);
};

সংরক্ষিত তথ্য ব্যবহারকারী দ্বারা সংশোধন বা মুছে ফেলা হতে পারে

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

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

সংরক্ষিত তথ্য পুরানো হতে পারে

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

IndexedDB এর IDBOpenDBRequest.onupgradeneeded() পদ্ধতির মাধ্যমে স্কিমা সংস্করণ এবং আপগ্রেড করার জন্য অন্তর্নির্মিত সমর্থন রয়েছে; যাইহোক, আপনাকে এখনও আপনার আপগ্রেড কোডটি এমনভাবে লিখতে হবে যাতে এটি পূর্ববর্তী সংস্করণ থেকে আসা ব্যবহারকারীকে পরিচালনা করতে পারে (একটি বাগ সহ সংস্করণ সহ)।

ইউনিট পরীক্ষাগুলি এখানে খুব সহায়ক হতে পারে, কারণ সমস্ত সম্ভাব্য আপগ্রেড পাথ এবং ক্ষেত্রে ম্যানুয়ালি পরীক্ষা করা প্রায়শই সম্ভব হয় না।

আপনার অ্যাপ্লিকেশন পারফরম্যান্স রাখা

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

একটি সাধারণ নিয়ম হিসাবে, ইনডেক্সডডিবিতে পড়া এবং লেখা ডেটা অ্যাক্সেস করার জন্য প্রয়োজনীয়তার চেয়ে বড় হওয়া উচিত নয়।

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

IndexedDB-তে অ্যাপ্লিকেশন স্টেট কীভাবে বজায় রাখা যায় তা পরিকল্পনা করার সময় এটি কিছু চ্যালেঞ্জ উপস্থাপন করে, কারণ বেশিরভাগ জনপ্রিয় স্টেট ম্যানেজমেন্ট লাইব্রেরি (যেমন Redux ) আপনার সম্পূর্ণ স্টেট ট্রিকে একটি একক জাভাস্ক্রিপ্ট অবজেক্ট হিসাবে পরিচালনা করে কাজ করে।

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

একটি একক রেকর্ডে সমগ্র রাজ্য গাছ সঞ্চয় করার পরিবর্তে, আপনার এটিকে পৃথক রেকর্ডে বিভক্ত করা উচিত এবং শুধুমাত্র সেই রেকর্ডগুলি আপডেট করা উচিত যা প্রকৃতপক্ষে পরিবর্তিত হয়৷

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

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

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

উপসংহার

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

সঠিকভাবে IndexedDB ব্যবহার করলে ব্যবহারকারীর অভিজ্ঞতা নাটকীয়ভাবে উন্নত হতে পারে, এটিকে ভুলভাবে ব্যবহার করা বা ত্রুটির ঘটনাগুলি পরিচালনা করতে ব্যর্থ হলে তা ভাঙা অ্যাপ এবং অসুখী ব্যবহারকারীদের দিকে নিয়ে যেতে পারে।

যেহেতু ক্লায়েন্ট সঞ্চয়স্থানে আপনার নিয়ন্ত্রণের বাইরে অনেক বিষয় জড়িত থাকে, তাই এটি গুরুত্বপূর্ণ যে আপনার কোডটি ভালভাবে পরীক্ষা করা হয়েছে এবং সঠিকভাবে ত্রুটিগুলি পরিচালনা করে, এমনকি যেগুলি প্রাথমিকভাবে ঘটার সম্ভাবনা কম বলে মনে হতে পারে।