Lovable-ലും Supabase-ലും 16 ഉൽപ്പന്നങ്ങൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ സംഭവിക്കുന്ന സാങ്കേതിക പിഴവുകൾ

Inithouse-ൽ ഞങ്ങൾ 16 ഉൽപ്പന്നങ്ങളാണ് പ്രവർത്തിപ്പിക്കുന്നത്. ഇവയ്‌ക്കെല്ലാം ഞങ്ങൾ Lovable-ഉം Supabase-ഉം ആണ് ഉപയോഗിക്കുന്നത്. ഒരു ടീം തന്നെ എല്ലാം നിയന്ത്രിക്കുന്നു. കേൾക്കുമ്പോൾ ഇത് നല്ലതാണെന്ന് തോന്നാം, എന്നാൽ 16 കസ്റ്റം ഡൊമൈനുകൾ (custom domains), 16 Supabase പ്രോജക്റ്റുകൾ, 16 എഡ്ജ് ഫംഗ്ഷനുകൾ (edge functions) എന്നിവ കൈകാര്യം ചെയ്യേണ്ടി വരുമ്പോൾ സാഹചര്യം മാറുന്നു.

ഞങ്ങളുടെ സമയം നഷ്ടപ്പെടുത്തിയ ചില തെറ്റുകൾ ഞങ്ങൾ വരുത്തിയിട്ടുണ്ട്. ഏറ്റവും വലിയ അഞ്ച് സാങ്കേതിക പിഴവുകളും അവ പരിഹരിച്ച രീതികളും താഴെ നൽകുന്നു.

1. അസ്ഥിരമായ ഡാറ്റാബേസ് സ്കീമകൾ (Inconsistent database schemas)

ഞങ്ങളുടെ ആദ്യത്തെ മൂന്ന് ഉൽപ്പന്നങ്ങളും ഒരേ ഡാറ്റയ്ക്ക് വ്യത്യസ്ത ടേബിൾ പേരുകളാണ് ഉപയോഗിച്ചിരുന്നത്. ഒരു പ്രോജക്റ്റിൽ അനലിറ്റിക്സിനായി page_views എന്നും മറ്റൊന്നിൽ analytics_events എന്നും ഉപയോഗിച്ചു. ഇത് കോഡ് പങ്കിടുന്നത് (shared code) അസാധ്യമാക്കി. ഒരു ഉച്ചതിരിഞ്ഞ് തീർക്കാവുന്ന ഒരു ജോലി പൂർത്തിയാക്കാൻ രണ്ടാഴ്ചയോളം എടുത്തു.

പരിഹാരം: ഞങ്ങൾ ഒരു ഷെയർഡ് മൈഗ്രേഷൻ ടെംപ്ലേറ്റ് (shared migration template) നിർമ്മിച്ചു. ഓരോ പുതിയ ഉൽപ്പന്നത്തിനും അനലിറ്റിക്സ്, ബ്ലോഗ് പോസ്റ്റുകൾ, ഓതന്റിക്കേഷൻ (auth) എന്നിവയ്ക്കായി ഒരേ അടിസ്ഥാന ടേബിളുകൾ ലഭിക്കുന്നു. തിരക്കില്ലാത്ത ആഴ്ചകളിൽ പഴയ പ്രോജക്റ്റുകളും ഞങ്ങൾ ഇതുപോലെ പരിഷ്കരിച്ചു. ഇപ്പോൾ, ഒരു മോണിറ്ററിംഗ് എൻഡ്പോയിന്റ് (monitoring endpoint) ചേർക്കാൻ ഒരു ദിവസം വേണ്ടിവരുന്നതിന് പകരം വെറും 20 മിനിറ്റ് മതിയാകും.

2. തകരാറിലായ കസ്റ്റം ഡൊമൈനുകൾ (Broken custom domains)

കസ്റ്റം ഡൊമൈനുകൾ കണക്ട് ചെയ്യാൻ Lovable അനുവദിക്കുന്നു. ചിലപ്പോൾ ഡെപ്ലോയ്മെന്റ് (deploy) വിജയകരമാകും, പക്ഷേ DNS വെരിഫിക്കേഷൻ പരാജയപ്പെടും. പ്രിവ്യൂ URL പ്രവർത്തിക്കും, എന്നാൽ ലൈവ് ഡൊമൈൻ ഒരു ബ്ലാങ്ക് പേജ് മാത്രമായിരിക്കും കാണിക്കുക. ലൈവ് URL പരിശോധിക്കാത്തതിനാൽ ഞങ്ങൾക്ക് മൂന്ന് ദിവസത്തെ ട്രാഫിക് നഷ്ടമായി.

പരിഹാരം: ഞങ്ങൾ ഒരു പോസ്റ്റ്-പബ്ലിഷ് ചെക്ക്‌ലിസ്റ്റ് (post-publish checklist) ഉപയോഗിക്കുന്നു. ഓരോ ലൈവ് ഡൊമൈനും ഇൻകോഗ്നിറ്റോ വിൻഡോയിൽ (incognito window) തുറന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു. കൂടാതെ, ഒരു ഡൊമൈൻ പരാജയപ്പെട്ടാൽ Slack-ലേക്ക് സന്ദേശം അയക്കുന്ന ഒരു അപ്‌ടൈം ചെക്കും (uptime check) ഞങ്ങൾ ചേർത്തു.

3. ചിതറിക്കിടക്കുന്ന ഡാറ്റാ വിസിബിലിറ്റി (Fragmented data visibility)

ഓരോ ഉൽപ്പന്നത്തിനും പ്രത്യേക ഡാഷ്‌ബോർഡുകൾ തുറക്കാതെ തന്നെ ഞങ്ങളുടെ മുഴുവൻ പോർട്ട്‌ഫോളിയോയുടെയും പ്രവർത്തനം അറിയാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞിരുന്നില്ല. വിവരങ്ങളില്ലാതെ ഞങ്ങൾ പ്രവർത്തിക്കുകയായിരുന്നു.

പരിഹാരം: ഞങ്ങൾ ഓരോ Supabase പ്രോജക്റ്റിലും ഒരു സ്റ്റാറ്റ്‌സ് API എൻഡ്പോയിന്റ് (stats API endpoint) വിന്യസിച്ചു. ഓരോ ഉൽപ്പന്നവും ഉപയോക്താക്കളുടെ എണ്ണം, സൈൻഅപ്പുകൾ തുടങ്ങിയ പ്രധാന വിവരങ്ങൾ ഒരു സ്റ്റാൻഡേർഡ് ഫോർമാറ്റിൽ അയക്കുന്നു. ഒരു സിംഗിൾ സ്ക്രിപ്റ്റ് ഉപയോഗിച്ച് ഈ ഡാറ്റയെല്ലാം ഒരൊറ്റ ഡാഷ്‌ബോർഡിലേക്ക് എത്തിക്കുന്നു.

4. കമ്പോൺന്റുകൾ കോപ്പി-പേസ്റ്റ് ചെയ്യുന്നത് (Copy-pasting components)

ഞങ്ങൾ ഒരു പ്രോജക്റ്റിൽ നിന്നുള്ള React കമ്പോൺന്റുകൾ മറ്റൊന്നിലേക്ക് കോപ്പി ചെയ്യാറുണ്ടായിരുന്നു. ഈ കമ്പോൺന്റുകൾ പഴയ രീതിയിലുള്ള സങ്കൽപ്പങ്ങൾ ഉൾക്കൊള്ളുന്നവയായിരുന്നു. ഒരു ഉൽപ്പന്നത്തിലെ പ്രൈസിംഗ് കാർഡ് (pricing card) മറ്റൊരു ഉൽപ്പന്നത്തിൽ പ്രവർത്തിക്കാത്തത് വ്യത്യസ്തമായ പേയ്‌മെന്റ് ഫ്ലോ (payment flow) പ്രതീക്ഷിച്ചത് കൊണ്ടാണ്. ഇത്തരം അദൃശ്യമായ ബഗുകൾ (phantom bugs) പരിഹരിക്കാൻ ഞങ്ങൾ ദിവസങ്ങൾ ചിലവഴിച്ചു.

പരിഹാരം: ഞങ്ങൾ കോപ്പി-പേസ്റ്റ് ചെയ്യുന്നത് നിർത്തി. പകരം കമ്പോൺന്റ് പാറ്റേണുകളുടെ (component patterns) ഒരു ഡോക്യുമെന്റ് ഞങ്ങൾ സൂക്ഷിക്കുന്നു. ഈ പാറ്റേണുകൾ അടിസ്ഥാനമാക്കി പുതിയ കമ്പോൺന്റുകൾ നിർമ്മിക്കാൻ ഞങ്ങൾ Lovable-നോട് ആവശ്യപ്പെടുന്നു. ഇത് സെറ്റപ്പ് ചെയ്യാൻ അല്പം സമയം എടുക്കുമെങ്കിലും പരിപാലിക്കാൻ വളരെ എളുപ്പമാണ്.

5. ചാറ്റ് ഹിസ്റ്ററി ഡോക്യുമെന്റേഷനായി ഉപയോഗിക്കുന്നത് (Using chat history as documentation)

സാങ്കേതിക തീരുമാനങ്ങൾ ഓർത്തെടുക്കാൻ ഞങ്ങൾ Lovable ചാറ്റ് ഹിസ്റ്ററിയെയാണ് ആശ്രയിച്ചിരുന്നത്. ചാറ്റ് ലോഗുകൾ പലപ്പോഴും കുഴപ്പമുള്ളവയാണ്. അവയിൽ വിജയകരമായ മാറ്റങ്ങളും പരാജയപ്പെട്ട ശ്രമങ്ങളും കലർന്നു കിടക്കുന്നു. നീളമുള്ള ഒരു ചാറ്റിൽ നിന്ന് ഒരു പ്രത്യേക മാറ്റത്തിന്റെ കാരണം കണ്ടെത്തുക എന്നത് പ്രയാസകരമാണ്.

പരിഹാരം: ഞങ്ങൾ തീരുമാനങ്ങൾ രേഖപ്പെടുത്തുന്നത് Linear-ലേക്ക് മാറ്റി. എന്താണ് മാറ്റം വരുത്തിയതെന്നും എന്തുകൊണ്ട് എന്ന് വിവരിക്കുന്ന ഒരു വരി Linear-ൽ ഞങ്ങൾ എഴുതുന്നു. Lovable ചാറ്റ് എന്നത് കാര്യങ്ങൾ നടപ്പിലാക്കാൻ വേണ്ടിയുള്ളതാണ്, എന്നാൽ 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