ما هي الوسيطة؟ التعريف والمثال على حالات الاستخدام

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

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

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

تعريف الوسيطة

الوسيط هو برنامج يعمل كوسيط بين تطبيقين أو خدمتين لتسهيل اتصالهم.

يمكنك التفكير في الأمر على أنه وكيل يمكنه العمل كمجمع بيانات أو مترجم أو مجرد وكيل يقوم بإعادة توجيه الطلبات.

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

1) مترجم

هناك العديد من تنسيقات تبادل البيانات ، مثل JSON و XML و Protobuf. على الرغم من أننا نستخدم JSON في الغالب في الوقت الحاضر ، لكل منهم حالات الاستخدام الخاصة به.

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

يمكنك أيضًا التحقق من مقالتي حول Protobuffers إذا كنت مهتمًا بمعرفة المزيد عنها.

لنفترض الآن أننا بحاجة إلى هاتين الخدمتين ، اللتين تتحدثان بروتوكولات مختلفة ، للتواصل مع بعضهما البعض.

يمكننا إنشاء برمجية وسيطة تستخدم مكتبة تحويل البيانات وترجمة الطلبات إلى تنسيق يمكن للخدمة المستقبلة فهمه.

2) تراكم البيانات المكررة

تعد بنية الخدمات المصغرة نمطًا معماريًا شائعًا يتم تطبيقه بشكل شائع في التطبيقات الحديثة.

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

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

لنفترض الآن أننا نريد تنفيذ بحثنا بطريقة يبحث فيها عن المستخدمين والمنتجات.

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

هذه المشكلة لها حلول متعددة ، وسننظر في اثنين منها.

تراكم البيانات

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

ثم يمكننا تجميع النتائج من كلا الخادمين وإعادتها إلى العميل. لاحظ أن عدد الطلبات يزداد خطيًا مع زيادة عدد الخوادم (ونحتاج أيضًا إلى دمج هذه البيانات).

تكرار البيانات

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

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

لدينا خياران: أولاً ، يمكننا استدعاء طرق حفظ خادم البحث من طرق حفظ المستخدم وخوادم المنتج لتكرار البيانات. أو يمكننا إنشاء برمجية وسيطة للحفظ ، والتي ستقوم بما يلي:

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

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

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

إليك نفس الحل مع البرامج الوسيطة:

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

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

3) API الأمن

بالنسبة لأي كود من جانب العميل للواجهة الأمامية ، يمكننا عرض الطلبات الصادرة ، إما في وحدة تحكم المتصفح أو عبر وكيل.

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

يمكننا استخدام البرامج الوسيطة كوكيل لإخفاء عنوان URL لخادم المصادقة. تتواصل الواجهة الأمامية مع البرامج الوسيطة وستقوم بإعادة توجيه الطلب إلى خادم المصادقة ، وإعادة الاستجابة مرة أخرى.

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

لم يكن هذا ممكنًا من قبل ، لأن واجهتنا الأمامية كانت تتصل بخادم المصادقة. نظرًا لأن الواجهة الأمامية تعني كمبيوتر العميل ، لم نتمكن من تطبيق مرشح IP.

4) الكشف عن واجهات برمجة التطبيقات العامة

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

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

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

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

استنتاج

في هذا المنشور ، بدأنا بتحديد ماهية البرامج الوسيطة وحاولنا تصنيف حالات استخدام البرامج الوسيطة في تطوير الويب.

ضع في اعتبارك أن هذه ليست قائمة كاملة بحالات الاستخدام ، ولكن ما زلت آمل أن تكون مفيدة لك.

شكرا لقرائتك. إذا أعجبك المقال ، أدعوك للتحقق من مدونتي. يمكنك أيضًا الاشتراك في القائمة البريدية الخاصة بي ليتم إخطاري عند نشر منشور جديد :)