عندما تفشل الأنظمة، لا يهتم المستخدمون بأي اعتماد معطل. عليهم معرفة ما إذا كان المنتج لا يزال يساعدهم في إنهاء المهمة التي فتحوه من أجلها.
لهذا السبب، فإن التدهور اللائق مهم أكثر من التوافر كمعيار أداء مجرّد. يمكن أن يكون النظام متدهورًا جزئيًا وما زال يحافظ على معظم قيمة المستخدم إذا تم تصميم أوضاع الفشل بشكل جيد.
ما يبدو عليه التدهور الجيد
بدلاً من صفحة فارغة أو نافذة خطأ عالمية، قد يقدم المنتج القابل للتحمل ما يلي:
- تقديم بيانات كتالوج مخزنة
- إخفاء أداة ثانوية
- عرض محتوى قديم لكنه لا يزال مفيدًا
- إبقاء مسارات القراءة متاحة بينما يتم إيقاف مسارات الكتابة
هذا ليس إخفاءً للواقع. بل هو تحديد أي تجربة أقل ضررًا عندما يكون جزء من المكدس غير صحي.
لماذا "stale-while-revalidate" مفيد
نموذج "stale-while-revalidate" مفيد للمحتوى الذي يتغير نادرًا ولكن يتم قراءته باستمرار.
Cache-Control: s-maxage=60, stale-while-revalidate=86400
هذا يخبر ذاكرة التخزين المؤقت الوسيطة أنها تستطيع الاستمرار في تقديم محتوى قديم قليلاً بينما تحاول تحديثه في الخلفية. إذا فشل التحديث، قد يتلقى المستخدمون استجابة مفيدة بدلاً من خطأ من المصدر.
هذا منطقي بالنسبة لـ:
- صفحات المنتجات
- الوثائق
- المحتوى العام
وهو أقل منطقية بالنسبة لـ:
- الأرصدة
- إجماليات الخروج
- الحالة الحساسة للغاية في الوقت الحقيقي
تدهور واجهة المستخدم مهم أيضًا
المرونة في الخلفية هي جزء فقط من القصة. يجب أن تعزل بنية الواجهة الأمامية الفشل بحيث لا يؤدي اعتماد ضعيف واحد إلى تعطيل الصفحة بأكملها.
غالبًا ما يعني ذلك:
- تقنيات بديلة على مستوى المكونات
- تقديم جزئي
- رسائل حالة واضحة ولكن هادئة
قراءة إضافية