نظرة عامة

Sham منتج منصّة مبنيّ على نظام خلفي بـ Django + Django REST Framework يعرض واجهة JSON برمجية واحدة لأكثر من مستهلك. وإلى جانب هذه الواجهة يعيش sham_mobile، عميل جوال مرافق يتحدّث إلى نقاط الوصول ذاتها التي يستخدمها سطح الويب. والنظام كلّه يعمل داخل حاويات، تتقدّمه Nginx، ويُشحن عبر مسار GitLab CI، مع مجلّد نسخ احتياطي محفوظ داخل شجرة المستودع بحيث تكون الاستعادة اهتمامًا من الدرجة الأولى لا فكرة لاحقة.

التحدي

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

تصميم النظام

النظام الخلفي مشروع Django 5 مع عزل طبقة REST داخل تطبيق api واحد، بما يُبقي النماذج والمُسلسِلات وviewsets وتوجيه المسارات في مكان واحد بدل تشتّتها عبر اثني عشر تطبيقًا نصف ممتلئ. وتعمل المصادقة على djangorestframework-simplejwt، وهو ما يناسب شكل المشكلة: فعميل الجوال لا يملك حاوية كوكيز ولا انتماء جلسة يتّكئ عليهما، ولذلك يتيح حمل رمزَي الوصول والتحديث في ترويسة Authorization للعميلين أن يصادقا عبر مسار الكود نفسه تمامًا. ويقف django-cors-headers أمام ذلك ليتيح للسطح العامل في المتصفّح إصدار طلبات عابرة للأصل نحو مضيف الواجهة البرمجية دون التساهل في أي شيء تجاه المستدعين الآخرين.

يمرّ التعامل مع الوسائط عبر Pillow، وهو ما يلجأ إليه حقل ImageField في Django حين يحتاج إلى التحقّق من الملفات المرفوعة ومعالجتها — فحص الأبعاد، والتأكّد من الصيغة، وأي تغيير للحجم يجري في الطريق إلى التخزين. أما الأصول الثابتة فيقدّمها whitenoise من داخل عملية التطبيق نفسها، ما يعني أن الحاوية مكتفية ذاتيًا فيما يخصّ هذه الأصول، ويترك Nginx حرًّا ليفعل ما يُتقنه فعلًا: إنهاء الاتصالات، وتقديم الوسائط التي يرفعها المستخدمون من القرص، وتمرير كل ما عدا ذلك عبر وكيل عكسي إلى gunicorn. وتُخرَج التهيئة إلى الخارج عبر python-dotenv مقابل ملف .env.example محفوظ في المستودع، فتعمل الصورة ذاتها في كل بيئة دون أن يكون مخبوزًا داخلها شيء سوى الكود. وطبقة الحفظ الافتراضية هي SQLite (db.sqlite3)، ما يُبقي التطوير المحلي عند أمر manage.py migrate واحد دون أي اعتماديات على خدمات.

ويُعالَج اهتمامان تشغيليان بوصفهما كودًا من الدرجة الأولى لا معرفة شفهية متوارثة. فالتقارير مبنيّة على openpyxl لمخرجات جداول البيانات وعلى reportlab لتوليد ملفات PDF، وكلاهما يُدار من جانب الخادم بحيث يستطيع عميل الجوال طلب مستند دون أن يشحن معه محرّك تصيير. والتهيئة الأولية مكتوبة في سكربتات: يُنشئ create_admin.py المستخدم الخارق الأوّل دون تفاعل، بينما يزرع setup_categories.py تصنيف الفئات الذي يعتمد عليه المنتج — سكربتان يحوّلان حاوية جديدة إلى نسخة قابلة للاستخدام دون أن ينقر أحد داخل لوحة الإدارة. والتسليم معرَّف عبر Dockerfile، وdocker-compose.yml الذي يربط التطبيق بإعدادات nginx، و.gitlab-ci.yml الذي يقود المسار، فيما يحمل backups/ أدوات الاستعادة.