الأخطاء التقنية الناتجة عن تشغيل 16 منتجاً على Lovable و Supabase
نحن ندير 16 منتجاً في Inithouse. نستخدم Lovable و Supabase لجميع هذه المنتجات، ويدير فريق واحد كل شيء. يبدو هذا أمراً جيداً حتى تواجه 16 نطاقاً مخصصاً (custom domains)، و16 مشروع Supabase، و16 مجموعة من الـ edge functions.
لقد ارتكبنا أخطاءً كلفتنا الكثير من الوقت. إليكم أكبر خمسة أخطاء تقنية والحلول التي اعتمدناها.
- عدم اتساق مخططات قواعد البيانات (database schemas)
استخدمت منتجاتنا الثلاثة الأولى أسماء جداول مختلفة لنفس البيانات. استخدم أحد المشاريع page_views للتحليلات، بينما استخدم مشروع آخر analytics_events. جعل هذا من المستحيل كتابة كود مشترك. فالمهمة التي كان من المفترض أن تستغرق ظهيرة يوم واحد، استغرقت أسبوعين.
الحل: قمنا ببناء قالب تهجير (migration template) مشترك. يحصل كل منتج جديد على نفس الجداول الأساسية للتحليلات، وتدوينات المدونة، والمصادقة (auth). قمنا بتحديث المشاريع القديمة خلال أسابيع العمل الهادئة. الآن، يستغرق إضافة نقطة نهاية للمراقبة (monitoring endpoint) 20 دقيقة بدلاً من يوم كامل.
- تعطل النطاقات المخصصة (custom domains)
يتيح لك Lovable ربط نطاقات مخصصة. أحياناً تنجح عملية النشر (deploy) ولكن تفشل عملية التحقق من DNS. يعمل رابط المعاينة (preview URL) بشكل صحيح، لكن النطاق المباشر يظهر صفحة فارغة. لقد فقدنا حركة مرور (traffic) لمدة ثلاثة أيام لأننا لم نتحقق من الرابط المباشر.
الحل: نستخدم قائمة مراجعة ما بعد النشر. نقوم بفتح كل نطاق مباشر في نافذة متخفية (incognito window) للتحقق منه. كما أضفنا فحصاً لوقت التشغيل (uptime check) يرسل تنبيهاً إلى Slack في حال تعطل أي نطاق.
- تشتت رؤية البيانات
لم نكن نستطيع رؤية أداء محفظة منتجاتنا بالكامل دون فتح لوحات تحكم (dashboards) منفصلة لكل منتج. كنا نعمل دون رؤية واضحة.
الحل: قمنا بنشر نقطة نهاية لـ stats API في كل مشروع Supabase. يرسل كل منتج مقاييس رئيسية مثل عدد المستخدمين وعمليات التسجيل بتنسيق قياسي. ويقوم سكربت واحد بسحب هذه البيانات إلى لوحة تحكم واحدة.
- نسخ ولصق المكونات (components)
اعتدنا على نسخ مكونات React من مشروع إلى آخر. كانت هذه المكونات تحمل افتراضات قديمة. فمثلاً، فشلت بطاقة تسعير من منتج ما في منتج آخر لأنها كانت تتوقع تدفق دفع (payment flow) مختلفاً. قضينا أياماً في تصحيح هذه الأخطاء الوهمية (phantom bugs).
الحل: توقفنا عن النسخ واللصق. أصبحنا نحتفظ بوثيقة لأنماط المكونات (component patterns). نطلب من Lovable بناء مكون جديد بناءً على هذه الأنماط. قد يستغرق الإعداد وقتاً أطول، لكن الصيانة تصبح أسهل بكثير.
- استخدام سجل الدردشة كوثائق (documentation)
كنا نعتمد على سجل دردشة Lovable لتذكر القرارات التقنية. سجلات الدردشة فوضوية؛ فهي تخلط بين التغييرات الناجحة والمحاولات الفاشلة. ومن الصعب العثور على سبب محدد لتغيير ما في سلسلة رسائل طويلة.
الحل: نقلنا تسجيل القرارات إلى Linear. نكتب سطراً واحداً في Linear يشرح ما الذي تغير ولماذا. دردشة Lovable مخصصة للتنفيذ، بينما Linear مخصص للقرارات.
الدرس بسيط: لا تعامل 16 منتجاً كأنها 16 مشروعاً منفصلاً، بل عاملها كمحفظة واحدة. قم بتوحيد قوالبك وراقب كل شيء من مكان واحد.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi