Lovable ਅਤੇ Supabase 'ਤੇ 16 ਪ੍ਰੋਡਕਟ ਚਲਾਉਣ ਦੀਆਂ ਤਕਨੀਕੀ ਗਲਤੀਆਂ
ਅਸੀਂ Inithouse ਵਿਖੇ 16 ਪ੍ਰੋਡਕਟ ਚਲਾਉਂਦੇ ਹਾਂ। ਅਸੀਂ ਉਹਨਾਂ ਸਾਰਿਆਂ ਲਈ Lovable ਅਤੇ Supabase ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇੱਕ ਹੀ ਟੀਮ ਸਭ ਕੁਝ ਸੰਭਾਲਦੀ ਹੈ। ਇਹ ਸੁਣਨ ਵਿੱਚ ਤਾਂ ਵਧੀਆ ਲੱਗਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ 16 ਕਸਟਮ ਡੋਮੇਨ (custom domains), 16 Supabase ਪ੍ਰੋਜੈਕਟ ਅਤੇ edge functions ਦੇ 16 ਸੈੱਟਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਥਿਤੀ ਬਦਲ ਜਾਂਦੀ ਹੈ।
ਅਸੀਂ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਕੀਤੀਆਂ ਜਿਨ੍ਹਾਂ ਕਾਰਨ ਸਾਡਾ ਸਮਾਂ ਬਰਬਾਦ ਹੋਇਆ। ਇੱਥੇ ਪੰਜ ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਤਕਨੀਕੀ ਗਲਤੀਆਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਹੱਲ ਦਿੱਤੇ ਗਏ ਹਨ।
- ਅਸੰਗਤ (Inconsistent) ਡਾਟਾਬੇਸ ਸਕੀਮਾਵਾਂ
ਸਾਡੇ ਪਹਿਲੇ ਤਿੰਨ ਪ੍ਰੋਡਕਟ ਇੱਕੋ ਜਿਹੇ ਡਾਟਾ ਲਈ ਵੱਖ-ਵੱਖ ਟੇਬਲ ਨਾਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਨ। ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਐਨਾਲਿਟਿਕਸ (analytics) ਲਈ page_views ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਸੀ। ਦੂਜੇ ਵਿੱਚ analytics_events ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਸੀ। ਇਸ ਕਾਰਨ ਸਾਂਝਾ ਕੋਡ (shared code) ਲਿਖਣਾ ਅਸੰਭਵ ਹੋ ਗਿਆ। ਇੱਕ ਕੰਮ ਜੋ ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਉਸ ਵਿੱਚ ਦੋ ਹਫ਼ਤੇ ਲੱਗ ਗਏ।
ਹੱਲ: ਅਸੀਂ ਇੱਕ ਸਾਂਝਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੈਂਪਲੇਟ (shared migration template) ਤਿਆਰ ਕੀਤਾ। ਹਰ ਨਵੇਂ ਪ੍ਰੋਡਕਟ ਲਈ ਐਨਾਲਿਟਿਕਸ, ਬਲੌਗ ਪੋਸਟਾਂ ਅਤੇ auth ਲਈ ਇੱਕੋ ਜਿਹੇ ਬੇਸ ਟੇਬਲ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਅਸੀਂ ਸ਼ਾਂਤ ਹਫ਼ਤਿਆਂ ਦੌਰਾਨ ਪੁਰਾਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਇਸ ਅਨੁਸਾਰ ਢਾਲਿਆ। ਹੁਣ, ਇੱਕ ਮਾਨੀਟਰਿੰਗ ਐਂਡਪੁਆਇੰਟ (monitoring endpoint) ਜੋੜਨ ਵਿੱਚ ਇੱਕ ਦਿਨ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ 20 ਮਿੰਟ ਲੱਗਦੇ ਹਨ।
- ਖਰਾਬ ਕਸਟਮ ਡੋਮੇਨ (Broken custom domains)
Lovable ਤੁਹਾਨੂੰ ਕਸਟਮ ਡੋਮੇਨ ਜੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਕਈ ਵਾਰ ਡਿਪਲਾਈ (deploy) ਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ ਪਰ DNS ਵੈਰੀਫਿਕੇਸ਼ਨ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ। ਪ੍ਰੀਵਿਊ URL ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਲਾਈਵ ਡੋਮੇਨ 'ਤੇ ਇੱਕ ਖਾਲੀ ਪੇਜ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਅਸੀਂ ਲਾਈਵ URL ਦੀ ਜਾਂਚ ਨਾ ਕਰਨ ਕਾਰਨ ਤਿੰਨ ਦਿਨਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਗੁਆ ਦਿੱਤਾ।
ਹੱਲ: ਅਸੀਂ ਪਬਲਿਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦੀ ਇੱਕ ਚੈੱਕਲਿਸਟ (post-publish checklist) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਹਰ ਲਾਈਵ ਡੋਮੇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਉਸਨੂੰ ਇੱਕ ਇਨਕੋਗਨੀਟੋ (incognito) ਵਿੰਡੋ ਵਿੱਚ ਖੋਲ੍ਹਦੇ ਹਾਂ। ਅਸੀਂ ਇੱਕ ਅਪਟਾਈਮ ਚੈੱਕ (uptime check) ਵੀ ਜੋੜਿਆ ਹੈ ਜੋ ਡੋਮੇਨ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ Slack ਨੂੰ ਪਿੰਗ (ping) ਕਰਦਾ ਹੈ।
- ਖਿੰਡੀ ਹੋਈ ਡਾਟਾ ਵਿਜ਼ੀਬਿਲਟੀ (Fragmented data visibility)
ਅਸੀਂ ਹਰ ਪ੍ਰੋਡਕਟ ਲਈ ਵੱਖਰੇ ਡੈਸ਼ਬੋਰਡ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਇਹ ਨਹੀਂ ਦੇਖ ਸਕਦੇ ਸੀ ਕਿ ਸਾਡਾ ਪੂਰਾ ਪੋਰਟਫੋਲੀਓ ਕਿਵੇਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਸਾਨੂੰ ਕੁਝ ਵੀ ਸਾਫ਼ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਿਹਾ ਸੀ।
ਹੱਲ: ਅਸੀਂ ਹਰ Supabase ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੱਕ ਸਟੈਟਸ API ਐਂਡਪੁਆਇੰਟ (stats API endpoint) ਡਿਪਲਾਈ ਕੀਤਾ। ਹਰ ਪ੍ਰੋਡਕਟ ਯੂਜ਼ਰਸ ਅਤੇ ਸਾਈਨਅੱਪਸ ਵਰਗੇ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ (key metrics) ਇੱਕ ਸਟੈਂਡਰਡ ਫਾਰਮੈਟ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਇੱਕ ਸਿੰਗਲ ਸਕ੍ਰਿਪਟ ਇਸ ਡਾਟਾ ਨੂੰ ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਇਕੱਠਾ ਕਰ ਲੈਂਦੀ ਹੈ।
- ਕੰਪੋਨੈਂਟਸ ਦੀ ਕਾਪੀ-ਪੇਸਟਿੰਗ (Copy-pasting components)
ਅਸੀਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਦੂਜੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ React ਕੰਪੋਨੈਂਟਸ ਕਾਪੀ ਕਰਦੇ ਸਨ। ਇਹ ਕੰਪੋਨੈਂਟਸ ਪੁਰਾਣੀਆਂ ਧਾਰਨਾਵਾਂ ਨਾਲ ਆਉਂਦੇ ਸਨ। ਇੱਕ ਪ੍ਰੋਡਕਟ ਦਾ ਪ੍ਰਾਈਸਿੰਗ ਕਾਰਡ ਦੂਜੇ ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ ਕਿਉਂਕਿ ਉਹ ਇੱਕ ਵੱਖਰੇ ਪੇਮੈਂਟ ਫਲੋ (payment flow) ਦੀ ਉਮੀਦ ਕਰ ਰਿਹਾ ਸੀ। ਅਸੀਂ ਇਹਨਾਂ ਅਣਜਾਣ ਬੱਗਾਂ (phantom bugs) ਨੂੰ ਠੀਕ ਕਰਨ ਵਿੱਚ ਕਈ ਦਿਨ ਬਿਤਾਏ।
ਹੱਲ: ਅਸੀਂ ਕਾਪੀ-ਪੇਸਟ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਅਸੀਂ ਕੰਪੋਨੈਂਟ ਪੈਟਰਨਾਂ (component patterns) ਦਾ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਰੱਖਦੇ ਹਾਂ। ਅਸੀਂ Lovable ਨੂੰ ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਇੱਕ ਨਵਾਂ ਕੰਪੋਨੈਂਟ ਬਣਾਉਣ ਲਈ ਕਹਿੰਦੇ ਹਾਂ। ਇਸ ਨੂੰ ਸੈੱਟਅੱਪ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਜ਼ਿਆਦਾ ਲੱਗਦਾ ਹੈ ਪਰ ਇਸ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ।
- ਚੈਟ ਹਿਸਟਰੀ ਨੂੰ ਡਾਕੂਮੈਂਟੇਸ਼ਨ ਵਜੋਂ ਵਰਤਣਾ
ਅਸੀਂ ਤਕਨੀਕੀ ਫੈਸਲਿਆਂ ਨੂੰ ਯਾਦ ਰੱਖਣ ਲਈ Lovable ਚੈਟ ਹਿਸਟਰੀ 'ਤੇ ਨਿਰਭਰ ਸੀ। ਚੈਟ ਲੌਗਸ ਬਹੁਤ ਉਲਝਣ ਵਾਲੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਸਫਲ ਬਦਲਾਅਾਂ ਨੂੰ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ ਨਾਲ ਮਿਲਾ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਲੰਬੀ ਥ੍ਰੈਡ ਵਿੱਚ ਕਿਸੇ ਬਦਲਾਅ ਦਾ ਖਾਸ ਕਾਰਨ ਲੱਭਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
ਹੱਲ: ਅਸੀਂ ਫੈਸਲਿਆਂ ਦੀ ਲੌਗਿੰਗ (decision logging) ਨੂੰ Linear 'ਤੇ ਸ਼ਿਫਟ ਕਰ ਦਿੱਤਾ। ਅਸੀਂ Linear ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਲਿਖਦੇ ਹਾਂ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ। Lovable ਚੈਟ ਕਾਰਜਕਾਰੀ (execution) ਲਈ ਹੈ, ਜਦਕਿ 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