كوروليف. الطب لشبكة الإنترنت

منذ حوالي عام ، تم نشر مقال نيكيتا بروكوبوف الواضح عن خيبة الأمل في البرمجيات. إذا حكمنا من خلال التعليقات الإيجابية ، فإن المطورين ليسوا غير مبالين بجودة منتجاتهم. ربما حان الوقت لبدء التمثيل؟

في هذه المقالة ، أود أن أتحدث عن تطوري ، والذي ، في رأيي ، يمكن أن يعالج مشاكل الأداء الرئيسية لشبكة الويب الحديثة ويجعل المستخدم أكثر سعادة. المشاكل هي: كود JS الثقيل ، الوقت المرتفع لبدء العمل مع الصفحة (TTI) ، ارتفاع الذاكرة واستهلاك المعالج.

قبل قراءة المزيد ، اتبع الرابط . جرب لعب مباراتين. يفضل اللعب من سطح المكتب.

القليل من التاريخ

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

نهج حديث لتطوير موقع الويب هو نتيجة تطوير متطلبات تفاعل واجهة المستخدم. سقطت المهام لتحسين التفاعل على أكتاف المبرمجين. وكثيرا ما لم يكن لديهم الكفاءات والسلطة لتطوير حل "من البداية إلى النهاية". تعلم مصممو التخطيط كتابة JS وأصبحوا الواجهة الأمامية. بدأ المنطق يتدفق تدريجياً من الخادم إلى العميل. من السهل على المتسابق الأمامي الكتابة للمتصفح ، والواجهة الخلفية مريحة لعدم التفكير في المستخدم (أعط JSON لك ، ثم على الأقل لا ينمو العشب). قبل عامين فقط ، كان هناك زيادة في الاهتمام بالعمارة بدون خادم ، حيث تم اقتراح أن تطبيقات JS ستعمل مباشرة مع قاعدة البيانات وحافلات الأحداث.

حاليًا ، "موقع الويب الكروي في فراغ" هو تطبيق JS معقد وخادم واجهة برمجة تطبيقات بسيط يتواصل من خلاله. يعمل المنطق الرئيسي على عميل سميك ، وينحرف جانب الخادم إلى طبقة بسيطة لقاعدة البيانات.

الحاجة إلى الحفاظ على المنطق على العميل يخلق مشاكل. إذا "انطلقت" الخدمة وبدأت في كسب المال ، فستكون الأمور أكثر سوءًا من حيث الإنتاجية. ستتغير المتطلبات. سيتغير فريق التطوير. سيكون هناك المزيد والمزيد من التعليمات البرمجية الجديدة ، ولن يتم تنظيف الرمز القديم. ستتضخم الصفحة من التبعيات ، وستحمل JSON حول الغرض الذي لا يتذكره أحد ، ولكن من المخيف حذفه ، وفجأة يحدث شيء. ستظهر مهام الخلفية SetInterval ، والتي يتم تنفيذ كل منها لعدة مللي ثانية في كل ثانية ، والتي ستؤدي بعد مرور بعض الوقت إلى الفرامل وتسخين جهاز iPad المستخدم المؤسف لدرجة أنه يمكنه قلي البيض المقلي عليه. ينتهي الأمر بحقيقة أن الواجهة الأمامية المحترقة ستأتي إلى المدير مع اقتراح لإعادة كتابة كل شيء من الصفر في إطار جديد. سيرفض المدير ، وستبدأ الواجهة الأمامية في استخدام إطارين معًا.

كيف يعمل Korolev

لذا ، ماذا لو عدنا إلى نقطة التقرير؟ اللحظة التي جاء فيها شخص بفكرة تحديث المحتوى دون إعادة تحميل الصفحة ، وأدت الحتمية التاريخية إلى ظهور AJAX؟ ماذا لو تركت كل شيء على الخادم وقمت بعمل عميل رفيع؟ تقدم أفضل المواقع العرض المسبق لصفحة الخادم (SSR) بحيث يرى المستخدم الواجهة قبل تحميل JS وبدء تشغيله. يمكنك الذهاب إلى أبعد من ذلك وترك الرمز الوحيد المسؤول عن معالجة الإدخال / الإخراج على العميل ، نظرًا للمتطلبات الحالية للتفاعل. الأفكار حول هذا امتدت إلى مشروع Korolev .

كيف يعمل على جانب العميل؟ يأتي المستخدم إلى الصفحة. يعطي الخادم HTML الذي تم إنشاؤه ونصًا صغيرًا (~ 6 كيلوبايت بدون ضغط) يتصل بالخادم عبر مقبس ويب. عندما يطلق مستخدم حدثًا (على سبيل المثال ، نقرة) ، يرسله النص البرمجي إلى الخادم. بعد معالجة الحدث ، يقوم الخادم بإنشاء قائمة من أوامر النموذج "إضافة <div> هناك" ، "إضافة فئة إلى هذا العنصر" ، "حذف مثل هذا العنصر". يطبق العميل قائمة الأوامر على DOM. على هذا النحو ، لا يحدث العمل مع HTML - يعمل البرنامج النصي مباشرة مع DOM ، لذلك لا تقلق من إعادة تعيين محتويات النموذج أو موضع التمرير.

ماذا يحدث على الخادم؟ عندما يأتي طلب صفحة من المتصفح ، ينشئ Korolev جلسة جديدة. للجلسة ، يتم إجراء الحالة الأولية ، التي يتم تخزينها في ذاكرة التخزين المؤقت. يتم إنشاء HTML من هذه الحالة ، والتي يتم تقديمها للعميل كاستجابة للطلب. بالإضافة إلى ذلك ، يقوم الخادم بحفظ "DOM الافتراضي" في الجلسة. بعد طلب الصفحة ، يقبل الخادم طلب فتح مقبس الويب. يربط Korolev مقبس ويب مفتوح بجلسة عمل. يمكن لكل حدث قادم من العميل تغيير الحالة المرتبطة بالجلسة. كل تغيير في الحالة يؤدي إلى استدعاء وظيفة render ، التي تشكل "DOM افتراضي" جديد ، مقارنة بالإصدار القديم. نتائج المقارنة في قائمة أوامر لإرسالها إلى العميل.

ماذا يحدث في التعليمات البرمجية ورئيس المطور؟ يمكن أن يذكرك ما سبق برد الفعل ، مع اختلاف أن كل شيء يعمل على الخادم. من حيث نهج التنمية ، لدينا أيضا شيء مماثل. لذلك ، إذا كنت تعمل مع React أو "DOM افتراضي" آخر ، فإن نهج الملكة سيكون مألوفًا لك. إذا لم تكن على دراية بـ React ، فتخيل أن لديك بيانات تقوم بإدراجها في القالب. تخيل أنه وفقًا للقالب ، فإن معالجات الأحداث مبعثرة يمكنها تغيير البيانات (ولكن ليس DOM). قمت بتغيير البيانات ، وتغير الصفحة نفسها. يتوصل كوروليف نفسه إلى كيفية تغيير DOM.

الأداء

هناك سؤالان شائعان حول Korolev: "ماذا لو كانت التأخيرات عالية" و "هل هذا لن يؤدي إلى تحميل الخادم الخاص بي". كلا السؤالين معقول جدا يستخدم المبرمج الأمامي لتشغيل برنامجه على الجهاز المحلي للمستخدم. هذا يعني أنه سيتم تطبيق التغييرات التي تم إجراؤها عليه بمجرد انتهاء جهاز JS من تنفيذ التعليمات البرمجية وبدء المتصفح في العرض. لقد عرضت على وجه التحديد مثالًا لاستخدام "بأقصى سرعة" في البداية. يمكنك ملاحظة التأخير فقط إذا أتيت من الجانب الآخر من العالم (الخوادم موجودة في موسكو) أو جلست على الإنترنت عبر GPRS. حسنًا ، أو خادمي الظاهري المثير للشفقة مع نواة واحدة و 1 غيغابايت من ذاكرة الوصول العشوائي لا يمكن أن يتحمل تأثير الهرب.

عادة ما يتم طرح السؤال حول تحميل الخادم من قبل المتسوقين. يعمل محرك إخراج التغيير بسرعة كبيرة: ~ 10 آلاف استنتاج في الثانية لشجرتين تعسفيتين من 500 عقدة على جهاز ماك بوك الأصغر لعام 2013. يقدم العرض الثابت أيضًا نتيجة جيدة: ما يصل إلى مليون صفحة في الثانية. يتم تخزين كل "DOM افتراضي" ومعالجته في شكل تسلسلي خاص ويأخذ 128 كيلوبايت لصفحة ويب متوسطة. تم تحسين عملية الإخراج بشكل خاص ولا تحتوي على حمل للذاكرة و GC.

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

السعر

عليك أن تدفع مقابل الإعانات. يجب التخلي عن بعض العادات ، وبعض العادات الجديدة لاكتسابها. على سبيل المثال ، يجب عليك التخلي عن الرسوم المتحركة JS وأن تكون راضيًا عن الرسوم المتحركة CSS. سيكون عليك معرفة كيفية جعل البنية التحتية موزعة جغرافيًا في البداية إذا كنت ترغب في خدمة المستخدمين من بلدان مختلفة بجودة عالية. يجب أن تتخلى عن شبيبة وتذهب إلى سكالا.

أشعر بالخجل قليلاً (في الواقع لا) لأنني ضللت القارئ ولم أقل على الفور أن كوروليف كتب بلغة سكالا. هل تقرأ حتى هذه اللحظة إذا تحدثت عن هذا على الفور؟ بالحديث عن الملكة ، لا بد لي من التغلب على القوالب النمطية. الأول يرجع إلى حقيقة أن عرض الخادم يُنظر إليه على أنه شيء بطيء وليس تفاعليًا. والثاني يتعلق بحقيقة أن سكالا شيء معقد. والصورة النمطية الأولى والثانية لا علاقة لها بالواقع. علاوة على ذلك ، فإن البرمجة بأسلوب React على Scala أكثر ملاءمة من JS. ينجذب الحديث شبيبة نحو البرمجة الوظيفية ، سكالا يخرجها من خارج منطقة الجزاء. على سبيل المثال ، يحتوي أي كائن في Scala على طريقة copy() تسمح لك بنسخ كائن عن طريق تغيير بعض الحقول. يتم إنشاء مجموعات ثابتة في مكتبة سكالا القياسية.

الخلاصة

تم تطوير Korolev لمدة ثلاث سنوات من قبل العديد من المطورين وتم حل العديد من مشاكل "الأطفال" فيه. المشروع موثق جيدًا ، وجميع الوظائف مغطاة بأمثلة. أقترح البدء في تنفيذ الملكة بخدمات مستقلة صغيرة. آمل أن يساعد Korolev في جعل البرامج أقل مخيبة للآمال.

رابط للمشروع على جيثب