IndexedDB এবং জনপ্রিয় স্টেট ম্যানেজমেন্ট লাইব্রেরির মধ্যে অ্যাপ্লিকেশন স্টেট সিঙ্ক করার পেশাদার পদ্ধতি সম্পর্কে জানুন।
কোনও ব্যবহারকারী প্রথমবার কোনও ওয়েবসাইট বা অ্যাপ্লিকেশন লোড করলে, UI রেন্ডার করার জন্য ব্যবহৃত প্রাথমিক অ্যাপ্লিকেশন স্টেট তৈরি করতে প্রায়ই বেশ কিছুটা কাজ করতে হয়। যেমন, কখনও কখনও অ্যাপকে ক্লায়েন্ট-সাইডে ব্যবহারকারীকে যাচাই করতে হয় এবং তারপরে পৃষ্ঠায় দেখানোর জন্য প্রয়োজনীয় সব ডেটা পাওয়ার আগে একাধিক API অনুরোধ করতে হয়।
IndexedDB-তে অ্যাপ্লিকেশন স্টেট স্টোর করা, বার বার ভিজিট করার জন্য লোড টাইম দ্রুত করার একটি দুর্দান্ত উপায় হতে পারে। অ্যাপটি ব্যাকগ্রাউন্ডে যেকোনও API পরিষেবার সাথে সিঙ্ক করতে পারে এবং stale-while- revalidate স্ট্র্যাটেজি ব্যবহার করে নতুন ডেটা সহ UI আপডেট করতে পারে।
তবে, IndexedDB ব্যবহার করার সময় অনেক গুরুত্বপূর্ণ বিষয় বিবেচনা করতে হয় যা API-তে নতুন ডেভেলপারদের কাছে অবিলম্বে স্পষ্ট নাও হতে পারে। এই ডকুমেন্ট সাধারণ প্রশ্নের উত্তর দেয় এবং IndexedDB-তে অ্যাপ্লিকেশন স্টেট পারসিস্ট করার সময় মনে রাখার মতো কিছু গুরুত্বপূর্ণ বিষয় নিয়ে আলোচনা করে।
আপনার অ্যাপকে অনুমানযোগ্য রাখুন
IndexedDB-এর জটিলতার বেশিরভাগই এই কারণে হয় যে, এমন অনেক বিষয় আছে যেগুলির উপর আপনার (ডেভেলপার) কোনও নিয়ন্ত্রণ নেই। এই বিভাগে IndexedDB নিয়ে কাজ করার সময় আপনাকে যেসব সমস্যা মনে রাখতে হবে তার অনেকগুলির ব্যাপারে আলোচনা করা হয়েছে।
স্টোরেজে ডেটা লেখা নাও হতে পারে
IndexedDB-তে লেখার সময় বিভিন্ন কারণে সমস্যা হতে পারে এবং কিছু ক্ষেত্রে ডেভেলপার হিসেবে এইসব কারণ আপনার নিয়ন্ত্রণের বাইরে থাকে। যেমন, কিছু ব্রাউজার ব্যক্তিগত ব্রাউজিং মোডে থাকাকালীন IndexedDB-তে লেখার অনুমতি দেয় না। এছাড়াও, এমন হতে পারে যে ব্যবহারকারী এমন কোনও ডিভাইস ব্যবহার করছেন যার ডিস্ক স্টোরেজে খালি জায়গা প্রায় নেই এবং ব্রাউজার আপনাকে কোনও কিছু স্টোর করতে দেবে না।
এই কারণে, আপনার IndexedDB কোডে সবসময় সঠিক সমস্যা সমাধান করার পদ্ধতি প্রয়োগ করা অত্যন্ত গুরুত্বপূর্ণ। এর অর্থ হল, মেমরিতে অ্যাপ্লিকেশন স্টেট (এটি স্টোর করার পাশাপাশি) রাখা সাধারণত একটি ভালো আইডিয়া, যাতে প্রাইভেট ব্রাউজিং মোডে রান করার সময় বা স্টোরেজ স্পেস উপলভ্য না থাকলে UI ভেঙে না যায় (এমনকি স্টোরেজ প্রয়োজন এমন কিছু অন্যান্য অ্যাপ ফিচার কাজ না করলেও)।
ব্যবহারকারী হয়ত সেভ করা ডেটা পরিবর্তন করেছেন বা মুছে দিয়েছেন
সার্ভার-সাইড ডেটাবেসের মতো নয়, যেখানে আপনি অননুমোদিত অ্যাক্সেস সীমাবদ্ধ করতে পারেন, ক্লায়েন্ট-সাইড ডেটাবেস ব্রাউজার এক্সটেনশন এবং ডেভেলপার টুলের মাধ্যমে অ্যাক্সেস করা যায়, এবং সেগুলি ব্যবহারকারী মুছে ফেলতে পারেন।
ব্যবহারকারীদের পক্ষে তাদের স্থানীয়ভাবে স্টোর করা ডেটা পরিবর্তন করা অস্বাভাবিক হলেও, ব্যবহারকারীদের পক্ষে এটি মুছে ফেলা বেশ সাধারণ। আপনার অ্যাপ্লিকেশন যাতে কোনও সমস্যা ছাড়াই এই দুটি পরিস্থিতিই সামলাতে পারে তা নিশ্চিত করা গুরুত্বপূর্ণ।
সেভ করা ডেটা হয়ত পুরনো হয়ে গেছে
আগের বিভাগের মতোই, ব্যবহারকারী নিজে ডেটা পরিবর্তন না করলেও, স্টোরেজে থাকা ডেটা আপনার কোডের আগের কোনও ভার্সন দ্বারা লেখা হতে পারে, সম্ভবত এমন একটি ভার্সন যাতে বাগ আছে।
IndexedDB-তে স্কিমা ভার্সন এবং এর IDBOpenDBRequest.onupgradeneeded() পদ্ধতি ব্যবহার করে আপগ্রেড করার জন্য বিল্ট-ইন সহায়তা রয়েছে; তবে, আপনাকে এখনও
এমনভাবে আপনার আপগ্রেড কোড লিখতে হবে যাতে এটি আগের ভার্সন (বাগ সহ একটি ভার্সন সহ) থেকে আসা ব্যবহারকারীকে
ম্যানেজ করতে পারে।
এই ক্ষেত্রে ইউনিট টেস্ট খুব সহায়ক হতে পারে, কারণ সব সম্ভাব্য আপগ্রেড পাথ ও কেস ম্যানুয়ালি টেস্ট করা প্রায়শই সম্ভব হয় না।
আপনার অ্যাপের পারফর্ম্যান্স ভালো রাখুন
IndexedDB-এর অন্যতম প্রধান ফিচার হল এর অ্যাসিঙ্ক্রোনাস API, তবে এটি ব্যবহার করার সময় পারফর্ম্যান্স নিয়ে চিন্তা করতে হবে না বলে ভুল করবেন না। এমন অনেক ঘটনা আছে যেখানে ভুল ব্যবহারের ফলে এখনও মূল থ্রেড ব্লক হয়ে যেতে পারে, যার ফলে অ্যাপ কাজ করা বন্ধ করে দিতে পারে।
সাধারণ নিয়ম হিসেবে, IndexedDB-তে রিড ও রাইট করার সময় ডেটা অ্যাক্সেস করার জন্য প্রয়োজনীয় ডেটার থেকে বেশি ডেটা ব্যবহার করা উচিত নয়।
IndexedDB-এর মাধ্যমে বড়, নেস্টেড অবজেক্টকে একটি রেকর্ড হিসেবে স্টোর করা সম্ভব হলেও (এবং ডেভেলপারদের দৃষ্টিভঙ্গি থেকে এটি করা বেশ সুবিধাজনক), এই অভ্যাস এড়িয়ে চলা উচিত। কারণ, IndexedDB কোনও অবজেক্ট স্টোর করার সময়, প্রথমে সেটির একটি স্ট্রাকচার্ড ক্লোন তৈরি করে এবং স্ট্রাকচার্ড ক্লোনিং প্রসেসটি মূল থ্রেডে ঘটে। অবজেক্ট যত বড় হবে, ব্লকিং টাইম তত বেশি হবে।
IndexedDB-তে কীভাবে অ্যাপ্লিকেশন স্টেট বজায় রাখা যায় তা প্ল্যান করার সময় এটি কিছু চ্যালেঞ্জের সৃষ্টি করে, কারণ বেশিরভাগ জনপ্রিয় স্টেট ম্যানেজমেন্ট লাইব্রেরি (যেমন Redux) আপনার সম্পূর্ণ স্টেট ট্রিকে একটি সিঙ্গল JavaScript অবজেক্ট হিসেবে ম্যানেজ করার মাধ্যমে কাজ করে।
এইভাবে স্টেট ম্যানেজ করার অনেক সুবিধা আছে এবং IndexedDB-তে সম্পূর্ণ স্টেট ট্রিকে একটি রেকর্ড হিসেবে স্টোর করা আকর্ষণীয় ও সুবিধাজনক মনে হতে পারে, তবে প্রতিটি পরিবর্তনের পরে এটি করলে (থ্রটল/ডিবাউন্স করা হলেও) মূল থ্রেড অপ্রয়োজনীয়ভাবে ব্লক হয়ে যাবে, রাইট এররের সম্ভাবনা বাড়বে এবং কিছু ক্ষেত্রে ব্রাউজার ট্যাব ক্র্যাশ করবে বা কাজ করা বন্ধ করে দেবে।
একটি রেকর্ডে সম্পূর্ণ স্টেট ট্রি সেভ করার পরিবর্তে, আপনাকে এটি আলাদা আলাদা রেকর্ডে বিভক্ত করতে হবে এবং শুধুমাত্র সেই রেকর্ডগুলি আপডেট করতে হবে যা আসলে পরিবর্তিত হয়।
বেশিরভাগ পেশাদার পদ্ধতির মতোই, এটিও কোনও 'সব বা কিছুই নয়' ধরনের নিয়ম নয়। যেসব ক্ষেত্রে স্টেট অবজেক্টকে ভেঙে শুধু ন্যূনতম পরিবর্তন-সেট লেখা সম্ভব নয়, সেখানে ডেটাকে সাব-ট্রি-তে ভেঙে শুধু সেগুলি লেখা, সবসময় সম্পূর্ণ স্টেট ট্রি লেখার চেয়ে এখনও বেশি পছন্দসই। একটু একটু করে উন্নতি করা একেবারে উন্নতি না করার চেয়ে ভালো।
সবশেষে, আপনার লেখা কোডের পারফর্ম্যান্সের প্রভাব পরিমাপ করা উচিত। এটি ঠিক যে IndexedDB-তে ছোট রাইট বড় রাইটের চেয়ে ভালো পারফর্ম করবে, তবে এটি তখনই গুরুত্বপূর্ণ যখন আপনার অ্যাপ্লিকেশনের মাধ্যমে IndexedDB-তে করা রাইট আসলে বড় টাস্ক-এর দিকে নিয়ে যায় যা মূল থ্রেডকে ব্লক করে এবং ব্যবহারকারীর অভিজ্ঞতাকে খারাপ করে। পরিমাপ করা গুরুত্বপূর্ণ যাতে আপনি বুঝতে পারেন যে আপনি কীসের জন্য অপ্টিমাইজ করছেন।
উপসংহার
ডেভেলপাররা IndexedDB-এর মতো ক্লায়েন্ট স্টোরেজ মেকানিজম ব্যবহার করে তাদের অ্যাপ্লিকেশনের ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে পারেন। এটি সেশন জুড়ে স্টেট বজায় রাখার পাশাপাশি, বারবার ভিজিট করার সময় প্রাথমিক স্টেট লোড হতে যে সময় লাগে তা কমিয়ে দেয়।
IndexedDB সঠিকভাবে ব্যবহার করলে ব্যবহারকারীর অভিজ্ঞতা নাটকীয়ভাবে উন্নত হতে পারে, তবে এটি ভুলভাবে ব্যবহার করলে বা ত্রুটিগুলি সঠিকভাবে পরিচালনা না করলে অ্যাপগুলি ভেঙে যেতে পারে এবং ব্যবহারকারীরা অসন্তুষ্ট হতে পারে।
ক্লায়েন্ট স্টোরেজ আপনার নিয়ন্ত্রণের বাইরে থাকা অনেক বিষয়ের উপর নির্ভর করে, তাই আপনার কোড ভালভাবে পরীক্ষা করা এবং সঠিকভাবে সমস্যা সমাধান করা অত্যন্ত গুরুত্বপূর্ণ, এমনকি যেসব সমস্যা প্রাথমিকভাবে হওয়ার সম্ভাবনা নেই বলে মনে হয় সেগুলিও।