كيف يمكن لمصنع جعة صغير أن يوضح آلية عمل خادم الويب؟

إذا كنت قد بدأت لتوّك كمطوّر ويب، يمكن أن يراودك السؤال التالي: كيف يمكن لكل المفاهيم الجديدة أن تتصل مع بعضها البعض عندما نقوم بطلب الولوج إلى رابط ما على متصفح الإنترنت الخاص بنا؟

كيف يمكن لمصنع جعة صغير أن يوضح آلية عمل خادم الويب؟

بالتأكيد قد تعرف الفرق بين التطبيقات Front-end و back-end، لكن ذلك لن يمنحك سوى نظرة على الصورة الكبيرة لما يحدث! وحتى تصبح هذه النظرة أكثر عمقًا، قمنا بإعداد هذا الدليل المبسّط الذي يشرح آلية الاتصال بين المتصفح (client-side) والخوادم المختلفة (server-side). فلنبدأ رحلتنا…

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

نموذج زبون-خادم (Client-Server):

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

وفي الجانب المقابل، يقوم فريق العمليات المصنّع للجعة (الذي يمثّل الخادم Server) بتلبية طلبات الزبائن، أي ينتظر الطلبات من الزبائن (clients)، ويقدم لهم الموارد المناسبة للطلب بالاعتماد على قدراتهم الحاسوبية. وكمثال شائع عن الزبون (client) نأخذ متصفح الويب كـChrome، أمّا بالنسبة للخوادم فتوضع في موقع منعزل بعيد، وتديرها شركات عالمية كأمازون مثلا.

قد تظن أن هذه العمليات وحيدة البعد كعمليات الشراء المعروفة مثلًا،  لكن لا، انتظر! سترى مع اكتمال الصورة شيئًا فشيئًا، أن الأمور معقدة أكثر من ذلك بكثير.

نموذج الطلب-الرد (Request-Response):

كما رأينا في نموذج الزبون-خادم لكل طرف أدوار مختلفة، الزبون هو طالب الخدمة، والخادم هو المستجيب. وفي مرحلة ما بعد تقديم الطلب، بالتأكيد سيُرد عليه.

وهكذا، ترسل المتصفحات (مثل Chrome) الطلبات إلى خوادم مركزية، تقوم بإعطائها المعلومات المطلوبة، على سبيل المثال، عندما ترسل طلب تحميل صفحة معينة، يجب أن يرسل الخادم الصفحة بآخر إصدار لها اعتمادًا على أحدث بيانات Upvote والتعليق.

لذا ربما تتساءل مجددًا: “كيف يتعامل الإنترنت مع هذا النطاق الواسع من الطلبات والردود؟“.

أولًا، يجب أن تعلم أن كل جهاز متصل بشبكة (كالإنترنت) يُسمى مضيف Host. ولكل مضيف عنوان IP فريد خاص به، يقوم خادم الـ DNS (وهو نوع من الخوادم) بربط عنوان الصفحة URL التي تطلبها بعنوان IP خاص بمخدّم معين.

عندما تكتب عنوان URL مثل موقعنا aliens-sci.com ، فأنت لا تتصل مباشرة بخوادم ويب “الفضائيون“. وإنما تقوم أولاً بالاتصال بخادم الـ DNS الذي توفره شركة المضيف. بعد ذلك، يستجيب الخادم لطلبك باستخدام العنوان المحدد لخادم “الفضائيون” . عندها يمكن للمتصفح تقديم طلب لخادم الفضائيون.

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

فلنعد الخطوات إذًا:

• يقوم المتصفح بإدخال عنوان الـ URL (aliens-sci.com).
• يُرسل الطلب إلى خادم الـ DNS الذي يردّ عنوان الـ IP لخادم الفضائيون.
• يرسل المتصفح الطلب إلى خادم الفضائيون.
• يردّ مخدّم الفضائيون الصفحة الرئيسية.

يُسمى هذا في كثير من الأحيان “فصل الاهتمامات Seperaion Of Concerns”. يسمح لكل خادم بتنفيذ وظيفة متخصصة، بحيث يمكن لكل جزء العمل بأقصى فاعليّة ممكنة.

تنويه: فصل الاهتمامات SoC: في علوم الحاسوب، هو مبدأ تصميمي لفصل البرامج الحاسوبية إلى أقسام واضحة، كل منها يُعنون كـاهتمام منفصل، ويكون عبارة عن مجموعة المعلومات التي تخصّ البرنامج الحاسوبي، كتفاصيل العتاد المطلوب على سبيل المثال.

هل سمعت من قبل بمفهوم المنفذ Port؟

ماذا تعني المنافذ؟

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

وبالمثل، يحتوي الخادم يحتوي مسارات لأنواع مختلفة من الطلبات، تُسمى منافذ Ports، سنورد لكم بعض أنواع المنافذ:

المنفذ 25: يستخدمه البروتوكول SMTP (توجيه البريد الإلكتروني).

المنفذ 80: يستخدمه البروتوكول HTTP (طلبات الويب الموصوفة أعلاه).

المنفذ 143: يستخدمه البروتوكول IMAP (لإدارة البريد الإلكتروني).

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

أين قواعد البيانات من الويب من هذا؟

حتى الآن، قمنا بتغطية مسار طلب مفرد إلى خادم الويب!  في تطبيقات الـfront-end يمكنك كتابة كود برمجي بلغة الجافا سكريبت JavaScript، ليقوم الخادم باستلام الطلب ومعالجته بلغة أخرى مثل بايثون Python أو  PHP أو منصة عمل مثل Node.js. لكن ماذا عن الجزء الذي يجب أن نحصل على بيانات ومعلومات منه؟

نحصل على البيانات التي نحتاجها مما تُسمى قاعدة المعطيات التي تكون مكتوبة باستخدام لغة SQL اختصارًا لـ Structured Query Language (وهي لغة الاستعلامات البنيوية) أو MongoDB، أو مجموعة من اللغات الأخرى لبناء قاعدة معطيات علاقاتية. لكن مهلاً! حتى الآن لم نخزن قاعدة المعطيات على نفس الخادم الذي نستخدمه!

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

قاعدة البيانات هي مجرد بنية رقمية لتخزين البيانات، يقوم الخادم بتوفير بروتوكولات تسمح بمشاركتها على الشبكة. فلنفترض أن أحد الزبائن قدم طلبات على الجعة بعدد كبير يصل إلى 1000 طلبية. سيحتاج المصنع إلى الاتصال مع المستودع وطلب كمية من القوارير تتناسب مع الطلبية (هذه دورة طلب- استجابة أخرى)، في هذه الحالة يأخذ المخدّم دور الزبون والمخدم معًا، يستقبل طلب من المستخدم النهائي، ويرسل طلب إلى خادم آخر بعد ذلك، وتعتمد استجابتها على استجابة مخدّم قاعدة المعطيات.

بالطبع لا يلاحظ المستخدم النهائي أي من هذه العمليات القابعة وراء الكواليس، من وجه نظره أرسل طلب واستقبل الرد لا أكثر ولا أقل.

مثال واقعي عن قواعد المعطيات والمخدّمات

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

بالإضافة إلى ذلك، يسمح لك Heroku بإضافة إيداعاتك المباشرة أولًا بأول إلى المخزن الافتراضي، باستخدام التعليمة البسيطة التالية: (git push heroku master)، بعد ذلك، ستظهر التغييرات التي أجريتها بعد شراء مجال domain من خدمة مثل Namecheap ووصله إلى تطبيق Heroku الخاص بك. ولكن إنْ كنت ترغب في استخدام قاعدة بيانات مع تطبيقك الحي (ربما ستفعل ذلك!)، ستظل بحاجة إلى حل استضافة منفصل لقاعدة البيانات تلك. ويقترح الكاتب لذلك استخدام قاعدة البيانات ClearDB التي لديها تطبيق في موقع Heroku، وتحتوي على نسخة مجانية مرنة تتوسع مع توسع قاعدة المعطيات الخاصة بك.

هل أصبت السهم وفهمت ما يحدث خلف الكواليس أثناء تصفحك على شبكة الإنترنت؟ هل أمتعك هذا الشرح؟ اعط أمثلة أخرى على غرار “مصنع الجعة”، الأمر ممتع حقًا…