نادراً ما تتحدث المنتجات الرقمية الحديثة إلى واجهة خلفية واحدة عبر واجهة برمجية موحدة واحدة. فقد تعرض شركة بيع بالتجزئة نفس الخدمات الأساسية على تطبيق ويب متجاوب، وتطبيق iOS أصلي، وتطبيق Android، وطبقة تكامل مع شركاء، ولوحة تحكم داخلية للإدارة — ولكل من هذه المستهلكين تفاوتات مختلفة في زمن الاستجابة، وتفضيلات مختلفة لحجم البيانات، وآليات مصادقة مختلفة، ودورات إصدار مختلفة. ومحاولة خدمة كل هؤلاء من واجهة برمجية عامة واحدة تنتج عادة واجهة بأدنى قاسم مشترك لا ترضي أحداً تماماً. هذا التوتر هو ما دفع أنماط بوابة الواجهة البرمجية، وعلى وجه التحديد بنية الواجهة الخلفية للواجهة الأمامية (BFF)، إلى صميم الهندسة البرمجية الحديثة.
تقف بوابة الواجهة البرمجية بين العملاء ومجموعة الخدمات الخلفية التي تشكل النظام، وتعمل كنقطة دخول واحدة يتم التحكم فيها. فبدلاً من أن يكتشف كل عميل ويستدعي عشرات الخدمات المصغّرة مباشرة، تُركّز البوابة التوجيه والمصادقة وتحديد المعدل وتحويل الطلبات والمراقبة في مكان واحد. أما طبقة BFF فتذهب بهذه الفكرة خطوة أبعد: فبدلاً من أن تحاول بوابة واحدة أن تكون كل شيء لكل شخص، تحصل كل تجربة عميل رئيسية على واجهة خلفية مخصصة لها، مصممة خصيصاً لتجميع وتشكيل وتحسين البيانات لتلك الواجهة الأمامية بالتحديد.
تبدأ الحجة الأساسية لصالح البوابات وBFF بملاحظة بسيطة: العملاء ليسوا متبادلين. فتطبيق محمول على شبكة محدودة يريد حمولات صغيرة ومبسّطة تتجنب رحلات الشبكة المتعددة. أما لوحة تحكم غنية على الويب فقد تريد استدعاءً واحداً يجمّع بيانات من خمس خدمات مختلفة لأن المتصفح يمكنه تحمل طلب خلفي أثقل قليلاً في مقابل عدد أقل من رحلات الشبكة. وعلى الجانب الآخر، تحتاج واجهة برمجية موجهة للشركاء إلى ضمانات صارمة لإصدار النسخ وعقود يمكن التنبؤ بها لأن فرق الشركاء الخارجية لا يمكن أن يُطلب منها إعادة النشر كل مرة تتغير فيها بنية خدمة داخلية.
عندما تحاول واجهة برمجية واحدة تلبية كل هذه الحاجات في آن واحد، تنتهي الفرق بإضافة حقول اختيارية، ومعاملات استعلام متضخمة، ومنطق شرطي لا يفهمه أحد تماماً بعد ستة أشهر. تصبح الواجهة البرمجية حلاً وسطاً، والحلول الوسطى تتراكم كدين تقني. تقسيم المشكلة حسب العميل — من خلال البوابات للمخاوف الشاملة وBFF لتشكيل البيانات الخاص بكل عميل — يسمح لكل فريق بالتحسين للقيود التي تهم مستهلكيه فعلاً.
تمتلك البوابة المصممة جيداً مجموعة متسقة من المسؤوليات الشاملة حتى لا تحتاج كل خدمة على حدة إلى إعادة تنفيذها. تحدث المصادقة والتحقق من الرموز عند الحافة، حتى تتمكن الخدمات الخلفية من الوثوق بأن الطلب الذي وصلها قد تم فحصه مسبقاً. يحمي تحديد المعدل والتقييد الأنظمة الخلفية من أن يطغى عليها عميل مزعج واحد أو محاولة استخلاص بيانات آلية. يسمح تحويل الطلبات والاستجابات للبوابة بتكييف عقود الخدمات القديمة مع توقعات العملاء الحديثة دون فرض إعادة كتابة الخدمة الأساسية. يعطي التسجيل المركزي، ورؤوس التتبع، وإصدار المقاييس، فرق التشغيل مكاناً واحداً لمراقبة أنماط حركة البيانات عبر النظام بأكمله. وأخيراً، تتعامل كثير من البوابات مع إنهاء TLS، وقوائم السماح لعناوين IP، وقواعد أساسية لجدار حماية تطبيقات الويب، مما يوحّد ضوابط أمنية كانت ستتكرر عبر كل خدمة.
ولأن البوابة ترى كل طلب، فإنها تصبح أيضاً مكاناً طبيعياً لتنفيذ التوجيه التجريبي (canary)، وتقسيمات اختبار A/B، وتحويل حركة البيانات بأسلوب "الأزرق والأخضر"، مما يربطها ارتباطاً وثيقاً باستراتيجية الإصدار والنشر وليس الأمن فقط.
بينما تدور البوابة إلى حد كبير حول التوجيه والسياسة الشاملة، تدور BFF حول تكييف شكل البيانات الفعلي لتجربة معينة. وتُدار كل BFF عادة من نفس الفريق الذي يملك الواجهة الأمامية التي تخدمها، وهذا خيار تنظيمي متعمد: فالأشخاص الذين يفهمون ما تحتاجه شاشة تطبيق محمول هم من يقررون كيفية تجميع وتنسيق البيانات لها، بدلاً من التفاوض على هذه القرارات مع فريق خلفي منفصل.
تقوم BFF عادة بعدة وظائف في الوقت نفسه. فهي تجمّع استدعاءات لعدة خدمات مصغّرة خلفية في استجابة واحدة، فتُجنّب العميل إجراء عدة رحلات شبكة. وتُعيد تشكيل البيانات إلى البنية التي تتوقعها واجهة المستخدم بالضبط، فتُلغي منطق التحليل من جانب العميل الذي كان سيتكرر عبر المنصات. ويمكنها التخزين المؤقت بقوة لأنماط الوصول الخاصة بعميلها، لأنها تفهم نسب القراءة/الكتابة لذلك العميل أفضل من واجهة برمجية عامة. كما تصبح حدوداً طبيعية لتدفقات المصادقة الخاصة بكل عميل — فقد يستخدم تطبيق محمول تدفق رمز تحديث عبر BFF الخاص به، بينما يستخدم تكامل شريك تدفق بيانات اعتماد عميل OAuth عبر BFF مختلفة تماماً.
نمط BFF ليس مجانياً. فكل BFF إضافية هي خدمة قابلة للنشر أخرى، ولها خط بناء خاص بها، ودورة استدعاء طوارئ خاصة بها، ونقطة فشل محتملة خاصة بها. الفرق التي تتبنى BFF دون نموذج ملكية واضح تنتهي غالباً بعدة BFF تكرر منطق الأعمال بصمت، لأنه لم يتم توحيد القواعد التي كان يجب أن تعيش في خدمة مشتركة أو مكتبة مشتركة. هذا التكرار هو تحديداً نوع المشكلة التي صُمم النمط لتجنبها، لكنها انتقلت طبقة أعلى في المكدس.
هناك أيضاً خطر أن تتحول BFF إلى مكب لمنطق كان يجب أن يعيش أقرب إلى المجال. فإذا تسربت قواعد التحقق، أو حسابات التسعير، أو قرارات التفويض إلى BFF لأن ذلك مريح، ينتهي النظام بمنطق أعمال مبعثر عبر عدة BFF يجب الحفاظ على اتساقه يدوياً. من الممارسات المفيدة معاملة BFF بصرامة كطبقة تجميع وتشكيل فقط، ودفع قواعد الأعمال الحقيقية إلى خدمات المجال حيث يمكن مشاركتها واختبارها مرة واحدة.
المنظمات الصغيرة، أو المنتجات التي لديها نوع أو نوعان فقط من العملاء، غالباً لا تحتاج إلى BFF على الإطلاق — واجهة برمجية واحدة مصممة جيداً، وربما بمرونة اختيار الحقول التي تقدمها GraphQL، قد تغطي الحاجة دون العبء التشغيلي لإدارة واجهات خلفية متعددة.
في الممارسة، تشغّل كثير من الأنظمة الناضجة كلا الطبقتين في آن واحد، بمسؤوليات مختلفة في كل طبقة. تقف بوابة الواجهة البرمجية عند حافة الشبكة تماماً، فتتعامل مع TLS، والمصادقة، وتحديد المعدل العام، والتوجيه إلى BFF الصحيحة بناءً على تعريف العميل لنفسه (عبر رأس، أو نطاق فرعي، أو مسار). ثم تقف كل BFF خلف البوابة، تجمّع استدعاءات إلى خدمات المجال الفعلية وتشكّل الاستجابة لواجهتها الأمامية المحددة. وتقف خدمات المجال خلف BFF، تعرض واجهات برمجية داخلية لا يتعين عليها القلق من مخاوف خاصة بالعميل على الإطلاق، لأن هذه المسؤولية استوعبتها طبقة BFF مسبقاً.
هذا الترتيب الطبقي يحافظ على مسؤولية كل مكوّن ضيقة. فالبوابة لا تعرف شيئاً عن شاشات واجهة المستخدم. وBFF لا تنفّذ المصادقة من الصفر ولا تتعامل مع شهادات TLS الخام. وخدمات المجال لا تعرف إن كانت تُستدعى من تطبيق محمول أو لوحة تحكم على الويب أو خدمة داخلية أخرى. يمكن لكل طبقة أن تتطور بشكل مستقل ما دامت العقود بينها ثابتة.
لنأخذ شركة لوجستية كان تطبيق تتبع الشحنات المحمول التابع لها ولوحة العمليات الداخلية يستدعيان نفس واجهة "الشحنات" البرمجية العامة. مع مرور الوقت، نمت الواجهة البرمجية لتضم اثني عشر معامل استعلام اختياري لتلبية كلا المستهلكين، وكان كل تغيير يهدد بكسر عميل واحد أثناء تصحيح الآخر. لاحظ فريق الهاتف المحمول أن تطبيقه يقوم بأربعة استدعاءات متتالية فقط لعرض شاشة تتبع واحدة — واحد للشحنة، وواحد لشركة الشحن، وواحد للموقع الحالي، وواحد لصور التسليم — لأن الواجهة البرمجية المشتركة لم تكن تجمّعها.
قدّم الفريق BFF خاصة بالهاتف المحمول يملكها فريق الهاتف المحمول. وعرضت نقطة نهاية واحدة، `/tracking-screen/{shipmentId}`، تستدعي داخلياً خدمات الشحنة وشركة الشحن والموقع والصور بالتوازي، وتدمج النتائج في شكل JSON الذي تتوقعه مكوّنات واجهة المستخدم في التطبيق بالضبط. كما خزّنت BFF مؤقتاً بيانات شركة الشحن، التي تتغير نادراً، لمدة خمس عشرة دقيقة، مما قلّص جزءاً معتبراً من الاستدعاءات الخلفية. في الوقت نفسه، وُضعت بوابة واجهة برمجية أمام BFF الجديدة للهاتف المحمول وواجهة لوحة العمليات الحالية معاً، تتعامل مع المصادقة بشكل موحد وتمنح فريق العمليات رؤية على حركة البيانات من كلا نوعي العملاء عبر مجموعة واحدة من لوحات المراقبة.
كانت النتيجة شاشة هاتف محمول تُحمّل في رحلة شبكة واحدة بدلاً من أربع، وواجهة برمجية للعمليات يمكن أن تتطور دون خوف من كسر تطبيق الهاتف المحمول، وفريق أمن لم يكن عليه تدقيق منطق المصادقة إلا في مكان واحد — البوابة — بدلاً من منطق مكرر ومبعثر عبر كود كلا العميلين.
إن إدخال بوابة وBFF واحدة أو أكثر يغيّر السطح التشغيلي للنظام، وينبغي على الفرق التخطيط لذلك بشكل متعمد. كل نقلة إضافية تزيد من زمن الاستجابة، فتحتاج البوابات وBFF إلى ميزانيات أداء ومراقبة خاصة بها، لا فقط الخدمات الخلفية التي تستدعيها. الأمن أيضاً يحتاج إلى توزيع دقيق للمسؤوليات؛ فإنهاء TLS والتحقق من الرموز عند الحافة نمط قوي، لكنه فعّال فقط إذا كانت الشبكة بين البوابة والخدمات الداخلية موثوقة ومراقبة بذاتها.
تعالج بوابات الواجهة البرمجية وطبقات BFF مشكلة تنمو طبيعياً مع توسع المنتجات الرقمية عبر القنوات: فواجهة برمجية واحدة لا يمكنها في النهاية أن تخدم كل عميل جيداً دون أن تصبح حلاً وسطاً غير قابل للإدارة. توحّد البوابات المخاوف الشاملة — الأمن، والتوجيه، والمراقبة — التي يحتاج كل عميل إلى معاملتها بشكل متسق. وتمنح BFF كل تجربة عميل شكل البيانات المخصص والمجمّع والمخزن مؤقتاً الذي تحتاجه فعلاً، مملوكاً من الفريق الأقرب لتلك التجربة. عند استخدامهما معاً، وبانضباط بشأن مكان بقاء منطق الأعمال الحقيقي، تسمح هذه الأنماط للمؤسسات بتوسيع عدد تجارب العملاء التي تدعمها دون مضاعفة تعقيد خدمات المجال الأساسية لديها.
