الأخطاء التقنية الناتجة عن تشغيل 16 منتجاً باستخدام Lovable و Supabase

نحن ندير 16 منتجاً في Inithouse. نستخدم Lovable و Supabase لجميع هذه المنتجات، ويدير فريق واحد كل شيء.

إدارة 16 منتجاً تعني 16 نطاقاً مخصصاً (custom domains)، و16 مشروع Supabase، و16 مجموعة من الـ edge functions. هذا النطاق الواسع يؤدي إلى تكرار الأخطاء.

إليكم خمسة أخطاء تقنية ارتكبناها وكيف قمنا بإصلاحها.

  1. عدم اتساق مخططات قواعد البيانات (Database Schemas) استخدمت منتجاتنا الثلاثة الأولى أسماءً مختلفة لنفس البيانات. استخدم أحد المشاريع page_views للتحليلات، بينما استخدم مشروع آخر analytics_events.

استغرق كتابة الأدوات المشتركة أسبوعين بدلاً من فترة ما بعد الظهر، لأننا اضطررنا لكتابة استعلامات (queries) مخصصة لكل مشروع.

الحل: قمنا ببناء قالب هجرة (migration template) مشترك. يستخدم كل منتج جديد نفس الجداول الأساسية للتحليلات، وتدوينات المدونة، والمصادقة (auth).

  1. فشل النطاقات الصامت يتيح لك Lovable ربط نطاقات مخصصة. أحياناً تنجح عملية النشر (deploy) ولكن تفشل عملية التحقق من DNS. يعمل رابط المعاينة (preview URL)، ولكن النطاق المباشر يظهر صفحة فارغة.

فقدنا حركة مرور (traffic) لمدة ثلاثة أيام في أحد المنتجات قبل أن نلاحظ ذلك.

الحل: نستخدم قائمة مراجعة ما بعد النشر. نقوم بفتح النطاق المباشر في نافذة متخفية (incognito window) للتحقق منه. كما نستخدم cron job لإرسال ping للنطاق كل خمس دقائق.

  1. تشتت رؤية البيانات لمعرفة أداء منتجاتنا، كان علينا فتح لوحات تحكم Supabase وخصائص GA4 منفصلة. كنا نعمل دون رؤية واضحة.

الحل: قمنا بنشر نقطة نهاية (endpoint) لـ stats API في كل مشروع Supabase. يستخدم كل منتج edge function لإرجاع المقاييس الرئيسية بتنسيق واحد. يقوم نص برمجي (script) بسيط بسحب البيانات من جميع نقاط النهاية الـ 16 إلى لوحة تحكم واحدة.

  1. نسخ ولصق المكونات (Components) اعتدنا على نسخ مكونات React من مشروع إلى آخر، مما تسبب في حدوث أخطاء (bugs). فبطاقة التسعير في أحد المشاريع كانت تفترض الدفع لمرة واحدة، وعندما قمنا بلصقها في مشروع اشتراكات (subscription)، تعطل مسار Stripe.

الحل: توقفنا عن نسخ ولصق الكود. نقوم الآن بالاحتفاظ بوثيقة لأنماط المكونات (component patterns). نطلب من Lovable بناء مكون جديد بناءً على تلك الأنماط، مما يمنع حدوث أخطاء ناتجة عن افتراضات قديمة.

  1. استخدام الدردشة كتوثيق كنا نستخدم سجل دردشة Lovable كتوثيق لنا. إن العثور على قرار تقني محدد في سلسلة دردشة طويلة أمر صعب وبطيء.

الحل: نقلنا تسجيل القرارات إلى Linear. يحصل كل تغيير تقني رئيسي على تعليق في Linear يشرح ما الذي تغير ولماذا. تظل دردشة Lovable للتنفيذ، بينما يظل Linear لاتخاذ القرارات.

الدرس المستفاد: لا تعامل 16 منتجاً كـ 16 مشروعاً منفصلاً، بل عاملها كمحفظة واحدة (portfolio). قم بتوحيد قوالبك وراقب كل شيء بشكل مركزي.

المصدر: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh