حول تويتر, روبي أون ريلز, وما كل يُقال عن مشاكل الثباتية Scaling في الريلز

منذُ ظهرت منصة تطوير الويب روبي أون ريلز Ruby On Rails ارتفعت شعبيتها بشكل صاروخي وسريع بين مطوري الويب, وذلك لسرعة تطوير التطبيقات فيها من جهة, ولأن المنصة سهّلت على المطوّر استخدام مفاهيم رائعة مثل MVC, ORM , Database Migrations, Scaffolding, .. الخ.

صحيح أنها لم تخترع معظم هذه المفاهيم التي كانت موجودة سابقاً لكنها أول من حوّل هذه المفاهيم من مفاهيم أقرب منها إلى مفاهيم نظرية جميلة حين تقرأها لكن معقدة حين تطبقها إلى مفاهيم موجودة من أصل المنصة, بل بُنيت عليها المنصة بشكل جميل ومتناغم ومتكامل.

ربما يعد تويتر Twitter أحد أضخم المواقع المبنية على روبي أون ريلز, تويتر الذي شهد نسبة نمو مهولة بلغت 1,689% خلال عام واحد فقط (من شباط 2008 حتى شباط 2009). وفي صفحة كيف بُني تويتر في موقع تويتر يشرح القائمون على الموقع لماذا اختاروا منصة الريلز لبناء تويتر إذ يقولون:

”قمنا ببناء تويتر باستخدام روبي أون ريلز وذلك لأنها تُتيح لنا العمل بسرعة وسهولة –إن فريقنا يميل إلى تطبيق الميّزات والتعديلات عدة مرات يومياً. إن الريلز تقدم منصّات هيكلية كود جاهزة بحيث لا نضطر لاختراع العجلة في كل مرة نريد فيها إضافة شيء جديد مثل نموذج تسجيل دخول أو ميّزة لرفع الصور”.

كل هذا جميل, لكن المشكلة بدأت تظهر إثرَ التوقّفات والأعطال المتكررة والعديدة التي طرأت على موقع تويتر الذي لم يكن يتوقع القائمون عليه كل هذا الإقبال على الخدمة في فترة قصيرة. حتى أن صفحة الخطأ الشهيرة التي تظهر للمستخدمين أثناء حدوث عطل في الموقع والمعروفة باسم “Fail Whale”, والتي تصوّر حوتاً ترفعه مجموعة من العصافير, أصبحت أشهر صفحة خطأ في تاريخ الويب. لدرجة أن صورة (حوت الفشل) هذا صار لها نوادي معجبين و انتشرت بشكل هائل على القمصان والأكواب واللوحات وخلفيات سطح المكتب والرسوم المتحركة وحتى أغاني البوب! وهذه الشهرة لهذه الصورة التي لا تظهر إلا عندما يتوقف الموقع عن العمل تدلك على أن أعطال الموقع لم تكن بالقليلة على الإطلاق.

من هنا ظهر بعض من يغنّون موّال “Ruby doesn’t scale”, أي أن لغة روبي غير ثابتة ولا يمكن الاعتماد عليها في بناء المشاريع الضخمة! وبدأ هذا الكلام يتردد بكثرة بين المبرمجين وخاصة المبتدئين منهم إذ يضعون اللوم لمشاكل الثباتية التي عانى منها تويتر على لغة روبي ناسين وجود عوامل أخرى تحدد (ثباتية) الموقع أهمها قواعد البيانات والطريقة التي بُني فيها الموقع. وهذا يذكرني بالجدالات العقيمة التي غالباً ما تدور بين أوساط المبرمجين ومطوّري الويب على غرار :”أيّهما أفضل من ناحية الأمان Security اللغة الفلانية أم اللغة العلّانية؟” وتدور النقاشات وتحتدم حتى تكاد تصل إلى حد الشجار بينما الجواب بكل بساطة هو أنك لا تستطيع أن تقول هذه اللغة سيئة من الناحية الأمنية واللغة الثانية جيدة فالأمر بالنهاية يعتمد على المبرمج وطريقة كتابة البرنامج والاحتياطات المُتّخذة من قبل المبرمج لمحاولة تلافي ترك ثغرات في برنامجه.

بنفس الطريقة بدا لي أنه من السذاجة اتهام لغة روبي أو منصة ريلز بأنها (doesn’t scale), حسناً صحيح أنني من عشاق لغة روبي ومنصة ريلز وربما أول من كتب مقالة تعريفية باللغة العربية عنها ومن أوائل من استخدمها لتطوير المواقع لكن هذا لا يعني أنني لم أحاول تحرّي أمر الثباتية هذا بشكل حيادي وموضوعي.

في لقاء أجراه موقع zdnet الشهير مع Ezra Zygmuntowicz (لا تحاول قراءة اسمه كي لا تضيع وقتك) أحد مؤسسي شركة Engine Yard وهي من أشهر شركات استضافة الريلز ومن أهم خبراء الروبي أون ريلز, يقول:

”Languages don’t scale. Architectures scale.”

. أي أن لغات البرمجة بحد ذاتها ليس لها علاقة بالثباتية, بل المهم هو طريقة هندسة البرنامج. كما يقول بأن الغالبية العظمى من مشاكل تويتر هي مشاكل في قواعد البيانات, أو بشكل أدق الطريقة التي تم فيها بناء قاعدة البيانات. ويضيف بأن شركته تستضيف حوالي 600 تطبيق (منها مواقع ضخمة جداً مثل Github وغيره) ورغم ذلك لم يلاحظوا أية مشاكل في الثباتية. ويضيف بأن عنق الزجاجة bottleneck بالنسبة لجميع التطبيقات بغض النظر عن لغة برمجتها هي قاعدة البيانات. ويقول بأنه من ميزات الريلز أنها تقدم أدوات مساعدة تساعد المبرمج على الحد بشكل كبير من (التخبيص) الذي يمكن أن يطرأ على قاعدة البيانات, لكن تبقى هنالك نسبة من العمل تقع على عاتق المبرمج لمحاولة تحسين أداء عمل قاعدة البيانات خاصة عندما ينمو الموقع ويكبر وهذا ينطبق على جميع التطبيقات بغض النظر عن لغة البرمجة.

من جهة أخرى, وفي المدونة الخاصة بموقع تويتر يذكر أحد مطوري تويتر بوضوح سبب عدم ثباتية الموقع إذا يقول (للأسف يبدو أن وصلة تلك المقالة قد تغيرت ولم أعثر عليها لكن المقطع التالي متداول بشدة في معظم المقالات التي تتحدث عن ثباتية التويتر) :

“بشكل أساسي, تويتر هو نظام للمراسلة. لكن لم يتم بناؤه كنظام للمراسلة. ولأجل السهولة, تم بناء تويتر باستخدام تقنيات أكثر مُلائَمة لبناء نظام إدارة محتوى“.

عند هذه العبارة, يتوقف مطور الويب المخضرم Kevin Yank والكاتب في موقع Sitepoint الشهير. ماذا يقصد المبرمج من عبارة استخدام تقنيات أكثر مُلائمة لبناء نظام إدارة محتوى؟ في الواقع –كأي منصة تطوير ويب أخرى– لدى الريلز طرق معينة لإجراء عمليات معينة وذلك كي تسهّل المهمة وتسرع العمل للمبرمج. ويمكن للريلز أن تقودك في طريق معين قد لا يكون هو الطريق الأنسب للمهمة التي تقوم بها وهذا هو حال جميع المنصات, أن تقودك إلى هذا الطريق لا يعني أنك لا تستطيع تنفيذ أي شيء آخر عن طريقها. إن منصة العمل تساعدك بشكل كبير لكنها لا تقوم بالبرمجة عوضاً عنك في النهاية. لهذا يتوقع الكاتب أن مبرمج تويتر عندما بدأ العمل, كان على عجلة من أمره فاتخذ المسار التقليدي والسهل الذي توفره الريلز وهو مسار نظام إدارة المحتوى. ففي نظام إدارة المحتوى, كل مقالة لها كاتب, لذا تستطيع بسهولة الحصول على قائمة بجميع المقالات (بالنسبة لتويتر هو الخط الزمني العام لجميع الرسائل), أو الحصول على جميع المقالات التي كتبها كاتب معين (بالنسبة لتويتر هو على سبيل المثال الخط الزمني للرسائل الخاصة بك فقط).

للأسف, المبرمج لم يأخذ بالحسبان العملية الأكثر طلباً على الإطلاق بالنسبة لتويتر وهي عرض الرسائل من المستخدمين الذين تقوم بمتابعتهم فقط. ففي تطبيق مبني بطريقة نظام لإدارة المحتوى, الطريقة الوحيدة لتنفيذ هذا الطلب هي فلترة الرسائل Tweets الخاصة بكل مستخدم على حدى لاستخراج الرسائل الخاصة بالمستخدمين الذين تتابعهم فقط, وهي عملية ستكلف البرنامج الكثير جداً. الصورة التالية توضح الطريقة المذكورة:

(الصورة من موقع sitepoint.com)

يقول الكاتب, بأنه لو توقع المبرمج بأن هذه العملية هي العملية التي ستكون الأكثر إجهاداً بالنسبة لبرمجية تويتر, لكان من الممكن تصميم العملية بشكل مختلف بحيث تعكس طبيعة تويتر الحقيقية كنظام للمراسلة. كان يمكن أن يصمم بالشكل التالي: عندما يقوم مستخدم بإرسالة رسالة, يقوم البرنامج بالبحث عن المستخدمين الذين يتابعون هذا المستخدم ويقوم بوضع نسخة من الرسالة في الخط الزمني الخاص لكل مستخدم. الصورة التالية توضح هذه الطريقة:

(الصورة من موقع sitepoint.com)

ومرة أخرى يكرر الكاتب, بأن كلا الطريقتين يمكن تنفيذهما باستخدام روبي أون ريلز, والطريقة الأولى هي الطريقة التي ستقودك إليها الريلز في حال لم تتوقف قليلاً لتفكر بميزات وخصائص برنامجك. وفي النهاية لو كنت تقوم ببناء خدمة لتجذب المستخدمين على نطاق واسع ولم تقم بتصميم برنامجك لدعم هذه الفكرة, فلا يوجد لغة برمجة أو منصة عمل على الكرة الأرضية ستمنع برنامجك من الانهيار تحت الضغط الشديد!

الآن أعتقد أنه يوجد تساؤل لدى من يقرأ هذا الكلام, والتساؤل هو:”إن كانت مشاكل عدم الثباتية في تويتر لا علاقة لها بلغة روبي أو منصة ريلز, فلماذا لجأ مطوروا تويتر إلى لغة Scala كبديل عن الروبي؟“. في الواقع سؤال وجيه لكن أولاً دعونا نصحح معلومة خاطئة هاهنا: تويتر لم يستغنِ عن الروبي لصالح Scala, بل قام بإلغاء بعض الأجزاء المكتوبة بلغة روبي واستبدل بها أجزاء مكتوبة بـ Scala, تماماً كما فعل Facebook المكتوب أساساً بـ PHP عندما استبدل جزءاً من بنيته التحتية بأجزاء مكتوبة بـ C و ++C لكن حينها لم يقل أحد بأن “PHP Doesn’t Scale”!!

لكن ما هي قصة الضجة التي حدثت حول Scala؟ دعونا نتعرف على المزيد من التفاصيل.

بدأت القصة عندما كان Alex Payne مدير فريق الـ API في تويتر يتحدث في أحد المحاضرات عن تحويل أجزاء من تويتر من لغة روبي إلى Scala وهنا تم نشر العديد مئات المقالات في المدونات والرسائل على تويتر تتحدث عن أن روبي أثبتت فشلها وأن Scala هي الحل البديل والأوحد … إلخ. لكن بعض المبرمجين استغربوا كيف فهم الناس من حديث Alex بأن الروبي هي لغة غير ثابتة وبأن تويتر سوف يعمل على Scala عوضاً عنها. حتى Alex قال في رسالة له على تويتر:

”إن الأمر يزعجني بالفعل. لا أعتقد بأن الناس الذين كانوا حاضرين أثناء ألقاء محاضرتي قد أخذوا هذا الانطباع – يقصد الانطباع أن روبي غير ثابتة وسيتم استبدال Scala بها– . لقد حرّفت الصحافة الموضوع“.

في الواقع إن Alex لم يكن يقول بأن الريلز غير ثابتة, بل كان يقول بأنه معجب بلغة Scala وبأنه تم إعادة كتابة بعض الأجزاء المكتوبة بلغة روبي في تويتر والسبب بكل بساطة بأن روبي غير مناسبة لأداء بعض المهام, ولا يوجد لغة في العالم مناسبة لأداء جميع المهام بنفس الكفاءة لهذا السبب تستخدم غوغل في بنيتها التحتية مزيجاً من Java و ++C و Python ويستخدم Facebook مزيجاً من PHPو C و ++ Cو Erlang. لكن لا أدري لماذا ثارت الضجة على روبي أون ريلز بالذات؟ حسب ما استقرأت فالسبب هو بعض المبرمجين المتشككين في منصة روبي أون ريلز التي جاءت وقلبت الأمور رأساً على عقب واستفزت المنصة بعض المبرمجين المتعصبين (نعم! للأسف يوجد مبرمجين متعصبين للغات برمجة يحبونها), وساهم في هذا فيديوهات مثل فيديو (أنشىء مدونة في ربع ساعة مع روبي أون ريلز), وفيديوهات المقارنات الطريفة بين روبي أون ريلز و PHP و بين روبي أون ريلز و جافا و روبي أون ريلز و دوت نيت التي سلطت الضوء بقوة على تعقيد اللغات الأُخرى ومقارنة هذا ببساطة وقوة الريلز في آنٍ معاً.

إذاً ما فعلته Scala هي الجلوس في الطبقات الوسطى وتأدية مهام معينة بشكل أفضل مما كانت تؤديه روبي وذلك لأن Scala في النهاية أسرع من روبي وهي لغة ممتازة تتميز بعدد من الأمور لن نخوض فيها هنا. أما باقي ما تبقى من تويتر فما يزال يعمل على روبي أون ريلز دون أية تغيير.

لهذا إن كنت مطوّر ويب تحب تجربة الريلز لكنك متردد بسبب كل تلك الإشاعات التي تسمعها من هنا وهناك. فأقدم على هذه الخطوة ولا تتردد, وستجد عالماً جديداً ومثيراً من تطوير الويب … إلى أقصى حد.