تطوير Laravel في المغرب
Laravel هو خلفيتي الأساسية لمنصات SaaS متعددة المستأجرين والفوترة والصلاحيات والطوابير — من طنجة لفرق تحتاج واجهات يمكن الاعتماد عليها.
العمل ليس "CRUD في عطلة أسبوع". إنه نمذجة المجال وعزل المستأجرين وضمان موثوقية المهام وكتابة واجهات تستطيع فرق أخرى الاعتماد عليها.
يعني تعدد المستأجرين عادة عزلاً على مستوى الاستعلام، لا مجرد عمود tenant_id يمكن لجملة WHERE منسية تجاوزه. تعمل الطوابير على Redis حتى لا تحجب مهمة بطيئة — تصدير أو دفعة بريد أو إعادة محاولة webhook — الطلب الذي أطلقها، وتبقى المهام الفاشلة مرئية بدل أن تختفي بصمت.
تُنمذج الفوترة والصلاحيات معاً منذ البداية: تحدد الخطة ما يستطيع الدور فعله، وتُبقي أحداث اشتراك Stripe هذا الربط محدَّثاً حين يرفع مستأجر خطته أو يخفضها أو يلغي اشتراكه. يعمل AnyWare ERP وBROC ServiceOS بهذه الطريقة — Laravel في الأساس وPostgreSQL للبيانات وRedis للمهام التي يجب أن تكون موثوقة.
أتولى قواعد كود Laravel قائمة بقدر ما أبدأ مشاريع جديدة تقريباً. معظم ذلك العمل هو فكّ استعلامات تتجاوز عزل المستأجر، أو مهام بلا استراتيجية إعادة محاولة، أو فحوصات صلاحيات متناثرة في المتحكمات بدل أن تكون مركزية — نوع الدين التقني الذي يبدو جيداً حتى يسجّل عميل ثانٍ.
مشاكل الأعمال
- CRUD لا يعبّر عن العزل أو الفوترة أو الصلاحيات، فتُضاف كل متطلبات جديدة كحالة خاصة بدل أن تلائم نموذجاً صُمم لاستيعابها.
- مهام وكاش تتسرب بين العملاء، لأن مفتاح الكاش أو حمولة المهمة بُنيت دون التفكير في عزل المستأجر منذ البداية.
- واجهات REST لا تستطيع فرق الواجهة الاعتماد عليها، لأن شكل الاستجابة يتغيّر دون ترقية إصدار ولا يعلم أحد خارج فريق الخلفية حتى ينكسر شيء.
- تطبيق Laravel يتحدث فيه كل متحكم مباشرة إلى نماذج Eloquent بلا طبقة خدمة، فتُنسخ قاعدة العمل نفسها إلى ثلاثة متحكمات ويُحدَّث اثنان منها فقط عند تغييرها.
- أعلام ميزات وإعدادات مُثبَّتة لكل بيئة بدل أن تُدار من قاعدة البيانات، فيعني تفعيل شيء لمستأجر واحد نشراً لا مجرد تبديل مفتاح.
- استعلامات N+1 تُشحن لأن Eloquent يسهّل التحميل الكسول لعلاقة داخل حلقة دون ملاحظة، حتى تنتهي مهلة صفحة كانت تعمل جيداً مع عشرة صفوف عند عشرة آلاف.
- ترحيلات لم تُختبر استعادتها قط، فلا يمكن فعلياً التراجع عن نشر سيئ بنظافة ويصبح الإصلاح تصليحاً يدوياً لقاعدة البيانات تحت الضغط.
منهج التطوير
- نمذجة المجال في PHP: مستأجرون ومصادقة وطوابير وPostgreSQL وRedis — مع فرض حدود المستأجر عند طبقة الاستعلام لا تركها لذاكرة كل متحكم.
- تسليم واجهات REST بإصدارات ثم واجهة الإدارة أو المنتج التي تستهلكها، حتى يثبت العقد قبل بناء الواجهة المعتمدة عليه.
- معالجة فشل الطوابير وإعادة المحاولة في نفس الخطوة مع الحالة الطبيعية، لأن مهمة تختفي بصمت عند أول فشل أسوأ من عدم وجودها أصلاً.
- استخدام نظام طوابير وأحداث Laravel بوعي — مهام لكل ما هو بطيء أو خارجي، وأحداث لكل ما يحتاج جزء آخر من النظام التفاعل معه — بدل حشو كل ذلك في دالة متحكم واحدة.
- كتابة اختبارات وظيفية على طبقة الواجهة لا اختبارات وحدة على أصناف معزولة فقط، حتى يعني نجاح مجموعة الاختبارات أن المنتج يعمل فعلياً من طرف لطرف.
- تحميل العلاقات مسبقاً بوعي وفحص عدد الاستعلامات في الصفحات التي تسرد أي شيء، حتى تُكتشف مشكلة N+1 في التطوير لا عند وصول بيانات حقيقية.
- اختبار أن الترحيلات تتراجع بنظافة لا فقط أنها تعمل للأمام، حتى يملك نشر سيئ تراجعاً حقيقياً بدل إصلاح يدوي.
ما تحصل عليه
- SaaS وERP وتطبيقات أعمال تبقى قابلة للصيانة بعد العميل الثاني، حين تصطدم افتراضات صُنعت لمستأجر واحد بمستأجر ثانٍ يعمل بشكل مختلف.
- معمارية من طنجة تستطيع فرق أوروبية قراءتها وتوسيعها، لأن مفردات المجال في الكود تطابق المفردات التي يستخدمها العمل فعلاً.
- خلفية يستطيع مطورون آخرون — من عندي أو من توظيف العميل — التمكّن منها خلال أيام لا أسابيع، لأن مفردات المجال في الكود تطابق العمل.
- تنبيهات أقل في منتصف الليل، لأن فشل الطوابير وتسرب المستأجرين وأخطاء الصلاحيات صُمم ضدها بدل اكتشافها في الإنتاج.
- صفحات تبقى سريعة مع نمو البيانات، لأن أنماط الاستعلام فُحصت مقابل أحجام واقعية لا قاعدة تطوير فارغة فقط.
- مسار تراجع حقيقي حين يسوء نشر، بدل إصلاح يدوي لقاعدة البيانات تحت الضغط.
مشاريع مختارة
أسئلة شائعة
Is Laravel suitable for SaaS?
Yes, when tenancy, queues, billing and permissions are designed from the start. I build Laravel SaaS that way by default.
Do you build REST APIs with Laravel?
Yes. Versioned REST APIs with authentication, rate limits, and documentation that frontend and mobile teams can actually use.