نظرة عامة

AirAds منصّة فائقة المحلّية لاكتشاف التجّار والإعلان عنهم، تساعد العملاء على العثور على النشاط التجاري القريب المناسب في اللحظة التي يحتاجون إليه فيها — عبر البحث بالخريطة والقائمة والواقع المعزّز والصوت. وهي تخدم طرفَي سوق محلّي: المستهلكون الذين يتصفّحون العروض والمقاطع القصيرة والملفات التعريفية للتجّار من حولهم، وأصحاب الأنشطة التجارية الذين يطالبون بقوائمهم ويديرونها ويروّجون لها. ويُسلَّم المنتج على شكل سبعة تطبيقات فرعية متناسقة — نظام خلفي Django REST، وثلاث بوّابات React (الإدارة والتاجر والعميل)، وعميل جوّال Flutter مخطّط له، ومستودع مشترك للبنية التحتية، ومستودع للتوثيق — وجميعها مطوّرة كعمل مملوك لـ AmalAxis.

التحدي

يعاني الاكتشاف المحلّي من مشكلة البداية الباردة: الدليل بلا قيمة ما لم يكن مكتظًّا بأنشطة تجارية دقيقة، ومع ذلك لن يُدخل أي مالك بيانات قائمته يدويًا في منصّة فارغة. تحلّ AirAds ذلك بنموذج «المطالبة للتملّك» — إذ يُزوَّد الدليل مسبقًا ببيانات أوّلية من Google Places وGeoNames، ثم تُزال تكراراته، ثم يُسلَّم إلى المُلّاك الحقيقيين ليطالبوا بمُدخلاتهم ويُثروها. وفوق ذلك تأتي مشكلات أصعب: ترتيب النتائج وفق الصلة المحلّية الحقيقية لا وفق القرب الخام، وفرض تحكّم صارم بالوصول جغرافيًا وبحسب الأدوار بحيث لا يمسّ مدير المدينة إلا بيانات مدينته، وحماية معلومات التعريف الشخصية من طرف إلى طرف، ونقل فيديوهات التجّار (المقاطع القصيرة) إلى تخزين الكائنات دون حجب مسار الطلب. وكان على النظام أن يوفّق بين هذه الاعتبارات عبر نظام خلفي واحد يغذّي ثلاث واجهات أمامية مختلفة، وتطبيق جوّال في نهاية المطاف.

تصميم النظام

النظام الخلفي تطبيق أحادي البنية بـ Django 5.1 + Django REST Framework، منظّم في أكثر من ستة عشر تطبيقًا مركّزًا — accounts وvendors وdiscovery وgeo وreels وsubscriptions وpayments وaudit وgovernance وimports وnotifications وtags وanalytics والتطبيقان الخاصان بالبوّابات vendor_portal/user_portal — تكشف نحو 98 نقطة نهاية. تعتمد المصادقة على djangorestframework-simplejwt، مع فئة CustomerUserJWTAuthentication منفصلة بحيث تبقى رموز المستهلك والتاجر معزولة عن رموز الإدارة، وتحمل رموز JWT مطالبات جغرافية تقود تحديد النطاق. ويدعم GeoDjango فوق PostgreSQL + PostGIS الاستعلامات المكانية، بينما يعمل Redis ذاكرةَ تخزين مؤقت ووسيطًا لـ Celery في الأعمال غير المتزامنة (الإشعارات والاستيراد ومعالجة الفيديو) المجدولة عبر django-celery-beat. أما معلومات التعريف الشخصية المصنّفة كمقيّدة فتُشفَّر أثناء التخزين بـ AES-256-GCM عبر مكتبة cryptography، وتُقنَّع عند العرض وتُستبعد من السجلات؛ ويولّد drf-spectacular مخطّط OpenAPI، ويخدم Daphne طبقة ASGI.

التكاملات مقصودة وحاملة للثقل. فـ Stripe (Checkout وبوّابة العملاء وwebhooks) يشغّل نموذج الاشتراكات المتدرّج — Silver وGold وDiamond وPlatinum — الذي تتغذّى مُضاعِفاته مباشرةً في ترتيب النتائج. ويتولّى Twilio مصادقة الرسائل النصية ورموز التحقّق لمرّة واحدة. وتُرفع مقاطع التجّار القصيرة وصورهم إلى DigitalOcean Spaces (المتوافق مع S3) عبر django-storages وboto3، باستخدام نمط الرفع المباشر إلى التخزين الذي لا يسلّم الـ API سوى s3_key والمدّة، مع بديل محلّي MEDIA_ROOT أثناء التطوير. ويوفّر Google Places كلًّا من مسار التزويد بالبيانات الأوّلية والإثراء على مستوى كل تاجر، محكومًا باستراتيجية موثّقة لإزالة التكرارات.

تتشارك الواجهات الأمامية الثلاث منظومة تقنية واحدة — React 18، وTypeScript 5، وVite، وZustand لحالة العميل، وTanStack Query v5 لحالة الخادم، وaxios، وreact-hook-form مع تحقّق Zod، وRecharts، وأيقونات Lucide، ونظام تصميم مخصّص باسم «AirAd DLS» — لكنها تتباين بحسب الدور. فلوحة الإدارة تضيف خرائط Leaflet، واستيراد CSV عبر PapaParse، وعرض الفروقات للتغييرات المدقَّقة؛ وبوّابة التاجر تتكامل مع Stripe Elements وLottie ومنتقيات التواريخ للعروض الترويجية؛ وبوّابة العميل تتّكئ على Google Maps وFramer Motion وSwiper وتدفّق مقاطع قصيرة على غرار TikTok. أما تطبيق الجوّال المخطّط له بـ Flutter (مع Riverpod وGo Router وDio والواقع المعزّز على الجهاز وspeech_to_text وإشعارات FCM) فيعيد استخدام عقد الـ API نفسه. وكل ذلك مُعبّأ في حاويات Docker Compose خلف وكيل Nginx عكسي، ويُشحن إلى DigitalOcean App Platform عبر بيئات التطوير والتجهيز والإنتاج، مع GitLab CI/CD الذي يشغّل الفحص اللغوي وSemgrep وفحص الأسرار بـ TruffleHog والاختبارات، إضافة إلى نسخ احتياطي مُبرمَج وخطة تعافٍ من الكوارث.