ما هي البرمجيات الوسيطة (Middleware)؟ تعريفها وأبرز حالات الاستخدام

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

تعريف البرمجيات الوسيطة (Middleware)

ببساطة، البرمجيات الوسيطة (Middleware) هي طبقة برمجية تعمل كوسيط بين تطبيقين أو خدمتين مختلفتين لتسهيل عملية الاتصال بينهما. يمكن النظر إليها كوكيل (proxy) قادر على أداء وظائف متعددة، مثل تجميع البيانات، أو ترجمة التنسيقات، أو مجرد تمرير الطلبات بين الأطراف المعنية.

حالات الاستخدام الشائعة للبرمجيات الوسيطة

1. الترجمة بين تنسيقات البيانات المختلفة

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

تخيل أن لدينا خدمتين تتحدثان بروتوكولات مختلفة وتحتاجان إلى التواصل. هنا يأتي دور البرمجيات الوسيطة (Middleware)؛ يمكننا إنشاء Middleware يستفيد من مكتبة لتحويل البيانات، ليقوم بترجمة الطلبات إلى التنسيق الذي تفهمه الخدمة المستقبلة.

2. تجميع وتكرار البيانات

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

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

تجميع البيانات (Accumulating Data)

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

تكرار البيانات (Duplicating Data)

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

لدينا خياران لتطبيق ذلك: أولاً، يمكننا استدعاء دوال الحفظ (save methods) الخاصة بخادم البحث من دوال الحفظ الخاصة بخوادم المستخدمين والمنتجات لتكرار البيانات. أو يمكننا إنشاء Middleware مخصص لعملية الحفظ، والذي سيقوم بالآتي:

• عند وصول طلب حفظ (save request)، يستدعي دالة الحفظ في خادم المنتج/المستخدم ودالة الحفظ في خادم البحث.
• إذا فشلت عملية الحفظ الأولى، فلا يتم استدعاء دالة الحفظ في الخادم الآخر (للحفاظ على اتساق قواعد البيانات).

دعونا نلقي نظرة على مخططات التصميم مع وبدون استخدام Middleware. أولاً، هذا هو الشكل بدون Middleware:

يبدو معقدًا، أليس كذلك؟ بالفعل، هذا التصميم يزيد من تعقيد الكود ويربط المكونات ببعضها بإحكام (tightly coupled).

وهنا نفس الحل مع Middleware:

في هذا السيناريو، يقوم العميل ببساطة باستدعاء Middleware لحفظ منتج أو مستخدم، ويتولى الأخير بقية المهام. لا يوجد أي كود يتعلق بتكرار البيانات في خوادم المنتجات أو المستخدمين أو حتى في جانب العميل. البرمجيات الوسيطة (Middleware) تتكفل بكل ذلك.

3. تعزيز أمان واجهات برمجة التطبيقات (API Security)

بالنسبة لأي كود يعمل في الواجهة الأمامية (front-end) من جانب العميل، يمكننا بسهولة عرض الطلبات الصادرة، إما من خلال وحدة تحكم المتصفح (browser's console) أو عبر وكيل (proxy). لقد تحدثنا سابقًا عن خادم المستخدمين الذي يتولى مهام تسجيل الدخول والتسجيل. إذا كان كود الواجهة الأمامية يرسل الطلبات مباشرة إلى هذا الخادم، فإن عنوان خادم المصادقة الخاص بنا سيكون مكشوفًا.

بعد معرفة عنوان IP الخاص بالخلفية (backend)، يمكن للمهاجمين استخدام أدوات للعثور على نقاط النهاية (endpoints) ومسح الخادم بحثًا عن الثغرات الأمنية. يمكننا استخدام Middleware كوكيل (proxy) لإخفاء عنوان URL الخاص بخادم المصادقة لدينا. تتواصل الواجهة الأمامية (front-end) مع Middleware، والذي يقوم بدوره بإعادة توجيه الطلب إلى خادم المصادقة، ثم يعيد الاستجابة. يتيح لنا هذا النهج أيضًا حظر جميع الطلبات الموجهة إلى خادم المصادقة، باستثناء تلك القادمة من عنوان URL الخاص بـ Middleware. هذا يجعل خادم المصادقة الخاص بنا أكثر أمانًا بشكل ملحوظ. لم يكن هذا ممكنًا في السابق، لأن الواجهة الأمامية كانت تتواصل مباشرة مع خادم المصادقة. وبما أن الواجهة الأمامية تعني جهاز العميل، لم يكن بإمكاننا تطبيق تصفية بناءً على عنوان IP.

4. إتاحة واجهات برمجة التطبيقات (APIs) العامة بشكل مقيد

في الجزء السابق، تعلمنا أن البرمجيات الوسيطة (Middleware) يمكن استخدامها لتقييد الوصول إلى واجهة برمجة التطبيقات (API) الخاصة بنا. الآن دعنا ننظر إلى الجانب الآخر من المعادلة: ماذا لو أردنا منح وصول مقيد إلى API الخاص بنا؟

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

لهذا الغرض، يمكننا تطبيق Middleware يقوم فقط بكشف بعض نقاط النهاية (endpoints) المحددة وإعادة توجيه الطلبات إلى API الفعلي الخاص بنا. بعد ذلك، نوفر هذا API المعدل للمطورين المشاركين في الهاكاثون.

الخلاصة التقنية

في هذا المقال، استعرضنا مفهوم البرمجيات الوسيطة (Middleware) بشكل معمق، بدءًا من تعريفها الأساسي وصولاً إلى تحليل أبرز حالات استخدامها في تطوير الويب. لقد رأينا كيف يمكن لـ Middleware أن تلعب دورًا محوريًا في تبسيط الاتصال بين الخدمات المختلفة، وتحسين أداء البحث عبر تجميع أو تكرار البيانات، بالإضافة إلى تعزيز أمان واجهات برمجة التطبيقات (APIs) وإدارة الوصول إليها بفعالية. إن مرونة Middleware وقدرتها على العمل كطبقة تجريد (abstraction layer) تجعلها أداة لا غنى عنها في بناء أنظمة موزعة قوية وقابلة للتطوير، وتساهم بشكل كبير في فصل الاهتمامات (separation of concerns) داخل بنية التطبيق.