بناء تطبيقات الوقت الفعلي باستخدام WebSockets
الاستعلام الدوري (Polling) سيء لتطبيقك.
قمت ذات مرة ببناء أداة دردشة (chat widget) باستخدام AJAX polling. قمت بضبط التطبيق ليطلب من الخادم رسائل جديدة كل ثانية. لقد عمل الأمر، لكنه كان بطيئاً. واجهة المستخدم كانت تشعر بالبطء. كان الخادم يبذل جهداً كبيراً جداً. معظم الطلبات كانت تعيد بيانات فارغة. شعرت وكأنني أحاول ملء حوض استحمام بملعقة صغيرة.
تقنية WebSockets تغير هذا الأمر.
بدلاً من الطلبات المستمرة، تقوم بفتح اتصال واحد مستمر. يتيح ذلك تدفقاً ثنائياً للبيانات؛ حيث يمكن للخادم دفع البيانات إلى العميل فوراً، ويمكن للعميل إرسال البيانات إلى الخادم فوراً.
لماذا تستخدم WebSockets؟
• ينخفض زمن الاستجابة (Latency) من مئات الملي ثانية إلى عشرات الملي ثانية. • يصبح حمل الخادم قابلاً للتوقع. • توفر في عرض النطاق الترددي (bandwidth) عن طريق إزالة رؤوس HTTP المتكررة. • تعمل في الدردشة، والإشعارات المباشرة، والألعاب الجماعية.
كيف تعمل:
يبدأ الاتصال بطلب ترقية HTTP (HTTP upgrade request). إذا وافق الخادم، فإنه يرسل رمز الحالة 101. بعد ذلك، تستخدم بروتوكولاً ثنائياً خاماً أو نصياً. لن تكون هناك ملفات تعريف ارتباط (cookies) أو رؤوس (headers) تبطئ سرعتك بعد الآن.
فخاخ شائعة يجب تجنبها:
- انقطاع الاتصال: الشبكات قد تفشل. يجب عليك تنفيذ استراتيجية إعادة محاولة مثل التراجع الأسي (exponential backoff).
- تسرب الذاكرة (Memory leaks): أغلق دائماً الـ sockets الخاصة بك عندما يغادر المستخدم. الاتصالات "الزومبي" (Zombie connections) تستهلك ذاكرة الخادم.
- حلقات الرسائل: عند البث (broadcasting)، تخطَّ المرسل الأصلي. وإلا، سيرى المستخدم رسالته مرتين.
- الاتصالات الخاملة: تقوم بعض الخوادم الوكيلة (proxies) بإغلاق الاتصالات الصامتة. استخدم نبضات القلب (ping/pong heartbeat) لإبقاء الـ socket حياً.
توقف عن سؤال الخادم عما إذا كان قد تغير شيء ما. ابدأ بإبقاء الخط مفتوحاً لتتمكن من التحدث متى احتجت لذلك.
تحديك:
خذ مثالاً بسيطاً للدردشة. أضف مؤشراً لـ "...typing" (جاري الكتابة). قم بنشره على مستضيف مثل Render أو Fly.io. بمجرد أن ترى ذلك المؤشر يتحرك في الوقت الفعلي دون الحاجة إلى الاستعلام الدوري (polling)، فقد ارتقيت بمستواك.