كاشف فجوات أحداث SSE: مشاريع تخرج هندسة البرمجيات

قد ينقطع اتصال لوحة متابعة في منتصف عرض سجل طويل، ثم تعود الشاشة وكأن كل شيء سليم بينما بعض الأحداث لم يصل. مشروع تخرج في هندسة البرمجيات يمكن أن يحول هذه المشكلة إلى مختبر قابل للتكرار: خادم محلي ينتج أحداثاً ذات معرّفات متزايدة، وعميل متصفح يسجل آخر حدث عالجه، ثم يعيد الاتصال بعد انقطاع متعمد. يبين المختبر هل استؤنف السجل من النقطة الصحيحة أم ظهرت فجوة أو نسخة مكررة. هذا يختلف عن تخزين ملفات CSV؛ موضوعه ترتيب أحداث حية واستعادة العميل عند الاتصال، وليس نقطة حفظ لمهمة استيراد.

يمكن تقديم النطاق بوصفه مشاريع تخرج هندسة البرمجيات، مع تسليم مختبر مستقل وسيناريوهات انقطاع قابلة للإعادة.

اتفق على شكل الحدث قبل كتابة الواجهة

يبث الخادم استجابة من نوع text/event-stream، ويضمّن كل رسالة رقماً أو معرفاً في حقل id مع بياناتها. معيار HTML يشرح صيغة تدفق الأحداث وطريقة تفسير الأسطر، ويعرّف ترويسة Last-Event-ID التي يرسلها المتصفح عند إعادة الاتصال تلقائياً. لا تجعل الرقم مجرد عداد للعرض؛ ينبغي أن يمثل موضعاً قابلاً للبحث في سجل الخادم. إذا أعاد الخادم بدء العد من واحد بعد إعادة تشغيله، فالمعرف قد يصبح ملتبساً؛ أضف معرف جلسة أو رقماً مركباً يميز حقبة السجل. راجع قسم Server-sent events في معيار HTML قبل اختيار شكل الإطارات.

في النسخة الأولى، يحتفظ الخادم بمئة حدث في الذاكرة، ويعرض واجهة صغيرة للمشغل: إيقاف الاتصال، توليد حدث، مسح السجل، وإعادة الاتصال من معرّف مختار. يمكن استخدام مسار SSE نفسه لإرسال أحداث الاختبار، لكن سجل الأحداث المخزن لا ينبغي أن يعتمد على اتصال المتصفح الحالي. بهذا الفصل يستطيع الطالب فحص ما كان موجوداً في الخادم حتى عندما كان العميل غير متصل.

نفّذ الاستئناف مع فجوة معلنة

عند الاتصال الأول، يقرأ العميل الأحداث بالتتابع ويخزن آخر معرف أكمل معالجته. بعد قطع الشبكة، يرسل المتصفح المعرف السابق تلقائياً عبر الترويسة المحددة في المعيار. يبحث الخادم عن الحدث الذي يأتي بعده ويعيد ما تبقى بالترتيب. إذا لم يعد المعرف موجوداً لأن نافذة الاحتفاظ قصيرة، يجب أن يرسل الخادم حدث إعادة مزامنة واضحاً أو يطلب من العميل تحميل لقطة حالة جديدة عبر طلب منفصل؛ لا يقفز بصمت إلى أحدث رقم. وثائق EventSource على MDN تشرح سلوك إعادة الاتصال وخصائص الواجهة التي يعتمد عليها المتصفح.

مثال: استلم العميل الأرقام 40 إلى 44، ثم انقطع قبل وصول 45. بعد الاتصال، يرسل آخر رقم مكتمل وهو 44، ويعيد الخادم 45 و46. إذا بدأ سجل الاحتفاظ عند 60، فالمطلوب ليس إرسال 60 ثم متابعة عادية، بل التصريح بأن 45–59 غير متاحة وإجراء مزامنة كاملة. سجّل الفجوة كحالة مستقلة حتى يمكن قياس تكرارها عند تغيير حجم نافذة الاحتفاظ.

افصل وصول الحدث عن تطبيق أثره

حتى مع الاستئناف قد يرى العميل الرسالة ذاتها ثانية إذا تعطل بعد تنفيذ التغيير وقبل حفظ آخر معرف. لذلك اجعل معالجة الحدث قابلة للتكرار: خزّن المعرف مع أثره في معاملة محلية واحدة، أو افحص إن كان قد عولج قبل إضافة العنصر إلى الواجهة. لا تعتمد على ذاكرة المتصفح المؤقتة بوصفها قاعدة البيانات الوحيدة إذا كان المطلوب بقاء الحالة بعد إعادة تحميل الصفحة. يمكن أن يقتصر المختبر على جدول محلي بسيط يعرض الأحداث والتغييرات الناتجة عنها، مع زر لمسح البيانات.

هذه «مرة واحدة» ليست خاصية سحرية يضمنها الاتصال؛ إنها نتيجة تصميم التخزين ومعالجة التكرار. وثّق نقطة الحفظ في كل مرحلة، ثم أوقف التطبيق اصطناعياً بين استلام الرسالة وتثبيت أثرها. إن لم يستطع الفريق تحديد ترتيب الخطوات الذي ينتج نسخة مكررة، فاختبار الفشل غير كافٍ.

مثال تشغيل يمكن إعادة إنتاجه

أنشئ الأحداث order-1 إلى order-8، واجعل العميل يتوقف عند 4. أعد الاتصال وسجّل ما إذا وصل 5 ثم 6 ثم 7 ثم 8. بعد ذلك امسح أحداث 5 و6 من مخزن الخادم عمداً، مع إبقاء آخر معرف للعميل عند 4. النتيجة المتوقعة هي إشارة فجوة ومطالبة بتحميل لقطة، لا إظهار 7 كأن التسلسل كامل. الأسماء والأعداد هنا مثال للاختبار فقط ولا تمثل نظام طلبات حقيقياً.

أضف عموداً لكل محاولة اتصال: وقت البدء، آخر معرف معروف، أول وآخر معرف أعيد، عدد التكرارات، وحالة الفجوة. حافظ على سجل الأحداث والنتائج في ملف اختبار حتى يمكن مقارنة إصدارين من العميل. اجعل وقت الانتظار وسرعة البث قابلين للإعداد لتكرار ظروف الاتصال البطيء.

اختبارات القبول وحالات الفشل

اختبر اتصالاً مستقراً، وانقطاعاً بين حدثين، وانقطاعاً أثناء معالجة الحدث، ومعرفاً غير معروف، وسجلاً انتهت مدة احتفاظه، وتكرار إرسال حدث، وإعادة تشغيل الخادم. القبول يعني أن الواجهة تعرض التسلسل الصحيح أو فجوة معلنة، وأنها لا تدعي اكتمالاً لمجرد أن الاتصال عاد. اختبر أيضاً رسالة مع بيانات متعددة الأسطر، ومعرفاً فارغاً، وسلسلة UTF-8 عربية؛ صيغة الحدث لها قواعد تحليل، فلا تفترض أن كل سطر بيانات مستقل هو رسالة منفصلة.

راقب استهلاك الذاكرة وعدد الاتصالات المتزامنة، وأغلق EventSource عند مغادرة الشاشة. لا تستخدم بثاً بلا حدود في مختبر صفّي صغير. إن كان الخادم يدعم الوكيل العكسي، تحقق من أن التخزين المؤقت لا يجمع الاستجابة ويؤخر الإطارات؛ هذه نقطة تشغيل يجب إثباتها في بيئتك، لا استنتاجها من نجاح محلي.

حدود المشروع وتسليم مشاريع التخرج

هذا النموذج لا يحل تلقائياً ترتيب الأحداث بين عدة منتجين ولا يضمن تخزيناً دائماً أو تسليماً فورياً في كل شبكة. استئناف SSE يساعد على طلب ما فاته العميل فقط إذا احتفظ الخادم بتاريخ مناسب وعرف كيف يفسر المعرّف. كما أن واجهة EventSource التقليدية لا توفر كل خيارات ترويسات طلب مخصصة؛ وثّق المصادقة والقيود التي تختارها، ولا تضع أسراراً في عنوان URL. يشرح دليل MDN لاستخدام SSE إنشاء الاتصال والاستماع إلى أنواع الأحداث.

يمكن أن يتضمن التسليم شيفرة الخادم والعميل، مولد سيناريوهات الفشل، مخطط حالات، ومقارنة موثقة بين الاستئناف من سجل كامل والاستعادة من لقطة. ترتبط الفكرة بـمشاريع التخرج وقواعد البيانات وواجهات API. يستطيع الفريق مراجعة مستورد CSV ذي نقطة تحقق للمقارنة بين حفظ تقدم عملية دفعية واستعادة تدفق أحداث؛ التشابه في فكرة نقطة الاستئناف فقط، أما نموذج الاتساق والمصدر مختلفان. يجب أن يذكر التقرير عدد أحداث الاختبار والقيود المعروفة، لا أن يصف النموذج بأنه جاهز للإنتاج.