عودة الحوسبة خادم العميل؟

أحد الأشياء التي وجدتها مثيرة للاهتمام في عالم التطوير خلال الأشهر القليلة الماضية هي كيف تعود التطبيقات الحديثة إلى وضع المزيد من المعلومات الاستخباراتية في العميل بدلاً من الخادم. لا يعد طراز خادم العميل شيئًا جديدًا بالطبع: إنه الطريقة التي تم بها إنشاء التطبيقات التقليدية لسنوات ، حيث تتحدث تطبيقات العميل الغنية مع التطبيقات من جانب الخادم. ولكن في عصر الويب وحتى الويب 2.0 ، انتقل التركيز إلى تطبيقات الويب التي كان الجزء الأكبر من الذكاء بها على خادم الويب (عادة في خوادم التطبيقات المستندة إلى Java) وكان العميل مجرد صفحة ويب بسيطة في متصفح حيث تقوم في كل مرة تنقر فيها ، بتحميل صفحة جديدة.

لكن في الآونة الأخيرة ، أدى نضج HTML5 و CSS وبصفة خاصة JavaScript إلى قيام المطورين بوضع ذكاء حقيقي ومعالجة حقيقية في صفحة الويب نفسها. على وجه الخصوص ، رأينا ظهور مجموعة متنوعة من الأطر المستندة إلى جافا سكريبت من جانب العميل والتي تجعل من الأسهل إنشاء واجهات ذكية ذكية تعمل بالكامل داخل متصفح ويب حديث. عادةً ما تكون المستعرضات المعنية مستندة إلى محرك Webkit ، بما في ذلك Chrome و Safari ، ولكن يبدو أن معظم التطبيقات تعمل بشكل جيد في الإصدارات الحالية من Firefox و Internet Explorer أيضًا. ينتهي بك الأمر بصفحة ويب أكثر تعقيدًا تتغير ديناميكيًا ، وتسحب البيانات من الخادم حسب الحاجة.

يبدو أن ثلاثة أطر عمل MVC بشكل خاص تحظى بمعظم الاهتمام: Backbone.js و Ember.js و Angular.js. (يرمز MVC إلى وحدة التحكم في عرض الطراز - إنها في الأساس البنية الكامنة وراء حوسبة عميل الويب. "js" تعني جافا سكريبت.) بشكل أساسي ، كل هذا يمثل ثمرة لنهج AJAX (JavaScript غير متزامن و XML) الشائعة على مدار العقد الماضي أو لذلك ، ولكن الحصول على أكثر نضجا وموحدة تقريبا. تتمثل الفكرة في وضع المزيد من الحالة والذكاء في المستعرض ، ثم جعل المتصفح يتصل بواجهة برمجة تطبيقات REST على جانب الخادم.

العمود الفقري هو أبسط وأقل هذه الأطر ؛ يتم استخدامه على نطاقات مختلفة من قبل العديد من المواقع الشعبية. نشأ Ember من إطار يسمى Sproutcore الذي دعمته شركة Apple ، وهو إطار أكثر شمولًا مصممًا للسماح لك بإجراء تطبيقات على نمط سطح المكتب. غالبًا ما يستخدم مع Bootstrap - مجموعة من القوالب لـ HTML و CSS التي تم إنشاؤها في الأصل بواسطة موظفي Twitter. الزاوي هو بديل Google الذي يبدو أنه في مكان ما بين - يعتقد بعض الناس أنه أكثر مرونة بعض الشيء أو على الأقل "أقل رأي" من Ember ولكنه أكثر شمولاً من Backbone. (لاحظ أن Google تدفع المطورين إلى استخدام Angular لتحسين جودة الترميز ، ولكن داخليًا تستخدم بالفعل مجموعة مختلفة من الأطر ذات الملكية.) حتى Microsoft أضافت خطاطيف إلى Visual Studio لهذه الأطر.

هذا هو شبكة الإنترنت ، وهناك العشرات من البدائل. واحدة من أكثر الأشياء إثارة للاهتمام التي سمعتها مؤخرًا هي Meteor ، المصممة للعمل مع JavaScript على جانبي العميل والخادم. ولكن هذا لا يزال مبكرًا جدًا ، ولا أعرف أي مستخدمين حقيقيين حتى الآن. في غضون ذلك ، يتم تشغيل المزيد من المطورين باستخدام Node.js ، وغالبًا ما يستخدم في تطبيقات جافا سكريبت من جانب الخادم.

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

ربما الأهم من ذلك ، يمكنك إنشاء تطبيقات للهواتف المحمولة تتناسب مع الأجهزة المختلفة دون الحاجة إلى كتابة تطبيقات أصلية محددة. لا تزال هناك حجة جيدة للتطبيقات الأصلية ، والتي يمكنها معالجة الميزات المحددة لكل نظام أساسي بشكل مباشر. ومع ذلك ، وجد الكثير من المطورين أن هذه الأُطُر يمكنها تسريع عملية تطوير الأنظمة الأساسية بشكل كبير ، خاصةً عند استخدامها مع أشياء مثل PhoneGap ، إطار عمل مفتوح المصدر تم شراؤه من قِبل Adobe وفتح مصدره في مشروع Apache Cordova.

المحمول بالطبع ، يجلب القيود الخاصة به ، بما في ذلك سرعة المعالجات ، وربما الأهم من ذلك ، سرعة - وأحيانا عدم الاتصال. أحد الأسباب التي تجعل الأشخاص يحبون التطبيقات على صفحات الويب هو أنه في كثير من الأحيان يمكنك تنزيل الوظيفة الأساسية عبر شبكة Wi-Fi أو اتصال سريع والحصول على البيانات التي تحتاجها فقط وليس التصميم بأكمله. حزم مثل PhoneGap تحل هذه المشكلة عن طريق وضع JavaScript في تطبيق تم تنزيله.

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

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