Lovable आणि Supabase वर १६ उत्पादने चालवताना होणाऱ्या तांत्रिक चुका

आम्ही Inithouse मध्ये १६ उत्पादने चालवतो. आम्ही त्या सर्वांसाठी Lovable आणि Supabase वापरतो. एकच टीम सर्व गोष्टींचे व्यवस्थापन करते. हे ऐकायला चांगले वाटते, जोपर्यंत तुम्हाला १६ कस्टम डोमेन्स (custom domains), १६ Supabase प्रोजेक्ट्स आणि १६ edge functions च्या संचांचा सामना करावा लागत नाही.

आमच्याकडून अशा काही चुका झाल्या ज्यामुळे आमचा वेळ वाया गेला. येथे पाच सर्वात मोठ्या तांत्रिक चुका आणि त्यावर आम्ही केलेले उपाय दिले आहेत.

१. विसंगत डेटाबेस स्कीमा (Inconsistent database schemas)

आमच्या पहिल्या तीन उत्पादनांमध्ये एकाच प्रकारच्या डेटासाठी वेगवेगळ्या टेबल नावांचा वापर केला होता. एका प्रोजेक्टमध्ये analytics साठी page_views वापरले होते, तर दुसऱ्यामध्ये analytics_events वापरले होते. यामुळे सामायिक कोड (shared code) लिहिणे अशक्य झाले. एक काम जे एका दुपारी पूर्ण व्हायला हवे होते, त्यासाठी दोन आठवडे लागले.

उपाय: आम्ही एक सामायिक मायग्रेशन टेम्पलेट (shared migration template) तयार केले. प्रत्येक नवीन उत्पादनासाठी analytics, blog posts आणि auth साठी समान बेस टेबल्स दिले जातात. आम्ही शांततेच्या काळात (quiet weeks) जुन्या प्रोजेक्ट्समध्ये हे बदल केले. आता, मॉनिटरिंग एंडपॉइंट (monitoring endpoint) जोडण्यासाठी एक दिवस न लागता फक्त २० मिनिटे लागतात.

२. बिघडलेले कस्टम डोमेन्स (Broken custom domains)

Lovable तुम्हाला कस्टम डोमेन्स कनेक्ट करण्याची सुविधा देते. कधीकधी डिप्लॉयमेंट (deploy) यशस्वी होते पण DNS व्हेरिफिकेशन (verification) अयशस्वी होते. प्रिव्ह्यू URL (preview URL) काम करते, पण लाईव्ह डोमेनवर फक्त एक कोरा पृष्ठ (blank page) दिसतो. आम्ही लाईव्ह URL तपासला नाही, त्यामुळे आमचा तीन दिवसांचा ट्रॅफिक वाया गेला.

उपाय: आम्ही 'पोस्ट-पब्लिश चेकलिस्ट' (post-publish checklist) वापरतो. आम्ही प्रत्येक लाईव्ह डोमेन इन्कॉग्निटो विंडोमध्ये (incognito window) उघडून त्याची पडताळणी करतो. आम्ही एक 'अपटाइम चेक' (uptime check) देखील जोडला आहे, जो डोमेन फेल झाल्यास Slack वर मेसेज पाठवतो.

३. विखुरलेली डेटा व्हिजिबिलिटी (Fragmented data visibility)

प्रत्येक उत्पादनासाठी वेगळे डॅशबोर्ड न उघडता आमच्या संपूर्ण पोर्टफोलिओची कामगिरी कशी आहे, हे आम्हाला पाहता येत नव्हते. आम्ही अंधारात काम करत होतो.

उपाय: आम्ही प्रत्येक Supabase प्रोजेक्टमध्ये एक stats API endpoint तैनात केला. प्रत्येक उत्पादन युजर्स आणि साइनअप्स यांसारखे महत्त्वाचे मेट्रिक्स (metrics) एका प्रमाणित फॉरमॅटमध्ये पाठवते. एक सिंगल स्क्रिप्ट हा सर्व डेटा एका डॅशबोर्डमध्ये आणते.

४. कंपोनंट्स कॉपी-पेस्ट करणे (Copy-pasting components)

आम्ही एका प्रोजेक्टमधील React कंपोनंट्स दुसऱ्या प्रोजेक्टमध्ये कॉपी करायचो. या कंपोनंट्समध्ये जुन्या गृहितकांचा (assumptions) समावेश असायचा. एका उत्पादनाचा 'प्राइसिंग कार्ड' (pricing card) दुसऱ्या उत्पादनात काम करत नसे, कारण तिथे पेमेंट फ्लो (payment flow) वेगळा अपेक्षित होता. या 'फँटम बग्स' (phantom bugs) शोधण्यात आमचे अनेक दिवस गेले.

उपाय: आम्ही कॉपी-पेस्ट करणे थांबवले. आम्ही कंपोनंट पॅटर्नचा (component patterns) एक दस्तऐवज (document) ठेवतो. आम्ही Lovable ला या पॅटर्नवर आधारित नवीन कंपोनंट तयार करण्यास सांगतो. हे सेट करण्यासाठी थोडे जास्त वेळ लागते, पण मेंटेन करणे खूप सोपे जाते.

५. चॅट हिस्ट्रीचा डॉक्युमेंटेशन म्हणून वापर करणे (Using chat history as documentation)

तांत्रिक निर्णय लक्षात ठेवण्यासाठी आम्ही Lovable च्या चॅट हिस्ट्रीवर अवलंबून होतो. चॅट लॉग्स खूप विस्कळीत असतात. त्यात यशस्वी बदल आणि अयशस्वी प्रयत्न एकत्र मिसळलेले असतात. लांब चॅट थ्रेडमध्ये बदलाचे विशिष्ट कारण शोधणे कठीण असते.

उपाय: आम्ही निर्णय नोंदवण्याचे (decision logging) काम Linear वर हलवले. काय बदलले आणि का बदलले, हे आम्ही Linear मध्ये एका ओळीत लिहितो. Lovable चॅट हे अंमलबजावणीसाठी (execution) आहे, तर Linear हे निर्णयांसाठी आहे.

धडा साधा आहे. १६ उत्पादनांना १६ वेगळे प्रोजेक्ट्स मानू नका. त्यांना एका पोर्टफोलिओप्रमाणे treat करा. तुमचे टेम्पलेट्स प्रमाणित (standardize) करा आणि सर्व गोष्टी एकाच ठिकाणाहून मॉनिटर करा.

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

Optional learning community: https://t.me/GyaanSetuAi