من الثابت إلى البث: رحلة داخل SSE

الأحداث المرسلة من الخادم (Server-Sent Events - SSE)

هذا بصراحة واحد من أنماط الاتصال المفضلة لدي.

فكرته قائمة على نموذج الطلب/الاستجابة (Request/Response) الكلاسيكي، لكن مع لمسة مختلفة:

الاستجابة تبقى مفتوحة لفترة طويلة جداً.

كيف تعمل الـ SSE؟

عند استخدام الأحداث المرسلة من الخادم (SSE)، يقوم الخادم بالحفاظ على اتصال الاستجابة مفتوحًا، ويرسل البيانات على شكل دفعات صغيرة (Chunks) كأحداث متتابعة عبر الزمن — بدل أن يغلق الاتصال بعد إرسال استجابة واحدة فقط.

لنأخذ مثال بث الرسائل في ChatGPT:

1. العميل (Client – أي المتصفح أو التطبيق) يرسل رسالة إلى الخادم.

2. تصل الاستجابة على شكل دفعات صغيرة، وكأن شخصًا يكتبها أمامك مباشرة.

3. هذا هو عمل الـ SSE — الخادم يرسل كل جزء فور توليده، عبر تيار استجابة واحد مستمر (Ongoing Response Stream).

4. بعد اكتمال الرسالة، يمكنك إما إغلاق الاتصال أو إبقاؤه مفتوحًا لأحداث جديدة.

في حالتي، اخترت إغلاق التيار بعد الانتهاء. وسأشرح السبب لاحقًا.

مميزات SSE

1. يعمل عبر بروتوكول HTTP العادي — باستخدام نفس نموذج الطلب/الاستجابة المألوف لدينا.

2. ممتاز للحصول على تحديثات فورية (Real-time Updates).

عيوب SSE

1. يجب أن يبقى العميل متصلاً — إذا انقطع الاتصال، تفقد التيار.

2. مع HTTP/1.1، المتصفحات مثل Chrome تضع حدًا أقصى: ٦ اتصالات مفتوحة لكل نطاق (Domain).

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