Lovable ಮತ್ತು Supabase ನಲ್ಲಿ 16 ಉತ್ಪನ್ನಗಳನ್ನು ನಡೆಸುವಾಗ ಆಗುವ ತಾಂತ್ರಿಕ ತಪ್ಪುಗಳು
ನಾವು Inithouse ನಲ್ಲಿ 16 ಉತ್ಪನ್ನಗಳನ್ನು ನಡೆಸುತ್ತಿದ್ದೇವೆ. ಅವೆಲ್ಲದಕ್ಕೂ ನಾವು Lovable ಮತ್ತು Supabase ಬಳಸುತ್ತೇವೆ. ಒಂದು ತಂಡವೇ ಎಲ್ಲವನ್ನೂ ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಕೇಳಲು ಚೆನ್ನಾಗಿರುತ್ತದೆ, ಆದರೆ ನೀವು 16 ಕಸ್ಟಮ್ ಡೊಮೇನ್ಗಳು (custom domains), 16 Supabase ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಮತ್ತು 16 edge functions ಸೆಟ್ಗಳನ್ನು ಎದುರಿಸುವವರೆಗೆ ಮಾತ್ರ.
ನಾವು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವಂತಹ ತಪ್ಪುಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ. ಇಲ್ಲಿ ಐದು ದೊಡ್ಡ ತಾಂತ್ರಿಕ ತಪ್ಪುಗಳು ಮತ್ತು ಅವುಗಳಿಗೆ ನಾವು ಕಂಡ ಪರಿಹಾರಗಳಿವೆ.
1. ಅಸಮಂಜಸವಾದ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾಗಳು (Inconsistent database schemas)
ನಮ್ಮ ಮೊದಲ ಮೂರು ಉತ್ಪನ್ನಗಳು ಒಂದೇ ರೀತಿಯ ಡೇಟಾಕ್ಕಾಗಿ ವಿಭಿನ್ನ ಟೇಬಲ್ ಹೆಸರುಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದವು. ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಅನಾಲಿಟಿಕ್ಸ್ (analytics) ಗಾಗಿ page_views ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು. ಇನ್ನೊಂದು analytics_events ಅನ್ನು ಬಳಸುತ್ತಿತ್ತು. ಇದರಿಂದ ಹಂಚಿಕೆಯ ಕೋಡ್ (shared code) ಬರೆಯುವುದು ಅಸಾಧ್ಯವಾಯಿತು. ಒಂದು ಮಧ್ಯಾಹ್ನದಲ್ಲಿ ಮುಗಿಸಬೇಕಾದ ಕೆಲಸಕ್ಕೆ ಎರಡು ವಾರಗಳು ಬೇಕಾದವು.
ಪರಿಹಾರ: ನಾವು ಒಂದು ಹಂಚಿಕೆಯ ಮೈಗ್ರೇಷನ್ ಟೆಂಪ್ಲೇಟ್ (shared migration template) ಅನ್ನು ನಿರ್ಮಿಸಿದೆವು. ಪ್ರತಿಯೊಂದು ಹೊಸ ಉತ್ಪನ್ನವು ಅನಾಲಿಟಿಕ್ಸ್, ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ಗಳು ಮತ್ತು auth ಗಾಗಿ ಒಂದೇ ರೀತಿಯ ಬೇಸ್ ಟೇಬಲ್ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ. ನಾವು ಕೆಲಸದ ಒತ್ತಡ ಕಡಿಮೆ ಇರುವ ವಾರಗಳಲ್ಲಿ ಹಳೆಯ ಪ್ರಾಜೆಕ್ಟ್ಗಳನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದೆವು. ಈಗ, ಒಂದು ಮಾನಿಟರಿಂಗ್ ಎಂಡ್ಪಾಯಿಂಟ್ (monitoring endpoint) ಅನ್ನು ಸೇರಿಸಲು ಒಂದು ದಿನದ ಬದಲಿಗೆ ಕೇವಲ 20 ನಿಮಿಷಗಳು ಸಾಕು.
2. ಕೆಟ್ಟುಹೋದ ಕಸ್ಟಮ್ ಡೊಮೇನ್ಗಳು (Broken custom domains)
Lovable ನೀವು ಕಸ್ಟಮ್ ಡೊಮೇನ್ಗಳನ್ನು ಕನೆಕ್ಟ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಕೆಲವೊಮ್ಮೆ ಡಿಪ್ಲಾಯ್ (deploy) ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಆದರೆ DNS ವೆರಿಫಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತದೆ. ಪ್ರಿವ್ಯೂ URL ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಲೈವ್ ಡೊಮೇನ್ ಖಾಲಿ ಪುಟವನ್ನು ತೋರಿಸುತ್ತದೆ. ನಾವು ಲೈವ್ URL ಅನ್ನು ಪರಿಶೀಲಿಸದ ಕಾರಣ ಮೂರು ದಿನಗಳ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಳೆದುಕೊಂಡೆವು.
ಪರಿಹಾರ: ನಾವು ಪೋಸ್ಟ್-ಪಬ್ಲಿಷ್ ಚೆಕ್ಲಿಸ್ಟ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಅದನ್ನು ಪರಿಶೀಲಿಸಲು ನಾವು ಪ್ರತಿಯೊಂದು ಲೈವ್ ಡೊಮೇನ್ ಅನ್ನು ಇನ್ಕಾಗ್ನಿಟೊ ವಿಂಡೋದಲ್ಲಿ (incognito window) ತೆರೆಯುತ್ತೇವೆ. ಡೊಮೇನ್ ವಿಫಲವಾದರೆ Slack ಗೆ ಸಂದೇಶ ಕಳುಹಿಸುವ ಅಪ್ಟೈಮ್ ಚೆಕ್ ಅನ್ನು (uptime check) ಕೂಡ ನಾವು ಸೇರಿಸಿದ್ದೇವೆ.
3. ಚದುರಿದ ಡೇಟಾ ದೃಶ್ಯೀಕರಣ (Fragmented data visibility)
ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳನ್ನು ತೆರೆಯದೆ ನಮ್ಮ ಇಡೀ ಪೋರ್ಟ್ಫೋಲಿಯೊ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನಮಗೆ ತಿಳಿಯುತ್ತಿರಲಿಲ್ಲ. ನಮಗೆ ಏನೂ ತಿಳಿಯದ ಸ್ಥಿತಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೆವು.
ಪರಿಹಾರ: ನಾವು ಪ್ರತಿಯೊಂದು Supabase ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಒಂದು stats API ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ನಿಯೋಜಿಸಿದೆವು. ಪ್ರತಿಯೊಂದು ಉತ್ಪನ್ನವು ಬಳಕೆದಾರರು ಮತ್ತು ಸೈನ್-ಅಪ್ಗಳಂತಹ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ಗಳನ್ನು (key metrics) ಪ್ರಮಾಣಿತ ಫಾರ್ಮ್ಯಾಟ್ನಲ್ಲಿ ಕಳುಹಿಸುತ್ತದೆ. ಒಂದು ಸಿಂಗಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಈ ಡೇಟಾವನ್ನು ಒಂದೇ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗೆ ತರುತ್ತದೆ.
4. ಘಟಕಗಳನ್ನು (components) ಕಾಪಿ-ಪೇಸ್ಟ್ ಮಾಡುವುದು
ನಾವು ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ React components ಕಾಪಿ ಮಾಡುತ್ತಿದ್ದೆವು. ಈ ಘಟಕಗಳು ಹಳೆಯ ಕಲ್ಪನೆಗಳನ್ನು ಹೊತ್ತು ತರುತ್ತಿದ್ದವು. ಒಂದು ಉತ್ಪನ್ನದ ಪ್ರೈಸಿಂಗ್ ಕಾರ್ಡ್ (pricing card) ಇನ್ನೊಂದರಲ್ಲಿ ವಿಫಲವಾಯಿತು ಏಕೆಂದರೆ ಅದು ವಿಭಿನ್ನ ಪೇಮೆಂಟ್ ಫ್ಲೋವನ್ನು ನಿರೀಕ್ಷಿಸಿತ್ತು. ಈ ಅಸ್ಪಷ್ಟ ಬಗ್ಗಳನ್ನು (phantom bugs) ಡಿಬಗ್ ಮಾಡಲು ನಾವು ದಿನಗಟ್ಟಲೆ ಕಳೆಯಬೇಕಾಯಿತು.
ಪರಿಹಾರ: ನಾವು ಕಾಪಿ-ಪೇಸ್ಟ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆವು. ನಾವು ಕಂಪೊನೆಂಟ್ ಪ್ಯಾಟರ್ನ್ಗಳ (component patterns) ದಾಖಲೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ. ಈ ಪ್ಯಾಟರ್ನ್ಗಳ ಆಧಾರದ ಮೇಲೆ ಹೊಸ ಕಂಪೊನೆಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ನಾವು Lovable ಗೆ ಸೂಚಿಸುತ್ತೇವೆ. ಇದನ್ನು ಸೆಟಪ್ ಮಾಡುವುದು ಸ್ವಲ್ಪ ನಿಧಾನವಾಗಿದ್ದರೂ, ನಿರ್ವಹಿಸುವುದು ತುಂಬಾ ಸುಲಭವಾಗಿದೆ.
5. ಚಾಟ್ ಇತಿಹಾಸವನ್ನು ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಆಗಿ ಬಳಸುವುದು
ತಾಂತ್ರಿಕ ನಿರ್ಧಾರಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ನಾವು Lovable ಚಾಟ್ ಇತಿಹಾಸವನ್ನು ಅವಲಂಬಿಸಿದ್ದೆವು. ಚಾಟ್ ಲಾಗ್ಗಳು ಅಸ್ತವ್ಯಸ್ತವಾಗಿರುತ್ತವೆ. ಅವು ಯಶಸ್ವಿ ಬದಲಾವಣೆಗಳನ್ನು ಮತ್ತು ವಿಫಲ ಪ್ರಯತ್ನಗಳನ್ನು ಬೆರೆಸಿರುತ್ತವೆ. ಉದ್ದವಾದ ಚಾಟ್ನಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಯ ಕಾರಣವನ್ನು ಹುಡುಕುವುದು ಕಷ್ಟ.
ಪರಿಹಾರ: ನಾವು ನಿರ್ಧಾರಗಳ ದಾಖಲಾತಿಯನ್ನು (decision logging) Linear ಗೆ ವರ್ಗಾಯಿಸಿದೆವು. ಏನನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ ಮತ್ತು ಏಕೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಒಂದು ಸಾಲನ್ನು ನಾವು Linear ನಲ್ಲಿ ಬರೆಯುತ್ತೇವೆ. Lovable ಚಾಟ್ ಕಾರ್ಯಗತಗೊಳಿಸಲು (execution), ಆದರೆ Linear ನಿರ್ಧಾರಗಳಿಗಾಗಿ.
ಪಾಠ ಸರಳವಾಗಿದೆ. 16 ಉತ್ಪನ್ನಗಳನ್ನು 16 ಪ್ರತ್ಯೇಕ ಪ್ರಾಜೆಕ್ಟ್ಗಳಂತೆ ಪರಿಗಣಿಸಬೇಡಿ. ಅವುಗಳನ್ನು ಒಂದೇ ಪೋರ್ಟ್ಫೋಲಿಯೊ ಎಂದು ಪರಿಗಣಿಸಿ. ನಿಮ್ಮ ಟೆಂಪ್ಲೇಟ್ಗಳನ್ನು ಪ್ರಮಾಣೀಕರಿಸಿ (standardize) ಮತ್ತು ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸ್ಥಳದಿಂದ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ.
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
Optional learning community: https://t.me/GyaanSetuAi