Makosa ya Kiufundi ya Kuendesha Bidhaa 16 kwenye Lovable na Supabase
Tunasimamia bidhaa 16 hapa Inithouse. Tunatumia Lovable na Supabase kwa bidhaa zote. Timu moja inasimamia kila kitu. Hii inaonekana vizuri mpaka unapokabiliana na custom domains 16, miradi 16 ya Supabase, na seti 16 za edge functions.
Tulifanya makosa yaliyotupotezea muda. Hapa kuna makosa matano makubwa ya kiufundi na jinsi tulivyoyarekebisha.
- Database schemas zisizo na msimamo
Bidhaa zetu tatu za kwanza zilitumia majina tofauti ya majedwali (tables) kwa data ileile. Mradi mmoja ulitumia page_views kwa ajili ya analytics. Mwingine ulitumia analytics_events. Hii ilifanya iwe vigumu kuandika shared code. Kazi ambayo ingepaswa kuchukua mchana mmoja ilichukua wiki mbili.
Suluhisho: Tulitengeneza shared migration template. Kila bidhaa mpya hupata base tables zinazofanana kwa ajili ya analytics, blog posts, na auth. Tulirekebisha miradi ya zamani wakati wa wiki zenye kazi kidogo. Sasa, kuongeza monitoring endpoint inachukua dakika 20 badala ya siku nzima.
- Custom domains zinazofeli
Lovable inakuwezesha kuunganisha custom domains. Wakati mwingine deploy inafanikiwa lakini DNS verification inashindwa. Preview URL inafanya kazi, lakini live domain inaonyesha ukurasa mtupu. Tulipoteza trafiki ya siku tatu kwa sababu hatukukagua live URL.
Suluhisho: Tunatumia post-publish checklist. Tunafungua kila live domain kwenye incognito window ili kuikagua. Pia tumeongeza uptime check ambayo inatuma ujumbe Slack ikiwa domain itafeli.
- Data visibility iliyogawanyika
Hatukuweza kuona jinsi portfolio yetu nzima inavyofanya kazi bila kufungua dashboard tofauti kwa kila bidhaa. Tulikuwa tunatembea gizani.
Suluhisho: Tulituma stats API endpoint kwenye kila mradi wa Supabase. Kila bidhaa hutuma key metrics kama vile watumiaji na signups katika muundo wa kawaida. Script moja inavuta data hii na kuiweka kwenye dashboard moja.
- Kunakili na kubandika components
Zamani tulikuwa tunanakili React components kutoka mradi mmoja kwenda mwingine. Components hizi zilikuwa na dhana za zamani. Kadi ya bei (pricing card) kutoka bidhaa moja ilifeli kwenye nyingine kwa sababu ilitarajia mtiririko tofauti wa malipo. Tulitumia siku nyingi kufanya debugging ya hitilafu hizi zisizoonekana.
Suluhisho: Tuliacha kunakili na kubandika. Tunatunza hati ya component patterns. Tunaiambia Lovable itengeneze component mpya kulingana na mifumo hii. Inachukua muda mrefu zaidi kuanzisha lakini ni rahisi zaidi kudumisha.
- Kutumia chat history kama documentation
Tulitegemea Lovable chat history kukumbuka maamuzi ya kiufundi. Chat logs ni zilizochanganyika. Zinachanganya mabadiliko yaliyofanikiwa na majaribio yaliyofeli. Ni vigumu kupata sababu maalum ya mabadiliko katika thread ndefu.
Suluhisho: Tulihamishia decision logging kwenye Linear. Tunaandika mstari mmoja kwenye Linear tukielezea nini kimebadilika na kwa nini. Lovable chat ni kwa ajili ya utekelezaji. Linear ni kwa ajili ya maamuzi.
Somo ni rahisi. Usichukulie bidhaa 16 kama miradi 16 tofauti. Zichukulie kama portfolio moja. Weka viwango vya templates zako na ufuatilie kila kitu kutoka sehemu moja.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi