نظرة عامة

Global Media Platform نظام لنشر الوسائط وتوزيعها، مبنيّ حول واجهة أمامية معيارية على Next.js/TypeScript ونظام خلفي على Django + DRF. يخدم الفرق التحريرية وفرق الوسائط التي تحتاج إلى رفع أصول الوسائط ومعالجتها وتنظيمها ونشرها، مع مساعدة الذكاء الاصطناعي منسوجة داخل سير عمل المحتوى لا مضافة إليه لاحقًا. يحمل النظام الخلفي سطح التخزين والمعالجة وتكامل الذكاء الاصطناعي؛ أما الواجهة الأمامية فهي طبقة عرض وتحرير قائمة على المكوّنات، تُنشر بشكل مستقل.

التحدي

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

تصميم النظام

النظام الخلفي مشروع Django 4.2 مبنيّ على فصل مقصود بين core/ وapps/، بينما يحتفظ config/ بالإعدادات وجذور المسارات ونقاط الدخول لـ WSGI/ASGI. يحمل core/ الأساس المشترك — النماذج القاعدية، ومزائج المُسلسِلات والعروض المشتركة، ومحوّلات التخزين، وعملاء التكامل — في حين تعيش كل ميزة كتطبيق Django مستقل بذاته تحت apps/. وهذا يُبقي اتجاه الاعتمادية أحاديًا: تطبيقات الميزات تستورد من core، ولا تستورد بعضها من بعض أبدًا. سطح HTTP هو Django REST Framework، حيث يوفّر djangorestframework-simplejwt مصادقة عديمة الحالة برمزَي الوصول والتحديث، ويمنح django-filter نقاط وصول القوائم تصفية تعريفية وبحثًا عبر معاملات الاستعلام، ويسمح django-cors-headers للواجهة الأمامية المنشورة بشكل منفصل باستدعاء الواجهة البرمجية عبر أصل مختلف. تُقرأ التهيئة من البيئة عبر python-dotenv، فتعمل الصورة ذاتها مقابل SQLite محليًا (db.sqlite3 مُضمَّن في المستودع للتطوير) ومقابل قاعدة بيانات مُدارة في بيئة النشر.

التعامل مع الوسائط هو مركز ثقل النظام الخلفي. فقد جرى ضبط django-storages على واجهة S3 عبر boto3 بحيث يكتب حقلا FileField/ImageField في Django مباشرة إلى تخزين الكائنات بدل نظام الملفات المحلي، وتُستبان عمليات القراءة إلى روابط S3. ويتولّى Pillow معالجة الصور — التحقّق، وفحص الأبعاد، واشتقاق النسخ التي تستهلكها الواجهة الأمامية — فتُعيد الواجهة البرمجية أصولًا معالَجة بأحجام صحيحة بدل النسخ الأصلية الخام. أما مساعدة الذكاء الاصطناعي فهي وصلة تكامل منفصلة: يقع عميل openai، ومعه httpx طبقةَ نقل أساسية، خلف دوال خدمة في النظام الخلفي بدل استدعائه من العروض مباشرة، وهو ما يُبقي التعامل مع النموذج قابلًا للاستبدال وللاختبار، ويمنع مهلة خارجية من أن تتحوّل إلى فشل طلب غير مُعالَج. ويُشحن النظام كله كحاوية — فهناك Dockerfile و.dockerignore ومجلّد deploy/، يقودها مسار .gitlab-ci.yml.

الواجهة الأمامية تطبيق Next.js 14 على app router، مكتوب بـ TypeScript بتنميط صارم في كل أنحائه. وبدل الشجرة المسطّحة التقليدية components/، يفصل الاهتمامات عبر modules/ (مركّبات مرتبطة بالميزات) وcomponents/ (عناصر عرض أوّلية) وlib/ (عملاء الواجهة البرمجية والتنسيق والمساعدات المشتركة) وtypes/ (عقود TypeScript التي تعكس حمولات DRF) وdata/ (محتوى ثابت ومنظَّم). التنسيق بـ Tailwind CSS مع PostCSS وAutoprefixer، والأيقونات من lucide-react. ولأن app router يُصيّر على الخادم افتراضيًا، تجلب صفحات القوائم والتفاصيل بياناتها من واجهة Django البرمجية على الخادم، فتبقى الحمولات وبيانات الاعتماد بعيدة عن العميل، وتختار المقاطع المفردة التفاعلية على جانب العميل حيث تحتاجها فقط. ويستهدف النشر Vercel عبر vercel.json، مع .env.production الذي يوفّر الرابط الأساسي للواجهة البرمجية — فنصفا النظام يُصدَّران ويُبنيان ويُطلقان بشكل مستقل.