Lovable اور Supabase پر 16 پروڈکٹس چلانے کی تکنیکی غلطیاں

ہم Inithouse میں 16 پروڈکٹس چلاتے ہیں۔ ہم ان سب کے لیے Lovable اور Supabase کا استعمال کرتے ہیں۔ ایک ہی ٹیم سب کچھ سنبھالتی ہے۔

16 پروڈکٹس کو سنبھالنے کا مطلب ہے 16 کسٹم ڈومینز، 16 Supabase پروجیکٹس، اور edge functions کے 16 سیٹس۔ اس پیمانے پر کام کرنے سے بار بار غلطیاں ہوتی ہیں۔

یہاں پانچ تکنیکی غلطیاں ہیں جو ہم نے کیں اور ہم نے انہیں کیسے درست کیا۔

1. غیر مستقل ڈیٹا بیس اسکیما (Inconsistent Database Schemas)

ہماری پہلی تین پروڈکٹس میں ایک ہی ڈیٹا کے لیے مختلف نام استعمال کیے گئے تھے۔ ایک پروجیکٹ میں analytics کے لیے page_views استعمال کیا گیا۔ دوسرے میں analytics_events استعمال کیا گیا۔

مشترکہ ٹولز (shared tools) لکھنے میں ایک دوپہر کے بجائے دو ہفتے لگ گئے کیونکہ ہمیں ہر پروجیکٹ کے لیے الگ سے کسٹم کوئریز لکھنی پڑیں۔

حل: ہم نے ایک مشترکہ مائیگریشن ٹیمپلیٹ (shared migration template) بنایا۔ ہر نئی پروڈکٹ analytics، بلاگ پوسٹس، اور auth کے لیے ایک ہی بیس ٹیبلز استعمال کرتی ہے۔

2. خاموش ڈومین کی ناکامیاں (Silent Domain Failures)

Lovable آپ کو کسٹم ڈومینز منسلک کرنے کی اجازت دیتا ہے۔ کبھی کبھی ڈیپلائمنٹ (deploy) کامیاب ہو جاتی ہے لیکن DNS کی تصدیق (verification) ناکام ہو جاتی ہے۔ پری ویو URL کام کرتا ہے، لیکن لائیو ڈومین پر خالی صفحہ نظر آتا ہے۔

ہمیں اس بات کا علم ہونے سے پہلے ہی ایک پروڈکٹ پر تین دن کا ٹریفک ضائع ہو گیا۔

حل: ہم پوسٹ پبلش چیک لسٹ (post-publish checklist) استعمال کرتے ہیں۔ ہم اس کی تصدیق کے لیے لائیو ڈومین کو incognito ونڈو میں کھولتے ہیں۔ ہم ہر پانچ منٹ میں ڈومین کو پنگ (ping) کرنے کے لیے ایک cron job بھی استعمال کرتے ہیں۔

3. ڈیٹا کی بکھری ہوئی نمائش (Fragmented Data Visibility)

یہ دیکھنے کے لیے کہ ہماری پروڈکٹس کی کارکردگی کیسی رہی، ہمیں الگ الگ Supabase ڈیش بورڈز اور GA4 پراپرٹیز کھولنی پڑتی تھیں۔ ہمیں اندازہ ہی نہیں ہوتا تھا کہ اصل میں کیا ہو رہا ہے۔

حل: ہم نے ہر Supabase پروجیکٹ پر ایک stats API endpoint ڈیپلائے کیا۔ ہر پروڈکٹ اہم میٹرکس (key metrics) کو ایک ہی فارمیٹ میں واپس کرنے کے لیے ایک edge function استعمال کرتی ہے۔ ایک سادہ اسکرپٹ تمام 16 اینڈ پوائنٹس سے ڈیٹا نکال کر ایک ہی ڈیش بورڈ میں لے آتا ہے۔

4. کمپوننٹس کی کاپی پیسٹنگ (Copy-Pasting Components)

ہم ایک پروجیکٹ سے دوسرے پروجیکٹ میں React کمپوننٹس کاپی کیا کرتے تھے۔ اس سے بگ (bugs) پیدا ہوئے۔ ایک پروجیکٹ کے پرائسنگ کارڈ میں یہ فرض کیا گیا تھا کہ ادائیگی صرف ایک بار ہوگی۔ جب ہم نے اسے سبسکرپشن پروجیکٹ میں پیسٹ کیا، تو اس نے Stripe کے فلو کو خراب کر دیا۔

حل: ہم نے کوڈ کی کاپی پیسٹنگ بند کر دی۔ ہم کمپوننٹ پیٹرنز (component patterns) کا ایک دستاویز برقرار رکھتے ہیں۔ ہم Lovable کو ان پیٹرنز کی بنیاد پر ایک نیا کمپوننٹ بنانے کا کہتے ہیں۔ اس سے پرانی مفروضات کی وجہ سے پیدا ہونے والے بگ سے بچا جا سکتا ہے۔

5. چیٹ کو دستاویز کے طور پر استعمال کرنا (Using Chat as Documentation)

ہم Lovable کی چیٹ ہسٹری کو اپنی دستاویز (documentation) کے طور پر استعمال کرتے تھے۔ ایک طویل چیٹ تھریڈ میں کسی مخصوص تکنیکی فیصلے کو تلاش کرنا مشکل اور سست کام ہے۔

حل: ہم نے فیصلے درج کرنے کا کام Linear پر منتقل کر دیا۔ ہر بڑے تکنیکی بدلاؤ کے لیے Linear میں ایک کمنٹ کیا جاتا ہے جس میں وضاحت کی جاتی ہے کہ کیا بدلا اور کیوں۔ Lovable چیٹ صرف عمل درآمد (execution) کے لیے رہتی ہے، جبکہ Linear فیصلوں کے لیے ہے۔

سبق: 16 پروڈکٹس کو 16 الگ الگ پروجیکٹس کے طور پر نہ دیکھیں۔ انہیں ایک پورٹ فولیو کے طور پر دیکھیں۔ اپنے ٹیمپلیٹس کو معیاری بنائیں اور ہر چیز کی مرکزی طور پر نگرانی کریں۔

Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh