تطبيق Lovable لا يعمل في بيئة الإنتاج؟ كيف تجعله جاهزًا للإنتاج

لماذا يعمل تطبيق Lovable في المعاينة ويتعطل في الإنتاج؟

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

• تسرب البيانات بين المستخدمين. يجعل Supabase الجدول في مخطط مكشوف قابلًا للقراءة والكتابة لأي دور لديه صلاحية عليه، ما لم يكن أمان مستوى الصف مفعّلًا وسياساته صحيحة.
• أسرار في المتصفح. المفتاح القابل للنشر (anon) آمن للإرسال؛ أما مفتاح service role فيتجاوز كل سياسات RLS ويجب ألا يصل إلى المتصفح أبدًا.
• مدفوعات تنحرف. عملية دفع تعود إلى صفحة نجاح ليست دليلًا على الدفع. يجب أن يتحقق الخادم من ذلك لدى Stripe.
• تغييرات تكسر ميزات قديمة. دون اختبارات الانحدار، قد يلغي كل أمر جديد شيئًا كان يعمل الأسبوع الماضي.
• انقطاعات صامتة. دون مراقبة، يكتشف عملاؤك الخلل قبلك.

لا شيء من هذا خاص بـ Lovable. فأي نسخة أولى سريعة، كتبها إنسان أو ذكاء اصطناعي، تميل إلى الثغرات نفسها، لأن مهمة النموذج الأولي إثبات الفكرة، لا الصمود أمام الغرباء.

هل تطبيق Lovable جاهز للإنتاج كما هو؟

جزئيًا. تقول وثائق Lovable إنه يكتب سياسات أمان مستوى الصف للجداول حين تربط Supabase، ويجري فحص أمان سريعًا عند النشر (مراجعة لقاعدة البيانات، مثل الجداول بلا RLS أو القواعد التي تسمح للجميع بالمرور، وتدقيقًا للمكتبات المعتمدة، وفحصًا لخادم MCP)، ويوفر فحصًا أعمق تبدؤه يدويًا. وتقول أيضًا بوضوح إن الفحص لا يستطيع ضمان أمان كامل ولا يغني عن مراجعة أمنية شاملة.

هذا وصف منصف. يستطيع الفحص أن يخبرك بوجود سياسة. لكنه لا يستطيع أن يخبرك بأن السياسة تطابق قواعد عملك، مثلًا أن مسؤول الفريق يرى الفواتير وعضو الفريق لا يراها. وهذا الحكم هو ما تعنيه الجاهزية للإنتاج عمليًا.

ماذا تعني الجاهزية للإنتاج لتطبيق Lovable؟

كيف أضيف مدفوعات Stripe إلى تطبيق Lovable بأمان؟

يعمل تكامل Stripe في Lovable عبر دوال الحافة (edge functions)، فيبقى مفتاحك السري خارج التطبيق، وتفتح المدفوعات لمرة واحدة صفحة Stripe Checkout. وبحسب وثائق Lovable، لا يُعدّ webhooks افتراضيًا: يتحقق التطبيق من حالة الدفع والاشتراك مباشرة لدى Stripe، ويمكن إضافة webhooks عند الطلب. وتشير الوثائق أيضًا إلى أن معرّفات الأسعار تختلف بين وضع الاختبار والوضع الحي، لذا يحتاج الإطلاق إلى معرّفات جديدة.

التحقق من الحالة عند الطلب يكفي لعملية دفع بسيطة. لكن حين تبيع اشتراكات، تحتاج عادةً إلى webhooks أيضًا، لأن التجديدات والبطاقات المرفوضة والإلغاءات تحدث حين لا يكون المستخدم على الصفحة. ووثائق Stripe محددة في كيفية فعل ذلك بأمان:

• تحقق من كل webhook بترويسة Stripe-Signature وسر نقطة النهاية، مقابل جسم الطلب الخام.
• توقّع أحداثًا مكررة وأحداثًا بغير ترتيبها. سجّل معرّفات الأحداث التي عالجتها لتُعالج كل واحدة مرة واحدة (عدم التكرار idempotency).
• تذكّر أن Stripe يعيد محاولة الإرسالات الفاشلة في الوضع الحي لمدة تصل إلى ثلاثة أيام، فقد تعيد نقطة نهاية معطلة تشغيل أيام من الأحداث حين تتعافى.
• افصل بين أسرار الاختبار والأسرار الحية. الكائنات في وضع لا تظهر في الآخر.

هل أصلحه بنفسي، أم أوظف مطورًا مستقلًا، أم أستعين بفريق؟

إن كان لتطبيقك عدد قليل من المستخدمين، ولا مدفوعات ولا بيانات حساسة، فيمكنك العمل على الجدول أعلاه بنفسك مع فحص الأمان في Lovable وSecurity Advisor في Supabase، الذي ينبّه إلى الجداول التي عُطّل فيها RLS والسياسات التي تسمح للجميع بالمرور. وهذا استغلال جيد لفترة بعد الظهر.

المطور المستقل أو سباق إنقاذ بسعر ثابت يناسب مشكلة معروفة ومحددة: تكامل واحد معطل، أو تدقيق واحد. وغالبًا ما يكونان الخيار الأرخص لذلك. لكن ما لا يمنحك إياه الإصلاح لمرة واحدة هو الأشهر الستة التالية: الاختبارات والإصدارات والترقيات والحادثة خارج ساعات العمل. وهذه المسؤولية المستمرة هي ما نبيعه: تتخصص Plutonapps في نقل تطبيقات Lovable إلى بيئة الإنتاج وتشغيلها، ومقارنتنا بين الوكالات والمطورين المستقلين والتوظيف الداخلي والاشتراكات توضح متى يناسب كل منها.

ماذا يحدث بعد الإطلاق، ومن المناوب؟

الإطلاق هو حيث يتغير العمل، لا حيث يتوقف. على أحد أن يراقب الأخطاء، ويطبق تحديثات الأمان، ويستجيب للحوادث، ويطلق الميزة التالية دون كسر سابقتها. في خطة Starter لدينا، يواصل المؤسسون كتابة الأوامر في Lovable، ويبني مهندسونا كل نسخة في المنتج الحقيقي، ويجرون اختبارات الانحدار والانحدار المرئي ومراجعة الشيفرة وفحوص الأمان مع كل تغيير، وينشرون في بيئة الإنتاج مرتين أسبوعيًا، ويتعاملون مع ما يصل إلى خمس حالات طارئة في الإنتاج شهريًا، مع دعم خلال ساعات العمل. وتضيف Growth النشر المستمر والدعم على مدار الساعة. التفاصيل والأسعار في صفحة الأسعار لدينا.