ਇੱਕ ਪ੍ਰਯੋਗਕ ਗਾਈਡ ਕਿ Ryan Dahl ਦੀਆਂ Node.js ਅਤੇ Deno ਚੋਣਾਂ ਨੇ ਕਿਵੇਂ ਬੈਕਐਂਡ JavaScript, ਟੂਲਿੰਗ, ਸੁਰੱਖਿਆ ਅਤੇ ਰੋਜ਼ਾਨਾ ਡੈਵਲਪਰ ਵਰਕਫਲੋ ਨੂੰ ਆਕਾਰ ਦਿੱਤਾ — ਅਤੇ ਅੱਜ ਕਿਵੇਂ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ JavaScript ਰਨਟਾਈਮ ਸਿਰਫ਼ ਕੋਡ ਚਲਾਉਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਬਿਲਟ-ਇਨ APIs, ਸੁਰੱਖਿਆ ਡਿਫ਼ਾਲਟ, ਪੈਕੇਜਿੰਗ ਅਤੇ ਵੰਡ ਅਤੇ ਉਹ ਰੋਜ਼ਾਨਾ ਟੂਲ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਡੈਵਲਪਰ ਨਿਰਭਰ ਕਰਦੇ ਹਨ — ਇਹ ਸਾਰੇ ਫੈਸਲੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਬੈਕਐਂਡ JavaScript ਦਾ ਅਨੁਭਵ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ ਰਹੇਗਾ: ਤੁਸੀਂ ਸੇਵਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਢਾਂਚਾ ਦਿੰਦੇ ਹੋ, ਪ੍ਰੋਡਕਸ਼ਨ ਮੁੱਦਿਆਂ ਨੂੰ ਕਿਵੇਂ ਡਿਬੱਗ ਕਰਦੇ ਹੋ ਅਤੇ ਤੁਸੀਂ ਕਿੰਨੀ ਨਿਸ਼ਚਿੰਤਤਾ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ।
ਪ੍ਰਦਰਸ਼ਨ ਸਭ ਤੋਂ ਸੁਝවන ਹਿੱਸਾ ਹੈ — ਸਰਵਰ I/O, concurrency ਅਤੇ CPU-ਭਾਰੀ ਟਾਸਕਾਂ ਨੂੰ ਕਿੰਨੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ। ਪਰ ਰਨਟਾਈਮ ਇਹ ਵੀ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਨੂੰ “ਮੁਫ਼ਤ” ਵਿੱਚ ਕੀ ਮਿਲਦਾ ਹੈ। ਕੀ ਤੁਹਾਡੇ ਕੋਲ URLs ਫੈਚ ਕਰਨ, ਫਾਇਲਾਂ ਪੜ੍ਹਨ, ਸਰਵਰ ਸ਼ੁਰੂ ਕਰਨ, ਟੈਸਟ ਚਲਾਉਣ, ਕੋਡ ਲਿੰਟ ਕਰਨ ਜਾਂ ਐਪ ਬੰਡਲ ਕਰਨ ਦੇ ਲਈ ਇੱਕ ਸਟੈਂਡਰਡ ਢੰਗ ਹੈ? ਜਾਂ ਕੀ ਤੁਸੀਂ ਇਹ ਹਿੱਸੇ ਖੁਦ ਜੋੜਦੇ ਹੋ?
ਦੋ ਰਨਟਾਈਮ ਜੇਕਰ ਸਮਾਨ JavaScript ਚਲਾ ਸਕਦੇ ਵੀ ਹਨ, ਤਾਂ ਵੀ ਡੈਵਲਪਰ ਅਨੁਭਵ ਬਹੁਤ ਹੱਦ ਤੱਕ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਪੈਕੇਜਿੰਗ ਵੀ ਮਾਹਤਵਪੂਰਨ ਹੈ: ਮੋਡੀਊਲ ਸਿਸਟਮ, ਡਿਪੇਂਡੈਂਸੀ ਰੇਜ਼ੋਲੇਸ਼ਨ, ਲਾਕਫਾਇਲ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਕਿਵੇਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ — ਇਹ ਸਾਰੇ ਬਣਾਉਣ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਸੁਰੱਖਿਆ ਖ਼ਤਰੇ 'ਤੇ ਅਸਰ ਪਾਉਂਦੇ ਹਨ। ਟੂਲਿੰਗ ਚੋਣ onboarding ਸਮਾਂ ਅਤੇ ਸਾਲਾਂ ਦੇ ਵਿਚਕਾਰ ਕਈ ਸੇਵਾਵਾਂ ਦੀ ਦੇਖਭਾਲ ਦੀ ਲਾਗਤ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਹਨ।
ਇਹ ਕਹਾਣੀ ਅਕਸਰ ਵਿਅਕਤੀਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਘੁੰਮਦੀ ਹੈ, ਪਰ ਇਸਨੂੰ ਸਮਝਣ ਲਈ ਇਹ ਜ਼ਿਆਦਾ ਉਪਯੋਗੀ ਹੈ ਕਿ ਸੀਮਾਵਾਂ ਅਤੇ ਟਰੇਡ-ਆਫ਼ ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਜਾਵੇ। Node.js ਅਤੇ Deno ਵੱਖ-ਵੱਖ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਹਨ: ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਬਾਹਰ JavaScript ਕਿਵੇਂ ਚਲਾਈਏ, ਡਿਪੇਂਡੈਂਸੀਜ਼ ਨੂੰ ਕਿਵੇਂ ਮੈਨੇਜ ਕਰੀਏ, ਅਤੇ ਲਚਕੀਲਾਪਣ ਨੂੰ ਸੁਰੱਖਿਆ ਅਤੇ ਸੰਗਤਤਾ ਨਾਲ ਕਿਵੇਂ ਬੈਲੰਸ ਕਰੀਏ।
ਤੁਸੀਂ ਵੇਖੋਂਗੇ ਕਿ ਕਿਉਂ ਕੁਝ ਸ਼ੁਰੂਆਤੀ Node.js ਚੋਣਾਂ ਨੇ ਇੱਕ ਵੱਡਾ ਐਕੋਸਿਸਟਮ ਖੋਲ੍ਹਿਆ—ਅਤੇ ਉਸ ਐਕੋਸਿਸਟਮ ਨੇ ਬਦਲੇ ਵਿੱਚ ਕੀ ਮੰਗ ਕੀਤੀ। ਤੁਸੀਂ ਇਹ ਵੀ ਵੇਖੋਂਗੇ ਕਿ Deno ਨੇ ਕੀ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਅਤੇ ਉਹਨਾਂ ਬਦਲਾਓਂ ਨਾਲ ਕਿਹੜੀਆਂ ਨਵੀਆਂ ਸੀਮਾਵਾਂ ਆਉਂਦੀਆਂ ਹਨ।
ਇਹ ਲੇਖ ਹੇਠਾਂ ਗੁਜ਼ਰਦਾ ਹੈ:
ਇਹ ਲੇਖ ਡੈਵਲਪਰਾਂ, ਟੈਕ ਲੀਡਾਂ ਅਤੇ ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਲਿਖਿਆ ਗਿਆ ਹੈ ਜੋ ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਲਈ ਰਨਟਾਈਮ ਚੁਣ ਰਹੀਆਂ ਹਨ—ਜਾਂ ਮੌਜੂਦਾ Node.js ਕੋਡ ਦੀ deਖਭਾਲ ਕਰ ਰਹੀਆਂ ਹਨ ਅਤੇ ਵੇਖ ਰਹੀਆਂ ਹਨ ਕਿ Deno ਉਹਨਾਂ ਦੇ ਸਟੈਕ ਦੇ ਕੁਝ ਹਿੱਸਿਆਂ ਲਈ ਫਿੱਟ ਹੈ ਜਾਂ ਨਹੀਂ।
Ryan Dahl ਸਭ ਤੋਂ ਵੱਧ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ Node.js (ਪਹਿਲੀ ਵਾਰੀ 2009 ਵਿੱਚ ਰਿਲੀਜ਼) ਬਣਾਉਣ ਲਈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ Deno ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਨ ਲਈ (2018 ਵਿੱਚ ਐਲਾਨ)। ਇਨ੍ਹਾਂ ਦੋ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਦੇਖਿਆ ਜਾਵੇ ਤਾਂ ਇਹ ਬੈਕਐਂਡ JavaScript ਦੇ ਵਿਕਾਸ ਅਤੇ ਜਦੋਂ ਹਕੀਕਤੀ ਵਰਤੋਂ ਨੇ ਟਰੇਡ-ਆਫ਼ ਖੋਲ੍ਹੇ ਤਾਂ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਕਿਵੇਂ ਬਦਲਦੀਆਂ ਹਨ ਇਹ ਦਾ ਇਕ ਜਨਤਕ ਰਿਕਾਰਡ lagda ਹੈ।
ਜਦੋਂ Node.js ਆਇਆ, ਸਰਵਰ ਵਿਕਾਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ thread-per-request ਮਾਡਲ ਹੋਂਦਾ ਸੀ ਜੋ ਬਹੁਤ ਸਾਰਿਆਂ concurrent connections ਹੇਠੀਂ ਝਿੰਝਟ ਵਿੱਚ ਪੈ ਜਾਂਦਾ ਸੀ। Dahl ਦੀ ਊਹਲੇ ਧਿਆਨ ਸਿੱਧੀ ਸੀ: Google ਦੇ V8 ਇੰਜਣ ਨੂੰ ਇੱਕ ਇਵੈਂਟ-ਚਲਿਤ ਅਪ੍ਰੋਚ ਅਤੇ ਨਾਨ-ਬਲਾਕਿੰਗ I/O ਨਾਲ ਜੋੜਕੇ JavaScript ਵਿੱਚ I/O-ਭਾਰੀ ਨੈਟਵਰਕ ਸਰਵਰ ਬਣਾਉਣਾ ਪ੍ਰਾਇਗਟਕ ਬਣਾਓ।
Node ਦੇ ਲਕਸ਼ ਪ੍ਰਯੋਗਕ ਸੀ: ਕੁਝ ਤੇਜ਼ ਚਲਾਓ, ਰਨਟਾਈਮ ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਅਤੇ ਕਮਿਊਨਿਟੀ ਨੂੰ ਖ਼ਾਲੀਆਂ ਜਗ੍ਹਾ ਭਰਣ ਦਿਓ। ਇਸ ਜ਼ੋਰ ਨੇ Node ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਪਰ ਇਸ ਨਾਲ ਕੁਝ ਅਜਿਹੇ ਰੁਝਾਨ ਵੀ ਬਣ ਗਏ ਜੋ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣਾ ਔਖਾ ਹੋ ਗਿਆ—ਖਾਸਕਰ ਡਿਪੇਂਡੈਂਸੀ কালਚਰ ਅਤੇ ਡਿਫ਼ਾਲਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ।
ਲਗਭਗ ਦਸ ਸਾਲ ਬਾਅਦ, Dahl ਨੇ “10 ਗੱਲਾਂ ਜਿਹੜਿਆਂ ਬਾਰੇ ਮੈਂ Node.js ਬਾਰੇ ਅਫਸੋਸ ਕਰਦਾ ਹਾਂ” ਪੇਸ਼ ਕੀਤੀਆਂ। Deno ਉਹ “ਦੂਜਾ ਡਰਾਫਟ” ਹੈ ਜੋ ਉਹਨਾਂ ਅਫਸੋਸਾਂ ਨਾਲ ਰੂਪ ਲੈਂਦਾ ਹੈ, ਸਪਸ਼ਟ ਡਿਫ਼ਾਲਟਸ ਅਤੇ ਇੱਕ ਹੋਰ ਓਪੀਨਿਅਨਟਡ ਡੈਵਲਪਰ ਅਨੁਭਵ ਦੇ ਨਾਲ।
ਲਚਕੀਲਾਪਣ ਨੂੰ ਪਹਿਲਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਨ ਦੇ ਬਜਾਏ, Deno ਦੇ ਲਕਸ਼ ਜ਼ਿਆਦਾ ਤੌਰ 'ਤੇ ਸੁੁਰੱਖਿਅਤ ਐਕਜ਼ੀਕਿਊਸ਼ਨ, ਆਧੁਨਿਕ ਭਾਸ਼ਾ ਸਮਰਥਨ (TypeScript) ਅਤੇ ਬਿਲਟ-ਇਨ ਟੂਲਿੰਗ ਵੱਲ ਹਨ ਤਾਂ ਜੋ ਟੀਮਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਘਣੇ ਤੀਰਥ-ਪਾਰਟੀ ਹਿੱਸਿਆਂ ਦੀ ਲੋੜ ਘਟੇ।
ਦੋਹਾਂ ਰਨਟਾਈਮਾਂ ਵਿੱਚ ਥੀਮ ਇਹ ਹੈ ਕਿ ਇੱਕ ਨੂੰ “ਸਹੀ” ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ—ਸੀਮਾਵਾਂ, ਅਪਣਾਉ ਅਤੇ hindsight ਇੱਕੋ ਵਿਅਕਤੀ ਨੂੰ ਬਹੁਤ ਵੱਖਰੇ ਨਤੀਜਿਆਂ ਲਈ optimize ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ।
Node.js ਸਰਵਰ 'ਤੇ JavaScript ਚਲਾਉਂਦਾ ਹੈ, ਪਰ ਇਸਦਾ ਮੁੱਖ ਵਿਚਾਰ "ਕਿਵੇਂ" ਇਹ ਉਡੀਕ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ ਉੱਪਰ ਜ਼ਿਆਦਾ ਧਿਆਨ ਹੈ।
ਜਿਆਦਾਤਰ ਬੈਕਐਂਡ ਕੰਮ ਉਡੀਕ ਹੁੰਦਾ ਹੈ: ਡੇਟਾਬੇਜ਼ ਕ੍ਵੈਰੀ, ਫਾਇਲ ਰੀਡ, ਦੂਜੇ ਸਰਵਿਸ ਤੱਕ ਨੈਟਵਰਕ ਕਾਲ। Node.js ਵਿੱਚ, ਇਵੈਂਟ ਲੂਪ ਇਕ ਕੋਆਰਡੀਨੇਟਰ ਵਾਂਗ ਹੈ ਜੋ ਇਹਨਾਂ ਟਾਸਕਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡਾ ਕੋਡ ਕਿਸੇ ਸਮੇਂ ਲੈਣ ਵਾਲੀ ਕਾਰਵਾਈ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ ਇੱਕ HTTP ਬੇਨਤੀ), Node ਉਸ ਉਡੀਕ ਵਾਲੇ ਕੰਮ ਨੂੰ ਸਿਸਟਮ ਨੂੰ ਸੌਂਪ ਦਿੰਦਾ ਹੈ, ਫਿਰ ਤੁਰੰਤ ਅੱਗੇ ਵੱਧ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਨਤੀਜਾ ਤਿਆਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਵੈਂਟ ਲੂਪ ਇੱਕ callback ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਰੱਖਦਾ ਹੈ (ਜਾਂ Promise ਨੂੰ resolve ਕਰਦਾ ਹੈ) ਤਾਂ ਜੋ ਤੁਹਾਡੀ JavaScript ਨਤੀਜੇ ਨਾਲ ਅੱਗੇ ਜਾ ਸਕੇ।
Node.js JavaScript ਇੱਕ ਮੁੱਖ ਸਿੰਗਲ ਥਰੇਡ 'ਚ ਚਲਦੀ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਇਕ ਸਮੇਂ ਇੱਕ ਟੁਕੜਾ JS ਚਲਦਾ ਹੈ। ਇਹ ਸੀਮਾ ਲੱਗ ਸਕਦੀ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ ਕਿ ਇਹ ਉਦੋਂ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਜੋ ਉਸ ਥਰੇਡ ਦੇ ਅੰਦਰ "ਉਡੀਕ" ਨਾ ਕੀਤੀ ਜਾਵੇ।
ਨਾਨ-ਬਲਾਕਿੰਗ I/O ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਸਰਵਰ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਕਬੂਲ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਪਿਛਲੀਆਂ ਅਜੇ ਵੀ ਡੇਟਾਬੇਜ਼ ਜਾਂ ਨੈਟਵਰਕ 'ਤੇ ਉਡੀਕ ਕਰ ਰਹੀਆਂ ਹਨ। concurrency ਹਾਸਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
ਇਸ ਲਈ Node ਬਹੁਤ ਸਾਰੀਆਂ ਇੱਕੱਠੀਆਂ ਕਨੈਕਸ਼ਨਾਂ ਹੇਠਾਂ “ਤੇਜ਼” ਮਹਿਸੂਸ ਕਰ ਸਕਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਤੁਹਾਡੀ JS ਮੁੱਖ ਥਰੇਡ ਵਿੱਚ ਪੈਰਲੇਲ ਨਹੀਂ ਚਲ ਰਹੀ।
Node ਅੱਛਾ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਉਡੀਕ ਵਿੱਚ ਲੰਘਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਗਣਨਾ 'ਚ ਲਗਾਉਂਦੀ ਹੈ (ਛਬੀ ਪ੍ਰੋਸੈਸਿੰਗ, ਵੱਡੀ ਪੱਧਰੀ JSON ਬਦਲਾਅ), ਤਾਂ Node ਨੇੜਤਲੇ ਥਰੇਡ ਨੂੰ ਰੋਕ ਦੇਂਦਾ ਹੈ ਅਤੇ ਹਰ ਕੁਝ ਦੇਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।
ਆਮ ਵਿਕਲਪ:
Node APIs ਅਤੇ ਬੈਕਐਂਡ-ਫੋਰ-ਫਰੰਟਐਂਡ ਸਰਵਰਾਂ, ਪ੍ਰਾਕਸੀਜ਼ ਅਤੇ ਗੇਟਵੇਜ਼, ਰੀਅਲ-ਟਾਈਮ ਐਪ (WebSockets), ਅਤੇ ਡੈਵਲਪਰ-ਫ੍ਰੈਂਡਲੀ CLI ਲਈ ਚਮਕਦਾ ਹੈ ਜਿੱਥੇ ਤੇਜ਼ ਸਟਾਰਟਅਪ ਅਤੇ ਰਿਚ ਐਕੋਸਿਸਟਮ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
Node.js ਨੂੰ JavaScript ਨੂੰ ਪ੍ਰਾਇਗਟਕ ਸਰਵਰ ਭਾਸ਼ਾ ਬਣਾਉਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਖਾਸਕਰ ਉਹਨਾਂ ਐਪਾਂ ਲਈ ਜੋ ਬਹੁਤ ਸਮਾਂ ਨੈਟਵਰਕ ਦੀ ਉਡੀਕ ਵਿੱਚ ਬਿਤਾਉਂਦੀਆਂ ਹਨ: HTTP ਰਿਕਵੇਸਟ, ਡੇਟਾਬੇਜ਼, ਫਾਇਲ ਰੀਡ ਅਤੇ APIs। ਇਸਦਾ ਮੁੱਖ ਸੋਚ ਇਹ ਸੀ ਕਿ ਥਰੂਪੁਟ ਅਤੇ ਜਵਾਬਦੇਹੀ "ਹਰ ਬੇਨਤੀ ਲਈ ਇੱਕ ਥਰੇਡ" ਦੇ ਮਾਡਲ ਤੋਂ ਜ਼ਿਆਦਾ ਗਿਣਤੀਵਾਰ ਹਨ।
Node Google ਦੀ V8 ਇੰਜਣ (ਤੇਜ਼ JavaScript ਐਗਜ਼ੀਕਿਊਸ਼ਨ) ਨੂੰ libuv ਨਾਲ ਜੋੜਦਾ ਹੈ, ਜੋ ਇਕ C ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਇਵੈਂਟ ਲੂਪ ਅਤੇ ਨਾਨ-ਬਲਾਕਿੰਗ I/O ਨੂੰ ਵੱਖ-ਵੱਖ OS ਉੱਤੇ ਹੈਂਡਲ ਕਰਦੀ ਹੈ। ਇਸ ਮਿਲਾਪ ਨੇ Node ਨੂੰ ਇੱਕ single-process ਅਤੇ ਇਵੈਂਟ-ਚਲਿਤ ਰਹਿਣ ਦਿਤਾ, ਜਿਵੇਂ ਕਿ ਕਈ ਸੰਚਾਰਕ ਕਨੈਕਸ਼ਨ ਹੇਠਾਂ ਵੀ ਚੰਗਾ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਸਕੇ।
Node ਨੇ ਕੁਝ ਪ੍ਰੈਗਮੈਟਿਕ ਕੋਰ ਮੋਡੀਊਲਜ਼ ਵੀ ਦਿੱਤੇ — ਖ਼ਾਸਕਰ http, fs, net, crypto, ਅਤੇ stream — ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੀਬਰ ਤੌਰ 'ਤੇ ਤੀਨ-ਚਾਰ ਪੈਕੇਜਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਹਕੀਕਤੀ ਸਰਵਰ ਬਣਾ ਸਕੋ।
ਟਰੇਡ-ਆਫ਼: ਛੋਟੀ standard library ਨੇ Node ਨੂੰ ਹਲਕਾ ਰੱਖਿਆ, ਪਰ ਇਸਨੇ ਡੇਵਲਪਰਾਂ ਨੂੰ ਪਹਿਲੇ ਤੋਂ ਹੀ ਬਾਹਰੀ ਡਿਪੇਂਡੈਂਸੀਜ਼ ਵੱਲ ਧੱਕ ਦਿੱਤਾ।
ਸ਼ੁਰੂਆਤੀ Node callbacks 'ਤੇ ਜ਼ੋਰ ਕਰਦਾ ਸੀ ਤਾਂ ਜੋ "ਜਦ I/O ਖਤਮ ਹੋਵੇ ਤਾਂ ਇਹ ਕਰੋ" ਨੂੰ ਦਰਸਾਇਆ ਜਾ ਸਕੇ। ਇਹ ਨਾਨ-ਬਲਾਕਿੰਗ I/O ਨਾਲ ਉਚਿਤ ਫਿੱਟ ਸੀ, ਪਰ ਇਸ ਨੇ ਕੋਈ-ਕੋਈ ਘੁੰਮਦੇ ਹੋਏ ਕੋਡ ਅਤੇ ਐਰਰ-ਹੈਂਡਲਿੰਗ ਰੁਝਾਨ ਛੱਡੇ।
ਕੱਲਾਂ ਦੇ ਨਾਲ, ecosystem ਨੇ Promises ਅਤੇ ਫਿਰ async/await ਵੱਲ ਮੂੰਹ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਕੋਡ synchronous ਲਾਜ਼ਮੀ ਪੜ੍ਹਨ ਵਾਲਾ ਬਣ ਗਿਆ ਪਰ ਨਾਨ-ਬਲਾਕਿੰਗ ਵਰਤੋਂ ਜਾਰੀ ਰਹੀ।
ਟਰੇਡ-ਆਫ਼: ਪਲੇਟਫਾਰਮ ਨੂੰ ਕਈ ਪੀੜੀਆਂ ਦੇ ਪੈਟਰਨ ਸਹਿਣੇ ਪਏ, ਅਤੇ ਟਿਊਟੋਰੀਅਲ, ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਟੀਮ ਕੋਡਬੇਸ ਅਕਸਰ ਮਿਸ਼ਰਤ ਅੰਦਾਜ਼ ਵਿੱਚ ਰਹੇ।
Node ਦੀ ਬੈਕਵਰਡ ਕੰਪੈਟਬਿਲਿਟੀ ਵਪਾਰਾਂ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ ਹੈ: ਅਪਗ੍ਰੇਡ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕਦਮ ਤੋਟਲ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਨਹੀਂ ਤੋੜਦੇ, ਅਤੇ ਕੋਰ APIs ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ।
ਟਰੇਡ-ਆਫ਼: ਇਹ ਸਥਿਰਤਾ "ਕਲੀਨ ਬ੍ਰੇਕ" ਸੁਧਾਰਾਂ ਨੂੰ ਦੇਰ ਜਾਂ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀ ਹੈ। ਕੁਝ ਅਨਕਾਂਨੀ ਅਤੇ ਲੈਗਸੀ APIs ਰਹਿ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਹਟਾਉਣਾ ਮੌਜੂਦਾ ਐਪਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ।
Node ਦੀ ਯੋਗਤਾ C/C++ ਬਾਈਂਡਿੰਗਜ਼ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਨੇ ਪਰਫਾਰਮੈਂਸ-ਕ੍ਰਿਟੀਕਲ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਸਿਸਟਮ ਫੀਚਰਾਂ ਤੱਕ ਪਹੁੰਚ ਦਿੰਦੀ — ਇਹ ਨੈਟਿਵ ਐਡਨਾਂ ਰਾਹੀਂ ਸੰਭਵ ਹੋਇਆ।
ਟਰੇਡ-ਆਫ਼: ਨੈਟਿਵ ਐਡਨਾਂ ਪਲੇਟਫਾਰਮ-ਨਿਰਧਾਰਤ ਬਿਲਡ ਸਟੈਪ, ਮੁਸ਼ਕਲ ਇੰਸਟਾਲੇਸ਼ਨ ਫੇਲ੍ਹਰ ਅਤੇ ਸੁਰੱਖਿਆ/ਅਪਡੇਟ ਬੋਝ ਲਿਆ ਸਕਦੇ ਹਨ—ਖ਼ਾਸਕਰ ਜਦ ਡਿਪੇਂਡੈਂਸੀ ਵੱਖ-ਵੱਖ ਮਾਹੌਲਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਕੰਪਾਇਲ ਹੁੰਦੀ ਹੈ।
ਕੁੱਲ ਮਿਲਾ ਕੇ, Node ਨੇ ਨੈਟਵਰਕਡ ਸੇਵਾਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਅਤੇ ਬਹੁਤ ਸਾਰੇ I/O ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਨ ਲਈ optimize ਕੀਤਾ—ਪਰ ਇਸ ਨੇ ਕੰਪੈਟਬਿਲਿਟੀ, ਡਿਪੇਂਡੈਂਸੀ ਕਲਚਰ, ਅਤੇ ਲੰਬੀ ਅਵਧੀ API ਵਿਕਾਸ ਵਿੱਚ ਜਟਿਲਤਾ ਨੂੰ ਸਵੀਕਾਰਿਆ।
npm ਉਹ ਵੱਡਾ ਕਾਰਣ ਹੈ ਜਿਸ ਨਾਲ Node.js ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਿਆ। ਇਸਨੇ “ਮੈਨੂੰ ਇੱਕ ਵੈੱਬ ਸਰਵਰ + ਲੋਗਿੰਗ + ਡੇਟਾਬੇਜ਼ ਡਰਾਈਵਰ ਚਾਹੀਦਾ” ਨੂੰ ਕੁਝ ਕਮਾਂਡਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ, ਲੱਖਾਂ ਪੈਕੇਜ ਤੁਰੰਤ ਪਲੱਗ-ਇਨ ਲਈ ਤਿਆਰ। ਟੀਮਾਂ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ, ਸਾਂਝੇ ਹੱਲ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੀ ਸਮੁਦਾਇਕ ਜਾਣਕਾਰੀ ਸੀ।
npm ਇਨਸਟਾਲ ਅਤੇ ਪ੍ਰਕਾਸ਼ਨ ਦੇ ਢੰਗ ਨੂੰ ਸਥਿਰ ਕਰਕੇ ਬੈਕਐਂਡ ਬਣਾਉਣ ਦੀ ਲਾਗਤ ਘਟਾ ਦਿੱਤੀ। JSON ਵੈਲੀਡੇਸ਼ਨ, ਤਾਰੀਖ ਹੈਲਪਰ ਜਾਂ HTTP ਕੁਲਾਇੰਟ ਦੀ ਲੋੜ? ਸੰਭਵ ਹੈ ਕਿ ਕੋਈ ਪੈਕੇਜ ਹੈ—ਉਸਦੇ ਨਾਲ ਉਦਾਹਰਨ, ਮਸਲੇ ਅਤੇ ਕਮਿਊਨਿਟੀ ਗਿਆਨ ਵੀ ਮਿਲਦਾ ਹੈ। ਇਹ ਡਿਲਿਵਰੀ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਖ਼ਾਸਕਰ ਜਦ ਤੁਸੀਂ ਕਈ ਛੋਟੇ ਫੀਚਰਾਂ ਨੂੰ ਟਾਈਟ ਡੈਡਲਾਈਨ ਹੇਠਾਂ ਜੋੜ ਰਹੇ ਹੋ।
ਟਰੇਡ-ਆਫ਼ ਇਹ ਹੈ ਕਿ ਇੱਕ ਡਾਇਰੈਕਟ ਡਿਪੇਂਡੈਂਸੀ ਦਰਅਸਲ ਦਹਾਂਹਾਂ (ਜਾਂ ਸੈਂਕੜੇ) ਅਪਰੋਖ ਡਿਪੇਂਡੈਂਸੀ ਲਿਆ ਸਕਦੀ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ ਟੀਮਾਂ ਅਕਸਰ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਮਿਲਦੀਆਂ ਹਨ:
Semantic Versioning ਆਰਾਮਦਾਇਕ ਲੱਗਦੀ ਹੈ: ਪੈਚ ਰਿਲੀਜ਼ ਸੁਰੱਖਿਅਤ ਹਨ, ਮਾਈਨਰ ਫੀਚਰ ਸ਼ਾਮਿਲ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਤੋੜ-ਛਾਡ ਦੇ, ਅਤੇ ਮੇਜਰ ਰਿਲੀਜ਼ ਟੂਟ ਸਕਦੀਆਂ ਹਨ। ਹਕੀਕਤ ਵਿੱਚ, ਵੱਡੇ ਡਿਪੇਂਡੈਂਸੀ ਗ੍ਰਾਫ SemVer ਦੀ ਗਾਰੰਟੀ ਨੂੰ ਕਰਹਲਦੀ ਹੈ।
ਕਈ ਵਾਰ ਮੇਨਟੇਨਰ minor ਹੇਠਾਂ breaking changes ਪੁਬਲਿਸ਼ ਕਰ ਦਿੰਦੇ ਹਨ, ਪੈਕੇਜ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਇੱਕ “ਸੁਰੱਖਿਅਤ” ਅਪਡੇਟ ਗਹਿਰੀ ਟ੍ਰਾਂਜ਼ੀਟਿਵ ਡਿਪੇਂਡੈਂਸੀ ਰਾਹੀਂ ਵਿਵਹਾਰ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜਦ ਤੁਸੀਂ ਇੱਕ ਚੀਜ਼ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਈ ਚੀਜ਼ਾਂ ਅੱਪਡੇਟ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਕੁਝ ਅਭਿਆਸ ਜੋ ਰਿਸਕ ਘਟਾਉਂਦੇ ਹਨ ਬਿਨਾਂ ਵਿਕਾਸ ਨੂੰ ਧੀਮਾ ਕੀਤੇ:
package-lock.json, npm-shrinkwrap.json, ਜਾਂ yarn.lock) ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕਮਿੱਟ ਕਰੋnpm audit ਬੇਸਲਾਈਨ ਹੈ; ਸ਼ੈਡਿਊਲਡ dependency review 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰੋnpm ਇੱਕ ਤੇਜ਼ੀ ਲਿਆਉਣ ਵਾਲਾ ਤਾਕਤਵਰ ਚੀਜ਼ ਹੈ ਅਤੇ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਵੀ: ਇਹ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ dependency hygiene ਨੂੰ ਬੈਕਐਂਡ ਕੰਮ ਦਾ ਇੱਕ ਅਹੰਕਾਰ ਭਾਗ ਬਣਾਉਂਦਾ ਹੈ।
Node.js ਮਸ਼ਹੂਰ ਤਰੀਕੇ ਨਾਲ ਅਣ-ਓਪੀਨੀਅਨਟਡ ਹੈ। ਇਹ ਇੱਕ ਮਜ਼ਬੂਤੀ ਹੈ — ਟੀਮਾਂ ਬਿਲਕੁਲ ਉਹੀ ਵਰਕਫਲੋ ਜੋ ਉਹ ਚਾਹੁੰਦੇ ਹਨ, ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਅਸੈਂਬਲ ਕਰ ਸਕਦੀਆਂ ਹਨ — ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਇੱਕ "ਆਮ" Node ਪ੍ਰੋਜੈਕਟ ਵਾਸਤਵ ਵਿੱਚ ਕਮਿਊਨਿਟੀ ਰਿਵਾਜਾਂ ਤੋਂ ਬਣੀ ਇੱਕ ਪਰੰਪਰਾ ਹੁੰਦੀ ਹੈ।
ਬਹੁਤ ਸਾਰੇ Node ਰੇਪੋ package.json ਫਾਇਲ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਹੋਂਦੇ ਹਨ ਜੋ ਇਕ ਕੰਟਰੋਲ ਪੈਨਲ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ:
dev / start ਐਪ ਚਲਾਉਣ ਲਈbuild ਕੰਪਾਇਲ ਜਾਂ ਬੰਡਲ ਕਰਨ ਲਈ (ਜਦ ਲੋੜ ਹੋਵੇ)test ਟੈਸਟ ਰਨਰ ਚਲਾਉਣ ਲਈlint ਅਤੇ format ਕੋਡ ਸਟਾਈਲ ਦੀ ਨਿਗਰਾਨੀ ਲਈtypecheckਇਹ ਪੈਟਰਨ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਟੂਲ ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਜੁੜ ਸਕਦਾ ਹੈ, ਅਤੇ CI/CD ਸਿਸਟਮ ਉਹੀ ਆਦੇਸ਼ ਚਲਾ ਸਕਦੇ ਹਨ।
ਇੱਕ Node ਵਰਕਫਲੋ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਵੱਖ-ਵੱਖ ਟੂਲਾਂ ਦਾ ਸੈੱਟ ਬਣ ਜਾਂਦਾ ਹੈ:
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ “ਗਲਤ” ਨਹੀਂ ਹੈ — ਇਹ ਤਾਕਤਵਰ ਹਨ, ਅਤੇ ਟੀਮਾਂ best-in-class ਵਿਕਲਪ ਚੁਣ ਸਕਦੀਆਂ ਹਨ। ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਟੂਲਚੇਨ integrate ਕਰ ਰਹੇ ਹੋ, ਸਿਰਫ਼ application ਕੋਡ ਨਹੀਂ ਲਿਖ ਰਹੇ।
ਕਿਉਂਕਿ ਟੂਲ ਵਿਕਾਸ ਅਲੱਗ-ਅਲੱਗ ਹੋਏ ਹਨ, Node ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਮਲੀ ਰੁਕਾਵਟਾਂ ਆ ਸਕਦੀਆਂ ਹਨ:
ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਦਰਦ ਨਵੇਂ ਰਨਟਾਈਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ — ਖਾਸਕਰ Deno — ਜੋ ਵੱਧ ਡਿਫ਼ਾਲਟਸ (formatter, linter, test runner, TypeScript ਸਹਾਇਆ) ਸਿੱਧਾ ਸ਼ਿਪ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਟੀਮਾਂ ਘੱਟ ਚਲਦਾ ਹਿੱਸਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਣ ਅਤੇ ਜਦ ਦਿਖਾਈ ਦੇ ਕਿ ਜ਼ਰੂਰੀ, ਤਾਂ ਹੀ ਜਟਿਲਤਾ ਜੋੜੀ ਜਾਵੇ।
Deno ਇੱਕ ਦੂਜੀ ਕੋਸ਼ਿਸ਼ ਵਾਂਗ ਬਣਾਇਆ ਗਿਆ ਸੀ ਇੱਕ JavaScript/TypeScript ਸਰਵਰ ਰਨਟਾਈਮ ਵਜੋਂ — ਜੋ ਕੁਝ ਸ਼ੁਰੂਆਤੀ Node.js ਫੈਸਲਿਆਂ ਨੂੰ ਮੁੜ ਸੋਚਦਾ ਹੈ ਜਦ ਸਾਲਾਂ ਦੀ ਹਕੀਕਤੀ ਵਰਤੋਂ ਨੇ ਉਹ ਗਲਤੀਆਂ ਖੋਲ੍ਹ ਦਿੱਤੀਆਂ।
Ryan Dahl ਜਨਤਕ ਤੌਰ 'ਤੇ ਦਰਸਾ ਚੁੱਕੇ ਹਨ ਕਿ ਜੇ ਉਹ ਮੁੜ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੁੰਦੇ ਤਾਂ ਉਹ ਕੀ ਬਦਲਦੇ: ਜਟਿਲ ਡਿਪੇਂਡੈਂਸੀ ਟ੍ਰੀਜ਼ ਨਾਲ ਪੈਦਾ ਹੋਣ ਵਾਲੀ ਰੁਕਾਵਟ, ਪਹਿਲ-ਕਲਾਸ ਸੁਰੱਖਿਆ ਮਾਡਲ ਦੀ ਘਾਟ ਅਤੇ ਡੈਵਲਪਰ ਸੁਵਿਧਾਵਾਂ ਦਾ ਬੋਲਟ-ਆਨ ਹੋਕੇ ਲਾਜ਼ਮੀ ਹੋ ਜਾਣਾ। Deno ਦੀਆਂ ਪ੍ਰੇਰਣਾਵਾਂ ਨੂੰ ਸਾਰਾਂਸ਼ ਰੂਪ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦੱਸਿਆ ਜਾ ਸਕਦਾ ਹੈ: ਡਿਫ਼ਾਲਟ ਵਰਕਫਲੋ ਨੂੰ ਸਧਾਰਨਾ, ਰਨਟਾਈਮ ਵਿੱਚ ਸੁਰੱਖਿਆ ਨੂੰ explicit ਬਣਾ ਕੇ ਰੱਖਣਾ, ਅਤੇ standards ਅਤੇ TypeScript ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪਲੇਟਫਾਰਮ ਨੂੰ ਆਧੁਨਿਕ ਕਰਨਾ।
Node.js ਵਿੱਚ, ਇੱਕ ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਨੈਟਵਰਕ, ਫਾਇਲ ਸਿਸਟਮ ਅਤੇ ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲਾਂ ਤਕ ਬਿਨਾਂ ਪੂਛੇ ਪਹੁੰਚ ਰੱਖਦੀ ਹੈ। Deno ਇਹ ਡਿਫ਼ਾਲਟ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ, ਇੱਕ Deno ਪ੍ਰੋਗਰਾਮ ਕੋਈ ਸੰਵੇਦਨਸ਼ੀਲ ਸਮਰੱਥਾ ਨਹੀਂ ਰੱਖਦਾ।
ਦਿਨ-ਰੋਜ਼ਾਨਾ ਲਈ ਇਹਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਰਨਟਾਈਮ ਤੇ ਪਰਮਿਸ਼ਨਾਂ ਇਰਾਦਤਨبيعات਼ ਤੌਰ ਤੇ ਦਿੰਦੇ ਹੋ:
--allow-read=./data--allow-net=api.example.com--allow-envਇਸ ਨਾਲ ਆਦਤਾਂ ਬਦਲਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਤੰਗ ਰੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਸਿਗਨਲ ਮਿਲਦਾ ਹੈ ਜਦ ਕੋਈ ਕੋਡ ਅਣਜਾਣੇ ਤਰੀਕੇ ਨਾਲ ਕੁਝ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਖੁਦ ਵਿੱਚ ਪੂਰਾ ਸੁਰੱਖਿਆ ਹੱਲ ਨਹੀਂ ਹੈ (ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਕੋਡ ਸਮੀਖਿਆ ਅਤੇ ਸਪਲਾਈ-ਚੇਨ ਸਫਾਈ ਦੀ ਲੋੜ ਹੈ), ਪਰ ਇਹ least privilege ਦੇ ਰਸਤੇ ਨੂੰ ਡਿਫ਼ਾਲਟ ਬਣਾਉਂਦਾ ਹੈ।
Deno ਮਾਡਿਊਲਾਂ ਨੂੰ URLs ਰਾਹੀਂ ਇੰਪੋਰਟ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਡਿਪੇਂਡੈਂਸੀਜ਼ ਬਾਰੇ ਸੋਚਣ ਦਾ ਢੰਗ ਬਦਲਦਾ ਹੈ। ਲੋਕਲ node_modules ਟ੍ਰੀ ਵਿੱਚ ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਸਿੱਧਾ ਰਿਫਰੈਂਸ ਕਰ ਸਕਦੇ ਹੋ:
import { serve } from "https://deno.land/std/http/server.ts";
ਇਹ ਟੀਮਾਂ ਨੂੰ ਇਹ ਵਿਛੇੜਾ ਦਿੰਦੈ ਕਿ ਕੋਡ ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਹੜੀ ਵਰਜ਼ਨ ਵਰਤੀ ਜਾ ਰਹੀ ਹੈ (ਅਕਸਰ URL ਨੂੰ pin ਕਰਕੇ)। Deno ਰਿਮੋਟ ਮੋਡੀਊਲਜ਼ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਹਰ ਰਨ 'ਤੇ ਦੁਬਾਰਾ ਡਾਊਨਲੋਡ ਨਾ ਕਰੋ — ਪਰ ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਵਰਜ਼ਨਿੰਗ ਅਤੇ ਅਪਡੇਟ ਹਨੇਰੀਟਣ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਰਣਨੀਤੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਉਹੀ ਜਿਵੇਂ ਤੁਸੀਂ npm ਪੈਕੇਜ ਅਪਡੇਟਸ ਨੂੰ ਮੈਨੇਜ ਕਰਦੇ ਹੋ।
Deno ਹਰ ਪ੍ਰੋਜੈਕਟ ਲਈ "Node.js ਤੋਂ ਚੰਗਾ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਰਨਟਾਈਮ ਹੈ ਜਿਸਦੇ ਅਲੱਗ-ਅਲੱਗ ਡਿਫ਼ਾਲਟ ਹਨ। ਜੇ ਤੁਸੀਂ npm ਐਕੋਸਿਸਟਮ, ਮੌਜੂਦਾ ਇੰਫਰਾਸਟਰੱਕਚਰ ਜਾਂ ਸਥਾਪਤ ਪੈਟਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋ ਤਾਂ Node.js ਅਜੇ ਵੀ ਮਜ਼ਬੂਤ ਚੋਣ ਹੈ।
Deno ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਬਿਲਟ-ਇਨ ਟੂਲਿੰਗ, ਇੱਕ ਪਰਮਿਸ਼ਨ ਮਾਡਲ ਅਤੇ URL-ਪਹਿਲਾ ਮੋਡੀਊਲ ਦਿਸ਼ਾ ਨੂੰ ਅਰੰਭ ਤੋਂ ਹੀ ਵਧੀਆ ਮੰਨਦੇ ਹੋ—ਖ਼ਾਸਕਰ ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਲਈ ਜਿੱਥੇ ਇਹ ਧਾਰਨਾਵਾਂ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ।
Deno ਅਤੇ Node.js ਵਿਚਕਾਰ ਮੁੱਖ ਫਰਕ ਇਹ ਹੈ ਕਿ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਡਿਫ਼ਾਲਟ ਤੌਰ 'ਤੇ "ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ"। Node ਮੰਨਦਾ ਹੈ ਕਿ ਜੇ ਤੁਸੀਂ ਸਕ੍ਰਿਪਟ ਚਲਾ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਚਲਾਉਣ ਵਾਲੇ ਯੂਜ਼ਰ ਦੇ ਅਕਾਊਂਟ ਦੀ ਕੋਈ ਵੀ ਪਹੁੰਚ ਰੱਖ ਸਕਦਾ ਹੈ: ਨੈਟਵਰਕ, ਫਾਇਲ, ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਆਦਿ। Deno ਇਹ ਧਾਰਣਾ ਉਲਟ ਦਿੰਦਾ ਹੈ: ਸਕ੍ਰਿਪਟ ਸ਼ੁਰੂ ਵਿੱਚ ਕੋਈ ਪਰਮਿਸ਼ਨ ਨਹੀਂ ਰੱਖਦਾ ਅਤੇ explicit ਤੌਰ 'ਤੇ ਪਹੁੰਚ ਲਈ ਮੰਗ ਕਰਦਾ ਹੈ।
Deno ਸੰਵੇਦਨਸ਼ੀਲ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਗੇਟ ਕੀਤੇ ਫੀਚਰ ਵਾਂਗ ਦੇਖਦਾ ਹੈ। ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਰਨਟਾਈਮ ਤੇ ਦਿੰਦੇ ਹੋ (ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ scope ਵੀ ਕਰ ਸਕਦੇ ਹੋ):
--allow-net): ਕੀ ਕੋਡ HTTP ਰਿਕਵੇਸਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਸਾਕੇਟ ਖੋਲ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਖਾਸ ਹੋਸਟਾਂ ਤੱਕ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਸਿਰਫ਼ api.example.com)।--allow-read, --allow-write): ਕੀ ਕੋਡ ਫਾਇਲ ਪੜ੍ਹ/ਲਿਖ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਕੁਝ ਫੋਲਡਰਾਂ (ਜਿਵੇਂ ./data) ਤਕ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹੋ।--allow-env): ਕੀ ਕੋਡ ਐਨਵਾਇਰਨਮੈਂਟ ਵਿੱਚੋਂ secrets ਅਤੇ configuration ਪੜ੍ਹ ਸਕਦਾ ਹੈ।ਇਸ ਨਾਲ dependency ਜਾਂ ਚਿੱਪੀ ਕੀਤੀ ਕੋਡ ਦੇ "ਬਲਾਸਟ ਰੇਡੀਅਸ" ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਆਪਣੇ ਆਪ ਇੱਕਸ ਵੀ ਉਹਨਾਂ ਜਗ੍ਹਾ ਤੱਕ ਪੁੱਜ ਨਹੀਂ ਸਕਦਾ ਜਿੱਥੇ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਨਹੀਂ ਪਹੁੰਚ ਦਿੱਤੀ ਗਈ।
ਇੱਕ-ਵਾਰੀ ਸਕ੍ਰਿਪਟਾਂ ਲਈ, Deno ਦੇ ਡਿਫ਼ਾਲਟ ਅਕਸਰ ਗਲਤੀ ਨਾਲ ਹੋਣ ਵਾਲੀ ਖੁਲਾਸੇ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਇੱਕ CSV ਪਾਰਸਿੰਗ ਸਕ੍ਰਿਪਟ --allow-read=./input ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ—ਇਸ ਲਈ ਜੇ ਕੋਈ ਡਿਪੇਂਡੈਂਸੀ kompromਮਾਈਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਵੀ ਇਹ ਬਿਨਾਂ --allow-net ਦੇ ਫੋਨ ਕਰਕੇ ਜਾਣ ਨਹੀਂ ਕਰ ਸਕਦੀ।
ਛੋਟੀਆਂ ਸੇਵਾਵਾਂ ਲਈ, ਤੁਸੀਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਸੇਵਾ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ webhook listener ਨੂੰ ਉਦਾਹਰਨ ਵਜੋਂ --allow-net=:8080,api.payment.com ਅਤੇ --allow-env=PAYMENT_TOKEN ਮਿਲ ਸਕਦੇ ਹਨ, ਪਰ ਕੋਈ ਫਾਇਲਸਿਸਟਮ ਪਹੁੰਚ ਨਹੀਂ, ਜਿਸ ਨਾਲ ਡੇਟਾ ਨਿਕਾਸ ਮੁਸ਼ਕਲ ਬਣ ਜਾਂਦਾ ਹੈ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ।
Node ਦੀ ਰਣਨੀਤੀ ਸੁਲਭਤਾ ਹੈ: ਘੱਟ flags, ਘੱਟ “ਇਹ ਕਿਉਂ ਫੇਲ ਹੋ ਰਿਹਾ ਹੈ?” ਮূহਰ। Deno ਦਾ ਅਭਿਗਮ ਪਹਿਲੇ ਚਰਣ ਵਿੱਚ ਰੁਕਾਵਟ ਜੋੜਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਤੈਅ ਕਰਨਾ ਅਤੇ ਘੋਸ਼ਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਕੀ ਕਰ ਸਕੇਗਾ।
ਇਹ ਰੁਕਾਵਟ ਇੱਕ ਫੀਚਰ ਵੀ ਹੋ ਸਕਦੀ ਹੈ: ਇਹ ਟੀਮਾਂ ਨੂੰ ਨੀਅਤ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੀ ਹੈ। ਪਰ ਇਹ ਵਧੇਰੇ ਸੈਟਅੱਪ ਅਤੇ ਕਈ ਵਾਰ ਡਿਬੱਗਿੰਗ ਵੀ ਲਿਆ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਘੱਟ ਪਰਮਿਸ਼ਨ ਕਿਸੇ ਬੇਨਤੀ ਜਾਂ ਫਾਇਲ ਪੜ੍ਹਨ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਟੀਮਾਂ ਪਰਮਿਸ਼ਨਾਂ ਨੂੰ ਐਪ ਦੇ ਠੇਕੇ ਦਾ ਇੱਕ ਹਿੱਸਾ ਬਣਾਉਣ ਲਈ ਇਹ ਤਰੀਕੇ ਵਰਤ ਸਕਦੀਆਂ ਹਨ:
--allow-env ਜੋੜ ਦਿੱਤਾ ਜਾਂ --allow-read ਨੂੰ ਵਧਾਇਆ, ਤਾਂ ਕਾਰਨ ਪੁਛੋਅਗਰ ਨਿਰੰਤਰ ਵਰਤੇ ਜਾਣ ਤਾਂ, Deno ਪਰਮਿਸ਼ਨ ਹਲਕੀ ਫੈਸਲੇਯੋਗ ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉਸ ਢੰਗ ਨਾਲ ਰਹਿੰਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਕੋਡ ਚਲਾਉਂਦੇ ਹੋ।
Deno TypeScript ਨੂੰ ਪਹਿਲਾ-ਕਲਾਸ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ .ts ਫਾਇਲ ਨੂੰ ਸਿੱਧਾ ਚਲਾ ਸਕਦੇ ਹੋ, ਅਤੇ Deno ਪਿੱਛੇ-ਪਿੱਛੇ ਕੰਪਾਇਲੇਸ਼ਨ ਕਦਮ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ, ਇਹ ਪ੍ਰੋਜੈਕਟ ਦੀ "ਆਕਾਰ" ਨੂੰ ਬਦਲਦਾ ਹੈ: ਘੱਟ ਸੈਟਅੱਪ ਫੈਸਲੇ, ਘੱਟ ਚਲਦੇ ਹਿੱਸੇ, ਅਤੇ ਇੱਕ ਸਾਫ਼ ਰਾਹ ਨਵੇਂ ਰੇਪੋ ਤੋਂ "ਚਲਦਾ ਕੋਡ" ਤੱਕ।
Deno ਨਾਲ, TypeScript ਇੱਕ ਨਿਰੀਆਡਤ ਐਡ-ਆਨ ਨਹੀਂ ਰਹਿੰਦਾ ਜੋ ਦਿਨ 1 ਤੇ ਇਕ ਵੱਖਰਾ build chain ਮੰਗਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਬੰਡਲਰ ਚੁਣਨ, tsc ਵੱਖ-ਵੱਖ ਸਟੈਪ ਤੇ ਟਾਈ ਕਰਨ ਜਾਂ ਕਈ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਕਨਫਿਗਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਮਹਿਸੂਸ ਕਰਦੇ ਤਾਂ ਜੋ ਲੋਕਲ ਤੌਰ 'ਤੇ ਕੋਡ ਚੱਲੇ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ TypeScript ਅਦ੍ਰਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ—ਟਾਇਪਸ ਅਜੇ ਵੀ ਮਤਲਬ ਰੱਖਦੇ ਹਨ। ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਰਨਟਾਈਮ ਆਮ TypeScript friction points (ਚਲਾਉਣਾ, ਕੈਸ਼ ਕੀਤਾ ਕੰਪਾਇਲ ਆਉਟਪੁੱਟ, ਅਤੇ ਟਾਈਪ-ਚੈਕਿੰਗ ਉਮੀਦਾਂ ਨਾਲ ਰਨਟਾਈਮ ਵਿਹਾਰ ਨਾਲ ਸੰਗਤੀ) ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੋ ਪ੍ਰੋਜੈਕਟ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਸਟੈਂਡਰਡ ਹੋ ਸਕਣ।
Deno ਕੁਝ ਅਜਿਹੇ ਟੂਲਾਂ ਨਾਲ ਆਉਂਦਾ ਹੈ ਜੋ ਉਹ ਮੁਢਲੇ ਬਹੁਤ ਸਾਰੇ ਟੀਮਾਂ ਤੁਰੰਤ ਲੱਭਦੀਆਂ ਹਨ:
deno fmt) ਕੋਡ ਸਟਾਈਲ ਲਈdeno lint) ਆਮ ਗੁਣਵੱਤਾ ਅਤੇ ਸਹੀਪਨ ਚੈੱਕ ਲਈdeno test) ਯੂਨਿਟ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਚਲਾਉਣ ਲਈਕਿਉਂਕਿ ਇਹ ਬਿਲਟ-ਇਨ ਹਨ, ਇੱਕ ਟੀਮ ਸਾਂਝੀਆਂ ਪਰੰਪਰਾਵਾਂ ਨੂੰ ਅਪਣਾਉਣ ਲਈ ਬੜੀ ਚਰਚਾ ਕਰਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੀ। ਸੰਰਚਨਾ ਆਮ ਤੌਰ 'ਤੇ deno.json ਵਿੱਚ ਕੇਂਦਰਿਤ ਹੁੰਦੀ ਹੈ, ਜੋ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਪੇਸ਼ਗੀ ਪੇਚੀਦਗੀ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
Node ਪ੍ਰੋਜੈਕਟ ਇੱਕੱਤਰ TypeScript ਅਤੇ ਬੇਹਤਰ ਟੂਲਿੰਗ ਨੂੰ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਨ—ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਆਪਣਾ ਵਰਕਫਲੋ ਖੁਦ ਜੋੜਦੇ ਹੋ: typescript, ts-node ਜਾਂ build steps, ESLint, Prettier, ਅਤੇ ਕੋਈ ਟੈਸਟ ਫਰੇਮਵਰਕ। ਉਹ ਲਚਕੀਲਾਪਣ ਕੀਮਤੀ ਹੈ, ਪਰ ਇਹ ਰੇਪੋਜ਼ ਵਿੱਚ ਅਸਮਾਨਤ ਜਥੇਬੰਦੀ ਉਤਪੰਨ ਕਰ ਸਕਦਾ ਹੈ।
Deno ਦਾ ਭਾਸ਼ਾ ਸਰਵਰ ਅਤੇ ਏਡੀਟਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ formatting, linting, ਅਤੇ TypeScript ਫੀਡਬੈਕ ਨੂੰ ਮਸ਼ੀਨਾਂ ਵਿੱਚ ਇੱਕਸਾਰ ਮਹਿਸੂਸ ਕਰਾਉਣ ਲਈ ਨਿਰਦੇਸ਼ਿਤ ਹੈ। ਜਦੋਂ ਹਰ ਕੋਈ ਉਹੀ ਬਿਲਟ-ਇਨ ਕਮਾਂਡ ਚਲਾਉਂਦਾ ਹੈ, "ਮੇਰੀ ਮਸ਼ੀਨ ਤੇ ਕੰਮ ਕਰਦਾ" ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਘੱਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਖਾਸਕਰ ਫਾਰਮੈਟਿੰਗ ਅਤੇ ਲਿੰਟ ਨਿਯਮਾਂ ਸਬੰਧੀ।
ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਇੰਪੋਰਟ ਕਰਦੇ ਹੋ, ਇਹ ਹਰ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ: ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਟੂਲਿੰਗ, ਪ੍ਰਕਾਸ਼ਨ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਟੀਮ ਕਿਸ ਤੇਜ਼ੀ ਨਾਲ ਰਿਵਿਊ ਕਰ ਸਕਦੀ ਹੈ।
Node CommonJS (require, module.exports) ਨਾਲ ਵੱਡਾ ਹੋਇਆ। ਇਹ ਸਧਾਰਨ ਸੀ ਅਤੇ ਸ਼ੁਰੂਆਤੀ npm ਪੈਕੇਜਾਂ ਨਾਲ ਚੰਗਾ ਕੰਮ ਕੀਤਾ, ਪਰ ਇਹ ਨਹੀਂ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰਾਂ ਨੇ ਸਟੈਂਡਰਡ ਕੀਤਾ।
Node ਹੁਣ ES modules (ESM) (import/export) ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਫਿਰ ਵੀ ਕਈ ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਮਿਲੇ-ਜੁਲੇ ਪਰੀਸਥਿਤੀ ਵਿੱਚ ਹਨ: ਕੁਝ ਪੈਕੇਜ CJS-ਮਾਤਰ ਹਨ, ਕੁਝ ESM-ਮਾਤਰ, ਅਤੇ ਐਪਸ ਨੂੰ ਕਈ ਵਾਰ ਅਡੈਪਟਰਾਂ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ। ਇਹ ਬਿਲਡ ਫਲੈਗ, ਫਾਇਲ ਐਕਸਟੇਸ਼ਨ (.mjs/.cjs) ਜਾਂ "type": "module" ਜਿਵੇਂ package.json ਸੈਟਿੰਗਜ਼ ਵਿੱਚ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ।
ਡਿਪੇਂਡੈਂਸੀ ਮਾਡਲ ਆਮ ਤੌਰ 'ਤੇ package-name imports ਹੁੰਦਾ ਹੈ ਜੋ node_modules ਰਾਹੀਂ ਰੇਜ਼ੋਲਵ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਰਜ਼ਨਿੰਗ ਲਾਕਫਾਇਲ ਦੁਆਰਾ ਨਿਯੰਤਰਤ ਹੁੰਦੀ ਹੈ। ਇਹ ਤਾਕਤਵਰ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਇੰਸਟਾਲ ਸਟੈਪ ਅਤੇ ਡਿਪੇਂਡੈਂਸੀ ਟ੍ਰੀ ਤੁਹਾਡੇ ਦਿਨ-ਪ੍ਰਤੀ-ਦਿਨ ਡੀਬੱਗਿੰਗ ਦਾ ਹਿੱਸਾ ਬਣ ਸਕਦੇ ਹਨ।
Deno ਨੇ ESM ਨੂੰ ਡਿਫ਼ਾਲਟ ਮੰਨਿਆ। ਇੰਪੋਰਟ explicit ਹੁੰਦੇ ਹਨ ਅਤੇ ਅਕਸਰ URLs ਜਾਂ absolute paths ਵਰਗੇ ਦਿੱਸਦੇ ਹਨ, ਜੋ ਇਹ ਸਪੱਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕੋਡ ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ ਅਤੇ "ਮੈਜਿਕ ਰੇਜ਼ੋਲਿਊਸ਼ਨ" ਘੱਟ ਕਰਦਾ ਹੈ।
ਟੀਮਾਂ ਲਈ, ਸਭ ਤੋਂ ਵੱਡਾ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਡਿਪੇਂਡੈਂਸੀ ਫੈਸਲੇ ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਜ਼ਿਆਦਾ ਦਿੱਖਦੇ ਹਨ: ਇੱਕ ਇੰਪੋਰਟ ਲਾਈਨ ਅਕਸਰ ਤੁਹਾਨੂੰ ਸ genau})
ਇੱਕ ਰਨਟਾਈਮ ਐਕਜ਼ੀਕਿਊਸ਼ਨ ਵਾਤਾਵਰਣ ਹੈ ਜੋ ਨਿਰਵਾਹੀ API, ਟੂਲਿੰਗ ਦੀਆਂ ਉਮੀਦਾਂ, ਸੁਰੱਖਿਆ ਡਿਫ਼ਾਲਟ ਅਤੇ ਵੰਡਣ ਦੇ ਮਾਡਲ ਨਾਲ ਆਉਂਦਾ ਹੈ। ਇਹ ਫੈਸਲੇ ਇਹ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਸੇਵਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਬਣਾਉਂਦੇ ਹੋ, ਡਿਪੇਂਡੈਂਸੀਜ਼ ਨੂੰ ਕਿਵੇਂ ਮੈਨੇਜ ਕਰਦੇ ਹੋ, ਪ੍ਰੋਡਕਸ਼ਨ ਦੌਰਾਨ ਬੱਗ ਨੂੰ ਕਿਵੇਂ ਡੀਬੱਗ ਕਰਦੇ ਹੋ ਅਤੇ ਰੀਪੋਜ਼ ਵਿੱਚ ਕੰਮਾਂ ਨੂੰ ਕਿਵੇਂ ਸਟੈਂਡਰਡ ਬਣਾਉਂਦੇ ਹੋ — ਸਿਰਫ਼ ਰੌ ਰਨ-ਟਾਈਮ ਦੇ ਪフォਰਫ਼ਾਰਮੈਂਸ ਹੀ ਨਹੀਂ।
Node ਨੇ ਇਕ ਇਵੈਂਟ-ਚਲਿਤ, ਨਾਨ-ਬਲਾਕਿੰਗ I/O ਮਾਡਲ ਪ੍ਰਚਲਿਤ ਕੀਤਾ, ਜੋ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਇੱਕੱਠੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ। ਇਸ ਨੇ JavaScript ਨੂੰ I/O-ਭਾਰੀ ਸਰਵਰਾਂ (API, ਗੇਟਵੇ, ਰੀਅਲ-ਟਾਈਮ) ਲਈ ਵਰਤਣ ਯੋਗ ਬਣਾਇਆ, ਪਰ ਇਹ ਟੀਮਾਂ ਨੂੰ CPU-ਭਾਰ ਵਾਲੇ ਕੰਮਾਂ ਬਾਰੇ ਸੋਚਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਮੇਨ ਥਰੇਡ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹਨ।
Node ਦਾ ਮੁੱਖ JavaScript ਥਰੇਡ ਇੱਕ ਸਮੇਂ ਇੱਕ ਹੀ ਟੁਕੜਾ ਚਲਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਸ ਥਰੇਡ ਵਿੱਚ ਭਾਰੀ ਗਣਨਾ ਕਰਦੇ ਹੋ ਤਾਂ ਹੋਰ ਸਭ ਕੁਝ ਰੁਕ ਜਾਂਦਾ ਹੈ。
ਵਹਿ-ਪ੍ਰਯੋਗਕ ਮਿਤਗੀਆਂ:
ਛੋਟੀ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਰਨਟਾਈਮ ਨੂੰ ਹਲਕਾ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਸਥਿਰਤਾ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਸ ਨਾਲ ਡੇਵਲਪਰਾਂ ਦੀ ਤਰਫ਼ ਥਰਡ-ਪਾਰਟੀ ਪੈਕੇਜਾਂ 'ਤੇ ਨਿਰਭਰਤਾ ਵਧਦੀ ਹੈ। ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਡਿਪੇਂਡੈਂਸੀ ਮੈਨੇਜਮੈਂਟ, ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਅਤੇ ਟੂਲਚੇਨ ਰਖ-ਰਖਾਵ ਦੀ ਲੋੜ ਵਧਾ ਸਕਦਾ ਹੈ।
npm ਵਿਕਾਸ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਈ ਮੌਜੂਦਾ ਪੈਕੇਜ ਇਕ ਕਮਾਂਡ ਨਾਲ ਉਪਲਬਧ ਹਨ, ਪਰ ਇਹ ਵੱਡੇ ਟ੍ਰਾਂਜ਼ੀਟਿਵ ਡਿਪੇਂਡੈਂਸੀ ਟ੍ਰੀਜ਼ ਵੀ ਬਣਾਉਂਦਾ ਹੈ।
ਆਮ ਸੁਰੱਖਿਆ ਅਤੇ ਸਥਿਰਤਾ ਨਿਯਮ:
SemVer ਪੂਰੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿਉਂਕਿ ਵਾਸਤਵ ਵਿੱਚ ਟ੍ਰਾਂਜ਼ੀਟਿਵ ਡਿਪੇਂਡੈਂਸੀਜ਼ ਅਣਗਿਣਤ ਬਦਲਾਵ ਲਿਆ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਸਾਰੇ ਪਰੋਜੈਕਟ ਸਹੀ ਢੰਗ ਨਾਲ SemVer ਨੂੰ ਫੋਲੋ ਨਹੀਂ ਕਰਦੇ।
ਹੈਰਾਨੀਆਂ ਘਟਾਉਣ ਲਈ:
Node ਪ੍ਰੋਜੈਕਟ ਅਕਸਰ ਫਾਰਮੇਟਿੰਗ, ਲਿੰਟਿੰਗ, ਟੈਸਟਿੰਗ, TypeScript ਅਤੇ ਬੰਡਲਿੰਗ ਲਈ ਵੱਖ-ਵੱਖ ਟੂਲ ਜੋੜਦੇ ਹਨ। ਇਹ ਲਚਕੀਲਾਪਣ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ ਪਰ ਕਾਫੀ ਤੇਜ਼ੀ ਨਾਲ ਕੰਫਿਗਰੇਸ਼ਨ ਅਤੇ ਵਰਜਨ-ਸੰਬੰਧੀ ਭਿੰਨਤਾ ਬਣ ਸਕਦੀ ਹੈ।
ਕੁਝ ਵਰਤੋਂਯੋਗ ਰੀਤੀਆਂ:
package.json ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਸਟੈਂਡਰਡ ਬਣਾਓDeno ਇੱਕ “ਦੂਜਾ ਖਾਕਾ” ਹੈ ਜੋ Node ਦੇ ਕੁਝ ਪਹਿਲੇ ਫੈਸਲਿਆਂ ਨੂੰ ਮੁੜ ਵਿਚਾਰਦਾ: ਇਹ TypeScript-ਪਹਿਲਾ ਹੈ, ਬਿਲਟ-ਇਨ ਟੂਲ ਲਿਆਉਂਦਾ (fmt/lint/test), ESM-ਪਹਿਲਾ ਮੋਡੀਊਲ ਸਿਸਟਮ ਵਰਤਦਾ ਅਤੇ ਪਰਮਿਸ਼ਨ-ਆਧਾਰਤ ਸੁਰੱਖਿਆ ਮਾਡਲ ਉਤੇ ਜ਼ੋਰ ਦਿੰਦਾ।
ਇਸਨੂੰ Node ਲਈ ਹਰ ਪ੍ਰੋਜੈਕਟ ਦਾ ਬਦਲ ਨਹੀਂ ਸਮਝਣਾ ਚਾਹੀਦਾ—ਇਹ ਉਨ੍ਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਖਾਸ ਹੈ ਜਿੱਥੇ ਇਹਨਾਂ ਡਿਫ਼ਾਲਟਸ ਦਾ ਫਾਇਦਾ ਹੋਵੇ।
Node ਆਮ ਤੌਰ 'ਤੇ ਸਕ੍ਰਿਪਟ ਨੂੰ ਨੈਟਵਰਕ, ਫਾਇਲਸਿਸਟਮ ਅਤੇ ਐਨਵਾਇਰনਮੈਂਟ ਤੱਕ ਪੂਰੀ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ। Deno ਇਹਨਾਂ ਕਾਬਲੀਆਂ ਨੂੰ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਨਾਂਕਾਰਦਾ ਹੈ ਅਤੇ explicit flags ਨਾਲ ਪਹੁੰਚ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: --allow-net, --allow-read)।
ਅਮਲ ਵਿੱਚ, ਇਹ least-privilege ਅਭਿਆਸ ਨੂੰ ਪ੍ਰੋਤਸਾਹਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਪਰਮਿਸ਼ਨ ਬਦਲਾਅ ਦੀ ਸਮੀਖਿਆ ਨੂੰ ਕੋਡ ਬਦਲਾਅ ਨਾਲ ਆਸਾਨੀ ਨਾਲ ਜੋੜਦਾ ਹੈ।
ਨਿੱਜੀ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ ਪਾਇਲਟ ਚੁਣੋ (webhook handler, scheduled job, ਜਾਂ internal CLI) ਅਤੇ ਸਫਲਤਾ ਮਾਪਦੰਡ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ (deployability, performance, observability, maintenance effort)।
ਸਿਰਲੇਖੀ ਚੈੱਕਸ:
ਇਕ ਛੋਟੀ ਪਾਇਲਟ ਨਾਲ ਤੁਸੀਂ ਰਿਸਕ ਘਟਾ ਕੇ ਇੱਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਨਮੂਨਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।