في السنوات القليلة الماضية، websockets أصبحت إلى حد ما مكونًا قياسيًا في جميع تطبيقات الويب الحديثة، ولكن لماذا حدث ذلك وكيف وصلنا إلى هنا؟ والأهم من ذلك، كيف يمكن لـ websockets مساعدتك في مراقبة بنيتك التحتية السحابية بشكل أكثر فعالية؟
نظرًا للطبيعة التقنية لهذا الموضوع، فمن الممكن الغوص بعمق شديد في التفاصيل. ولكنني سأحاول إبقاء الأمور عند مستوى عالٍ نسبيًا والتركيز على الفوائد التي تعود على مستخدمي بنيتنا التحتية السحابية.
الطريقة القديمة للقيام بالأشياء
في الأيام الأولى للويب، كان كل شيء ثابتًا. إذا كنت بحاجة إلى التفاعل مع خادم (أبعد من مجرد عرض صفحة ثابتة)، فسيتعين عليك تنفيذ نوع من برامج CGI النصية. وكان المثال النموذجي على ذلك هو شيء مثل الاشتراك في القائمة البريدية. تقوم بإدخال عنوان بريدك الإلكتروني والضغط على 'إرسال'، ثم ترى صفحة منفصلة تقوم بمعالجة البيانات. وكان هذا بدوره عبارة عن برنامج نصي يأخذ المدخلات ويعالجها على الخادم.
بحلول التسعينيات، تطورت البرمجة النصية من جانب الخادم بشكل كبير. وتطورت التكنولوجيا من تنفيذ مهام بسيطة إلى بناء صفحات ديناميكية بالكامل. لغات البرمجة مثل PHP، وتقنيات أكثر تقدمًا من جانب الخادم، مثل mod_perl، مكنت من برمجة ويب أكثر تطوراً بكثير. ورغم أن هذه التقنيات كانت مهمة، إلا أنها كانت لا تزال تتطور حول مفهوم إنشاء الصفحة عند التحميل. وبمجرد تحميلها، كان على المستخدم إعادة تحميل الصفحة بأكملها لتحديث المحتوى.
مع تطور الويب، دخلنا في AJAX/Web 2.0-حقبة الـ ’00، أصبحت صفحات الويب أكثر ديناميكية واستجابة. لم تعد بحاجة إلى إعادة تحميل الصفحة لتحديث المحتوى على الشاشة. كل ما كنت بحاجة إلى فعله هو تشغيل بعض إجراءات JavaScript. كانت العديد من صفحات AJAX لا تزال تعمل بواسطة PHP، ولكن مع إدخال JavaScript من جانب العميل، أصبح من الممكن جعلها أكثر ديناميكية.
تقديم AJAX
مع إدخال AJAX، أصبح من المهم بشكل متزايد وجود اتصال مستمر بين الخادم والعميل. وفجأة، أصبح بإمكانك الحصول على كمية كبيرة من استدعاءات API الناتجة عن مستخدم فردي على صفحة معينة. ونحن نفعل ذلك بطريقة 'السحب' (pull)، مما يعني أن العميل يطلب التحديثات من الخادم في فترة زمنية محددة (أو بناءً على إجراء معين).
مع دخولنا في حقبة الـ ’10، كان من الشائع أن تكون صفحات الويب مقسمة بالكامل بين الواجهة الأمامية (HTML/JavaScript/CSS) والواجهة الخلفية (Ruby on Rails, Django وغيرها)، والتي كانت تُستضاف غالبًا على خوادم مختلفة. وكانت الطريقة التي تتواصل بها الواجهة الأمامية مع الواجهة الخلفية هي عبر API. وكانت الواجهة الأمامية ثابتة إلى حد ما. ومع هذا الاتجاه، أصبح إجراء استدعاءات API إلى الخادم يمثل عنق زجاجة كبيرًا. فإذا كان عليك جلب عشرة أشياء مختلفة من الخادم، فإن ذلك يعني غالبًا أنك بحاجة إلى إجراء عشرة استدعاءات API مختلفة، حيث يحمل كل استدعاء عبئًا إضافيًا ووقت استجابة كبيرين.
الطريقة الحديثة
لمعالجة مشكلة وقت الاستجابة والعبء الإضافي هذه، تم تقديم websockets كجزء من HTML5 وتم تطبيقها في جميع المتصفحات الحديثة. وعلى عكس نهج 'السحب' التقليدي (أي قيام العميل بسؤال الخادم عن التغييرات)، فإن websocket هو كما يوحي الاسم، مقبس (socket)، حيث يمكن للخادم 'دفع' التغييرات إلى العميل. وبالتالي، إذا لم تكن هناك تغييرات، فلا داعي لأي اتصال. وأيضًا، نظرًا لأن العميل يمكنه الاتصال مباشرة بالخادم دون العبء الإضافي لفتح وإغلاق الاتصالات، فإن التطبيق يصبح أكثر استجابة بكثير.
هذا هو بالضبط كيف تم بناء تطبيق الويب الخاص بنا. التطبيق الفعلي عبارة عن صفحة ثابتة تفتح اتصال websocket بـ API. وبمجرد فتح هذا المقبس، يمكن لتطبيق الويب تلقي إشعارات من الخادم بالتغييرات. ما زلنا نرسل الأوامر إلى RESTful API، لكننا ندفع الإشعارات من الخادم إلى العميل باستخدام websocket.
ليس فقط لصفحات الويب
في حين أن الحالة الأكثر وضوحًا لتلقي التحديثات باستخدام websocket هي عبر المتصفح، إلا أن هناك حالات أخرى أيضًا. ربما تقوم بكتابة أداة تراقب التغييرات في بنيتك وتطلق إجراءً بناءً على ذلك. في هذه الحالة، يمكنك تسريع تطبيقك بشكل كبير من خلال استخدام websocket الخاص بنا.
في مكتبة Python الخاصة بنا، pycloudsigma، لدينا دعم مدمج لـ websockets. لدينا حتى مثال لكيفية الاستفادة من هذا لمراقبة أنشطة websocket ببضعة أسطر فقط من الكود. إليك عرض توضيحي سريع لـ monitor_websocket_activity.py الذي يراقب الإجراءات الناتجة عن إدخال المستخدم في تطبيق الويب.
لمزيد من المعلومات حول خدماتنا، تفضل بزيارة الميزات.
التعليقات
لا توجد تعليقات بعد. كن أول من يعلق.