Go for Cloud Infrastructure: ਸਾਦਾ ਡਿਜ਼ਾਇਨ, ਸਕੇਲ, ਅਤੇ ਸਟਾਰਟਅਪ ਗਤੀ

ਕਿਉਂ ਸਟਾਰਟਅਪਸ Go ਨੂੰ ਅਕਸਰ ਚੁਣਦੇ ਹਨ

ਸਟਾਰਟਅਪਸ ਕਿਸੇ ਕੋਡ ਲਿਖਣ ਦੀ ਘੱਟੀ ਕਾਰਨ ਨਹੀਂ ਫੇਲ ਹੁੰਦੇ—ਉਹ ਇਸ ਲਈ ਮੁੱਸ਼ਕਿਲੀ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਇੱਕ ਛੋਟੀ ਟੀਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਸਰਵਿਸਿਜ਼ ਉਤਾਰਣੀਆਂ, ਇਨਸੀਡੈਂਟਸ ਠੀਕ ਕਰਨੀਆਂ, ਅਤੇ ਫੀਚਰ ਐਡ ਕਰਦੇ ਰਹਿਣੇ ਪੈਂਦੇ ਹਨ। ਹਰ ਇਕ ਵਾਧੂ ਬਿਲਡ ਸਟੈਪ, ਅਸਪਸ਼ਟ ਡਿਪੈਂਡੈਂਸੀ ਜਾਂ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ concurrency ਬੱਗ ਡੈਡਲਾਈਨਾਂ ਛੱਡਣ ਅਤੇ ਰਾਤ ਦੇ ਪੇਜਿੰਗ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ।

Go ਇਨ੍ਹਾਂ ਮਾਹੌਲਾਂ ਵਿੱਚ ਮੁੜ-ਮੁੜ ਆਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਲਾਉਡ ਸਰਵਿਸਿਜ਼ ਦੀ ਰੋਜ਼ਾਨਾ ਹਕੀਕਤ ਲਈ ਟਿਊਨ ਕੀਤਾ ਗਿਆ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਪ੍ਰੋਗਰਾਮ, ਅਕਸਰ ਡਿਪਲੌਇਮੈਂਟ, ਅਤੇ APIs, ਕਿਊਜ਼ ਅਤੇ ਡੇਟਾਬੇਸਾਂ ਨਾਲ ਲਗਾਤਾਰ ਇੰਟੈਗਰੇਸ਼ਨ।

ਤਿੰਨ ਕਾਰਨ ਕਿ ਇਹ ਸਟਾਰਟਅਪ ਜੀਵਨ ਨਾਲ ਫਿੱਟ ਹੁੰਦਾ ਹੈ

ਪਹਿਲਾਂ, ਕਲਾਉਡ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਫਿੱਟ: Go ਨੈਟਵਰਕਡ ਸੌਫਟਵੇਅਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣਾਇਆ ਗਿਆ, ਇਸ ਲਈ HTTP ਸਰਵਿਸਿਜ਼, CLI ਅਤੇ ਪਲੇਟਫਾਰਮ ਟੂਲਿੰਗ ਲਿਖਣਾ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਹ ਡਿਪਲੌਇਅਬਲ ਆਰਟੀਫੈਕਟ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਕੰਟੇਨਰ ਅਤੇ Kubernetes ਨਾਲ ਅਸਾਨੀ ਨਾਲ ਚਲਦੇ ਹਨ।

ਦੂਜਾ, ਸਾਦਗੀ: ਭਾਸ਼ਾ ਟੀਮਾਂ ਨੂੰ ਪਾਠਯੋਗ, ਸਥਿਰ ਕੋਡ ਵੱਲ ਧਕੇਲਦੀ ਹੈ। ਇਸ ਨਾਲ “ਟ੍ਰਾਇਬਲ ਨੋਲੇਜ” ਘਟਦੀ ਹੈ ਅਤੇ ਜਦੋਂ ਟੀਮ ਵਧਦੀ ਹੈ ਜਾਂ ਆਨ-ਕਾਲ ਘੁੰਮਦੀ ਹੈ ਤਾਂ onboarding ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।

ਤੀਜਾ, ਸਕੇਲ: Go ਬਿਨਾਂ ਅਜੀਬ ਫ੍ਰੇਮਵਰਕਾਂ ਦੇ ਉੱਚ concurrency ਨੂੰ ਹੇਅਰਾਨੀ ਰਹਿਤ ਸੰਭਾਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਤਪਾਦ ਵਿੱਚ ਅਕਸਰ ਪੇਸ਼ਗੋਈਯੋਗ ਵਰਤੋਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਕੇਲ ਕਰ ਰਹੇ ਹੋ ਪਰ headcount ਨਹੀਂ ਵਧਾ ਰਹੇ, ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇੱਕ ਹਕੀਕਤੀ ਉਮੀਦ

Go ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼, APIs, ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਟੂਲਿੰਗ ਅਤੇ ਉਹਨਾਂ ਸਿਸਟਮਾਂ ਲਈ ਚਮਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਪਸ਼ਟ ਆਪਰੇਸ਼ਨਲ ਵਿਹਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ UI-ਭਾਰੀ ਐਪਾਂ, ਤੇਜ਼ ਡੇਟਾ ਸਾਇੰਸ ਇਟਰੇਸ਼ਨ ਜਾਂ ਉਹਨਾਂ ਡੋਮੇਨਾਂ ਵਿੱਚ ਜਿੱਥੇ ਇੱਕ ਪੱਕਾ, ਵਿਸ਼ੇਸ਼ ਇਕੋਸਿਸਟਮ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਇਸ ਗਾਈਡ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਵੇਖਾਏਗਾ ਕਿ Go ਦਾ ਡਿਜ਼ਾਇਨ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕਿੱਥੇ ਮਦਦ ਕਰਦਾ ਹੈ—ਅਤੇ ਕਿਵੇਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਇਹ ਤੁਹਾਡੇ ਸਟਾਰਟਅਪ ਦੀ ਅਗਲੀ ਸਰਵਿਸ ਲਈ ਸਹੀ ਬੈਟ ਹੈ ਜਾਂ ਨਹੀਂ।

Go ਕੀ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ

Go ਕਿਸੇ “ਬੇਹਤਰ ਸਕ੍ਰਿਪਟਿੰਗ ਭਾਸ਼ਾ” ਜਾਂ ਨਿਸ਼ਚਿਤ ਅਕਾਦਮਿਕ ਪ੍ਰੋਜੈਕਟ ਵਜੋਂ ਬਣਾਇਆ ਨਹੀਂ ਗਿਆ ਸੀ। ਇਹ Google ਦੇ اندر ਉਹਨਾਂ ਇੰਜੀਨੀਅਰਾਂ ਨੇ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਜਿਹੜੇ ਧੀਮੀ ਬਣਨ, ਜਟਿਲ ਡਿਪੈਂਡੈਂਸੀ ਚੇਨ ਅਤੇ ਕੋਡਬੇਸਾਂ ਤੋਂ ਥੱਕ ਚੁੱਕੇ ਸਨ ਜੋ ਟੀਮਾਂ ਦੇ ਵਧਣ ਨਾਲ ਬਦਲਣ ਵਿੱਚ ਔਖੇ ਹੋ ਜਾਦੇ ਸਨ। ਨਿਸ਼ਾਨਾ ਸਪਸ਼ਟ ਸੀ: ਵੱਡੇ ਪੈਮਾਨੇ ਤੇ ਨੈਟਵਰਕਡ ਸਰਵਿਸਿਜ਼ ਜੋ ਲਗਾਤਾਰ ਬਣਾਈਆਂ, ਸ਼ਿਪ ਕੀਤੀਆਂ ਅਤੇ ਚਲਾਈਆਂ ਜਾ ਸਕਣ।

ਮੂਲ ਲਕਸ਼: ਗਤੀ, ਸਾਦਗੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ

Go ਕੁਝ ਪ੍ਰਯੋਗਿਕ ਨਤੀਜਿਆਂ ਲਈ ਅਪਟੀਮਾਈਜ਼ کرتا ਹੈ ਜੋ ਰੋਜ਼ਾਨਾ ਕਲਾਉਡ ਸਿਸਟਮ ਚਲਾਉਣ ਵੇਲੇ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ:

• ਭਾਸ਼ਾ ਵਿੱਚ ਸਾਦਗੀ ਤਾਂ ਜੋ ਟੀਮਾਂ ਇੱਕੋ ਕੋਡ ਸਾਂਝਾ ਕਰ ਸਕਣ, ਤੇਜ਼ੀ ਨਾਲ ਰਿਵਿਊ ਕਰ ਸਕਣ, ਅਤੇ “ਚਤੁਰ” ਪੈਟਰਨਾਂ ਤੋਂ ਬਚਣਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਿਰਫ ਕੁਝ ਹੀ ਲੋਕ ਸਮਝਦੇ ਹਨ।
• ਫਾਸਟ ਕੰਪਾਇਲੇਸ਼ਨ ਤਾਂ ਜੋ ਫੀਡਬੈਕ ਲੂਪ ਘਟ ਰਹੇ। ਜਦੋਂ ਬਿਲਡ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ, ਤੁਸੀਂ ਵੱਧ ਅਕਸਰ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਜਲਦੀ ਰਿਫੈਕਟਰ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਆਰਕੀਟੈਕਚਰ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਠੀਕ ਕਰ ਲੈਂਦੇ ਹੋ।
• ਸੁਰੱਖਿਅਤ concurrency ਇਕ ਮੁੱਖ ਚਿੰਤਾ ਵਜੋਂ। Go ਅਨੁਮਾਨ ਲਗਾਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਨੈਟਵਰਕ ਨਾਲ ਗੱਲ ਕਰੇਗਾ, I/O 'ਤੇ ਰੁਕਵੇਂਗਾ, ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਇੱਕ ਨੂੰ ਇੱਕ ਸਮੇਂ ਸੰਭਾਲੇਗਾ।
• ਡਿਫੋਲਟ ਤੌਰ 'ਤੇ ਮਜ਼ਬੂਤ ਟੂਲਿੰਗ—formatter, tests, dependency management, profiling—ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੂਲਚੇਨ ਬਣਾਉਣ ਵਿੱਚ ਘੰਟੇ ਨਾ ਗੁਜ਼ਾਰੋਂ ਅਤੇ ਡਿਲਿਵਰੀ 'ਤੇ ਧਿਆਨ ਰੱਖੋ।

"ਕਲਾਉਡ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ" ਦਾ ਅਰਥ ਕੀ ਹੈ

ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਕਲਾਉਡ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ” ਸਿਰਫ ਸਰਵਰ ਅਤੇ Kubernetes ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਸੌਫਟਵੇਅਰ ਹੈ ਜੋ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ ਅਤੇ ਆਪਣੇ ਉਤਪਾਦ ਨੂੰ ਚਲਾਉਣ ਲਈ ਨਿਰਭਰ ਹੋ:

• ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼ ਅਤੇ APIs (REST/gRPC) ਜੋ ਬੇਨਣੁਤੀ ਸਮਭਾਲਦੇ ਹਨ ਅਤੇ ਬਿਜਨੈੱਸ ਲੌਜਿਕ ਚਲਾਉਂਦੇ ਹਨ
• ਅੰਦਰੂਨੀ ਟੂਲਿੰਗ ਜਿਵੇਂ CLIs, ਮਾਈਗ੍ਰੇਸ਼ਨ ਟੂਲ ਅਤੇ ਐਡਮਿਨ ਸਰਵਿਸੇਜ਼
• ਆਟੋਮੇਸ਼ਨ ਡਿਪਲੌਇਮੈਂਟ, ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਅਤੇ ਨਿਯਤ ਜੌਬਜ਼ ਲਈ
• ਪਲੇਟਫਾਰਮ ਕੰਪੋਨੈਂਟਸ ਜਿਵੇਂ controllers, operators, ਅਤੇ service meshes

Go ਇਹ ਕਿਸਮ ਦੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਬਿਨਾਂ ਰੁਕਾਵਟ ਦੇ ਬਣਾਉਣ, ਚਲਾਉਣ ਅਤੇ ਮਾਇੰਟੇਨ ਕਰਨ ਲਈ ਬਣਾ ਹੈ: ਸਿੱਧਾ ਬਣਾਇਆ, ਪੇਸ਼ਗੋਈਯੋਗ ਚੱਲਦਾ, ਅਤੇ ਜਦੋਂ ਕੋਡਬੇਸ—ਅਤੇ ਟੀਮ—ਵਧਦੀ ਹੈ ਤਾਂ ਰੱਖ-ਰਖਾਅ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਸਾਦਗੀ ਜੋ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਚਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ

Go ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਉਤਪਾਦਕਤਾ ਚਾਲ ਕੋਈ ਜਾਦੂਈ ਫਰੇਮਵਰਕ ਨਹੀਂ—ਇਹ ਰੋਕ-ਥਾਮ ਹੈ। ਭਾਸ਼ਾ ਜਾਣ-ਬਚ ਕੇ ਆਪਣੀ ਫੀਚਰ ਸੈੱਟ ਛੋਟੀ ਰੱਖਦੀ ਹੈ, ਜੋ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਫੈਸਲਿਆਂ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ।

ਘੱਟ ਚੋਈਸਾਂ, ਘੱਟ ਫੈਸਲਾ ਥਕਾਵਟ

ਛੋਟੀ ਭਾਸ਼ਾ ਸਤਹ ਨਾਲ, "ਕਿਹੜਾ ਪੈਟਰਨ ਵਰਤਣਾ ਹੈ?" ਦੇ ਝਗੜਿਆਂ ਘੱਟ ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਵਕਤ ਨਹੀਂ ਗੁਜ਼ਾਰਦੇ ਕਈ ਮੈਟਾ-ਪਰੋਗ੍ਰਾਮਿੰਗ ਤਰੀਕਿਆਂ, ਜਟਿਲ ਇਨਹੈਰੀਟੈਂਸ ਮਾਡਲਾਂ ਜਾਂ ਇੱਕੋ ਵਿਚਾਰ ਨੂੰ ਦੱਸਣ ਦੇ ਬਹੁਤ ਤੋਂ ਤਰੀਕਿਆਂ 'ਤੇ बहਸ ਕਰਨ ਵਿੱਚ। ਜ਼ਿਆਦਾਤਰ Go ਕੋਡ ਕੁਝ ਸਪਸ਼ਟ ਪੈਟਰਨਾਂ 'ਤੇ ਇਕਠੇ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੰਜੀਨੀਅਰ ਪ੍ਰੋਡਕਟ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਸਟਾਈਲ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਤਕ਼ਰਾਰ 'ਤੇ।

ਪਰੰਪਰਾਵਾਂ ਰਾਹੀਂ ਪਾਠਯੋਗਤਾ (ਅਤੇ gofmt)

Go ਕੋਡ ਇਰਾਦਾ ਕਰਕੇ ਸਾਫ਼-ਸੁਥਰਾ ਹੁੰਦਾ ਹੈ—ਅਤੇ ਇਹ ਸਟਾਰਟਅਪ ਵਿੱਚ ਫਾਇਦਾ ਹੈ ਜਿੱਥੇ ਹਰ ਕੋਈ ਇੱਕੋ ਸਰਵਿਸਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ। ਫਾਰਮੈਟਿੰਗ ਮੁੱਖ ਤੌਰ gofmt ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਰੀਪੋ ਵਿੱਚ ਕੋਡ ਲੇਖਕ ਤੋਂ ਬਿਨਾਂ ਵੀ ਇਕਸਾਰ ਦਿਖਦਾ ਹੈ।

ਉਹ ਇਕਸਾਰਤਾ ਰਿਵਿਊਜ਼ ਵਿੱਚ ਲਾਭਦਾਇਕ ਹੈ: diffs ਸਕੈਨ ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦੇ ਹਨ, ਗੱਲਬਾਤ "ਇਹ ਕਿਵੇਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ?" ਤੋਂ "ਕੀ ਇਹ ਸਹੀ ਅਤੇ ਮਾਇੰਟੇਨੇਬਲ ਹੈ?" ਵੱਲ ਢਲਦੀ ਹੈ, ਅਤੇ ਟੀਮ ਘੱਟ ਰੁਕਾਵਟ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀ ਹੈ।

ਬਿਨਾਂ ਭਾਰੀ ਰਸਮਾਂ ਵਾਲੇ ਇੰਟਰਫੇਸ

Go ਦੇ ਇੰਟਰਫੇਸ ਛੋਟੇ ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਹਨ। ਤੁਸੀਂ ਜਿੱਥੇ ਲੋੜ ਹੋ (ਅਕਸਰ ਖਪਤਕਾਰ ਕੋਲ) ਇੱਕ ਇੰਟਰਫੇਸ ਪਰिभਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਇਸ ਨੂੰ ਵਿਵਹਾਰ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ, ਅਤੇ ਟੈਸਟੇਬਿਲਿਟੀ ਜਾਂ ਮੋਡੀਊਲਰਿਟੀ ਲਈ ਕਿਸੇ ਵੱਡੇ ਫਰੇਮਵਰਕ ਨੂੰ ਖਿੱਚਣ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।

ਇਸ ਨਾਲ ਰਿਫੈਕਟੋਰਿੰਗ ਘੱਟ ਡਰਾਉਣੀ ਹੁੰਦੀ ਹੈ: ਇੰਪਲਿਮੇੰਟੇਸ਼ਨ ਬਦਲ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਕਲਾਸ ਹੀਰਾਰਕੀ ਲਿਖਣ ਦੀ ਲੋੜ ਦੇ, ਅਤੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਵਿੱਚ ਡਿਪੈਂਡੈਂਸੀ ਸਟੱਬ ਕਰਨਾ ਸਿੱਧਾ ਹੁੰਦਾ ਹੈ।

਑ਨਬੋਰਡਿੰਗ ਅਤੇ ਕੋਡ ਰਿਵਿਊ ਸਸਤਾ ਹੁੰਦੇ ਹਨ

ਨਵੇਂ ਹਾਇਰ ਆਮ ਤੌਰ 'ਤੇ ਜਲਦੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਆਦਿ-Golang ਸੁਭਾਅ ਪੇਸ਼ਗੋਈਯੋਗ ਹੁੰਦਾ ਹੈ: ਸਾਦਾ ਕੰਟਰੋਲ ਫਲੋ, ਸਪਸ਼ਟ ਏਰਰ ਹੈਂਡਲਿੰਗ, ਅਤੇ ਲਗਾਤਾਰ ਫਾਰਮੈਟਿੰਗ। ਰਿਵਿਊਅਰ ਘੱਟ ਸਮਾਂ ਚਤੁਰਾਈ ਨੂੰ ਡਿਕੋਡ ਕਰਨ ਵਿੱਚ ਲਗਾਉਂਦੇ ਹਨ ਅਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਸਹੀਤਾ, ਏਜ਼ ਕੇਸਾਂ ਅਤੇ ਆਪਰੇਸ਼ਨਲ ਸੁਰੱਖਿਆ 'ਤੇ ਲਗਾਉਂਦੇ ਹਨ—ਇਹੋ ਜਿਹੜਾ ਚੀਜ਼ ਛੋਟੀ ਅਤੇ ਅਹੰਕਾਰਪੂਰਨ ਟੀਮ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।

ਟੂਲਿੰਗ ਅਤੇ ਬਿਲਡ ਗਤੀ ਰੋਜ਼ਾਨਾ ਸ਼ਿਪਿੰਗ ਲਈ

Go ਦੀ ਟੂਲਿੰਗ "ਬੋਰੀੰਗ" ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਪਰ ਇਹ ਵਧੀਆ ਹੈ: ਤੇਜ਼, ਪੇਸ਼ਗੋਈਯੋਗ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਮਸ਼ੀਨਾਂ ਅਤੇ ਟੀਮਾਂ 'ਤੇ ਇੱਕੋ-ਜਿਹੀ। ਸਟਾਰਟਅਪਸ ਜਿਹੜੇ ਰੋਜ਼ਾਨਾ ਸ਼ਿਪ ਕਰਦੇ ਹਨ, ਲਈ ਇਹ ਇਕਸਾਰਤਾ ਲੋਕਲ ਡੈਵਲਪਮੈਂਟ ਅਤੇ CI ਵਿੱਚ friction ਘਟਾਉਂਦੀ ਹੈ।

ਤੇਜ਼ ਕੰਪਾਇਲ = ਘੱਟ ਫੀਡਬੈਕ ਲੂਪ

Go ਤੇਜ਼ੀ ਨਾਲ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਪ੍ਰੋਜੈਕਟ ਵਧਦੇ ਜਾਣ। ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਕੰਪਾਇਲ ਸਮਾਂ ਹਰ edit–run ਚੱਕਰ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਹਰ ਇੰਜੀਨੀਅਰ ਦੇ ਦਿਨ ਵਿੱਚ ਕੁਝ ਮਿੰਟ ਬਚਾਉਂਦੇ ਹੋ, ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਜੋੜਦਾ ਹੈ।

CI ਵਿੱਚ, ਤੇਜ਼ ਬਿਲਡ ਦਾ ਮਤਲਬ ਛੋਟੇ ਕਤਾਰਾਂ ਅਤੇ ਤੇਜ਼ ਮਰਜਾਂ ਹਨ। ਤੁਸੀਂ ਹਰ ਪੀ.ਆਰ. 'ਤੇ ਟੈਸਟ ਚਲਾ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਬੋਤਲਨੈਕ ਬਣਾਉਣ ਦੇ, ਅਤੇ ਤੁਸੀਂ ਗੁਣਵੱਤਾ ਚੈਕਸ ਨੂੰ ਬੰਦ ਕਰਨ ਦੀ ਥਾਵਾਂ ਰੱਖਦੇ ਹੋ।

ਟੈਸਟਿੰਗ ਜੋ ਬਿਲਟ-ਇਨ ਹੈ

go test ਮਿਆਰੀ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਹੈ, ਇੱਕ ਵਾਧੂ ਟੂਲ ਨਹੀਂ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਝਗੜਾ ਕਰੋ। ਇਹ ਯੂਨਿਟ ਟੈਸਟ ਚਲਾਉਂਦਾ ਹੈ, ਟੇਬਲ-ਡਰਿਵਨ ਟੈਸਟਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਹਾਰਦਾ ਹੈ, ਅਤੇ CI ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਇੰਟੈਗਰੇਟ ਕਰਦਾ ਹੈ।

ਕਵਰੇਜ ਵੀ ਸਿੱਧਾ ਹੈ:

go test ./... -cover

ਇਹ ਬੇਸਲਾਈਨ ਇਹ ਸਥਾਪਤ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ("ਟੈਸਟ ਕੋਡ ਦੇ ਨੇੜੇ ਰਹਿੰਦੇ ਹਨ", "push ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ go test ./... ਚਲਾਓ") ਬਿਨਾਂ ਫਰੇਮਵਰਕਾਂ ਬਾਰੇ ਬਹਿਸ ਕਰਨ ਦੇ।

Go modules ਨਾਲ ਪੇਸ਼ਗੋਈਯੋਗ ਬਿਲਡ

Go modules ਡਿਪੈਂਡੈਂਸੀਜ਼ ਨੂੰ ਲੌਕ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਬਿਲਡ ਅਚਾਨਕ ਨਾ ਬਦਲੇ। go.mod ਅਤੇ go.sum ਨਾਲ, ਤੁਹਾਨੂੰ ਲੈਪਟਾਪਾਂ ਅਤੇ CI ਏਜੰਟਾਂ 'ਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਇੰਸਟਾਲ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਸੇਵਾ ਦੀਆਂ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਦੀ ਇੱਕ ਸਾਫ਼ ਝਲਕ ਮਿਲਦੀ ਹੈ।

ਫਾਰਮੈਟਿੰਗ ਅਤੇ ਲਿੰਟਿੰਗ ਡਿਫੌਲਟ

gofmt ਸਾਂਝਾ ਸਟਾਈਲ ਗਾਈਡ ਹੈ। ਜਦੋਂ ਫਾਰਮੈਟਿੰਗ ਆਟੋਮੈਟਿਕ ਹੈ, ਕੋਡ ਰਿਵਿਊਜ਼ ਵਿੱਚ ਵ੍ਹਾਈਟਸਪੇਸ ਬਾਰੇ ਘੱਟ ਗੱਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਡਿਜ਼ਾਇਨ ਅਤੇ ਸਹੀਤਾ 'ਤੇ ਧਿਆਨ ਵੱਧਦਾ ਹੈ।

ਕਈ ਟੀਮਾਂ CI 'ਚ go vet (ਅਤੇ ਇਛਾ ਅਨੁਸਾਰ ਇੱਕ ਲਿੰਟਰ) ਜੋੜਦੀਆਂ ਹਨ, ਪਰ ਡਿਫੋਲਟ ਟੂਲਚੇਨ ਹੀ ਪ੍ਰਾਜੈਕਟਾਂ ਨੂੰ ਇੱਕ ਇਕਸਾਰ, ਮਾਇੰਟੇਨੇਬਲ ਬੇਸਲਾਈਨ ਵੱਲ ਧਕੇਲਦਾ ਹੈ।

ਸਰਵਿਸ ਵਰਕਲੋਡ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ concurrency

Go ਦਾ concurrency ਮਾਡਲ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਕਲਾਉਡ ਬੈਕਐਂਡ ਵਿੱਚ "ਘਰ ਵਾਲਾ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਸਰਵਿਸਿਜ਼ ਆਪਣਾ ਸਮਾਂ ਉਡੀਕਣ ਵਿੱਚ ਗੁਜ਼ਾਰਦੀਆਂ ਹਨ: HTTP ਬੇਨਤੀਆਂ ਆਉਣ ਦਾ ਉਡੀਕ, ਡੇਟਾਬੇਸ ਕੁਐਰੀ ਵਾਪਸ ਆਉਣ ਦਾ ਉਡੀਕ, ਮੈਸੇਜ਼ ਕਿਊ ਦਾ ਜਵਾਬ ਆਉਣ ਦੀ ਉਡੀਕ, ਜਾਂ ਕਿਸੇ ਹੋਰ API ਕਾਲ ਦਾ ਉਡੀਕ। Go ਇਸ ਉਡੀਕ ਦੌਰਾਨ ਕੰਮ ਨੂੰ ਚੱਲਦਾ ਰੱਖਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।

Goroutines: ਹਲਕੇ ਵਰਕਰ

ਗੋਰੁਟੀਨ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਹੋਰ ਕੰਮਾਂ ਨਾਲ ਇਕੱਠੇ ਚੱਲਦਾ ਹੈ। ਇਸ ਨੂੰ ਸੋਚੋ ਜਿਵੇਂ ਇੱਕ ਛੋਟਾ ਵਰਕਰ ਚਲਾਉਣਾ ਜੋ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਸੰਭਾਲਦਾ, ਇੱਕ ਨਿਯਤ ਕੰਮ ਚਲਾਉਂਦਾ, ਜਾਂ ਬਾਹਰੀ ਕਾਲ ਦੀ ਉਡੀਕ ਕਰਦਾ—ਬਿਨਾਂ ਮੈਨੁਅਲੀ ਥ੍ਰੈਡ ਮੈਨੇਜਮੈਂਟ ਦੀ ਲੋੜ ਦੇ।

ਅਮਲ ਵਿੱਚ, ਇਹ ਆਮ ਕਲਾਉਡ ਪੈਟਰਨਾਂ ਨੂੰ ਸਧਾਰਣ ਬਣਾਉਂਦਾ ਹੈ:

• ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਸੰਭਾਲਣਾ (ਹਰ ਬੇਨਤੀ ਹੈਂਡਲਰ concurrent I/O ਟਰਿੱਗਰ ਕਰ ਸਕਦਾ ਹੈ)
• ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼ (ਈਮੇਲ ਭੇਜਣਾ, ਰਿਪੋਰਟ ਜਨਰੇਸ਼ਨ, ਕੈਸ਼ ਰੀਫ੍ਰੈਸ਼)
• ਫੈਨ-ਆਊਟ / ਫੈਨ-ਇਨ (5 ਸਰਵਿਸਾਂ ਨੂੰ ਪੈਰਲੇਲ ਕਾਲ ਕਰੋ, ਫਿਰ ਨਤੀਜੇ ਜੋੜੋ)

ਚੈਨਲ: ਨਤੀਜੇ ਭੇਜਣ ਦਾ ਸਧਾਰਣ ਤਰੀਕਾ

ਚੈਨਲ typed ਪਾਈਪ ਹਨ ਜੋ ਗੋਰੁਟੀਨਾਂ ਦਰਮਿਆਨ ਮੂਲਾਂ ਭੇਜਣ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਕੰਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੋਆਰਡੀਨਿਆਂਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਇਹ ਲਾਭਦਾਇਕ ਹਨ: ਇੱਕ ਗੋਰੁਟੀਨ ਨਤੀਜੇ ਪ੍ਰੋਡਿਊਸ ਕਰਦੀ ਹੈ, ਦੂਜੀ ਉਨ੍ਹਾਂ ਨੂੰ ਖਪਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਸਾਂਝੀ-ਮੇਮੋਰੀ ਜਟਿਲਤਾਵਾਂ ਤੋਂ ਬਚਦੇ ਹੋ।

ਇੱਕ ਆਮ ਉਦਾਹਰਣ ਫੈਨ-ਆਊਟ/ਫੈਨ-ਇਨ ਹੈ: ਗੋਰੁਟੀਨਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਡੇਟਾਬੇਸ ਅਤੇ ਦੋ ਬਾਹਰੀ APIs ਨੂੰ ਕਾਲ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੇ ਨਤੀਜੇ ਚੈਨਲ ਵਿੱਚ ਭੇਜੋ, ਅਤੇ ਫਿਰ ਉਹ ਆਉਣ 'ਤੇ ਜਵਾਬ ਇਕੱਤਰ ਕਰੋ।

ਇਹ I/O-ਭਾਰੀ ਸਰਵਿਸਿਜ਼ ਨਾਲ ਕਿਉਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ

APIs, ਕਿਊਜ਼, ਅਤੇ ਡੇਟਾਬੇਸ-ਬੈਕਡ ਐਪਾਂ ਲਈ concurrency ਕੱਚੇ CPU ਬਾਰੇ ਨਹੀਂ ਹੁੰਦਾ ਬਲਕਿ ਸੇਵਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲਾਕ ਨਾ ਹੋਣ ਦੇ ਬਾਰੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਨੈੱਟਵਰਕ ਅਤੇ ਡਿਸਕ ਉੱਤੇ ਉਡੀਕ ਹੋਵੇ। Go ਦੀ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਰਨਟਾਈਮ "ਸਮਝਦਾਰੀ ਨਾਲ ਉਡੀਕ ਕਰੋ" ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਂਦੇ ਹਨ।

ਪ੍ਰਯੋਗਿਕ ਰਹਿਨੁਮਾ: ਸਾਦਾ ਰੱਖੋ

ਗੋਰੁਟੀਨਾਂ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਵਰਤੋ, ਪਰ ਚੈਨਲਾਂ ਵਿੱਚ ਚੋਣਸ਼ੀਲ ਰਹੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਰਵਿਸਿਜ਼ ਇਹਨਾਂ ਨਾਲ ਚੰਗਾ ਕਰ ਲੈਂਦੀਆਂ ਹਨ:

• ਪ੍ਰਤੀ ਬੇਨਤੀ ਇੱਕ ਗੋਰੁਟੀਨ
• ਬੈਕਗ੍ਰਾਊਂਡ ਟਾਸਕਸ ਲਈ ਇੱਕ ਛੋਟਾ ਵਰਕਰ ਪੂਲ
• ਚੈਨਲਾਂ ਸਿਰਫ ਉੱਥੇ ਜਿੱਥੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਮਿਊਟੈਕਸ ਜਾਂ ਸਧਾਰਣ ਫੰਕਸ਼ਨ ਕਾਲਾਂ ਨਾਲੋਂ ਸਪਸ਼ਟ ਹੋਵੇ

ਜੇ ਚੈਨਲਾਂ ਕਿਸੇ ਕਸਟਮ ਫਰੇਮਵਰਕ ਵਾਂਗ ਦਿਸਣ ਲੱਗਣ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸਧਾਰਨ ਕਰਨ ਦੀ ਨਿਸ਼ਾਨੀ ਹੁੰਦੀ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਓਪਰੇਸ਼ਨ

Go ਆਮ ਤੌਰ 'ਤੇ ਸਟਾਰਟਅਪਸ ਲਈ "ਪਰਯਾਪਤ ਪ੍ਰਦਰਸ਼ਨ" ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਮਿੱਠਾ ਬਿੰਦੂ ਲਬਦਾ ਹੈ: ਤੇਜ਼ ਬੇਨਤੀ ਸੰਭਾਲਣਾ, ਠੀਕ ਮੈਮਰੀ ਵਰਤੋਂ, ਅਤੇ ਲੋਡ ਹੇਠਾਂ ਪੇਸ਼ਗੋਈਯੋਗ ਵਰਤਾਰ—ਬਿਨਾਂ ਟੀਮ ਨੂੰ ਲਗਾਤਾਰ ਨੀਚਲੇ ਪੱਧਰ ਦੇ ਟਿ੍ਯੂਨਿੰਗ 'ਚ ਫਸਣ ਦੇ।

"ਪਰਯਾਪਤ ਪ੍ਰਦਰਸ਼ਨ" ਕੀ ਲੱਗਦਾ ਹੈ

ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਸਰਵਿਸਿਜ਼ਾਂ ਲਈ, ਲਕਸ਼ ਛੋਟਾ-ਥੋੜਾ throughput ਦਬਾਉਣਾ ਨਹੀਂ ਹੁੰਦਾ। ਮਕਸਦ p95/p99 latency ਸਥਿਰ ਰੱਖਣਾ, ਅਚਾਨਕ CPU ਚੋਟੀਆਂ ਤੋਂ ਬਚਣਾ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਵਧਣ 'ਤੇ ਹੇੱਡਰੂਮ ਬਣਾਈ ਰੱਖਣਾ ਹੈ। Go ਦੀ ਕੰਪਾਇਲ ਕੀਤੀ binaries ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਅਕਸਰ APIs, ਵਰਕਰਾਂ ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲਿੰਗ ਲਈ ਮਜ਼ਬੂਤ ਬੇਸਲਾਈਨ ਦਿੰਦੇ ਹਨ।

ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਅਤੇ ਲੇਟੇੰਸੀ

Go ਗਾਰਬੇਜ-ਕਲੈਕਟ ਕੀਤੀ ਭਾਸ਼ਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਰਨਟਾਈਮ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਅਣਉਪਯੋਗ ਮੈਮਰੀ ਨੂੰ ਵਾਪਸ ਲੈਂਦਾ ਹੈ। ਆਧੁਨਿਕ Go GC ਨੂੰ ਪੌਜ਼ ਟਾਈਮ ਛੋਟੀ ਰੱਖਣ ਲਈ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਇਹ ਹਾਲਾਂਕਿ ਟੇਲ ਲੇਟੇੰਸੀ 'ਤੇ ਅਸਰ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਅਲੋਕੇਸ਼ਨ ਦਰ ਉੱਚੀ ਹੋਵੇ।

ਜੇ ਤੁਹਾਡੀ ਸੇਵਾ latency-sensitive ਹੈ (ਭੁਗਤਾਨ, ਰੀਅਲਟਾਈਮ ਫੀਚਰ), ਤਾਂ ਤੁਸੀਂ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਦੀ ਪਰਵਾਹ ਕਰੋਗੇ:

• ਅਲੋਕੇਸ਼ਨ ਦਰ (ਕਿੰਨੀ ਵਾਰ ਤੁਸੀਂ ਛੋਟੀਆਂ-ਅਵਧੀ ਵਾਲੀਆਂ ਓਬਜੇਕਟ ਬਣਾਉਂਦੇ ਹੋ)
• ਹੀਪ ਵਾਧਾ (ਕਿੰਨੀ ਮੈਮਰੀ ਲਾਈਵ ਰਹਿੰਦੀ ਹੈ)
• ਟ੍ਰੈਫਿਕ ਬਰਸਟ ਦੌਰਾਨ p99 ਲੇਟੇੰਸੀ

ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ: Go ਦਾ GC ਵੇਹਵਾਰ ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਰ ਅਤੇ ਮੈਪ ਕਰਨਯੋਗ ਹੁੰਦਾ ਹੈ, ਜੋ ਓਪਰੇਸ਼ਨਜ਼ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

ਕਦੋਂ ਪ੍ਰੋਫਾਈਲ, ਘੱਟ ਅਲੋਕੇਟ ਕਰੋ, ਅਤੇ ਬੈਂਚਮਾਰਕ ਕਰੋ

ਇਹਨਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਦਿਲਚਸਪੀ ਨਾ ਲਵੋ ਸਿਰਫ ਸ਼ਕ 'ਤੇ। ਉਸ ਵੇਲੇ ਧਿਆਨ ਦਿਓ ਜਦੋਂ ਤੁਸੀਂ ਸਪਸ਼ਟ ਸੰਕੇਤ ਵੇਖੋ: ਉੱਚ p99 ਲੇਟੇੰਸੀ, ਵੱਧਦੀ ਮੈਮਰੀ, CPU ਸੈਚੁਰੇਸ਼ਨ, ਜਾਂ ਆਟੋਸਕੇਲਿੰਗ ਦਾ ਵਧਨਾ।

Go ਇਹ ਨੂੰ ਅਮਲੀ ਬਣਾਉਂਦਾ ਹੈ built-in profiling (pprof) ਅਤੇ benchmarking ਨਾਲ। ਆਮ ਫਾਇਦੇ ਵਿੱਚ ਬਫਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਾ, ਜ਼ਰੂਰੀ ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਚਣਾ, ਅਤੇ ਪ੍ਰਤੀ-ਬੇਨਤੀ ਅਲੋਕੇਸ਼ਨਾਂ ਨੂੰ ਘਟਾਉਣਾ ਸ਼ਾਮਿਲ ਹਨ—ਇਹ ਤਬਦੀਲੀਆਂ ਲਾਗਤ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦੋਹਾਂ ਸੁਧਾਰਦੀਆਂ ਹਨ।

ਰੰਨਟਾਈਮ-ਭਾਰੀ ਜਾਂ ਧੀਮੀ-ਸਟਾਰਟ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਟਰੇਡ-ਆਫ

ਰੰਨਟਾਈਮ-ਭਾਰੀ ਸਟੈਕਸ ਦੇ ਮੁਕਾਬਲੇ, Go ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਮੈਮਰੀ ਓਵਰਹੈੱਡ ਅਤੇ ਹੋਰ ਸਪਸ਼ਟ ਪ੍ਰਦਰਸ਼ਨ ਡੀਬੱਗਿੰਗ ਦਿੰਦਾ ਹੈ। ਧੀਮੀ-ਸਟਾਰਟ ਇਕੋਸਿਸਟਮਾਂ ਨਾਲੋਂ, Go ਦੀ startup time ਅਤੇ binary ਡਿਪਲੌਇਮੈਂਟ ਕੰਟੇਨਰਾਂ ਅਤੇ ਆਨ-ਡਿਮਾਂਡ ਸਕੇਲਿੰਗ ਲਈ ਅਸਾਨ ਹੋ ਸਕਦੀ ਹੈ।

ਟ੍ਰੇਡ-ਆਫ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਰਨਟਾਈਮ ਦਾ ਸਤਿਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ: ਜਦੋਂ ਬਾਤ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਤਾਂ ਅਲੋਕੇਸ਼ਨ-ਅਵੇਅਰ ਕੋਡ ਲਿਖੋ, ਅਤੇ ਮੰਨੋ ਕਿ GC ਪੂਰੀ ਤਰ੍ਹਾਂ deterministic latency ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ ਉਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਮੁਕਾਬਲੇ ਜਿੱਥੇ ਮੈਮਰੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਥੋਂ-ਹੱਥ ਮੈਨੇਜ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਡਿਪਲੌਇਮੈਂਟ ਜੋ ਕਲਾਉਡ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦਾ ਹੈ

Go ਦੀ ਡਿਪਲੌਇਮੈਂਟ ਕਹਾਣੀ ਇਸ ਨਾਲ ਮਿਲਦੀ ਹੈ ਕਿ ਸਟਾਰਟਅਪਸ ਅੱਜ ਕਿਵੇਂ ਸ਼ਿਪ ਕਰਦੇ ਹਨ: ਕੰਟੇਨਰ, ਬਹੁਤ ਸਾਰੇ ਵਾਤਾਵਰਣ, ਅਤੇ ਵੱਖ-ਵੱਖ CPU ਆਰਕੀਟੈਕਚਰ। ਵੱਡੀ ਖੁਲਾਸਾ ਇਹ ਹੈ ਕਿ Go ਇੱਕ ਸਿੰਗਲ static binary ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਲੋੜੀਂਦੀ ਚੀਜ਼ਾਂ ਸ਼ਾਮਿਲ ਹੁੰਦੀਆਂ ਹਨ।

Static binaries = ਸਿਮਪਲ ਇਮੇਜ

ਇੱਕ ਆਮ Go ਸਰਵਿਸ ਇੱਕ ਐਕਜ਼ੈਕਯੂਟੇਬਲ ਫਾਇਲ ਵਿੱਚ ਬਣਦੀ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਕੰਟੇਨਰ ਇਮੇਜ ਬਹੁਤ ਛੋਟੀ ਹੋਵੇ—ਕਈ ਵਾਰੀ ਸਿਰਫ ਬਾਈਨਰੀ ਅਤੇ CA ਸਰਟੀਫਿਕੇਟ। ਛੋਟੀਆਂ ਇਮੇਜਾਂ CI ਅਤੇ Kubernetes ਨੋਡਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਡਾਊਨਲੋਡ ਹੁੰਦੀਆਂ ਹਨ, ਘੱਟ ਮੂਵਿੰਗ ਪਾਰਟਸ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਪੈਕੇਜ-ਲੈਵਲ ਮੁੱਦਿਆਂ ਲਈ ਘੱਟ ਸਤਹ ਹੁੰਦਾ ਹੈ।

ਬਿਨਾਂ ਡਰ ਦੇ cross-compilation ਅਤੇ multi-arch

ਆਧੁਨਿਕ ਪਲੇਟਫਾਰਮ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ amd64 ਨਹੀਂ ਹੁੰਦੇ। ਕਈ ਟੀਮਾਂ amd64 ਅਤੇ arm64 ਦਾ ਮਿਲਾਜੁਲ ਚਲਾਉਂਦੀਆਂ ਹਨ (ਲਾਗਤ ਜਾਂ ਉਪਲਬਧਤਾ ਲਈ)। Go cross-compiling ਨੂੰ سੌਖਾ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਇੱਕੋ ਕੋਡਬੇਸ ਅਤੇ CI ਪਾਈਪਲਾਈਨ ਤੋਂ multi-arch ਇਮੇਜ ਬਣਾਉਣ ਅਤੇ ਪਬਲਿਸ਼ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਉਦਾਹਰਣ ਲਈ, ਇਕ ਬਿਲਡ ਸਟੈਪ ਟਾਰਗੇਟ OS/ਆਰਕੀਟੈਕਚਰ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਤੁਹਾਡੀ ਕੰਟੇਨਰ ਬਿਲਡ ਹਰ ਪਲੇਟਫਾਰਮ ਲਈ ਸਹੀ ਬਾਈਨਰੀ ਪੈਕੇਜ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਟੀਮਾਂ ਲਈ ਖਾਸ ਕਰਕੇ ਲਾਭਦਾਇਕ ਹੈ ਜੋ ਲੈਪਟਾਪ, CI ਰਨਰ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਨੋਡਸ 'ਤੇ ਡਿਪਲੌਇਮੈਂਟ ਦੇ ਮਿਆਰ ਨੂੰ ਸਥਿਰ ਕਰ ਰਹੇ ਹਨ।

ਛੋਟਾ ਓਪਰੇਸ਼ਨਲ ਫੁੱਟਪ੍ਰਿੰਟ

ਕਿਉਂਕਿ Go ਸਰਵਿਸਿਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਬਾਹਰੀ ਰਨਟਾਈਮ (ਜਿਵੇਂ ਕਿਸੇ VM ਜਾਂ ਇੰਟਰਪ੍ਰੈਟਰ ਵਰਜਨ) 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦੀਆਂ, ਸਿੰਕਰਨਾਈਜ਼ ਕਰਨ ਲਈ ਘੱਟ ਰਨਟਾਈਮ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਹੁੰਦੀਆਂ ਹਨ। ਘੱਟ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਦਾ ਮਤਲਬ ਹੋਰ "ਰਹੱਸਮਈ ਫੇਲਯਰ" ਵੀ ਘੱਟ ਹੁੰਦੇ ਹਨ ਜੋ ਗੁਮ ਹੋਏ ਸਿਸਟਮ ਲਾਈਬ੍ਰੇਰੀਜ਼ ਜਾਂ ਅਸੰਗਤ ਬੇਸ ਇਮੇਜਾਂ ਕਾਰਨ ਹੁੰਦੇ ਹਨ।

ਘੱਟ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ" ਸਮੱਸਿਆਵਾਂ

ਜਦੋਂ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰਦੇ ਹੋ ਉਹੀ ਬਾਈਨਰੀ ਹੈ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕੀਤੀ ਸੀ, ਤਾਂ ਵਾਤਾਵਰਣ ਡ੍ਰਿਫਟ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਟੀਮਾਂ dev, staging, ਅਤੇ production ਵਿੱਚ ਫਰਕਾਂ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਗੁਜ਼ਾਰਦੀਆਂ ਹਨ—ਅਤੇ ਫੀਚਰ ਨਿਰਭਰਤਾ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ।

ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ HTTP: ਇੱਕ ਕੁਦਰਤੀ ਮਿਲਾਪ

Go ਦਾ ਕਲਾਉਡ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਨਾਲ ਰਿਸ਼ਤਾ ਇੱਕ ਸਿੰਪਲ ਗੱਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਕਲਾਉਡ ਸਿਸਟਮ HTTP ਰਾਹੀਂ ਗੱਲ ਕਰਦੇ ਹਨ। Go ਇਸ ਨੂੰ ਪਹਿਲੀ-ਕਲਾਸ ਯੂਜ਼ ਕੇਸ ਵਜੋਂ ਸੌਂਪਦਾ ਹੈ, ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਸੋਚਿਆ ਗਿਆ ਕੋਈ ਚੀਜ਼।

ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਪਹਿਲਾਂ ਹੀ ਇੱਕ "ਫਰੇਮਵਰਕ" ਹੈ

net/http ਨਾਲ, ਤੁਸੀਂ ਅਜਿਹੇ ਪ੍ਰੋਡਕਸ਼ਨ-ਤਕ ਰਹਿਣ ਵਾਲੇ ਸਰਵਿਸਿਜ਼ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਸਥਿਰ ਪ੍ਰਿਮਿਟਿਵਜ਼ ਵਰਤਦੇ ਹਨ: ਸਰਵਰ, ਹੈਂਡਲਰ, routing ServeMux ਰਾਹੀਂ, ਕੁਕੀਜ਼, TLS, ਅਤੇ httptest ਵਰਗੇ ਸਹਾਇਕ ਟੁਲਜ਼ ਟੈਸਟਿੰਗ ਲਈ।

ਤੁਹਾਨੂੰ practical ਸਹਾਇਕ ਪੈਕੇਜ ਵੀ ਮਿਲਦੇ ਹਨ ਜੋ ਡਿਪੈਂਡੈਂਸੀ ਘਟਾਉਂਦੇ ਹਨ:

• encoding/json APIs ਲਈ
• net/url ਅਤੇ net ਨੀਚਲੇ-ਸਤਰ ਨੈੱਟਵਰਕਿੰਗ ਲਈ
• compress/gzip ਰਿਸਪਾਂਸ ਕੰਪ੍ਰੈਸ਼ਨ ਲਈ
• httputil reverse proxies ਅਤੇ ਡੀਬੱਗਿੰਗ ਲਈ

ਭਾਰ ਵਾਲੇ ਫਰੇਮਵਰਕਾਂ ਬਿਨਾਂ APIs (ਅਤੇ ਜਦੋਂ ਫਰੇਮਵਰਕ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ)

ਕਈ ਟੀਮਾਂ plain net/http ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਜਦੋਂ ਜ਼ਰੂਰਤ ਹੋਵੇ ਇੱਕ ਹਲਕੀ router (ਅਕਸਰ chi) ਜੋੜਦੀਆਂ ਹਨ ਤਾਂ ਜੋ routing ਪੈਟਰਨ, URL params, ਜਾਂ grouped middleware ਸਾਫ਼ ਹੋ ਸਕਣ۔

Gin ਜਾਂ Echo ਵਰਗੇ ਫਰੇਮਵਰਕ ਸ਼ੁਰੂਆਤੀ ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੇ ਹਨ ਕੁਝ ਸਹੂਲਤਾਂ (binding, validation, ਸੁੰਦਰ middleware APIs) ਦੇ ਕੇ। ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਇੱਕ ਹੋਰ opinionated structure ਪਸੰਦ ਕਰਦੀ ਹੈ ਤਾਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਸਾਫ਼, ਮਾਇੰਟੇਨੇਬਲ API ਸ਼ਿਪ ਕਰਨ ਲਈ ਉਹੇ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹਨ।

Context, cancellation, ਅਤੇ timeouts = ਕਲਾਉਡ ਸੰਭਾਲ

ਕਲਾਉਡ ਮਾਹੌਲਾਂ ਵਿੱਚ, ਬੇਨਤੀਆਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ, ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ upstream ਸਰਵਿਸ ਰੁਕ ਸਕਦੀਆਂ ਹਨ। Go ਦਾ context deadlines ਅਤੇ cancellation ਨੂੰ ਤੁਹਾਡੇ ਹੈਂਡਲਰਾਂ ਅਤੇ outbound ਕਾਲਾਂ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਨੂੰ ਆਮ ਬਣਾਉਂਦਾ ਹੈ।

func handler(w http.ResponseWriter, r *http.Request) {
  ctx := r.Context()
  req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil)

  client := &http.Client{Timeout: 2 * time.Second}
  resp, err := client.Do(req)
  if err != nil { http.Error(w, "upstream error", 502); return }
  defer resp.Body.Close()
}

ਟੀਮਾਂ ਦੁਆਰਾ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਪ੍ਰਾਇਕਟਿਕਲ ਪੈਟਰਨ

ਇੱਕ ਆਮ ਸੈਟਅਪ ਹੈ: router → middleware → handlers.

Middleware ਆਮ ਤੌਰ 'ਤੇ request IDs, structured logging, timeouts, auth, ਅਤੇ metrics ਸੰਭਾਲਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਚਿੰਤਾਵਾਂ ਨੂੰ ਕਿਨਾਰਿਆਂ 'ਤੇ ਰੱਖਣਾ ਹੈਂਡਲਰਾਂ ਨੂੰ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ—ਅਤੇ ਜਦੋਂ ਤੁਹਾਡੀ ਸਰਵਿਸ ਅਸਲ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਹੈ ਤਾਂ ਫੇਲਅਰਜ਼ ਨੂੰ ਡਾਇਗਨੋਸ ਕਰਨਾ ਵੀ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

ਨਿਰੀਖਣਯੋਗਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਸਕੇਲ 'ਤੇ

ਸਟਾਰਟਅਪਸ ਅਕਸਰ ਨਿਰੀਖਣਯੋਗਤਾ ਨੂੰ ਮੁੜ-ਮੁੜ ਤਦ ਤੱਕ ਟਾਲਦੇ ਹਨ ਜਦ ਤੱਕ ਕੁਝ ਟੁੱਟਦਾ ਨਹੀਂ। ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤੀ ਸਿਸਟਮ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਫੇਲਅਰ ਰੀਪੀਟੇਬਲ ਕਮ ਹੀ ਹੁੰਦੇ ਹਨ। ਦਿਨ ਪਹਿਲਾਂ ਹੀ ਬੁਨਿਆਦੀ ਲਾਗ, ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਟ੍ਰੇਸ ਹੋਣ ਨਾਲ "ਸਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਹੌਲਾ ਹੈ" ਤੋਂ ਬਦਲ ਕੇ "ਇਹ ਏਂਡਪਾਇੰਟ ਆਖਰੀ ਡਿਪਲੋਇ ਤੋਂ ਬਾਅਦ ਰੈਗਰੈੱਸ ਕੀਤਾ, ਅਤੇ DB ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਦੂਗਣੀ ਹੋ ਗਈ" ਵਿੱਚ ਆ ਜਾਉਂਦਾ ਹੈ।

ਲੋਗ, ਮੈਟ੍ਰਿਕਸ, ਟ੍ਰੇਸ: ਇੱਕ ਘੱਟ-ਪਰੰਤੂ ਲਾਭਦਾਇਕ ਸੈੱਟ

Go ਵਿੱਚ, ਸਟ੍ਰਕਚਰਡ ਲੋਗ (JSON) ਸਟੈਂਡਰਡਾਈਜ਼ ਕਰਨਾ ਅਤੇ ਕੁਝ ਉੱਚ-ਸੰਕੇਤ ਮੈਟ੍ਰਿਕਸ ਜੋੜਨਾ ਅਸਾਨ ਹੈ: request rate, error rate, latency percentiles, ਅਤੇ saturation (CPU, memory, goroutines)। ਟ੍ਰੇਸਜ਼ ਉਹ ਨਾਂ "ਕਿਉਂ" ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਸ ਨਾਲ ਸਮਾਂ ਸਰਵਿਸ ਬਾਰਡਰਾਂ 'ਤੇ ਕਿੱਥੇ ਵਰਤਿਆ ਗਿਆ।

Go ਇਕੋਸਿਸਟਮ ਇਸਨੂੰ ਭਾਰੀ ਫਰੇਮਵਰਕਾਂ ਬਿਨਾਂ ਉਦਯੋਗਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। OpenTelemetry ਦਾ Go ਲਈ ਪਹਿਲਾ-ਕਲਾਸ ਸਹਿਯੋਗ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਕਲਾਉਡ ਟੂਲ (ਅਥਵਾ self-hosted ਸਟੈਕ) ਇਸਨੂੰ ਇਨਜੇਸਟ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਆਮ ਸੈਟਅਪ: structured logging + Prometheus-ਸਟਾਈਲ ਮੈਟ੍ਰਿਕਸ + distributed tracing, ਸਾਰੇ ਇੱਕੋ request context ਨਾਲ ਵਾਇਰ ਕੀਤੇ ਹੋਏ।

pprof ਨਾਲ ਪ੍ਰੋਫਾਇਲਿੰਗ (ਜਿਨ੍ਹਾਂ ਉੱਤੇ ਤੁਸੀਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ)

Go ਦੀ built-in pprof ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕਦੀ ਹੈ:

• "ਰੀਲੀਜ਼ ਤੋਂ ਬਾਅਦ CPU ਕਿਉਂ ਉੱਚੀ ਹੋਈ?"
• "ਕੀ ਅਸੀਂ ਪ੍ਰਤੀ-ਬੇਨਤੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਐਲੋਕੇਟ ਕਰ ਰਹੇ ਹਾਂ?"
• "ਕੀ ਗੋਰੁਟੀਨ ਲਿਕ ਹੋ ਰਹੀ ਹੈ?"

ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਮਿੰਟਾਂ ਵਿੱਚ ਮੁੱਦੇ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਵੱਡੇ ਆਰਕੀਟੈਕਚਰ ਬਦਲਾਵਾਂ ਦੇ ਬਾਹਰ ਜਾ ਕੇ।

ਭਰੋਸੇਯੋਗਤਾ ਆਦਤਾਂ ਜੋ ਤੁਹਾਡੇ ਨਾਲ ਵਧਦੀਆਂ ਹਨ

Go ਤੁਹਾਨੂੰ ਆਪਰੇਸ਼ਨਲ ਅਨੁਸ਼ਾਸਨ ਵੱਲ ਧੱਕਦਾ ਹੈ: ਸਪਸ਼ਟ timeouts, context cancellation, ਅਤੇ predictable shutdown। ਇਹ ਆਦਤਾਂ cascading failures ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ ਅਤੇ ਡਿਪਲੌਇਮੈਂਟਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀਆਂ ਹਨ।

srv := &http.Server{Addr: ":8080", Handler: h, ReadHeaderTimeout: 5 * time.Second}

go func() { _ = srv.ListenAndServe() }()

<-ctx.Done() // from signal handling
shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
_ = srv.Shutdown(shutdownCtx)

ਇਸ ਨੂੰ bounded retries (jitter ਨਾਲ), backpressure (ਕਿਊਜ਼ ਨੂੰ ਸੀਮਤ ਕਰੋ, ਜਲਦੀ reject ਕਰੋ), ਅਤੇ ਹਰ outbound ਕਾਲ 'ਤੇ ਸਹੀ ਡਿਫੌਲਟਸ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਤੁਸੀਂ ਅਜਿਹੇ ਸਰਵਿਸਸ ਪ੍ਰਾਪਤ ਕਰੋਗੇ ਜੋ ਟ੍ਰੈਫਿਕ ਅਤੇ ਟੀਮ ਸਾਈਜ਼ ਵਧਣ ਨਾਲ ਵੀ ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ।

ਕੋਡਬੇਸ ਅਤੇ ਟੀਮ ਦਾ ਸਕੇਲਿੰਗ

ਇੱਕ ਸਟਾਰਟਅਪ ਦੀ ਪਹਿਲੀ Go ਸਰਵਿਸ ਅਕਸਰ ਇੱਕ ਜਾਂ ਦੋ ਲੋਕਾਂ ਦੁਆਰਾ ਲਿਖੀ ਜਾਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ "ਸਿਰਫ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਕਿੱਥੇ ਹੈ"। ਅਸਲੀ ਟੈਸਟ ਮਹੀਨਾ 18 'ਤੇ ਹੁੰਦਾ ਹੈ: ਹੋਰ ਸਰਵਿਸਿਜ਼, ਹੋਰ ਇੰਜੀਨੀਅਰ, ਹੋਰ ਵਿਚਾਰ, ਅਤੇ ਹਰ ਫੈਸਲੇ ਨੂੰ ਸਮਝਾਉਣ ਲਈ ਘੱਟ ਸਮਾਂ। Go ਇੱਥੇ ਵਧੀਆ ਤਰ੍ਹਾਂ ਸਕੇਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟੀਮਾਂ ਨੂੰ ਇਕਸਾਰ ਸਟਰੱਕਚਰ, ਸਥਿਰ ਡਿਪੈਂਡੈਂਸੀਜ਼, ਅਤੇ ਸਾਂਝੀਆਂ ਪਰੰਪਰਾਵਾਂ ਵੱਲ ਧੱਕਦਾ ਹੈ।

ਸਰਵਿਸਿਜ਼ ਨੂੰ ਛੋਟਾ ਅਤੇ ਮਾਇੰਟੇਨੇਬਲ ਰੱਖੋ

Go ਦਾ package ਮਾਡਲ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਬੇਸਲਾਈਨ:

• /cmd/<service> ਮੁੱਖ ਐਂਟ੍ਰੀਪੌਇੰਟ ਲਈ
• /internal/... ਉਹ ਕੋਡ ਜਿਸਨੂੰ ਤੁਸੀ ਹੋਰ ਮਾਡਿਊਲ ਆਯਾਤ ਨਾ ਕਰਨਾ ਚਾਹੁੰਦੇ
• ਛੋਟੇ ਪੈਕੇਜ ਜਿਨ੍ਹਾਂ ਦੇ ਨਾਮ ਉਨ੍ਹਾਂ ਦੇ ਕੰਮ ਦੇ ਆਧਾਰ 'ਤੇ ਹੋਣ (storage, billing, auth), ਨਾ ਕਿ ਜਿਸਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਰੱਖਿਆ ਹੈ

ਇਸ ਨਾਲ "ਕੁਝ ਵਿਅਪਕ ਸਰਫ਼ੇਸ, ਬੇਹਤਰੇਨ ਨਿੱਜੀ ਵੇਰਵੇ" ਦਾ ਪ੍ਰਵਾਹ ਬਣਦਾ ਹੈ। ਟੀਮਾਂ ਇੰਟਰਨਲ ਨੂੰ ਰਿਫੈਕਟਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਕੰਪਨੀ-ਵਿਆਪੀ ਤੋੜ-ਛੋੜ ਕਰਕੇ।

ਸਮੇਂ ਦੇ ਨਾਲ ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਅਨੁਕੂਲਤਾ

Go ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਚੇਨਡ-ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਘੱਟ ਉਥਲੇ ਕਰਦਾ ਹੈ:

ਪਹਿਲਾਂ, Go 1 compatibility promise ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਭਾਸ਼ਾ ਅਤੇ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਟੁੱਟਣ ਵਾਲੇ ਬਦਲਾਅ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਅਪਗ੍ਰੇਡ ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਾਪਦ ਹੁੰਦੇ ਹਨ (ਇੱਕ ਵਧੀਆ ਗੱਲ)।

ਦੂਜਾ, Go modules ਡਿਪੈਂਡੈਂਸੀ ਵਰਜ਼ਨਿੰਗ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਆਪਣੇ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਇੱਕ breaking API change ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, Gosemantic import versioning (/v2, /v3) ਸਹਾਇਕ ਹੈ, ਜੋ migration ਦੌਰਾਨ ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ ਵਰਜਨ ਨੂੰ ਇਕੱਠੇ ਮੌਜੂਦ ਹੋਣ ਦਿੰਦਾ ਹੈ ਬਗੈਰ ਕੋਈ ਬੜਾ-ਪੱਟੀ ਰੀਰਾਈਟ ਫੋर्स ਕਰਨ ਦੇ।

ਜਿੱਥੇ ਕੋਡ ਜਨਰੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ

Go ਟੀਮਾਂ ਅਕਸਰ "ਜਾਦੂ" ਤੋਂ ਪਰਹੇਜ਼ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਚੁਣੀਂਦਾ ਕੋਡ ਜਨਰੇਸ਼ਨ ਦੋਹਰਾਵਾਂ ਕੰਮ ਨੂੰ ਘੱਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਡ੍ਰਿਫਟ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ:

• Protobuf/OpenAPI clients: typed clients ਜਨਰੇਟ ਕਰੋ ਤਾਂ ਜੋ ਸਰਵਿਸ-ਟੂ-ਸਰਵਿਸ ਕਾਲਾਂ ਸੰਗਤ ਰਹਿਣ।
• Mocks: ਯੂਨਿਟ ਟੈਸਟਾਂ ਲਈ ਇੰਟਰਫੇਸ mocks ਜਨਰੇਟ ਕਰੋ, ਹੱਥ-ਲਿਖੇ ਸਟੱਬਾਂ ਤੋਂ ਬਚਣ ਲਈ।
• Typed API models: request/response ਕਿਸਮਾਂ ਜਨਰੇਟ ਕਰੋ ਤਾਂ ਜੋ mismatches compile-time 'ਤੇ ਫੜੇ ਜਾ ਸਕਣ।

ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ generated ਕੋਡ ਨੂੰ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਰੱਖੋ (ਉਦਾਹਰਣ ਲਈ /internal/gen) ਅਤੇ ਸਰੋਤ ਸქੀਮਾ ਨੂੰ ਅਸਲੀ ਆਰਟਿਫੈਕਟ ਮੰਨੋ।

ਹਾਇਰਿੰਗ ਅਤੇ ਑ਨਬੋਰਡਿੰਗ ਦੀ ਰਫਤਾਰ

Go ਦੀਆਂ ਪਰੰਪਰਾਵਾਂ ਤੁਹਾਡੇ ਲਈ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਬੰਧਕੀ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। gofmt, idiomatic ਨਾਂਕਰਨ, ਅਤੇ ਆਮ ਪ੍ਰੋਜੈਕਟ ਲੇਆਊਟਾਂ ਨਾਲ, ਨਵੇਂ ਹਾਇਰ ਜਲਦੀ ਯੋਗਦਾਨ ਦੇ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ "ਅਸੀਂ Go ਕਿਵੇਂ ਲਿਖਦੇ ਹਾਂ" ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਵਿੱਚ ਸਮਾਨ ਦਿਖਦਾ ਹੈ। ਕੋਡ ਰਿਵਿਊਜ਼ ਅੰਦਾਜ਼ਾਂ ਅਤੇ ਸਟਾਈਲ ਬਹਿਸ ਤੋਂ ਡਿਜ਼ਾਇਨ ਅਤੇ ਸਹੀਤਾ ਵੱਲ ਵੱਧਦੀਆਂ ਹਨ—ਜਿੱਥੇ ਤੁਸੀਂ ਸੀਨੀਅਰ ਧਿਆਨ ਚਾਹੁੰਦੇ ਹੋ।

ਜਦੋਂ Go ਸਿਰਫ਼ ਸਭ ਤੋਂ ਵਧੀਆ ਟੂਲ ਨਹੀਂ

Go ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼ ਅਤੇ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਡਿਫਾਲਟ ਹੈ, ਪਰ ਇਹ ਹਰ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਹੈ। ਅਹਸਾਸੀ ਤੌਰ 'ਤੇ ਪਛਾਣੋ ਕਿ ਤੁਸੀਂ ਅੱਗੇ 3–6 ਮਹੀਨਿਆਂ ਵਿੱਚ ਕੀ ਬਣਾਉਣ ਜਾਣੇ ਹੋ—ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਅਸਲ ਵਿੱਚ ਕੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੀ ਹੈ—ਤਾਂ ਸਭ ਤੋਂ ਘੱਟ ਪਛਤਾਵੇ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ।

ਉਹ ਸਥਿਤੀਆਂ ਜਿੱਥੇ Go ਥੋੜ੍ਹਾ ਹੌਲੀ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ

ਜੇ ਤੁਹਾਡਾ ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ ਕੰਮ ਇੰਟਰਨੈੱਟ UI ਅਤੇ ਯੂਜ਼ਰ ਫਲੋਜ਼ 'ਤੇ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਹੈ, ਤਾਂ Go ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਚੋਣ ਨਹੀਂ ਹੋ ਸਕਦਾ। Go ਸਰਵਿਸਾਂ ਅਤੇ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਵਿੱਚ ਚਮਕਦਾ ਹੈ, ਪਰ ਤੇਜ਼ UI ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਆਮ ਤੌਰ 'ਤੇ JavaScript/TypeScript ਪਰਿਵਾਰਾਂ ਜਾਂ ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਜ਼ਿਆਦਾ ਆਸਾਨ ਹੁੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਕੋਲ ਪੱਕੇ UI ਫਰੇਮਵਰਕ ਹੁੰਦੇ ਹਨ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇ ਤੁਹਾਡਾ ਮੁੱਖ ਕੰਮ ਭਾਰੀ ਡੇਟਾ ਸਾਇੰਸ, ਨੋਟਬੁੱਕਸ, ਅਤੇ ਅਨੁਸ਼ੀਲਨਾਤਮਕ ਵਿਸ਼ਲੇਸ਼ਣ ਹੈ, ਤਾਂ Go ਦਾ ਇਕੋਸਿਸਟਮ ਪਤਲਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ Go ਵਿੱਚ ਡੇਟਾ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ Python ਅਕਸਰ ਤਜਰਬੇ ਤੇਜ਼ੀ, ਕਮਿਊਨਟੀ ਲਾਇਬ੍ਰੇਰੀਜ਼, ਅਤੇ ML ਟੀਮਾਂ ਵਿੱਚ ਆਮ ਸਹਿਯੋਗ ਪੈਟਰਨ ਲਈ ਜਿੱਤ ਜਾਂਦੀ ਹੈ।

ਤੁਸੀਂ ਜੋ ਟਰੇਡ-ਆਫ ਉਮੀਦ ਕਰੋ

Go ਦੀ ਸਾਦਗੀ ਅਸਲੀ ਹੈ, ਪਰ ਇਸ ਦੇ ਕੁਝ "ਘਰੜੇ ਬਿੰਦੂ" ਵੀ ਹਨ ਜੋ ਰੋਜ਼ਾਨਾ ਵਿਕਾਸ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ:

• Generics ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ ਪਰ ਅਨੁਕੂਲ ਹੋਣਾ ਪੈਂਦਾ ਹੈ. ਜੇ ਤੁਹਾਡੀ ਟੀਮ Go ਨੂੰ pre-generics ਸਿੱਖੀ ਹੈ ਜਾਂ dynamic ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਆ ਰਹੀ ਹੈ, ਤਾਂ generics ਬਾਰੇ ਕਦੋਂ ਵਰਤਣਾ ਹੈ ਇਸ 'ਤੇ ਸਿੱਖਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
• ਏਰਰ ਹੈਂਡਲਿੰਗ ਸਪਸ਼ਟ ਹੈ ਅਤੇ verbose ਲੱਗ ਸਕਦੀ ਹੈ. ਫਾਇਦਾ ਸਪਸ਼ਟਤਾ ਅਤੇ predictable control flow ਹੈ; ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਖਰਾਬੀਸਮਭਾਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੋਰ ਕੋਡ ਹੋਵੇਗਾ, ਖਾਸ ਕਰਕੇ I/O-ਭਾਰੀ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ।
• ਘੱਟ "ਬੈਟਰੀਜ਼-ਇਨਕਲੂਡ" ਫਰੇਮਵਰਕ। Go ਤੁਹਾਨੂੰ ਛੋਟੇ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਨੂੰ ਜੋੜ ਕੇ ਕੰਪੋਜ਼ ਕਰਨ ਵੱਲ ਧਕੇਲਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਵੱਡੇ "ਸਭ ਕੁਝ ਕਰੋ" ਫਰੇਮਵਰਕ ਨੂੰ ਅਪਣਾਉਣ ਵੱਲ। ਇਹ ਲੰਬੇ ਸਮੇਂ ਲਈ ਮਾਇੰਟੇਨੇਬਿਲਟੀ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਉਹ ਟੀਮਾਂ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ ਜਿਹੜੀਆਂ ਬਾਹਰ-ਬਾਹਰ ਤੋਂ conventions ਅਤੇ scaffolding ਤੁਰੰਤ ਚਾਹੁੰਦੀਆਂ ਹਨ।

ਜਦੋਂ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਜਿੱਤ ਸਕਦੀਆਂ ਹਨ

ਭਾਸ਼ਾ ਦੀ ਚੋਣ ਅਕਸਰ ਫਿੱਟ ਬਾਰੇ ਹੁੰਦੀ ਹੈ, ਨਾ ਕਿ "ਸਭ ਤੋਂ ਵਧੀਆ"। ਕੁਝ ਆਮ ਮਾਮਲੇ:

• Python: ਜਦੋਂ ਤੁਹਾਡਾ ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਕੀ ਬਣਾਉਣਾ ਹੈ (ਪ੍ਰਯੋਗ, ਪ੍ਰੋਟੋਟਾਈਪ, ਡੇਟਾ-ਚਲਿਤ ਫੀਚਰ) ਅਤੇ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਇਟਰੇਟ ਕਰਨ ਲਈ ਮੌਜੂਦਾ ML/ਡੇਟਾ ਟੂਲਿੰਗ ਦੀ ਲੋੜ ਹੈ।
• Java (ਜਾਂ Kotlin): ਜਦੋਂ ਤੁਸੀਂ ਡੀਪਲੀ ਇੱਕ ਐਨਟਰਪ੍ਰਾਈਜ਼ ਮਾਹੌਲ ਵਿੱਚ ਇੰਟੇਗਰੇਟ ਕਰ ਰਹੇ ਹੋ ਜੋ ਪਹਿਲਾਂ ਹੀ JVM 'ਤੇ ਚੱਲਦਾ ਹੈ, ਪੱਕੇ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਹਨ, ਅਤੇ ਉਹ ਓਪਰੇਸ਼ਨਲ ਪੈਟਰਨ ਜਿਹੜੇ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਮੰਨਣੇ ਪੈਂਦੇ ਹਨ।

ਇੱਕ ਸਧਾਰਣ ਫੈਸਲਾ ਚੈਕਲਿਸਟ

Go ਨੂੰ ਆਪਣੇ ਮੱਖ-ਸਟੈਕ ਲਈ ਨੂੰਇਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਵਾਲਾਂ ਨਾਲ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ ਜਾਂਚੋ:

1. ਕੀ ਤੁਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਬੈਕਐਂਡ ਸਰਵਿਸਿਜ਼, APIs, ਜਾਂ ਇਨਫ੍ਰਾਸਟ੍ਰਕਚਰ ਕੰਪੋਨੈਂਟਾਂ ਬਣਾਉ ਰਹੇ ਹੋ?
2. ਕੀ ਤੁਹਾਡੀ ਟੀਮ ਉੱਚ-ਸਤਰ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ 'ਤੇ ਨਹੀਂ ਬਲਕਿ ਸਧਾਰਤ, ਸਪਸ਼ਟ ਕੋਡ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦੀ ਹੈ?
3. ਕੀ ਤੁਹਾਨੂੰ static binaries ਅਤੇ ਸਿੱਧੀ ਡਿਪਲੌਇਮੈਂਟ (ਕੰਟੇਨਰ, Kubernetes) ਤੋਂ ਲਾਭ ਹੋਵੇਗਾ?
4. ਕੀ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਲੇਟੇੰਸੀ ਮਹੱਤਵਪૂਰਨ ਉਤਪਾਦ ਲੋੜ ਹੈ?
5. ਕੀ ਤੁਹਾਡੇ ਅਹਮ ਡਿਪੈਂਡੈਂਸੀਜ਼ Go ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਰਥਿਤ ਹਨ (SDKs, ਡੇਟਾਬੇਸ, ਕਿਊਜ਼, ਕਲਾਉਡ ਸਰਵਿਸੇਜ਼)?

ਜੇ ਤੁਸੀਂ ਕਈ ਸਵਾਲਾਂ ਦਾ "ਨਾ" ਜਵਾਬ ਦਿੰਦੇ ਹੋ—ਅਤੇ "ਹਾਂ" UI ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਜਾਂ ਡੇਟਾ-ਸਾਇੰਸ-ਚਲਿਤ ਇਟਰੇਸ਼ਨ ਲਈ—ਤਾਂ Go ਤੁਹਾਡੇ ਸਿਸਟਮ ਦਾ ਕੇਂਦਰ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਹਾਲਾਂਕਿ ਇਹ ਫਰੈਂਟ-ਲਾਈਨ ਕੰਪੋਨੈਂਟ ਵਜੋਂ ਸ਼ਾਮਿਲ ਰਹਿ ਸਕਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤ ਕਰਨ ਲਈ: ਸਟਾਰਟਅਪਸ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ Go ਸਟੈਕ

ਇੱਕ Go ਸਟੈਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਣ ਲਈ ਫੈਨਸੀ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਲਕਸ਼ ਹੈ: ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸਰਵਿਸ ਸ਼ਿਪ ਕਰੋ, ਕੋਡਬੇਸ ਪਾਠਯੋਗ ਰੱਖੋ, ਅਤੇ ਜਦੋਂ ਉਤਪਾਦ ਸਾਬਤ ਕਰੇ ਤਾਂ ਹੀ ਜਟਿਲਤਾ ਜੋੜੋ।

ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਆਰਕੀਟੈਕਚਰ ਜੋ ਤੁਹਾਨੂੰ ਧੀਰਾ ਨਹੀਂ ਕਰੇਗਾ

ਇੱਕ single deployable service (ਇੱਕ ਰੀਪੋ, ਇੱਕ ਬਾਈਨਰੀ, ਇੱਕ ਡੇਟਾਬੇਸ) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ "ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼" ਨੂੰ ਬਾਅਦ ਦੀ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸਮਝੋ।

• ਪਹਿਲਾਂ single service: ਇੱਕ API + ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਜ਼ ਇੱਕੋ ਕੋਡਬੇਸ ਵਿੱਚ (ਵੱਖ-ਵੱਖ ਪੈਕੇਜ), ਇੱਕ deployment।
• ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਵੰਡੋ: ਸੇਵਾ ਨੂੰ ਤਦ ਤਕ ਵੱਖ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ownership ਬੰਡੀ, ਸਕੇਲਿੰਗ ਲੋੜਾ, ਜਾਂ ਡਿਪਲੌਇਮੈਂਟ ਕੈਡੈਂਸ ਟਕਰਾਅ ਦਾ ਸਪਸ਼ਟ ਕਾਰਨ ਨਾ ਹੋਵੇ।

ਆਮ ਬਣਨ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲਾਕ (ਸਧਾਰਣ ਡਿਫਾਲਟ)

ਬੋਰੀੰਗ ਤੇ ਚੰਗੇ ਸਹਾਇਕ ਲਾਇਬ੍ਰੇਰੀ ਚੁਣੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਸਥਿਰ ਕਰੋ।

• Router: net/http ਨਾਲ chi ਜਾਂ gorilla/mux (ਜਾਂ ਜੇ ਟੀਮ ਚਾਹੇ ਤਾਂ ਹਲਕਾ ਫਰੇਮਵਰਕ)।
• Config: environment variables + ਇੱਕ ਛੋਟਾ ਲੋਡਰ (ਜਿਵੇਂ viper ਜਾਂ ਹਲਕੀ custom config ਪੈਕੇਜ)।
• Logging: structured logs zap ਜਾਂ zerolog ਰਾਹੀਂ।
• Database access: database/sql + sqlc (type-safe queries) ਜਾਂ gorm ਜੇ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ।
• Migrations: golang-migrate/migrate ਜਾਂ goose।

CI/CD ਜਰੂਰੀ ਚੀਜ਼ਾਂ ਰੋਜ਼ਾਨਾ ਸ਼ਿਪਿੰਗ ਲਈ

ਪਾਇਪਲਾਈਨ ਸਖਤ ਪਰ ਤੇਜ਼ ਰੱਖੋ।

• ਹਰ PR 'ਤੇ go test ./..., golangci-lint, ਅਤੇ gofmt (ਜਾਂ goimports) ਚਲਾਓ।
• ਇੱਕ ਵਰਜ਼ਨਡ ਆਰਟੀਫੈਕਟ (ਕੰਟੇਨਰ ਇਮੇਜ ਜਾਂ ਸਾਦਾ ਬਾਈਨਰੀ) ਬਣਾਓ, ਅਤੇ ਇਸਨੂੰ registry ਵਿੱਚ ਸਟੋਰ ਕਰੋ।
• ਡਿਪਲੌਇਮੈਂਟ ਤੋਂ ਬਾਅਦ ਇੱਕ ਬੇਸਿਕ smoke ਟੈਸਟ ਕਦਮ ਜੋੜੋ (health endpoint + ਇੱਕ ਅਹੰਕਾਰਪੂਰਨ ਡਿਪੈਂਡੈਂਸੀ ਚੈੱਕ)।

ਜਿੱਥੇ Koder.ai ਫਿੱਟ ਹੁੰਦਾ ਹੈ (ਜਦੋਂ ਤੁਸੀਂ ਪੂਰਾ ਉਤਪਾਦ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ)

ਜੇ ਤੁਹਾਡਾ ਸਟਾਰਟਅਪ ਕੇਵਲ "Go ਸਰਵਿਸ" ਤੋਂ ਵੱਧ ਕਿਛ ਬਣਾਉਣ ਵਾਲਾ ਹੈ—ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕ ਬੈਕਐਂਡ API ਅਤੇ ਇੱਕ ਵੈੱਬ ਡੈਸ਼ਬੋਰਡ—ਤਾਂ Koder.ai ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਐਕਸੇਲੇਰੇਟਰ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸਾਦੀ ਚੈਟ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਵੈੱਬ, ਸਰਵਰ, ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ, agent-based ਆਰਕੀਟੈਕਚਰ ਹੇਠਾਂ।

Go ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਨ ਵਾਲੀਆਂ ਟੀਮਾਂ ਲਈ, ਇਹ ਆਮ ਸਟਾਰਟਅਪ ਡਿਫਾਲਟਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਿਲਦਾ ਹੈ: Go backend + PostgreSQL, ਅਤੇ ਇੱਕ React ਵੈੱਬ ਐਪ (ਵਿਕਲਪਿਕ Flutter ਮੋਬਾਈਲ ਲਈ)। ਤੁਸੀਂ "planning mode" ਵਿੱਚ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਡਿਪਲੌਇ ਅਤੇ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹੋ, ਕਸਟਮ ਡੋਮੇਨ ਵਰਤ ਸਕਦੇ ਹੋ, ਅਤੇ ਫ਼੍ਰਿਕਵੈਂਟ ਰਿਲੀਜ਼ਜ਼ ਨੂੰ ਘੱਟ ਖਤਰਿਆਂ ਨਾਲ ਕਰਨ ਲਈ snapshots/rollback 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ ਹੋ—ਉਹੀ ਓਪਰੇਸ਼ਨਲ ਵਰਕਫਲੋ ਜੋ Go ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਮਾਣਦੀਆਂ ਹਨ।

30–60–90 ਦਿਨਾਂ ਦੀ ਅਪਣਾਉਣ ਯੋਜਨਾ

30 ਦਿਨ: ਸਧਾਰਨ ਪ੍ਰੋਜੈਕਟ ਲੇਆਊਟ, ਲੋਗਿੰਗ ਪਰੰਪਰਾਵਾਂ, ਇੱਕ ਡਿਪਲੌਇਮੈਂਟ ਪਾਈਪਲਾਈਨ, ਅਤੇ "ਅਸੀਂ Go ਕਿਵੇਂ ਲਿਖਦੇ ਹਾਂ" ਦਸਤਾਵੇਜ਼।

60 ਦਿਨ: ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਟੈਸਟ, CI ਵਿੱਚ migrations, ਅਤੇ ਸਧਾਰਨ on-call ਰਨਬੁੱਕਸ (ਡਿਬੱਗ, ਰੋਲਬੈਕ, ਅਤੇ ਲਾਗ ਪੜ੍ਹਨ ਦੇ ਤਰੀਕੇ)।

90 ਦਿਨ: ਸੇਵਾ ਹੱਦਾਂ ਨੂੰ ਸਿਰਫ਼ ਜਦੋਂ ਸਾਬਤ ਹੋਵੇ ਤਦ ਵੰਡੋ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਬਜਟ ਲਗਾਓ (timeouts, DB pool ਸੀਮਾਵਾਂ, ਅਤੇ staging ਵਿੱਚ ਲੋਡ ਟੈਸਟ)।