Lovable మరియు Supabase లపై 16 ఉత్పత్తులను నడపడంలో ఎదురైన సాంకేతిక తప్పులు
మేము Inithouseలో 16 ఉత్పత్తులను నడుపుతున్నాము. వాటన్నింటికీ మేము Lovable మరియు Supabase ఉపయోగిస్తాము. ఒకే టీమ్ అన్నింటినీ నిర్వహిస్తుంది. ఇది వినడానికి బాగుంటుంది, కానీ మీరు 16 కస్టమ్ డొమైన్లు, 16 Supabase ప్రాజెక్ట్లు మరియు 16 సెట్ల edge functionsలను ఎదుర్కోవాల్సి వచ్చినప్పుడు పరిస్థితి మారుతుంది.
మాకు సమయాన్ని వృధా చేసిన కొన్ని తప్పులు జరిగాయి. ఇక్కడ ఐదు అతిపెద్ద సాంకేతిక తప్పులు మరియు వాటికి మేము చేసిన పరిష్కారాలు ఉన్నాయి.
- అస్థిరమైన డేటాబేస్ స్కీమాలు (Inconsistent database schemas)
మా మొదటి మూడు ఉత్పత్తులు ఒకే రకమైన డేటా కోసం వేర్వేరు టేబుల్ పేర్లను ఉపయోగించాయి. ఒక ప్రాజెక్ట్ అనలిటిక్స్ కోసం page_viewsని ఉపయోగించింది. మరొకటి analytics_eventsని ఉపయోగించింది. దీనివల్ల షేర్డ్ కోడ్ (shared code) రాయడం అసాధ్యమైంది. ఒక మధ్యాహ్నం కాలంలో పూర్తి చేయాల్సిన పని రెండు వారాల సమయం తీసుకుంది.
పరిష్కారం: మేము ఒక షేర్డ్ మైగ్రేషన్ టెంప్లేట్ను (shared migration template) రూపొందించాము. ప్రతి కొత్త ఉత్పత్తికి అనలిటిక్స్, బ్లాగ్ పోస్ట్లు మరియు auth కోసం ఒకే రకమైన బేస్ టేబుల్స్ లభిస్తాయి. పని ఒత్తిడి తక్కువగా ఉన్న వారాల్లో పాత ప్రాజెక్ట్లను కూడా వీటితో సరిచేసాము. ఇప్పుడు, ఒక మానిటరింగ్ ఎండ్పాయింట్ను (monitoring endpoint) జోడించడానికి ఒక రోజుకు బదులుగా కేవలం 20 నిమిషాలు మాత్రమే పడుతుంది.
- పాడైపోయిన కస్టమ్ డొమైన్లు (Broken custom domains)
Lovable మీకు కస్టమ్ డొమైన్లను కనెక్ట్ చేయడానికి అనుమతిస్తుంది. కొన్నిసార్లు డిప్లాయ్ (deploy) విజయవంతమవుతుంది కానీ DNS వెరిఫికేషన్ విఫలమవుతుంది. ప్రివ్యూ URL పనిచేస్తుంది, కానీ లైవ్ డొమైన్ ఖాళీ పేజీని చూపిస్తుంది. మేము లైవ్ URLని తనిఖీ చేయకపోవడం వల్ల మూడు రోజుల ట్రాఫిక్ను కోల్పోయాము.
పరిష్కారం: మేము పోస్ట్-పబ్లిష్ చెక్లిస్ట్ను (post-publish checklist) ఉపయోగిస్తున్నాము. వెరిఫై చేయడానికి మేము ప్రతి లైవ్ డొమైన్ను ఇన్కోగ్నిటో విండోలో ఓపెన్ చేస్తాము. డొమైన్ విఫలమైతే Slackకి నోటిఫికేషన్ పంపేలా ఒక అప్టైమ్ చెక్ (uptime check)ను కూడా జోడించాము.
- విచ్ఛిన్నమైన డేటా విజిబిలిటీ (Fragmented data visibility)
ప్రతి ఉత్పత్తి కోసం విడివిడి డ్యాష్బోర్డ్లను ఓపెన్ చేయకుండా మా మొత్తం పోర్ట్ఫోలియో ఎలా పని చేస్తుందో మేము చూడలేకపోయాము. మాకు పరిస్థితిపై స్పష్టత లేదు.
పరిష్కారం: మేము ప్రతి Supabase ప్రాజెక్ట్కు ఒక స్టాట్స్ API ఎండ్పాయింట్ను (stats API endpoint) డిప్లాయ్ చేశాము. ప్రతి ఉత్పత్తి యూజర్లు మరియు సైన్అప్ల వంటి కీలక మెట్రిక్స్ను ఒకే రకమైన ఫార్మాట్లో పంపుతుంది. ఒకే స్క్రిప్ట్ ఈ డేటాను ఒకే డ్యాష్బోర్డ్లోకి తీసుకువస్తుంది.
- కాంపోనెంట్లను కాపీ-పేస్ట్ చేయడం (Copy-pasting components)
మేము ఒక ప్రాజెక్ట్ నుండి మరొక ప్రాజెక్ట్కు React కాంపోనెంట్లను కాపీ చేసేవాళ్ళం. ఈ కాంపోనెంట్లతో పాత అంచనాలు (assumptions) కూడా వచ్చేవి. ఒక ఉత్పత్తికి చెందిన ప్రైసింగ్ కార్డ్ మరొక ఉత్పత్తిలో విఫలమైంది, ఎందుకంటే అది వేరే పేమెంట్ ఫ్లోను ఆశించింది. ఈ తెలియని బగ్స్ను (phantom bugs) డీబగ్ చేయడానికి మేము రోజులు గడిపాము.
పరిష్కారం: మేము కాపీ-పేస్ట్ చేయడం ఆపివేశాము. మేము కాంపోనెంట్ ప్యాటర్న్ల (component patterns) కోసం ఒక డాక్యుమెంట్ను నిర్వహిస్తున్నాము. ఈ ప్యాటర్న్ల ఆధారంగా కొత్త కాంపోనెంట్ను నిర్మించమని మేము Lovableకి చెబుతాము. ఇది సెటప్ చేయడానికి కొంచెం నెమ్మదిగా ఉన్నప్పటికీ, నిర్వహించడం చాలా సులభం.
- చాట్ హిస్టరీని డాక్యుమెంటేషన్గా ఉపయోగించడం (Using chat history as documentation)
సాంకేతిక నిర్ణయాలను గుర్తుంచుకోవడానికి మేము Lovable చాట్ హిస్టరీపై ఆధారపడేవాళ్ళం. చాట్ లాగ్లు గందరగోళంగా ఉంటాయి. అవి విజయవంతమైన మార్పులను మరియు విఫలమైన ప్రయత్నాలను కలిపి ఉంచుతాయి. ఒక సుదీర్ఘమైన థ్రెడ్లో మార్పుకు గల నిర్దిష్ట కారణాన్ని కనుగొనడం కష్టం.
పరిష్కారం: మేము నిర్ణయాలను నమోదు చేసే ప్రక్రియను Linearకి మార్చాము. ఏమి మారింది మరియు ఎందుకు మారింది అనే అంశాన్ని Linearలో ఒకే ఒక లైన్లో రాస్తాము. Lovable చాట్ అనేది అమలు (execution) కోసం, Linear అనేది నిర్ణయాల (decisions) కోసం.
పాఠం చాలా సరళమైనది. 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