Node.js 26.5.0 ਹੁਣ ਉਪਲਬਧ ਹੈ। ਇਹ ਇੱਕ Current ਰਿਲੀਜ਼ ਹੈ, LTS ਬ੍ਰਾਂਚ ਨਹੀਂ, ਇਸ ਲਈ ਇਹ ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਅਤਿ-ਆਧੁਨਿਕ ਸਮਰੱਥਾਵਾਂ ਦੇ ਮੋਹਰੀ ਹਿੱਸੇ 'ਤੇ ਹੈ। ਇਹ ਅੰਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਕਿਸੇ ਅਜਿਹੇ production fleet ਵਿੱਚ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਜੋ ਅਠਾਰਾਂ ਮਹੀਨਿਆਂ ਦੀ ਸਥਿਰਤਾ ਦੀ ਉਮੀਦ ਰੱਖਦਾ ਹੋਵੇ। ਪਰ ਇਹ ਛੋਟੀਆਂ, ਤੇਜ਼ ਰਿਲੀਜ਼ਾਂ ਹੀ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਭਵਿੱਖ ਨੂੰ ਰੂਪ ਲੈਂਦੇ ਹੋਏ ਦੇਖਦੇ ਹੋ। ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ maintainers ਕਿਹੜੀਆਂ APIs ਨੂੰ ਨਿਖਾਰ ਰਹੇ ਹਨ ਅਤੇ runtime ਅੱਗੇ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ। 26.5.0 ਵਿੱਚ, ਮੁੱਖ ਕੰਮ Web Streams API ਵਿੱਚ ਹੋਇਆ ਹੈ, ਜਿਸ ਵਿੱਚ ਕੁਝ ਨਿਸ਼ਾਨਾ ਬੱਧੇ ਸੁਧਾਰ (fixes) ਕੀਤੇ ਗਏ ਹਨ ਜੋ Node ਨੂੰ browser parity ਦੇ ਹੋਰ ਨੇੜੇ ਲੈ ਜਾਂਦੇ ਹਨ। ਇਹ ਰਿਲੀਜ਼ file system ਅਤੇ URL handling layers ਵਿੱਚ ਦੋ ਕਮੀਆਂ ਨੂੰ ਵੀ ਸੁਧਾਰਦੀ ਹੈ।
Node.js ਵਿੱਚ Web Streams ਕੀ ਕਰ ਰਹੇ ਹਨ?
ਜੇਕਰ ਤੁਸੀਂ Node ਵਿੱਚ ਕਾਫੀ ਸਮੇਂ ਤੋਂ streaming ਕੋਡ ਲਿਖਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ built-in stream ਮੋਡਿਊਲ ਦਾ ਆਪਣਾ ਹੀ ਇੱਕ ਸੁਭਾਅ ਹੈ। Readable, Writable, Transform, ਅਤੇ Duplex ਸਾਲਾਂ ਤੋਂ ਇਸ ecosystem ਦੇ ਮੁੱਖ ਕੰਮ ਕਰਨ ਵਾਲੇ (workhorses) ਰਹੇ ਹਨ। ਉਹ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹਨ, ਪਰ ਉਹ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਮਿਲਣ ਵਾਲੇ streams ਵਰਗੇ ਨਹੀਂ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ front-end service worker ਅਤੇ ਇੱਕ back-end route handler ਵਿਚਕਾਰ logic ਸਾਂਝਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਅੰਤਰ ਰੁਕਾਵਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਅਖੀਰ ਵਿੱਚ adapters ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ, ਡੇਟਾ ਨੂੰ ਅਣਜਾਣ ਰੂਪਾਂ ਵਿੱਚ ਕਾਪੀ ਕਰਨ, ਜਾਂ ਸਿਰਫ ਸਾਂਝੇ ਕੋਡ ਤੋਂ ਬਿਲਕੁਲ ਬਚਣ ਦੇ ਮਜ਼ਬੂਰ ਹੋ ਜਾਂਦੇ ਹੋ।
Web Streams API ਉਸ ਅੰਤਰ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਮੌਜੂਦ ਹੈ। ਇਹ ਉਹੀ ਸਟੈਂਡਰਡ ਹੈ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ fetch body handling ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ Node ਵਿੱਚ ਲਿਆ ਕੇ, ਇਹ ਪ੍ਰੋਜੈਕਟ ਤੁਹਾਨੂੰ ਇੱਕ ਵਾਰ streaming logic ਲਿਖਣ ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਵੀ ਵਾਤਾਵਰਣ (environment) ਵਿੱਚ ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। API ReadableStream, WritableStream, ਅਤੇ TransformStream objects ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜੋ ਇੱਕ ਸਮਾਨ interface ਰਾਹੀਂ chunks ਨੂੰ ਪਾਸ ਕਰਦੇ ਹਨ। Version 26.5.0 ਉਸ interface ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਦਾ, ਪਰ ਇਹ ਦੋ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ਾਂ ਨੂੰ ਹੋਰ ਮਜ਼ਬੂਤ ਕਰਦਾ ਹੈ।
releaseLock ਨੂੰ ਠੀਕ ਕਰਨਾ ਅਤੇ BYOB Readers ਦੀ ਸਫਾਈ ਕਰਨਾ
ਇਸ ਰਿਲੀਜ਼ ਵਿੱਚ ਇੱਕ ਖਾਸ ਤਬਦੀਲੀ WritableStreamDefaultWriter 'ਤੇ releaseLock method ਲਈ ਇੱਕ fix ਹੈ। Web Streams ਮਾਡਲ ਵਿੱਚ, ਇੱਕ writer lock ਕਈ consumers ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ stream 'ਤੇ ਕੰਮ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ releaseLock() ਨੂੰ ਕਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸੰਕੇਤ ਦੇ ਰਹੇ ਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ writer ਆਪਣਾ ਕੰਮ ਖਤਮ ਕਰ ਚੁੱਕਾ ਹੈ ਅਤੇ ਅੰਡਰਲਾਈਂਗ stream ਅਗਲੀ ਕਾਰਵਾਈ ਲਈ ਖਾਲੀ ਹੈ। ਇੱਥੇ ਇੱਕ ਗਲਤ ਲਾਗੂਕਰਨ (implementation) stream ਨੂੰ ਅਸਥਿਰ ਸਥਿਤੀ ਵਿੱਚ ਛੱਡ ਸਕਦਾ ਹੈ, ਜਿੱਥੇ ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਰਹਿੰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਦੇ ਅਧੀਨ ਹੈ ਭਾਵੇਂ writer ਖਤਮ ਹੋ ਚੁੱਕਾ ਹੋਵੇ। ਅਪਲੋਡਸ ਨੂੰ parse ਕਰਨ ਵਾਲੇ ਜਾਂ storage ਵਿੱਚ data pipe ਕਰਨ ਵਾਲੇ ਇੱਕ ਰੁੱਝੇ ਹੋਏ server ਵਿੱਚ, ਇਸ ਤਰ੍ਹਾਂ ਦਾ stale lock pipeline ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ ਜਾਂ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ (errors) ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਸਰੋਤ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। 26.5.0 ਵਿੱਚ ਕੀਤਾ ਗਿਆ fix handoff ਨੂੰ ਦੁਬਾਰਾ ਭਵਿੱਖਬਾਣੀਯੋਗ (predictable) ਬਣਾਉਂਦਾ ਹੈ।
ਦੂਜੀ Web Streams ਤਬਦੀਲੀ ReadableStream ਅਤੇ TransformStream ਦੇ BYOB readers ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ। BYOB ਦਾ ਮਤਲਬ ਹੈ Bring Your Own Buffer। ਹਰ ਵਾਰ ਡੇਟਾ ਡਿਲੀਵਰ ਕਰਦੇ ਸਮੇਂ stream ਦੁਆਰਾ ਨਵੀਂ memory allocate ਕਰਨ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ buffer ਦਿੰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਰੱਖ ਕੇ ਰੱਖਿਆ ਹੋਇਆ ਹੈ। Stream ਉਸ buffer ਨੂੰ ਭਰਦੀ ਹੈ, ਤੁਸੀਂ bytes ਨੂੰ process ਕਰਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਉਸੇ buffer ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ ਲਈ ਵਾਪਸ ਦੇ ਦਿੰਦੇ ਹੋ। ਇਹ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਮਕੈਨੀਕਲ ਫਰਕ ਹੈ ਜੋ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਮੂਵ ਕਰਦੇ ਸਮੇਂ ਬਹੁਤ ਵੱਡੇ ਨਤੀਜੇ ਦਿੰਦਾ ਹੈ।
Node ਕੋਲ ਕੁਝ ਸਮੇਂ ਤੋਂ BYOB support ਹੈ, ਪਰ ReadableStream ਅਤੇ TransformStream ਵਿੱਚ edge cases ਉਦੋਂ ਗਲਤ ਵਿਵਹਾਰ ਕਰ ਸਕਦੇ ਸਨ ਜਦੋਂ BYOB reader ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ। Fix ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲੋਂ ਵਿਹਾਰਕ ਨਤੀਜਾ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਉਹ streams ਜੋ explicit buffers ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਹੁਣ reading ਅਤੇ transformation ਦੋਵਾਂ ਪੜਾਵਾਂ ਵਿੱਚ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ backpressure events ਦੌਰਾਨ ਅਜੀਬ ਗਲਤੀਆਂ ਕਾਰਨ BYOB readers ਤੋਂ ਬਚਦੇ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਰਿਲੀਜ਼ ਇਸ ਤੋਂ ਦੂਰ ਰਹਿਣ ਦਾ ਇੱਕ ਹੋਰ ਕਾਰਨ ਖਤਮ ਕਰ ਦਿੰਦੀ ਹੈ।
BYOB ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ
ਅਮੂਰਤ ਰੂਪ ਵਿੱਚ buffer reuse ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਇਹ ਸੋਚਣਾ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਹੈ ਕਿ ਇਹ ਕਿੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇੱਕ ਅਜਿਹੀ service ਲਿਖ ਰਹੇ ਹੋ ਜੋ telemetry uploads ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਉਹ uploads compressed logs ਜਾਂ raw sensor dumps ਹੋ ਸਕਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਕਈ ਸੌ ਮੈਗਾਬਾਈਟ ਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ stream ਡੇਟਾ ਦੇ ਹਰ ਹਿੱਸੇ ਲਈ ਇੱਕ ਨਵਾਂ Node Buffer allocate ਕਰਦੀ ਹੈ, ਤਾਂ garbage collector ਨੂੰ ਵਧੇਰੇ ਕੰਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ memory spikes ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੇ ਹਨ। BYOB reader ਦੇ ਨਾਲ, ਤੁਸੀਂ startup ਵੇਲੇ buffers ਦਾ ਇੱਕ ਮਾਮੂਲੀ pool allocate ਕਰਦੇ ਹੋ। Stream ਉਹਨਾਂ ਨੂੰ ਭਰਦੀ ਹੈ, ਤੁਹਾਡਾ parser ਉਹਨਾਂ ਨੂੰ ਖਾਲੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਵਾਪਸ ਆ ਜਾਂਦੇ ਹਨ। Memory ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ। ਇਹੀ ਪੈਟਰਨ ਉਦੋਂ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੋ sockets ਵਿਚਕਾਰ network traffic ਨੂੰ proxy ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ ਜਾਂ ਪੂਰੀ ਫਾਈਲ ਨੂੰ RAM ਵਿੱਚ ਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਵੱਡੀਆਂ CSV files ਨੂੰ ਲਾਈਨ-ਦਰ-ਲਾਈਨ parse ਕਰ ਰਹੇ ਹੁੰਦੇ ਹੋ।
ਇੱਥੇ ਟ੍ਰਾਂਸਫਾਰਮ ਸਟ੍ਰੀਮਜ਼ (Transform streams) ਵੀ ਉਨੀ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਇੱਕ TransformStream ਪਾਈਪਲਾਈਨ ਦੇ ਵਿਚਕਾਰ ਹੁੰਦਾ ਹੈ, ਜੋ ਸ਼ਾਇਦ gzip ਸਟ੍ਰੀਮ ਨੂੰ ਡੀਕੰਪ੍ਰੈਸ ਕਰ ਰਿਹਾ ਹੋਵੇ ਜਾਂ ਚੰਕਸ (chunks) ਨੂੰ ਤੁਰੰਤ ਐਨਕ੍ਰਿਪਟ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਜੇਕਰ ਟ੍ਰਾਂਸਫਾਰਮ ਸਟੈਪ BYOB ਬਫਰਸ (buffers) ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਖਰਾਬ ਆਉਟਪੁੱਟ, ਡ੍ਰੌਪ ਕੀਤੇ ਚੰਕਸ, ਜਾਂ ਲੋਡ ਦੇ ਅਧੀਨ ਰੁਕਾਵਟਾਂ ਦੇਖ ਸਕਦੇ ਹੋ। 26.5.0 ਦੇ ਫਿਕਸ (fixes) ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਦੀਆਂ ਪਾਈਪਲਾਈਨ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ, ਜਿਸ ਕਰਕੇ ਉੱਚ-ਥਰੂਪੁੱਟ (high-throughput) I/O ਚਲਾਉਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਇਸ ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਚੁੱਪਚਾਪ ਮਿਲੀਆਂ ਜਿੱਤਾਂ: ਫਾਈਲ ਸਿਸਟਮ ਅਤੇ ਗਲਤੀਆਂ ਦੀ ਸਪਸ਼ਟਤਾ
26.5.0 ਵਿੱਚ ਸਭ ਕੁਝ ਸਟ੍ਰੀਮਿੰਗ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ ਰਿਲੀਜ਼ fs.rm ਅਤੇ fs.rmSync ਵਿੱਚ ਵਿਵਹਾਰ ਨੂੰ ਵੀ ਠੀਕ ਕਰਦੀ ਹੈ ਜਦੋਂ recursive ਆਪਸ਼ਨ false 'ਤੇ ਸੈੱਟ ਹੁੰਦੀ ਹੈ। ਪਹਿਲਾਂ, ਡਾਇਰੈਕਟਰੀ ਪਾਥ ਦੇ ਨਾਲ recursive: false ਭੇਜਣ ਨਾਲ ਸਫਾਈ (cleanup) ਦੌਰਾਨ ਅਣਕਿਆਸੇ ਨਤੀਜੇ ਮਿਲ ਸਕਦੇ ਸਨ। ਮੈਥਡ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਸੀ ਜੋ ਕਾਲਰ ਦੇ ਸਪਸ਼ਟ ਇਰਾਦੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਸਨ, ਜਿਵੇਂ ਕਿ ਉਮੀਦ ਤੋਂ ਵੱਧ ਡਿਲੀਟ ਕਰਨਾ ਜਾਂ ਪਲੇਟਫਾਰਮ ਦੇ ਅਧਾਰ 'ਤੇ ਅਸੰਗਤ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੋਣਾ। ਫਾਈਲਾਂ ਦੀ ਸਫਾਈ ਅਜਿਹਾ ਕੰਮ ਹੈ ਜੋ ਬੋਰਿੰਗ ਅਤੇ ਅਨੁਮਾਨਯੋਗ (predictable) ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਬੋਰਿੰਗ ਹੋਣਾ ਚੰਗਾ ਹੈ। ਇਹ ਫ