المتصفح يوفر أكثر من مخزن لأن أنواع البيانات واستخداماتها مختلفة. LocalStorage بسيطة ومزامنة، IndexedDB قاعدة بيانات غير متزامنة للبيانات المنظمة، Cache Storage صممت أساسًا ل Request/Response وغالبًا تُستخدم مع Service Workers، و SessionStorage مرتبطة بسياق جلسة التبويب. اختيار المخزن الخطأ قد يسبب بطءًا أو تعقيدًا أو تسرب حالة بين أجزاء التطبيق. وفي بيئة متعددة Profiles، يجب أن تتأكد أن كل هذه الطبقات تتبع partition الصحيح.
LocalStorage مناسبة للقيم الصغيرة والبسيطة
API سهلة key/value لكنها synchronous، لذلك عمليات كثيرة أو قيم كبيرة قد تحجب main thread. استخدمها لتفضيلات صغيرة غير حساسة نسبيًا، وليس كقاعدة بيانات أو مكان Tokens عالية الحساسية يمكن سرقتها عبر XSS.
IndexedDB للبيانات المنظمة والكبيرة
IndexedDB asynchronous وتدعم object stores و indexes و transactions، لذلك تناسب offline data و collections أكبر. تحتاج schema/versioning ومراعاة أخطاء upgrade، لكنها أكثر مناسبة من LocalStorage عندما تصبح البيانات جزءًا حقيقيًا من التطبيق.
خطوات عملية
- حدد stores.
- اختر keys/indexes.
- اكتب migration لكل version.
- استخدم transactions.
- تعامل مع quota/errors.
- اختبر upgrade من نسخة قديمة.
Cache Storage ليست قاعدة بيانات عامة
هي مصممة لتخزين Request/Response pairs وتناسب assets أو API responses ضمن استراتيجيات Service Worker. لا تستخدمها لتخزين entities معقدة تحتاج query. واحذر من stale data عند تغيير API أو auth context.
SessionStorage لها lifecycle مختلفة
تعيش عادة مع page session وتنفصل بين tabs في حالات معينة، لكنها ليست بديلًا ل ـProfile isolation. استخدمها لحالة مؤقتة مثل خطوة wizard، لا لتخزين دائم تريد استعادته بعد إغلاق البيئة.
العزل بين Profiles يجب اختباره لكل API
اكتب marker مختلفة في كل مخزن داخل Profile A، ثم افتح نفس origin في Profile B وتأكد أنها غير موجودة. كرر بعد restart وأثناء التشغيل المتزامن. Cookie isolation وحدها لا تثبت أن IndexedDB أو Cache منفصلتان.
قائمة مراجعة
- LocalStorage منفصلة.
- IndexedDB منفصلة.
- Cache Storage منفصلة.
- Service Workers لا تتداخل.
- Permissions مرتبطة بال Profile الصحيحة.
- التنظيف لا يمس Profile أخرى.
ضع سياسة تنظيف و Backup
اعرف ماذا يحدث عند logout أو حذف Profile. بعض التطبيقات تحتاج الاحتفاظ ب offline data، وأخرى يجب أن تمسحها. لا تحذف كل storage بلا تمييز، ولا تنقلها بين Profiles بلا inventory واختبار توافق.
Quota و Eviction جزء من التصميم
Storage في المتصفح ليست مساحة غير محدودة. المتصفح قد يفرض quota أو يمسح بيانات في ظروف معينة. تعامل مع فشل الكتابة وراقب storage estimates عندما يناسب، ولا تجعل بيانات لا يمكن استعادتها تعيش فقط في client storage. البيانات المهمة تحتاج مزامنة أو مصدرًا خادميًا موثوقًا.
Transactions تمنع الحالة النصفية في IndexedDB
إذا كان تحديث كيان يحتاج الكتابة في أكثر من store، اجمع العمليات داخل transaction واحدة عندما يكون ذلك منطقيًا. بدون ذلك قد تنجح خطوة وتفشل أخرى وتترك cache أو index محلية لا تطابق البيانات الأساسية. اختبر abort paths مثلما تختبر النجاح.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…