HamzaandClaude Opus 4.8
95fea546f5
- docs/00-15: دراسة، بنية، محرك تعرفة، تسعير، نموذج استئجار، تكاملات، بيانات، realtime، خطة، devops، لاندنج، مخاطر، اصطلاحات سيرفر، تدفق نشر - backend/: NestJS 11 على Docker (health + tenants + عزل tenant_id + بادئة tripz_ + Redis DB 3) - apps/rider, apps/driver, dashboards/admin-web, dashboards/superadmin-web (هياكل) - sync-to-server.sh + .gitignore Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.7 KiB
3.7 KiB
14 — اصطلاحات السيرفر والعزل (قرارات تشغيلية محسومة)
هذه قرارات نهائية اتخذها المالك — تُطبَّق حرفياً في الكود والـ config من اليوم الأول.
1. بيئة العمل مقابل النشر
- كتابة الكود والتطوير: على الماك (محلياً).
- النشر (Deployment): على السيرفر.
- الباك إند يعمل داخل Docker في الحالتين (نفس الصور محلياً وعلى السيرفر).
2. السيرفر مشترك — العزل إلزامي
السيرفر الحالي تجريبي ومشترك: عليه برامج وملفات كثيرة (WordPress وغيره) وقد يعمل عليه نفس التطبيق أكثر من مرة. لذلك كل موارد Tripz تُعزل بوضوح:
أ. بادئة (Prefix) لكل شيء
- جداول قاعدة البيانات: بادئة
tripz_لكل جدول (مثال:tripz_trips,tripz_users). - مفاتيح Redis: بادئة
tripz:قبل كل مفتاح (فوق بادئةtenant:الداخلية). - قوائم/طوابير BullMQ: بادئة
tripz_. - أسماء حاويات/شبكات Docker: بادئة
tripz-.
ب. قاعدة بيانات منفصلة عن الأصلية
- PostgreSQL: قاعدة بيانات مستقلة خاصة بـ Tripz (اسمها
tripz)، لا نشارك قاعدة أي برنامج آخر. - Redis: نختار رقم قاعدة بيانات (DB index) غير الافتراضي 0 لتفادي التصادم — نعتمد DB رقم 3 (من أصل 0–15). قابل للتعديل عبر
REDIS_DBفي البيئة، لكن الافتراضي المعتمد ≠ 0.
ج. متغيرات البيئة الحاكمة
# PostgreSQL
DB_NAME=tripz
DB_TABLE_PREFIX=tripz_
# Redis — رقم غير افتراضي للعزل عن باقي البرامج على السيرفر
REDIS_DB=3
REDIS_KEY_PREFIX=tripz:
# BullMQ
QUEUE_PREFIX=tripz_
- في TypeORM: يُضبط
entityPrefix: process.env.DB_TABLE_PREFIX. - في Redis client / BullMQ: تُمرَّر
dbوkeyPrefixمن البيئة.
3. الخرائط — انطلق فقط (المأخوذ الوحيد من سيرو)
- نأخذ من سيرو شيئاً واحداً فقط: تكامل خرائط انطلق — الـ API والباكج والتنظيم الكامل الموجود في خدمة الخرائط (MapService) بتطبيق سيرو.
- الخطوة العملية: نفحص باكج/تنظيم انطلق في سيرو، ننقله/نكيّفه إلى تطبيق فلاتر الجديد (داخل
mobile/packages/tripz_core/maps) وإلى وكيل الخرائط في الباك إند. - كل ما عدا الخرائط من سيرو: لا يُنقل كوداً — يُعاد البناء من جديد بـ Cubit + Bloc + NestJS.
4. مصير سيرو — مؤجَّل (نعمل ونقرر لاحقاً)
- لا نفصل سيرو الآن ولا نربطه الآن. نبني منصة جديدة من الصفر (كيوبت + فلاتر + نِست) ونرى النتيجة والتنظيم.
- إذا خرج البناء الجديد نظيفاً ومرتباً → قد نستغني عن سيرو ونعتمد الجديد كأول تطبيق حقيقي/مبدئي للاستئجار.
- إذا لا → نعيد النظر. القرار النهائي بعد رؤية النتيجة، لا الآن.
- الثابت الوحيد الآن: ننسى سيرو عملياً ونأخذ منه الخرائط (انطلق) فقط.
← يُقرأ مع: 06-tenant-model · 11-devops-cicd · 07-integrations