Node.js 26.5.0 अब उपलब्ध है। यह एक Current रिलीज़ है, LTS ब्रांच नहीं, इसलिए यह उस अत्याधुनिक तकनीक पर आधारित है जो यह प्लेटफॉर्म कर सकता है। यह अंतर महत्वपूर्ण है। आपको इसे बिना सोचे-समझे किसी ऐसे प्रोडक्शन फ़्लीट (production fleet) में नहीं बदलना चाहिए जो अठारह महीनों की स्थिरता की अपेक्षा करता है। लेकिन ये छोटे, तेज़ रिलीज़ ही वे जगह हैं जहाँ आप भविष्य को आकार लेते हुए देखते हैं। वे दिखाते हैं कि मेंटेनर किन APIs को बेहतर बना रहे हैं और रनटाइम आगे किस दिशा में जा रहा है। 26.5.0 में, मुख्य काम Web Streams API में आता है, जिसमें दो लक्षित सुधार (targeted fixes) हैं जो Node को ब्राउज़र के समान (parity) बनाने की ओर ले जाते हैं। यह रिलीज़ फ़ाइल सिस्टम और URL हैंडलिंग लेयर्स में दो कमियों को भी दूर करती है।

Node.js में Web Streams क्या कर रहे हैं?

यदि आपने किसी भी समय Node में स्ट्रीमिंग कोड लिखा है, तो आप जानते होंगे कि बिल्ट-इन stream मॉड्यूल का अपना व्यक्तित्व है। Readable, Writable, Transform, और Duplex वर्षों से इकोसिस्टम के वर्कहॉर्स रहे हैं। वे शक्तिशाली हैं, लेकिन वे उन स्ट्रीम्स के समान नहीं हैं जो आपको ब्राउज़र में मिलते हैं। जब आप एक फ्रंट-एंड सर्विस वर्कर और एक बैक-एंड रूट हैंडलर के बीच लॉजिक साझा करने की कोशिश करते हैं, तो वह अंतर बाधा (friction) बन जाता है। आप अंततः एडेप्टर (adapters) फिर से लिखते हैं, डेटा को अपरिचित स्वरूपों में कॉपी करते हैं, या बस साझा कोड से पूरी तरह बचते हैं।

Web Streams API उस अंतर को पाटने के लिए मौजूद है। यह वही मानक (standard) है जो ब्राउज़र में fetch बॉडी हैंडलिंग को शक्ति देता है। इसे Node में लाकर, यह प्रोजेक्ट आपको स्ट्रीमिंग लॉजिक एक बार लिखने और उसे किसी भी वातावरण में चलाने की अनुमति देता है। यह API ReadableStream, WritableStream, और TransformStream ऑब्जेक्ट्स के साथ काम करता है जो एक समान इंटरफ़ेस के माध्यम से चंक्स (chunks) पास करते हैं। वर्ज़न 26.5.0 उस इंटरफ़ेस को फिर से नहीं लिखता है, लेकिन यह दो महत्वपूर्ण पहलुओं को और मज़बूत करता है।

releaseLock को ठीक करना और BYOB Readers की सफाई करना

इस रिलीज़ में एक ठोस बदलाव WritableStreamDefaultWriter पर releaseLock मेथड के लिए एक सुधार है। Web Streams मॉडल में, एक राइटर लॉक (writer lock) कई कंज्यूमर्स को एक साथ एक ही स्ट्रीम पर काम करने से रोकता है। जब आप releaseLock() कॉल करते हैं, तो आप संकेत दे रहे होते हैं कि आपका राइटर काम पूरा कर चुका है और अंतर्निहित (underlying) स्ट्रीम अगले ऑपरेशन के लिए मुक्त है। यहाँ एक दोषपूर्ण कार्यान्वयन (faulty implementation) स्ट्रीम को अनिश्चित स्थिति (limbo) में छोड़ सकता है, जिससे यह अभी भी मान लिया जाता है कि यह किसी के स्वामित्व में है, भले ही राइटर गायब हो गया हो। अपलोड्स को पार्स करने या स्टोरेज में डेटा पाइप करने वाले व्यस्त सर्वर में, इस तरह का stale lock पाइपलाइन को रोक सकता है या ऐसे एरर दे सकता है जिन्हें उनके स्रोत तक ट्रैक करना कठिन हो। 26.5.0 में सुधार इसे फिर से अनुमानित (predictable) बनाता है।

दूसरा Web Streams बदलाव यह सुधारता है कि ReadableStream और TransformStream, BYOB रीडर्स के साथ कैसे काम करते हैं। BYOB का अर्थ है Bring Your Own Buffer। हर बार डेटा डिलीवर करते समय स्ट्रीम द्वारा मेमोरी का एक नया चंक आवंटित करने के बजाय, आप इसे एक बफ़र देते हैं जिसे आपने पहले से ही अलग रख दिया है। स्ट्रीम उस बफ़र को भरती है, आप बाइट्स को प्रोसेस करते हैं, और फिर उसी बफ़र को पुन: उपयोग के लिए वापस दे देते हैं। यह एक छोटा यांत्रिक अंतर है जो बड़े पैमाने पर डेटा ले जाते समय बड़े परिणाम देता है।

Node में कुछ समय से BYOB सपोर्ट है, लेकिन ReadableStream और TransformStream में कुछ एज केस (edge cases) तब गलत व्यवहार कर सकते थे जब एक BYOB रीडर जुड़ा हो। सुधार की विशिष्टताएँ व्यावहारिक परिणाम की तुलना में कम महत्वपूर्ण हैं: जो स्ट्रीम स्पष्ट बफ़र्स (explicit buffers) का उपयोग करती हैं, वे अब रीडिंग और ट्रांसफ़ॉर्मेशन दोनों चरणों में अधिक विश्वसनीय हैं। यदि आपने बैकप्रेशर (backpressure) घटनाओं के दौरान अजीब एरर के कारण BYOB रीडर्स से परहेज किया है, तो यह रिलीज़ उससे दूर रहने का एक और कारण खत्म कर देती है।

BYOB वास्तव में कहाँ दिखाई देता है

अमूर्त (abstract) रूप में बफ़र पुन: उपयोग के बारे में बात करना आसान है। यह सोचना अधिक उपयोगी है कि यह कहाँ मायने रखता है।

कल्पना कीजिए कि आप एक ऐसी सर्विस लिख रहे हैं जो टेलीमेट्री अपलोड स्वीकार करती है। वे अपलोड कंप्रेस्ड लॉग्स या रॉ सेंसर डंप हो सकते हैं, जिनमें से प्रत्येक कई सौ मेगाबाइट का हो सकता है। यदि स्ट्रीम डेटा के हर स्लाइस के लिए एक नया Node Buffer आवंटित करती है, तो गार्बेज कलेक्टर (garbage collector) को अतिरिक्त काम करना पड़ता है और मेमोरी स्पाइक्स तेज़ी से बढ़ते हैं। BYOB रीडर के साथ, आप स्टार्टअप पर बफ़र्स का एक छोटा पूल आवंटित करते हैं। स्ट्रीम उन्हें भरती है, आपका पार्सर उन्हें खाली करता है, और वे वापस लौट आते हैं। मेमोरी स्थिर रहती है। यही पैटर्न तब लागू होता है जब आप दो सॉकेट्स के बीच नेटवर्क ट्रैफ़िक को प्रॉक्सी कर रहे होते हैं या पूरी चीज़ को RAM में लोड किए बिना लाइन-दर-लाइन बड़ी CSV फ़ाइलों को पार्स कर रहे होते हैं।

यहाँ Transform streams भी समान रूप से महत्वपूर्ण हैं। एक TransformStream पाइपलाइन के बीच में स्थित होता है, जो शायद gzip स्ट्रीम को डीकंप्रेस कर रहा हो या चलते समय (on the fly) चंक्स को एन्क्रिप्ट कर रहा हो। यदि ट्रांसफॉर्म स्टेप BYOB बफ़र्स को गलत तरीके से हैंडल करता है, तो आप करप्ट आउटपुट, ड्रॉप हुए चंक्स, या लोड के दौरान स्टॉल (stalls) देख सकते हैं। 26.5.0 के फिक्स ठीक इन्हीं तरह की पाइपलाइन की समस्याओं को दूर करते हैं, यही कारण है कि हाई-थ्रूपुट I/O चलाने वाले किसी भी व्यक्ति को इस पर ध्यान देना चाहिए।

शांत जीत: फ़ाइल सिस्टम और एरर क्लैरिटी

26.5.0 में सब कुछ स्ट्रीमिंग के बारे में नहीं है। यह रिलीज़ fs.rm और fs.rmSync के व्यवहार को भी ठीक करती है जब recursive विकल्प को false पर सेट किया जाता है। पहले, डायरेक्टरी पाथ के साथ recursive: false पास करने से क्लीनअप के दौरान अप्रत्याशित परिणाम मिल सकते थे। यह मेथड ऐसे तरीकों से काम कर सकता था जो कॉलर (caller) के स्पष्ट इरादे से मेल नहीं खाते थे, जैसे कि उम्मीद से ज़्यादा डिलीट करना या प्लेटफॉर्म के आधार पर असंगत (inconsistent) तरीकों से विफल होना। फ़ाइलों को साफ़ करना एक ऐसा ऑपरेशन है जिसे उबाऊ और अनुमानित (predictable) होना चाहिए। उबाऊ होना अच्छा है। यह फिक्स उस प्रेडिक्टेबिलिटी को बहाल करता है, ताकि आपके टेम्परेरी डायरेक्टरी क्लीनअप स्क्रिप्ट या डिप्लॉयमेंट टीयरडाउन लॉजिक ठीक वैसे ही काम करें जैसा कोड बताता है।

URL.canParse विफलता (failure) की रिपोर्ट कैसे करता है, इसमें भी क्वालिटी-ऑफ-लाइफ सुधार किया गया है। यह मेथड बिना किसी एरर (throw) के यह जाँचता है कि स्ट्रिंग एक वैध URL है या नहीं। 26.5.0 में, अब कुछ गलत होने पर यह बेहतर Error.cause जानकारी प्रदान करता है। मूल कारण को दबाने के बजाय, एरर ऑब्जेक्ट एक कॉज़ल चेन (causal chain) को सुरक्षित रखता है। इसका मतलब है कि जब किसी वैलिडेशन हेल्पर के अंदर URL पार्स विफल हो जाता है, तो आपके द्वारा लॉग किया गया स्टैक आपको बताता है कि समस्या गलत प्रोटोकॉल थी, होस्टनेम गायब था, या कोई अन्य संरचनात्मक समस्या थी। आप हर कॉल साइट पर मैन्युअल डिबग लॉग्स डालने में कम समय बिताते हैं।

क्या आपको अपग्रेड करना चाहिए?

उत्तर इस बात पर निर्भर करता है कि आप क्या चला रहे हैं।

यदि आपके प्रोडक्शन वर्कलोड v20.x जैसी LTS वर्शन पर हैं, तो वहीं रहें। ये फिक्स अंततः बैकपोर्ट किए जाएंगे या अगले सक्रिय LTS में आएंगे। स्थिरता और अनुमानित सपोर्ट टाइमलाइन, एक ऐसे सर्वर पर थोड़े स्मूथ स्ट्रीम लॉक या स्पष्ट URL एरर के लाभ से कहीं अधिक महत्वपूर्ण हैं जो पहले से ही काम कर रहा है।

यदि आप एक नई सेवा बना रहे हैं, रियल-टाइम डेटा पाइपलाइन का प्रोटोटाइप बना रहे हैं, या परफॉरमेंस-क्रिटिकल I/O के लिए सक्रिय रूप से Web Streams API का उपयोग कर रहे हैं, तो 26.5.0 पर स्विच करना सार्थक है। Node streams और ब्राउज़र Web Streams के बीच क्रमिक संरेखण (incremental alignment) केवल कम्पैटिबिलिटी की जीत नहीं है। यह एक अधिक एकीकृत (unified) JavaScript रनटाइम पर एक दांव है जहाँ वही डेटा-पुशिंग लॉजिक बिना किसी ट्रांसलेशन लेयर के सर्वर और क्लाइंट के बीच यात्रा कर सकता है। इससे कॉग्निटिव लोड कम होता है और जब आपकी टीम दोनों वातावरणों में कोड भेजती है, तो बग्स की संभावना भी कम हो जाती है।

यह रिलीज़ छोटी है, लेकिन दिशा स्पष्ट है। Node उन स्टैंडर्ड-आधारित APIs में निवेश करना जारी रख रहा है जो हर उस जगह काम करते हैं जहाँ JavaScript चलता है। Web Streams में सुधार कोई हेडलाइन फीचर्स नहीं हैं, लेकिन वे उस रास्ते को सुगम बनाते हैं जो वर्षों से कठिन रहा है। यदि आप Current लाइन पर हैं, तो 26.5.0 लें, और सही समय आने पर अपने LTS वर्शन में इन फिक्स के आने का इंतज़ार करें।

स्रोत: Dev.to – Node.js 26.5.0: What's New for Web Streams and Error Handling

चर्चा में शामिल हों और Telegram पर GyaanSetu कम्युनिटी के साथ सीखते रहें।