يشكّل Flutter وLaravel بنية عملية عندما يتولى تطبيق الهاتف تجربة الجهاز، وتتولى الخلفية قواعد العمل والصلاحيات والبيانات والتكاملات. الفائدة ليست وعداً بقاعدة شيفرة واحدة لكل شيء، بل واجهة برمجة تطبيقات (API) موحدة تستخدمها التطبيقات من دون تكرار القرار التجاري داخل كل عميل. ويبقى على الفريق مراعاة اختلاف iOS وAndroid، وتوافق الإصدارات، والمراقبة، والأمان، والعمل دون اتصال. وضوح المسؤوليات أهم من اختيار الحزم.
وزّع المسؤولية قبل كتابة الشاشات
حدد من يملك التحقق والصلاحية والسعر وانتقال الحالة والنتيجة المشتقة. يمكن لـ Flutter فحص الحقول لتحسين الاستجابة، لكن Laravel يتخذ القرار النهائي. يملك العميل التنقل وحالة العرض وقدرات الجهاز وطابوراً محلياً آمناً. تملك الخلفية سياق المستخدم والمستأجر والسياسات والمعاملات والآثار الخارجية. هذا الفصل يمنع إصدارين من التطبيق من حساب قاعدة واحدة بطريقتين مختلفتين.
اكتب عقد API صريحاً
وثق المسارات والحقول والأنواع والقيم الفارغة والتصفح والأخطاء وسياسة الإصدار. استخدم معرفات ثابتة وأكواد أخطاء آلية، ولا تجعل التطبيق يحلل جملة إنجليزية ليقرر السلوك. اختبر Laravel API Resources أو الطبقة التمثيلية بعينات عقد. يشرح دليل PWA دون اتصال العمليات المتينة، بينما يغطي دليل RTL-first الاتجاه والمحتوى اللذين يجب أن يدخلا عقد التطبيق أيضاً.
افصل جلسة المستخدم عن الجهاز والإشعارات
رمز الدخول وهوية الجهاز ورمز Push سجلات مختلفة بدورات حياة مختلفة. خزّن بيانات الاعتماد في آلية آمنة للمنصة، ودوّرها أو ألغها، ولا تضع أسرار الخادم داخل التطبيق. صمم تسجيل الخروج وفقد الجهاز وتعطيل الحساب وتغير كلمة المرور. يجب أن تتحقق الخلفية من كل طلب؛ إخفاء زر في Flutter ليس صلاحية. قيّد المحاولات الحساسة وسجل الحدث من دون رموز أو حمولة خاصة.
حوّل الأخطاء إلى حالات منتج
ميّز بين validation ومنع الصلاحية والتعارض وانتهاء الجلسة وعدم العثور والحد المؤقت وفشل المزود والخطأ غير المتوقع. أعطِ كل حالة كوداً ثابتاً ورسالة آمنة وإجراءً مناسباً. التعارض قد يحتاج تحديثاً أو مراجعة، والمهلة قد تحتاج استعلام حالة بدلاً من إعادة عمياء. أضف مرجع correlation للدعم. اختبر نصوص العربية والإنجليزية والحالة التي يرسل فيها الخادم كوداً لا يعرفه تطبيق قديم.
صمّم العمل دون اتصال كأوامر
حدد بالاسم الوظائف المتاحة. خزّن عملية بمعرف فريد وإصدار حمولة وهوية مستخدم ومستأجر ووقت واعتماد، وأظهر pending وsynced وfailed وneeds-attention. يعالج Laravel المعرف بطريقة idempotent حتى لا ينشئ التكرار موعداً أو فاتورة أخرى. قد تبقى العمليات الحساسة متصلة فقط. لا تصف التطبيق كله بأنه يعمل دون اتصال لأن شاشة مخزنة فتحت.
حل التعارض حسب خطورة البيانات
استخدم إصدار سجل أو شرطاً يكتشف التغيير على الخادم. قد تُدمج ملاحظة عادية، بينما الموعد والمخزون والمال تحتاج قاعدة أقوى أو مراجعة بشرية. أعد سياقاً يسمح للتطبيق بشرح التعارض من دون كشف حقول غير مصرح بها. احتفظ بالمدخلين حتى القرار. الكتابة الأخيرة ليست حلاً عاماً؛ هي سياسة فقد بيانات يجب قبولها صراحة إن استُخدمت.
حافظ على توافق إصدارات التطبيق
لا يحدث جميع المستخدمين فوراً، لذلك تخدم الخلفية عدة إصدارات. حدد نافذة دعم وراقب الإصدارات النشطة. اجعل التغييرات إضافية قدر الإمكان، ولا تغير معنى حقل موجود. عند كسر العقد، أنشئ إصداراً أو capability، وانشر التطبيق، وراقب التبني، ثم أوقف القديم بخطة ورسالة مفهومة. اختبر fixture قديم مع الخادم الجديد في CI.
انقل العمل البطيء إلى طابور
الإشعارات والتقارير ومعالجة الملفات واتصالات المزودين لا يجب أن تطيل طلب الموبايل بلا حاجة. استخدم jobs بمهلة وإعادة محدودة ومنع تكرار ورؤية للفشل. أعد حالة accepted ثم وفر endpoint للحالة أو تحديثاً موثوقاً. لا تعلن النجاح قبل النتيجة. اضبط حدود المعاملة حتى لا ترى الوظيفة بيانات نصف مكتوبة، واستخدم after-commit عند الحاجة.
اربط المراقبة عبر الطبقات
مرر معرف طلب أو عملية من Flutter إلى Laravel ثم job والمزود. راقب الزمن ونوع الخطأ وإصدار التطبيق والنظام والمسار وتأخير الطابور، من دون تسجيل محتوى الشاشة أو البيانات الشخصية افتراضياً. نظف crash reports من الرموز. يحتاج الدعم معرفة هل الأمر محلي أم وصل أم يعالج أم فشل. CPU الخادم وحده لا يصف تجربة المستخدم.
اختبر العقد والجهاز والفشل
اكتب اختبارات خلفية للصلاحيات والتمثيل، واختبارات عميل للتحليل والحالة، وfixtures مشتركة. اختبر انتهاء الرمز وتكرار الإرسال وشبكة بطيئة وإغلاق التطبيق وسط الرفع وإصداراً قديماً وتدوير Push وتأخر المزود. جرّب أجهزة حقيقية وإصدارات مدعومة؛ المحاكي لا يثبت قيود الخلفية والكاميرا والتخزين الآمن وسلوك النظام.
خطط للإطلاق والاسترداد
حدد ترتيب نشر الخلفية والتطبيق والتكوين، وما النسخة المتوافقة في كل لحظة. استخدم feature flags عندما تقلل خطر الانتقال، لكن لا تتركها بلا مالك أو تاريخ إزالة. جهز rollback لا يفسد البيانات التي كتبها الإصدار الجديد، واختبر backup واستعادة السجلات الحرجة. وثق من يراقب أول ساعات الإصدار وكيف يوقف وظيفة أو مزوداً من دون تعطيل التطبيق كله.
اختبر التوافق قبل تحديث العميل
شغّل نسخة تطبيق قديمة وأخرى جديدة ضد عقد API تجريبي، وغيّر حقلاً اختيارياً وأضف قيمة حالة واختبر خطأ صلاحية وانقطاعاً. يجب أن تبقى الاستجابة مفهومة وأن يظهر الحد الأدنى المدعوم بوضوح. سجّل من يقرر كسر التوافق وكيف تُنشر نسخة الخادم والعميل وترجعان. هذا التمرين يثبت فائدة العقد أكثر من مشاركة Models متشابهة بين المشاريع.
الخلاصة: اجعل الحد بين العميل والخادم منتجاً
ينجح هذا المزيج عندما يربط كل شاشة عقد واحد وقواعد موحدة وهوية عملية قابلة للتتبع. عرّف الملكية والتوافق ونطاق offline والمراقبة قبل توسيع الميزات. لمراجعة التصميم، اطلب ورشة معمارية لتطبيق Flutter وLaravel وأحضر مسارين حقيقيين وأقدم إصدار تنوي دعمه.