Node.js 26.5.0 आता उपलब्ध आहे. ही एक 'Current' रिलीज आहे, 'LTS' ब्रांच नाही, त्यामुळे ती प्लॅटफॉर्म काय करू शकते याच्या अग्रभागी (leading edge) आहे. हा फरक महत्त्वाचा आहे. अठरा महिन्यांच्या स्थिरतेची अपेक्षा असलेल्या प्रोडक्शन फ्लीटमध्ये (production fleet) तुम्ही ती आंधळेपणाने बदलू नये. परंतु या लहान, जलद रिलीजमध्ये तुम्ही भविष्याला आकार घेताना पाहू शकता. मेंटेनर्स कोणत्या APIs ला अधिक धारदार करत आहेत आणि रनटाइम पुढे कुठे जात आहे, हे यातून दिसून येते. 26.5.0 मध्ये, मुख्य काम Web Streams API मध्ये झाले आहे, ज्यामध्ये दोन लक्ष्यित सुधारणा (targeted fixes) आहेत ज्या Node ला ब्राउझरच्या बरोबरीच्या (browser parity) जवळ नेतात. या रिलीजमध्ये फाईल सिस्टम आणि URL हँडलिंग लेयर्समधील दोन त्रुटी देखील दूर केल्या आहेत.
Node.js मध्ये Web Streams काय करत आहेत?
जर तुम्ही बराच काळ Node मध्ये स्ट्रीमिंग कोड लिहिला असेल, तर तुम्हाला माहित असेल की अंगभूत stream मॉड्यूलचे स्वतःचे वेगळे वैशिष्ट्य आहे. Readable, Writable, Transform, आणि Duplex हे अनेक वर्षांपासून या इकोसिस्टमचे मुख्य आधारस्तंभ राहिले आहेत. ते शक्तिशाली आहेत, परंतु ते ब्राउझरमध्ये आढळणाऱ्या स्ट्रीम्ससारखे नाहीत. जेव्हा तुम्ही फ्रंट-एंड सर्व्हिस वर्कर आणि बॅक-एंड रूट हँडलर दरम्यान लॉजिक शेअर करण्याचा प्रयत्न करता, तेव्हा तो फरक अडथळा (friction) ठरतो. यामुळे तुम्हाला अडॅप्टर्स पुन्हा लिहावे लागतात, डेटा अनोळखी स्वरूपात कॉपी करावा लागतो किंवा सामायिक कोड (shared code) पूर्णपणे टाळावा लागतो.
तो फरक कमी करण्यासाठी Web Streams API अस्तित्वात आहे. हे तेच मानक (standard) आहे जे ब्राउझरमधील fetch बॉडी हँडलिंगला सक्षम करते. ते Node मध्ये आणून, हा प्रोजेक्ट तुम्हाला स्ट्रीमिंग लॉजिक एकदाच लिहिण्यास आणि ते कोणत्याही वातावरणात चालवण्यास अनुमती देतो. हे API ReadableStream, WritableStream, आणि TransformStream ऑब्जेक्ट्सवर काम करते जे एका समान इंटरफेसद्वारे चंक्स (chunks) पास करतात. व्हर्जन 26.5.0 त्या इंटरफेसला पुन्हा लिहित नाही, परंतु ते दोन महत्त्वाचे घटक अधिक मजबूत करते.
releaseLock सुधारणे आणि BYOB Readers स्वच्छ करणे
या रिलीजमधील एक ठोस बदल म्हणजे WritableStreamDefaultWriter वरील releaseLock मेथडमधील सुधारणा. Web Streams मॉडेलमध्ये, रायटर लॉक (writer lock) एकाच वेळी अनेक कंज्युमर्सना एकाच स्ट्रीमवर प्रक्रिया करण्यापासून रोखतो. जेव्हा तुम्ही releaseLock() कॉल करता, तेव्हा तुम्ही असे सूचित करता की तुमचा रायटर काम पूर्ण झाला आहे आणि मूळ स्ट्रीम पुढील ऑपरेशनसाठी मोकळी आहे. येथील चुकीच्या अंमलबजावणीमुळे स्ट्रीम अस्पष्ट स्थितीत (limbo) राहू शकते, म्हणजेच रायटर निघून गेला असूनही स्ट्रीमला वाटते की ती अजूनही कोणाच्या तरी मालकीची आहे. अपलोड्स पार्स करत असलेल्या किंवा स्टोरेजमध्ये डेटा पाइप करत असलेल्या व्यस्त सर्व्हरमध्ये, अशा प्रकारचा जुना (stale) लॉक पाइपलाइन थांबवू शकतो किंवा अशा त्रुटी निर्माण करू शकतो ज्यांचा मूळ शोध घेणे कठीण असते. 26.5.0 मधील सुधारणा यामुळे डेटा हस्तांतरण (handoff) पुन्हा अंदाजित (predictable) होते.
दुसरा Web Streams बदल ReadableStream आणि TransformStream हे BYOB रीडर्ससोबत कसे काम करतात यामध्ये सुधारणा करतो. BYOB म्हणजे 'Bring Your Own Buffer'. स्ट्रीमने प्रत्येक वेळी डेटा देताना मेमरीचा नवीन चंक (chunk) वाटप करण्याऐवजी, तुम्ही आधीच बाजूला ठेवलेला बफर त्याला देता. स्ट्रीम तो बफर भरते, तुम्ही बाइट्सवर प्रक्रिया करता आणि नंतर पुन्हा वापरण्यासाठी तोच बफर परत देता. जेव्हा तुम्ही मोठ्या प्रमाणात डेटा हाताळत असता, तेव्हा हा एक छोटा तांत्रिक फरक प्रचंड परिणाम देतो.
Node मध्ये काही काळापासून BYOB सपोर्ट आहे, परंतु BYOB रीडर जोडलेला असताना ReadableStream आणि TransformStream मधील काही विशेष प्रकरणांमध्ये (edge cases) त्रुटी येऊ शकत होत्या. सुधारणेचे तपशील कमी महत्त्वाचे आहेत, तर त्याचा व्यावहारिक परिणाम अधिक महत्त्वाचा आहे: स्पष्ट बफर वापरणाऱ्या स्ट्रीम्स आता रीडिंग आणि ट्रान्सफॉर्मेशन या दोन्ही टप्प्यांवर अधिक विश्वसनीय आहेत. जर तुम्ही बॅकप्रेशर (backpressure) इव्हेंट्स दरम्यान येणाऱ्या विचित्र त्रुटींमुळे BYOB रीडर्स टाळले असतील, तर ही रिलीज त्यापासून दूर राहण्याचे आणखी एक कारण काढून टाकते.
BYOB प्रत्यक्षात कुठे दिसून येते
अमूर्तपणे (abstract) बफरच्या पुनवापराविषयी बोलणे सोपे आहे. परंतु ते कुठे महत्त्वाचे आहे याचा विचार करणे अधिक उपयुक्त आहे.
कल्पना करा की तुम्ही टेलिमेट्री अपलोड स्वीकारणारी सेवा लिहित आहात. ते अपलोड कॉम्प्रेस केलेले लॉग्स किंवा रॉ सेन्सर डम्प्स असू शकतात, ज्यापैकी प्रत्येकाचा आकार शेकडो मेगाबाइट्स असू शकतो. जर स्ट्रीम डेटाच्या प्रत्येक भागासाठी नवीन Node Buffer वाटप करत असेल, तर गार्बेज कलेक्टरला (garbage collector) जास्त काम करावे लागते आणि मेमरी स्पाइक्स वेगाने वाढतात. BYOB रीडरसह, तुम्ही स्टार्टअपला बफर्सचा एक मर्यादित पूल (pool) वाटप करता. स्ट्रीम ते भरते, तुमचा पार्सर ते वापरतो आणि ते पुन्हा उपलब्ध होतात. मेमरी स्थिर राहते. जेव्हा तुम्ही दोन सॉकेट्स दरम्यान नेटवर्क ट्रॅफिक प्रॉक्सी करत असता किंवा संपूर्ण फाईल RAM मध्ये लोड न करता मोठ्या CSV फाईल्स ओळीने ओळीने (line by line) पार्स करत असता, तेव्हा देखील हाच पॅटर्न लागू होतो.
येथे ट्रान्सफॉर्म स्ट्रीम्स (Transform streams) देखील तितकेच महत्त्वाचे आहेत. एक TransformStream पाइपलाइनच्या मध्यभागी असते, जी कदाचित gzip स्ट्रीम डीकंप्रेस करते किंवा चंक्स (chunks) ऑन द फ्लाय एन्क्रिप्ट करते. जर ट्रान्सफॉर्म स्टेपने BYOB बफर्सचे चुकीच्या पद्धतीने व्यवस्थापन केले, तर तुम्हाला करप्ट आउटपुट, ड्रॉप झालेले चंक्स किंवा लोड असताना स्टॉल्स (stalls) दिसू शकतात. 26.5.0 मधील सुधारणा नेमक्या अशाच प्रकारच्या पाइपलाइनमधील अडचणी दूर करतात, म्हणूनच हाय-थ्रूपुट I/O चालवणारे प्रत्येकाने याकडे लक्ष दिले पाहिजे.
शांत विजय: फाईल सिस्टम आणि त्रुटींची स्पष्टता
26.5.0 मध्ये सर्व काही स्ट्रीमिंगबद्दल नाही. जेव्हा recursive पर्याय false वर सेट केला जातो, तेव्हा हे रिलीज fs.rm आणि fs.rmSync मधील वर्तणुकीतही सुधारणा करते. यापूर्वी, डिरेक्टरी पाथसोबत recursive: false पास केल्यामुळे क्लीनअप दरम्यान अनपेक्षित परिणाम मिळू शकत होते. ही पद्धत कॉलरच्या स्पष्ट हेतूशी जुळणार नाही अशा प्रकारे काम करू शकत होती, जसे की अपेक्षेपेक्षा जास्त फाईल्स डिलीट करणे किंवा प्लॅटफॉर्मनुसार विसंगत पद्धतीने फेल होणे. फाईल्स क्लीनअप करणे ही अशी प्रक्रिया आहे जी कंटाळवाणी आणि प्रेडिक्टेबल (predictable) असावी. कंटाळवाणी असणे हे चांगले आहे. ही सुधारणा ती प्रेडिक्टेबिलिटी परत आणते, ज्यामुळे तुमचे टेम्परेरी डिरेक्टरी क्लीनअप स्क्रिप्ट्स किंवा डिप्लॉयमेंट टीअरडाउन लॉजिक कोडमध्ये सुचवल्याप्रमाणेच काम करतील.
URL.canParse त्रुटी (failure) कशी रिपोर्ट करते, यामध्ये देखील एक 'क्वालिटी-ऑफ-लाईफ' सुधारणा करण्यात आली आहे. ही पद्धत चुकीच्या इनपुटवर एरर न फेकता (without throwing), स्ट्रिंग वैध 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 मधील वाढती सुसंगतता ही केवळ सुसंगततेचा विजय नाही. हा एका अधिक युनिफाइड JavaScript रनटाइमवरील विश्वास आहे, जिथे ट्रान्सलेशन लेयर्सशिवाय तेच डेटा-पुशिंग लॉजिक सर्व्हर आणि क्लायंट दरम्यान वापरले जाऊ शकते. यामुळे कॉग्निटिव्ह लोड कमी होतो आणि जेव्हा तुमची टीम दोन्ही वातावरणांसाठी कोड पाठवते, तेव्हा बग्सची शक्यताही कमी होते.
हे रिलीज लहान आहे, परंतु दिशा स्पष्ट आहे. Node अशा स्टँडर्ड-आधारित APIs मध्ये गुंतवणूक करत आहे जे JavaScript जिथे कुठे चालते तिथे काम करतात. Web Streams मधील सुधारणा या मुख्य वैशिष्ट्ये (headline features) नाहीत, परंतु त्या गेल्या अनेक वर्षांपासून खडतर असलेल्या मार्गाला सुकर करतात. जर तुम्ही Current लाईनवर असाल तर 26.5.0 घ्या, आणि योग्य वेळ आल्यावर या सुधारणा तुमच्या LTS जगात येण्याची प्रतीक्षा करा.
Source: Dev.to – Node.js 26.5.0: What's New for Web Streams and Error Handling
चर्चांमध्ये सामील व्हा आणि Telegram वरील GyaanSetu कम्युनिटीसोबत शिकत राहा.