Lovable اور Supabase پر 16 پروڈکٹس چلانے کی تکنیکی غلطیاں
ہم Inithouse میں 16 پروڈکٹس چلاتے ہیں۔ ہم ان سب کے لیے Lovable اور Supabase کا استعمال کرتے ہیں۔ ایک ہی ٹیم سب کچھ سنبھالتی ہے۔ یہ سننے میں تو اچھا لگتا ہے، لیکن تب تک، جب تک آپ کو 16 کسٹم ڈومینز، 16 Supabase پروجیکٹس، اور edge functions کے 16 سیٹس کا سامنا نہ کرنا پڑے۔
ہم نے ایسی غلطیاں کیں جن کی وجہ سے ہمارا وقت ضائع ہوا۔ یہاں پانچ بڑی تکنیکی غلطیاں اور ان کے حل موجود ہیں۔
- ڈیٹا بیس اسکیما میں عدم تسلسل
ہماری پہلی تین پروڈکٹس ایک ہی ڈیٹا کے لیے مختلف ٹیبل کے نام استعمال کرتی تھیں۔ ایک پروجیکٹ اینالیٹکس کے لیے page_views استعمال کرتا تھا۔ دوسرا analytics_events استعمال کرتا تھا۔ اس کی وجہ سے مشترکہ کوڈ (shared code) لکھنا ناممکن ہو گیا۔ ایک ایسا کام جو ایک دوپہر میں ہو جانا چاہیے تھا، اس میں دو ہفتے لگ گئے۔
The fix: ہم نے ایک مشترکہ مائیگریشن ٹیمپلیٹ (shared migration template) بنایا۔ ہر نئی پروڈکٹ کو اینالیٹکس، بلاگ پوسٹس، اور auth کے لیے ایک جیسے بنیادی ٹیبلز ملتے ہیں۔ ہم نے پرسکون ہفتوں کے دوران پرانے پروجیکٹس کو بھی اسی کے مطابق ڈھال لیا۔ اب، ایک مانیٹرنگ اینڈ پوائنٹ (monitoring endpoint) شامل کرنے میں ایک دن کے بجائے صرف 20 منٹ لگتے ہیں۔
- خراب کسٹم ڈومینز
Lovable آپ کو کسٹم ڈومینز منسلک کرنے کی اجازت دیتا ہے۔ کبھی کبھی ڈیپلائمنٹ (deploy) کامیاب ہو جاتی ہے لیکن DNS کی تصدیق (verification) ناکام ہو جاتی ہے۔ پری ویو URL کام کرتا ہے، لیکن لائیو ڈومین پر خالی صفحہ نظر آتا ہے۔ ہم نے تین دن کا ٹریفک کھو دیا کیونکہ ہم نے لائیو URL چیک نہیں کیا تھا۔
The fix: ہم پبلش کرنے کے بعد ایک چیک لسٹ استعمال کرتے ہیں۔ ہم تصدیق کے لیے ہر لائیو ڈومین کو انکوگنیٹو (incognito) ونڈو میں کھولتے ہیں۔ ہم نے ایک اپ ٹائم چیک (uptime check) بھی شامل کیا ہے جو ڈومین فیل ہونے کی صورت میں Slack پر اطلاع (ping) بھیجتا ہے۔
- ڈیٹا کی بکھری ہوئی دستیابی
ہم ہر پروڈکٹ کے لیے الگ الگ ڈیش بورڈز کھولے بغیر یہ نہیں دیکھ سکتے تھے کہ ہمارا پورا پورٹ فولیو کیسا کارکردگی دکھا رہا ہے۔ ہم اندھیرے میں تیر رہے تھے۔
The fix: ہم نے ہر Supabase پروجیکٹ پر ایک stats API اینڈ پوائنٹ ڈیپلائ کیا۔ ہر پروڈکٹ صارفین (users) اور سائن اپس (signups) جیسے اہم میٹرکس ایک معیاری فارمیٹ میں بھیجتی ہے۔ ایک ہی اسکرپٹ اس ڈیٹا کو ایک ڈیش بورڈ میں جمع کر لیتا ہے۔
- کمپوننٹس کی کاپی پیسٹنگ
ہم ایک پروجیکٹ سے دوسرے پروجیکٹ میں React کمپوننٹس کاپی کیا کرتے تھے۔ ان کمپوننٹس میں پرانی مفروضات (assumptions) شامل ہوتی تھیں۔ ایک پروڈکٹ کا پرائسنگ کارڈ دوسری پروڈکٹ میں کام نہیں کرتا تھا کیونکہ وہ ادائیگی کے ایک مختلف طریقے (payment flow) کی توقع رکھتا تھا۔ ہم نے ان فرضی بگ (phantom bugs) کو ٹھیک کرنے میں کئی دن ضائع کیے۔
The fix: ہم نے کاپی پیسٹنگ بند کر دی۔ ہم کمپوننٹ پیٹرنز (component patterns) کا ایک دستاویز برقرار رکھتے ہیں۔ ہم Lovable کو ان پیٹرنز کی بنیاد پر ایک نیا کمپوننٹ بنانے کا کہتے ہیں۔ اسے سیٹ اپ کرنے میں وقت زیادہ لگتا ہے لیکن اسے برقرار رکھنا بہت آسان ہے۔
- چیٹ ہسٹری کو دستاویز کے طور پر استعمال کرنا
ہم تکنیکی فیصلوں کو یاد رکھنے کے لیے Lovable کی چیٹ ہسٹری پر بھروسہ کرتے تھے۔ چیٹ لاگز بہت الجھے ہوئے ہوتے ہیں۔ وہ کامیاب تبدیلیوں کو ناکام کوششوں کے ساتھ ملا دیتے ہیں۔ ایک طویل تھریڈ میں کسی تبدیلی کی مخصوص وجہ تلاش کرنا مشکل ہوتا ہے۔
The fix: ہم فیصلوں کی لاگنگ (decision logging) کو Linear پر منتقل کر دیا۔ ہم Linear میں ایک لائن لکھتے ہیں جس میں وضاحت ہوتی ہے کہ کیا بدلا اور کیوں۔ Lovable کی چیٹ عمل درآمد (execution) کے لیے ہے، جبکہ 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