تُعد WebSockets قوية لأنها تدعم الاتصال ثنائي الاتجاه. ولهذا السبب أيضًا، غالبًا ما تكون زائدة عن الحاجة. الكثير من المنتجات لا تحتاج إلى قناة مزدوجة كاملة. تحتاج فقط إلى متصفح يبقى متصلاً ويتلقى التحديثات.
بالنسبة للإشعارات، واللوحات المعلوماتية، وتقدم الوظائف، وتغذيات النشاط، غالبًا ما تكون الأحداث المرسلة من الخادم هي الخيار الأكثر نظافة.
لماذا تستمر SSE في التكيف
تستمر SSE في البساطة لأنها تحافظ على نموذج النقل ضيقًا:
- طلب HTTP قياسي
EventSource مدمج في المتصفح- دفق بيانات من الخادم إلى العميل فقط
- تكامل سهل مع الوكلاء وأنماط المصادقة الموجودة
يبدو نقطة نهاية الخادم الحد الأدنى كما يلي:
app.get("/events", (req, res) => {
res.writeHead(200, {
"Content-Type": "text/event-stream",
"Cache-Control": "no-cache",
Connection: "keep-alive",
});
res.write(`event: ready\n`);
res.write(`data: ${JSON.stringify({ status: "ok" })}\n\n`);
});
وواجهة العميل صغيرة بالمثل:
const source = new EventSource("/events");
source.addEventListener("ready", (event) => {
console.log(JSON.parse(event.data));
});
عندما تتفوق WebSockets
تظل WebSockets الأداة الأفضل عندما يحتاج كل من المتصفح والخادم للتواصل بشكل متكرر:
- تفاعلات متعددة اللاعبين
- التحرير التعاوني
- قنوات الأوامر ثنائية الاتجاه
- أحداث عميل ذات تردد عالي
الخطأ هو اختيار WebSockets لأن "الزمن الحقيقي" يبدو أنه يتطلبها.
قاعدة أفضل
إذا كان المتصفح يستمع في الغالب، ابدأ بـ SSE. انتقل إلى WebSockets فقط عندما يكون الاتصال ثنائي الاتجاه مطلبًا حقيقيًا للمنتج، وليس مجرد رد فعل معماري.
المزيد من القراءة