تطبيق Lovable إلى الإنتاج: ما يجب إصلاحه قبل الإطلاق

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

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

النموذج الأولي مقابل الإنتاج: ما الذي يتغيّر فعلاً

Lovable أداة لبناء التطبيقات بالذكاء الاصطناعي، وكثيراً ما تُقرن بـ Supabase للمصادقة وقاعدة بيانات Postgres وتخزين الملفات. وهذا المزيج ينقل قدراً كبيراً من مسؤولية الأمان إلى الإعدادات: سياسات قاعدة البيانات، وإعدادات إعادة التوجيه، ومفاتيح API، وقواعد التخزين. تولّد الأداة الشيفرة، لكنها لا ترى مستخدميك الحقيقيين ولا أموالك الحقيقية ولا أخطاءك الحقيقية.

الجاهزية للإنتاج تعني أن كل إعداد من هذه الإعدادات قد اختبره شخص حاول كسره. وتتبع الأقسام التالية الترتيب الذي تؤلم به المشكلات عادةً.

أين تحتاج التطبيقات المبنية بـ Lovable عادةً إلى اهتمام هندسي

1. أمان مستوى الصف في Supabase

هذا أول ما ينبغي فحصه. ففي إعداد Supabase يتصل المتصفح بقاعدة البيانات عبر مفتاح عام، وتقرّر سياسات أمان مستوى الصف (RLS) ما يحق لكل مستخدم قراءته أو كتابته. وقد يؤدي جدول بلا سياسات، أو بسياسات تسمح بكل شيء، إلى كشف بيانات كل عميل.

اختبر ذلك بـحسابين. أنشئ العميل A والعميل B وأعطِ كلاً منهما سجلات منفصلة. سجّل الدخول بصفتك B، ثم حاول فتح سجلات A وتعديلها وحذفها بتغيير المعرّفات في عناوين URL واستدعاء API مباشرة. وإن نجح أي من ذلك فأنت أمام عائق يمنع الإطلاق. يشرح دليلنا حول سبعة أخطاء في RLS تقع فيها التطبيقات المبنية بالذكاء الاصطناعي الأنماط التي ينبغي البحث عنها، ومنها الأدوار المخزّنة في أماكن يستطيع المستخدمون تعديلها ومساحات التخزين المفتوحة أكثر من اللازم.

2. المصادقة وعناوين إعادة التوجيه ورسائل البريد الإلكتروني

المصادقة التي تعمل على عنوان المعاينة كثيراً ما تتعطل على نطاقك الفعلي، أو يكون سلوكها فيه متساهلاً، وهذا أسوأ. تحقّق مما يلي:

• أن عنوان الموقع وقائمة عناوين إعادة التوجيه المسموح بها تتضمن نطاق الإنتاج الخاص بك، لا عناوين معاينة قديمة ولا أحرفاً بديلة (wildcards) لم تعد بحاجة إليها.
• أن تأكيد البريد الإلكتروني والروابط السحرية وإعادة تعيين كلمة المرور تعمل من البداية إلى النهاية في الإنتاج، وأن روابط إعادة التعيين تنتهي صلاحيتها ولا يمكن إعادة استخدامها.
• أن رسائل المصادقة تصدر من نطاقك الخاص مع إعداد SPF وDKIM وDMARC حتى لا تصل إلى البريد العشوائي. فالمرسِل الافتراضي للبريد مخصص عموماً للاختبار لا لحركة المرور الفعلية؛ تحقّق من إعدادات مشروعك.
• أن الإجراءات المخصصة للمشرفين فقط تُفرض على الخادم أو بسياسة في قاعدة البيانات، لا أن تُخفى في الواجهة فحسب.

3. الأسرار وما يصل إلى المتصفح

كل ما يُضمَّن في الواجهة الأمامية فهو علني. مفتاح Supabase العام (anon) مصمَّم ليكون مرئياً، لكنه لا يكون آمناً إلا إذا كانت سياسات RLS صحيحة. أما مفتاح service-role أو مفتاح الدفع السري أو مفتاح مزوّد الذكاء الاصطناعي إذا وُجد في شيفرة الواجهة الأمامية فهو تسريب خطير. ابحث عن المفاتيح في ملفات JavaScript المبنية وفي سجل المستودع، وبدّل أي مفتاح انكشف يوماً، وانقل الاستدعاءات التي تحتاج إلى أسرار إلى دوال تعمل على الخادم. وضع حدوداً للإنفاق على أي مفتاح لذكاء اصطناعي أو لواجهة API تابعة لجهة خارجية.

4. خطافات Stripe وصلاحيات الوصول المدفوعة

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

5. بنية الشيفرة المولّدة والتكرار والاختبارات

غالباً ما تعمل الشيفرة المولّدة لكنها تكرر نفسها: مكوّنات متشابهة منسوخة باختلافات طفيفة، وقواعد عمل موزعة في أرجاء الواجهة، وغياب الاختبارات الآلية. وهذا ليس حالة طارئة في اليوم الأول، لكنه السبب في أن تغييراً صغيراً قد يكسر شيئاً لا علاقة له به. قبل أن تتوسع، أضف اختبارات حول مسارات الأموال والصلاحيات، وجمّع القواعد المكررة في مكان واحد، واحتفظ بتغييرات قاعدة البيانات في ملفات ترحيل (migrations) خاضعة لإدارة الإصدارات حتى يمكن إعادة إنشاء المخطط ومراجعته.

6. الأداء ومراقبة الأخطاء

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

7. النشر والنطاقات والنسخ الاحتياطية

حدّد أين يعمل التطبيق، ومن يملك صلاحية النشر، وكيف تعود إلى آخر نسخة سليمة. افصل بيئة الاختبار المرحلي (staging) عن الإنتاج، بقاعدة بيانات ومفاتيح مستقلة لكل منهما. تأكد من إعداد النطاق وHTTPS، وفعّل النسخ الاحتياطية لقاعدة البيانات، واستعد نسخة منها فعلاً لتعرف كم يستغرق ذلك. النسخة الاحتياطية التي لم تستعدها قط أمنية لا خطة.

8. ملكية الشيفرة والمستودع والتصدير

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

ما الذي يمكنك مواصلة طلبه بالأوامر بأمان، ومتى تستعين بمهندس

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

استعن بمهندس حين يكون الخطأ خفياً أو مكلفاً: سياسات قاعدة البيانات، وإعدادات المصادقة، وكل ما يمس المدفوعات، وعمليات الترحيل التي تغيّر البيانات أو تحذفها، والأسرار، وأي مجال يبدو فيه كل إصلاح وكأنه يكسر شيئاً آخر. وإن عجزت عن شرح من يرى ماذا في تطبيقك، فهذا وحده سبب كافٍ. نتناول هذا القرار بتفصيل أكبر في متى تتوقف عن الأوامر وتستعين بمهندس، ونورد قائمة الفحوصات الكاملة في قائمة الجاهزية للإنتاج من 20 نقطة.

مسار الإنقاذ خطوة بخطوة

1. التدقيق. احصل على مراجعة مستقلة لضبط الوصول وسياسات البيانات والمدفوعات والأسرار والنشر. ينبغي أن تكون النتيجة قائمة مرتبة حسب الأولوية مع خطوات إعادة إنتاج كل مشكلة، لا درجة غامضة.
2. إصلاح المشكلات الحرجة. أغلق أولاً كل ما يكشف البيانات أو الأموال: السياسات المفقودة أو المتساهلة، والمفاتيح المسرّبة، وwebhooks غير الموثَّقة.
3. التحصين. أضف اختبارات لمسارات الصلاحيات والفوترة، وانقل الأسرار والمنطق الحساس إلى الخادم، وأعدّ ملفات الترحيل وبيئة الاختبار المرحلي والمراقبة والنسخ الاحتياطية.
4. الإطلاق. أطلق التطبيق مع خطة للتراجع ومسؤول معيَّن بالاسم وتنبيهات سيتصرف أحد بناءً عليها. وابدأ بمجموعة صغيرة من المستخدمين الحقيقيين إن أمكن.
5. الصيانة. ستستمر التبعيات وتغييرات المنصة والميزات الجديدة في الوصول. قرّر من يطبّق التحديثات ويراقب الأخطاء، سواء كان فريقك أو خطة صيانة.

لاحظ ما هو غائب: إعادة الكتابة من الصفر. يمكن إصلاح معظم التطبيقات في مكانها، والتدقيق هو الطريقة التي تعرف بها إن كان تطبيقك منها.

أين تأتي UnlockLive في الصورة

تعمل UnlockLive IT من تورنتو ولها مركز هندسي في دكا، وهذه هي المرحلة التي ندعمها تحديداً.

• يمثّل التدقيق التقني لتطبيقات الذكاء الاصطناعي الخطوة الأولى: نراجع إعداد Lovable وSupabase لديك، ونختبر المجالات الخطرة، ونسلّمك قائمة إصلاحات مرتبة حسب الأولوية يمكنك العمل بها معنا أو من دوننا.
• أما خدمة إصلاح تطبيقات الذكاء الاصطناعي وإطلاقها فتنفّذ تلك القائمة: إصلاح المشكلات الحرجة، وتحصين التطبيق، وإطلاقه على بنية تحتية تتحكم فيها.

وإن لم تكن متأكداً من حاجتك إلى أي منهما، فالتدقيق التقني يختلف أيضاً عن اختبار الاختراق؛ ويوضح مقارنتنا بين التدقيق واختبار الاختراق ومراجعة الشيفرة أيها يناسب حالتك.

ابدأ بفحص مجاني

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