WebSocket أم SSE لعرض البيانات المباشرة؟
· PoolByte Technology
ليست هناك حاجة لإعادة طلب الصفحة بأكملها كل ثانية لإظهار حالة الطلب المباشر أو دردشة الدعم أو تقدم المعاملة. يمكن استخدام WebSocket وServer-Sent Events لنقل التحديثات عبر اتصال مفتوح. قم بالاختيار بناءً على اتجاه الرسالة وظروف التشغيل، وليس على الاسم الذي يبدو "أكثر حداثة".
إشعار من الخادم أو المحادثة؟
يعد SSE مناسبًا لإرسال تدفقات الأحداث من الخادم إلى المتصفح. تستمع واجهة EventSource في المتصفح لهذا الدفق؛ يمكن أيضًا إرسال أوامر العميل عبر طلبات HTTP العادية. مستند MDN SSE يصف تنسيق الحدث وسلوك إعادة الاتصال.
من ناحية أخرى، يوفر WebSocket مراسلة ثنائية الاتجاه. ويمكن تقييمه عند الحاجة إلى تفاعل متبادل مكثف. ومع ذلك، تتم أيضًا إدارة حجم وتكرار وتراكم قائمة انتظار الرسائل المراد كتابتها إلى الاتصال المفتوح. وصف WebSocket API يشير على وجه التحديد إلى حد التحكم في التدفق في واجهة برمجة التطبيقات الكلاسيكية.
في شاشة تصدير التقرير، يطلب المستخدم الملف مرة واحدة وينتظر تحديثات التقدم. قد يكون SSE كافيًا لهذا الاستخدام. في تطبيق التعاون، قد تتطلب التعديلات التعاونية للمستخدمين نموذج اتصال آخر. في كلتا الحالتين، توفر القدرة على الحصول على أحدث حالة من خلال طلب قياسي أولاً نقطة بداية موثوقة للمستخدم الذي يواجه مشكلات في الاتصال.
لا يظل التفويض ثابتًا أثناء فتح الاتصال
تحقق على الخادم من أن القناة المشتركة مملوكة للعميل. إن تغيير اسم القناة من قبل المستخدم لا ينبغي أن يمنح المستخدم الحق في تتبع طلب آخر. تصميم كيفية إغلاق الاتصال عند انتهاء الجلسة أو إلغاء الوصول. إن معرفة القناة لا تغني عن التحقق من صلاحيات الوصول.
اجعل محتوى الحدث صغيرًا أيضًا. بدلاً من إرسال سجل العميل بالكامل في كل رسالة، قم بنقل تغيير الحالة الضروري. لا تضع معلومات شخصية في سجلات الأخطاء أو أسماء القنوات العامة. يجب على العميل تقديم الرسائل كنص آمن عند كتابتها على الشاشة؛ نظرًا لأنه يأتي من الخادم، فلا ينبغي تحويله مباشرة إلى HTML.
ما هو الوضع الصحيح بعد الانقطاع؟
يمكن للمستخدم وضع الشاشة في الخلفية أو تبديل الشبكات. عند إعادة الاتصال، من الضروري استعادة الأحداث الفائتة أو الحصول على ملخص للموقف الأخير. إن نسبة التقدم التي تعود إلى الوراء، ويظهر نفس الإشعار مرة أخرى، والمهمة المكتملة المتبقية "قيد التشغيل" هي سيناريوهات اختبار منفصلة.
- إظهار حالة التحديث على الواجهة عند فقدان الاتصال.
- الحد من عمليات إعادة المحاولة وإضافة فترات انتظار بينهما.
- لا تقم بالتسجيل المزدوج لإعادة تسليم نفس الحدث في الواجهة.
- قياس عدد الاتصالات بالخادم لعلامات تبويب متعددة.
- لا تحدد نتيجة المهمة بالاعتماد فقط على الإخطار النهائي.
اختبارات القبول من جهة الاستضافة
اسأل عما إذا كان مسموحًا بالاتصالات الطويلة، ومهلة الوكيل العكسي، والتخزين المؤقت للإخراج، وميزانية الاتصال المتزامن. يمكن أن يؤدي إبقاء طلب PHP مفتوحًا لفترة طويلة إلى استنزاف سعة المعالجة على الاستضافة المشتركة؛ ومن الضروري اختيار الهندسة المعمارية وفقا لذلك. عند إعداد نطاق البرمجيات المخصصة ، قم بتضمين الاتصال النشط المتوقع وحجم الرسالة في شروط التسليم. تكمن قيمة العرض المباشر في أنه لا يزال بإمكانه إظهار النتيجة الصحيحة عند فقدان الاتصال.