ما هو الباك إند في التطبيق

ما هو الباك إند ولماذا نصف التطبيق هناك؟

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

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

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

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

ماذا يوجد داخل الباك إند؟

الباك إند ليس برنامجاً واحداً بل عدة قطع، كل واحدة تؤدي عملاً واحداً، وتجلس عادةً معاً على خادم واحد.

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

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

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

والقطعة الرابعة، التي يُفكَّر فيها متأخراً دائماً، هي تخزين الملفات. فصور الملف الشخصي والمرفقات لا تجلس عادةً داخل قاعدة البيانات؛ لها مكانها الخاص ويُحفظ عنوانها فقط في القاعدة. وكون هذا العنوان عاماً أو موقّعاً ومؤقتاً قرار أمني بذاته.

وكل هذا يعمل على الشيء الموصوف من تحت في كيف يعمل الإنترنت: آلة لا تُطفأ وتنتظر على عنوان.

حين يقال إن الخادم متوقف، ماذا حدث بالضبط؟

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

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

والثانية: الخادم رد وكان رده خطأ. ورمز الحالة مهم هنا وله عائلتان. فالخمسمئة تعني أن المشكلة من جهة الخادم، والأربعمئة تعني أن الطلب نفسه كان معطوباً. والتطبيق الذي يعرض الاثنين على أنهما «الخادم متوقف» يرسل المستخدم في طريق لا نهاية له؛ فالـ401 تعني سجّل الدخول ثانيةً والـ500 تعني اجلس وانتظر.

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

والثالثة هي حيث تضيع الفرق أكثر وقتها، لأن رقم الصبر مكتوب عادةً في مكان لا يبحث فيه أحد. فوثائق PHP نفسها، وهي تصف إعداد request_terminate_timeout، تقول إنه «مهلة خدمة طلب واحد يُقتل بعدها عملية العامل»، وتضيف صراحةً أن هذا الخيار يُستعمل حين لا يوقف max_execution_time تنفيذ السكربت. أي أن رقمين يعيشان في ملفين منفصلين، والأصغر هو صاحب الكلمة الأخيرة.

والنتيجة العملية لمن يكتب تطبيقاً: أعطِ كل طلب ترسله مهلة معلنة، وصنّف ردود الخطأ برمز الحالة لا بنصها، واكتب سلوكاً مختلفاً لكل عائلة. يأخذ هذا عشر دقائق في الساعة الأولى من المشروع، وإن أُهمل عاد بعد أشهر على شكل بلاغات «التطبيق لا يعمل» لا يمكن إعادة إنتاج أي منها.

نشتري باك إند جاهزاً أم نكتب واحداً بأنفسنا؟

وهناك طريق ثالث ينتهي إليه معظم الفرق الصغيرة: الباك إند كخدمة، أي خدمة تسلّمك قاعدة البيانات والدخول وتخزين الملفات جاهزة فلا ترفع خادماً أصلاً. وفايربيس من غوغل وسوبابيس مثالان معروفان.

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

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

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

وسؤال القفل يُسمع منهم أفضل مما يُسمع منا. فسوبابيس يكتب في صفحة معماريته أنه لا يجرّد قاعدة بيانات بوستجرس وأنك تصل إليها بصلاحيات كاملة، ويكتب في مبادئه أنه لتفادي القفل يبقي الانتقال إلى الداخل والخارج سهلاً، ولهذا يستعمل معايير قائمة مثل pg_dump وملفات CSV. وهذا ادعاء صانع عن منتجه هو لا قياس منا؛ فنحن لم ننفّذ هجرة حقيقية من أي منهما ولا نستطيع أن نقول كم تستغرق عملياً.

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

اسأل نفسك هذه قبل أن تختار

قرار الباك إند لا يكون تقنياً خالصاً تقريباً أبداً. أجب عن الأسئلة الأربعة أدناه بجدية والجواب يُظهر نفسه.

الأول: إن أرسل أحدهم غداً طلباً لا يرسله تطبيقك أبداً، فماذا يحدث؟ إن كان جوابك «تطبيقنا لا يفعل هذا» فأنت لم تفكر في الباك إند بعد. فمن يعمل ضد تطبيقك ليس مضطراً لاستعمال تطبيقك.

والثاني: أي الأرقام يجب ألا يحددها المستخدم؟ السعر والمخزون والنقاط والدور. وكل واحد من هذه يصل من جهة التطبيق هو عملياً إدخال مستخدم.

والثالث: إن تركت هذه الخدمة غداً فماذا يأتي معك؟ ليس اتهاماً للبائع بل تمريناً. والجواب يبيّن عادةً كم من منتجك ملكك فعلاً.

والرابع: من يعيد الخادم في الثالثة فجراً؟ إن كان الجواب لا أحد، فالخدمة المدارة أغلى وتُحسب الخيار الرخيص.

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