Node.js 26.5.0 ఇప్పుడు అందుబాటులోకి వచ్చింది. ఇది ఒక Current release, LTS branch కాదు, కాబట్టి ఇది ప్లాట్ఫారమ్ చేయగలిగే అత్యున్నత స్థాయి సామర్థ్యాల అంచున ఉంటుంది. ఆ తేడా చాలా ముఖ్యం. పద్దెనిమిది నెలల స్థిరత్వాన్ని ఆశించే ప్రొడక్షన్ ఫ్లీట్లోకి (production fleet) దీనిని గుడ్డిగా మార్చకూడదు. కానీ, ఈ చిన్న, వేగవంతమైన రిలీజ్లే భవిష్యత్తు ఎలా ఉండబోతుందో చూపిస్తాయి. మెయింటైనర్లు ఏ APIలను మెరుగుపరుస్తున్నారు మరియు రన్టైమ్ తదుపరి ఎటువైపు వెళ్తోంది అనేది ఇవి తెలియజేస్తాయి. 26.5.0లో, ప్రధానమైన మార్పు Web Streams APIలో ఉంది, బ్రౌజర్ స్థాయికి (browser parity) Nodeను మరింత దగ్గర చేసే రెండు లక్ష్యిత పరిష్కారాలు (targeted fixes) ఇందులో ఉన్నాయి. ఈ రిలీజ్ ఫైల్ సిస్టమ్ మరియు URL హ్యాండ్లింగ్ లేయర్లలోని రెండు లోపాలను కూడా సరిచేస్తుంది.
Node.jsలో Web Streams ఏం చేస్తున్నాయి?
మీరు Nodeలో కొంతకాలంగా స్ట్రీమింగ్ కోడ్ రాస్తుంటే, బిల్ట్-ఇన్ stream మాడ్యూల్కు దానికంటూ ఒక ప్రత్యేకత ఉందని మీకు తెలుస్తుంది. Readable, Writable, Transform, మరియు Duplex అనేవి సంవత్సరాలుగా ఈ ఎకోసిస్టమ్ యొక్క పనిముట్లుగా ఉన్నాయి. ఇవి శక్తివంతమైనవి, కానీ బ్రౌజర్లో మీరు చూసే స్ట్రీమ్స్ లాగా ఇవి ఉండవు. మీరు ఒక ఫ్రంట్-ఎండ్ సర్వీస్ వర్కర్ మరియు బ్యాక్-ఎండ్ రూట్ హ్యాండ్లర్ మధ్య లాజిక్ను పంచుకోవడానికి ప్రయత్నించినప్పుడు, ఆ వ్యత్యాసం ఇబ్బందులకు దారితీస్తుంది. మీరు అడాప్టర్లను మళ్ళీ రాయాల్సి వస్తుంది, డేటాను కొత్త రూపాల్లోకి కాపీ చేయాల్సి వస్తుంది, లేదా అసలు షేర్డ్ కోడ్ను వాడకుండానే ఉండాల్సి వస్తుంది.
ఆ వ్యత్యాసాన్ని తగ్గించడానికే Web Streams API ఉంది. బ్రౌజర్లో fetch బాడీ హ్యాండ్లింగ్కు ఉపయోగించే స్టాండర్డ్ ఇదే. దీనిని Nodeలోకి తీసుకురావడం ద్వారా, మీరు స్ట్రీమింగ్ లాజిక్ను ఒక్కసారి రాసి, ఏ ఎన్విరాన్మెంట్లోనైనా రన్ చేయవచ్చు. ఈ API ReadableStream, WritableStream, మరియు TransformStream ఆబ్జెక్ట్లతో పనిచేస్తుంది, ఇవి ఒకే విధమైన ఇంటర్ఫేస్ ద్వారా డేటా చంక్స్ను (chunks) పంపిస్తాయి. వెర్షన్ 26.5.0 ఆ ఇంటర్ఫేస్ను మళ్ళీ రాయదు, కానీ రెండు ముఖ్యమైన అంశాలను మరింత పటిష్టంగా చేస్తుంది.
releaseLock పరిష్కారం మరియు BYOB Readers క్లీనప్
ఈ రిలీజ్లో ఒక స్పష్టమైన మార్పు ఏమిటంటే, WritableStreamDefaultWriterలోని releaseLock మెథడ్కు చేసిన పరిష్కారం. Web Streams మోడల్లో, రైటర్ లాక్ (writer lock) అనేది ఒకేసారి బహుళ వినియోగదారులు (multiple consumers) ఒకే స్ట్రీమ్పై పనిచేయకుండా నిరోధిస్తుంది. మీరు releaseLock()ని కాల్ చేసినప్పుడు, మీ రైటర్ పని పూర్తయిందని మరియు అండర్లైయింగ్ స్ట్రీమ్ తదుపరి ఆపరేషన్ కోసం సిద్ధంగా ఉందని మీరు తెలియజేస్తున్నారు. ఇక్కడ తప్పుగా అమలు చేస్తే, రైటర్ లేకపోయినా స్ట్రీమ్ ఇంకా తన వద్దే ఉందని భావించి, ఒక మధ్యంతర స్థితిలో (limbo) ఉండిపోవచ్చు. అప్లోడ్లను పార్స్ చేస్తున్న లేదా డేటాను స్టోరేజీకి పంపిస్తున్న బిజీ సర్వర్లో, అటువంటి పాత లాక్ (stale lock) పైప్లైన్ను నిలిపివేయవచ్చు లేదా మూలాన్ని కనుగొనడం కష్టమైన ఎర్రర్లను కలిగించవచ్చు. 26.5.0లోని ఈ పరిష్కారం హ్యాండ్ఆఫ్ (handoff) ప్రక్రియను మళ్ళీ ఊహించదగినదిగా చేస్తుంది.
రెండవ Web Streams మార్పు ReadableStream మరియు TransformStreamలు BYOB రీడర్లతో ఎలా పనిచేస్తాయో మెరుగుపరుస్తుంది. BYOB అంటే Bring Your Own Buffer. స్ట్రీమ్ ప్రతిసారీ డేటాను అందించేటప్పుడు కొత్త మెమరీ చంక్ను కేటాయించడానికి బదులుగా, మీరు ముందుగానే సిద్ధం చేసుకున్న బఫర్ను దానికి అందిస్తారు. స్ట్రీమ్ ఆ బఫర్ను నింపుతుంది, మీరు ఆ బైట్లను ప్రాసెస్ చేస్తారు, ఆపై అదే బఫర్ను మళ్ళీ ఉపయోగించడానికి తిరిగి ఇస్తారు. మీరు పెద్ద మొత్తంలో డేటాను తరలిస్తున్నప్పుడు, ఈ చిన్న మెకానికల్ మార్పు అద్భుతమైన ఫలితాలను ఇస్తుంది.
Nodeలో BYOB సపోర్ట్ కొంతకాలంగా ఉంది, కానీ BYOB రీడర్ను అనుసంధానించినప్పుడు ReadableStream మరియు TransformStreamలలో కొన్ని ప్రత్యేక సందర్భాలు (edge cases) తప్పుగా ప్రవర్తించేవి. ఈ పరిష్కారం యొక్క సాంకేతిక వివరాల కంటే దాని ఆచరణాత్మక ఫలితం ముఖ్యం: స్పష్టమైన బఫర్లను ఉపయోగించే స్ట్రీమ్లు ఇప్పుడు రీడింగ్ మరియు ట్రాన్స్ఫర్మేషన్ దశలు రెండింటిలోనూ మరింత నమ్మదగినవిగా మారాయి. బ్యాక్ప్రెజర్ (backpressure) ఈవెంట్ల సమయంలో వచ్చే వింత ఎర్రర్ల వల్ల మీరు BYOB రీడర్లను వాడకుండా ఉండేవారైతే, ఈ రిలీజ్ దాని నుండి మీకు ఉపశమనం కలిగిస్తుంది.
BYOB నిజంగా ఎక్కడ ఉపయోగపడుతుంది?
బఫర్ రీయూజ్ (buffer reuse) గురించి సిద్ధాంతపరంగా మాట్లాడటం సులభం. కానీ అది ఎక్కడ అవసరమో ఆలోచించడం మరింత ఉపయోగకరంగా ఉంటుంది.
మీరు టెలిమెట్రీ అప్లోడ్లను స్వీకరించే సర్వీస్ను రాస్తున్నారని ఊహించుకోండి. ఆ అప్లోడ్లు కంప్రెస్ చేసిన లాగ్లు లేదా రా డేటా సెన్సార్ డంప్లు కావచ్చు, ఒక్కొక్కటి వందల మెగాబైట్ల పరిమాణంలో ఉండవచ్చు. స్ట్రీమ్ ప్రతి డేటా స్లైస్ కోసం కొత్త Node Bufferను కేటాయిస్తే, గార్బేజ్ కలెక్టర్ (garbage collector) అతిగా పనిచేయాల్సి వస్తుంది మరియు మెమరీ వినియోగం వేగంగా పెరుగుతుంది. BYOB రీడర్తో, మీరు స్టార్టప్లోనే ఒక మోడరేట్ బఫర్ పూల్ను కేటాయిస్తారు. స్ట్రీమ్ వాటిని నింపుతుంది, మీ పార్సర్ వాటిని ఖాళీ చేస్తుంది, మరియు అవి మళ్ళీ వాడుకలోకి వస్తాయి. దీనివల్ల మెమరీ స్థిరంగా ఉంటుంది. రెండు సాకెట్ల మధ్య నెట్వర్క్ ట్రాఫిక్ను ప్రాక్సీ చేస్తున్నప్పుడు లేదా పెద్ద CSV ఫైల్లను మొత్తం RAMలోకి లోడ్ చేయకుండా లైన్ బై లైన్ పార్స్ చేస్తున్నప్పుడు కూడా ఇదే పద్ధతి వర్తిస్తుంది.
Transform streams ఇక్కడ కూడా అంతే ముఖ్యమైనవి. ఒక TransformStream పైప్లైన్ మధ్యలో ఉంటుంది, బహుశా gzip స్ట్రీమ్ను డీకంప్రెస్ చేయడం లేదా డేటా చంక్స్ను వెంటనే ఎన్క్రిప్ట్ చేయడం వంటి పనులను చేస్తుంది. ఒకవేళ transform దశలో BYOB బఫర్లను సరిగ్గా నిర్వహించకపోతే, అవుట్పుట్ పాడవ్వడం (corrupted output), చంక్స్ మిస్ అవ్వడం లేదా లోడ్ ఎక్కువగా ఉన్నప్పుడు సిస్టమ్ ఆగిపోవడం (stalls) వంటివి జరగవచ్చు. 26.5.0 వెర్షన్ సరిగ్గా ఇటువంటి పైప్లైన్ సమస్యలనే పరిష్కరిస్తుంది, అందుకే హై-త్రూపుట్ I/O (high-throughput I/O) ఉపయోగిస్తున్న వారు దీనిపై దృష్టి సారించాలి.
నిశ్శబ్ద విజయాలు: ఫైల్ సిస్టమ్ మరియు ఎర్రర్ క్లారిటీ
26.5.0లో అంతా స్ట్రీమింగ్ గురించి మాత్రమే కాదు. recursive ఆప్షన్ను falseగా సెట్ చేసినప్పుడు fs.rm మరియు fs.rmSync ప్రవర్తనలో కూడా ఈ విడుదల మార్పులు చేసింది. గతంలో, డైరెక్టరీ పాత్తో పాటు recursive: falseను పంపడం వల్ల క్లీనప్ సమయంలో ఊహించని ఫలితాలు వచ్చేవి. ఈ మెథడ్ కాల్ చేసిన వ్యక్తి యొక్క ఉద్దేశానికి విరుద్ధంగా పనిచేయవచ్చు, అంటే ఆశించిన దానికంటే ఎక్కువ ఫైళ్లను డిలీట్ చేయడం లేదా ప్లాట్ఫారమ్ను బట్టి అస్థిరమైన రీతిలో విఫలం కావడం వంటివి జరిగేవి. ఫైళ్లను క్లీన్ చేయడం అనేది బోరింగ్గా మరియు ఊహించదగినదిగా (predictable) ఉండాల్సిన ప్రక్రియ. బోరింగ్గా ఉండటమే మంచిది. ఈ ఫిక్స్ ఆ ఊహించదగిన స్వభావాన్ని తిరిగి తెస్తుంది, తద్వారా మీ టెంపరరీ డైరెక్టరీ క్లీనప్ స్క్రిప్ట్లు లేదా డిప్లాయ్మెంట్ టేర్డౌన్ లాజిక్ కోడ్లో ఉన్న విధంగానే ఖచ్చితంగా పనిచేస్తాయి.
URL.canParse ఫెయిల్యూర్ (failure)ను రిపోర్ట్ చేసే విధానంలో కూడా ఒక క్వాలిటీ-ఆఫ్-లైఫ్ మెరుగుదల ఉంది. ఈ మెథడ్ తప్పుగా ఉన్న ఇన్పుట్ (malformed input) వల్ల ఎర్రర్ చూపించకుండానే, ఒక స్ట్రింగ్ సరైన URL అవునా కాదా అని తనిఖీ చేస్తుంది. 26.5.0లో, ఏదైనా తప్పు జరిగినప్పుడు ఇది ఇప్పుడు మెరుగైన Error.cause సమాచారాన్ని అందిస్తుంది. అసలు కారణాన్ని దాచిపెట్టే బదులు, ఎర్రర్ ఆబ్జెక్ట్ కారణాల గొలుసును (causal chain) భద్రపరుస్తుంది. అంటే, ఒక వాలిడేషన్ హెల్పర్ లోపల URL పార్సింగ్ విఫలమైనప్పుడు, మీరు లాగ్ చేసే స్టాక్ (stack) ద్వారా సమస్య తప్పు ప్రోటోకాల్ వల్ల వచ్చిందా, హోస్ట్ నేమ్ లేకపోవడం వల్ల వచ్చిందా లేదా మరేదైనా స్ట్రక్చరల్ సమస్య వల్ల వచ్చిందా అనేది తెలుస్తుంది. దీనివల్ల ప్రతి చోటా మాన్యువల్ డీబగ్ లాగ్లను (manual debug logs) జోడించాల్సిన అవసరం తగ్గి, సమయం ఆదా అవుతుంది.
మీరు అప్గ్రేడ్ అవ్వాలా?
దీనికి సమాధానం మీరు దేనిని ఉపయోగిస్తున్నారు అనే దానిపై ఆధారపడి ఉంటుంది.
మీ ప్రొడక్షన్ వర్క్లోడ్లు v20.x వంటి LTS వెర్షన్పై ఆధారపడి ఉంటే, అక్కడే కొనసాగండి. ఈ ఫిక్స్లు eventually బ్యాక్పోర్ట్ చేయబడతాయి లేదా తదుపరి యాక్టివ్ LTS వెర్షన్లో వస్తాయి. ఇప్పటికే సరిగ్గా పనిచేస్తున్న సర్వర్పై కొంచెం మెరుగైన స్ట్రీమ్ లాక్ లేదా స్పష్టమైన URL ఎర్రర్ కంటే, స్థిరత్వం (stability) మరియు ఊహించదగిన సపోర్ట్ టైమ్లైన్లే ముఖ్యం.
మీరు కొత్త సర్వీస్ను నిర్మిస్తున్నా, రియల్-టైమ్ డేటా పైప్లైన్ను ప్రోటోటైప్ చేస్తున్నా, లేదా పెర్ఫార్మెన్స్-క్రిటికల్ I/O కోసం Web Streams APIని చురుకుగా ఉపయోగిస్తున్నా, 26.5.0 కి మారడం మంచిది. Node streams మరియు బ్రౌజర్ Web Streams మధ్య పెరుగుతున్న సారూప్యత కేవలం కంపాటబిలిటీ (compatibility) పరంగా మాత్రమే కాదు. ఇది మరింత ఏకీకృత (unified) JavaScript రన్టైమ్ కోసం వేసిన పందెం, ఇక్కడ ట్రాన్స్లేషన్ లేయర్లు లేకుండానే ఒకే డేటా-పుషింగ్ లాజిక్ సర్వర్ మరియు క్లయింట్ మధ్య ప్రయాణించగలదు. ఇది మీ టీమ్ రెండు ఎన్విరాన్మెంట్లకు కోడ్ను పంపేటప్పుడు మెదడుపై ఒత్తిడిని (cognitive load) తగ్గిస్తుంది మరియు బగ్స్ వచ్చే అవకాశాలను తగ్గిస్తుంది.
ఈ విడుదల చిన్నదే కావచ్చు, కానీ దిశ స్పష్టంగా ఉంది. JavaScript ఎక్కడ నడిచినా పనిచేసే స్టాండర్డ్స్ ఆధారిత APIల కోసం Node నిరంతరం పెట్టుబడి పెడుతోంది. Web Streams మెరుగుదలలు పెద్ద వార్తలే కాకపోవచ్చు, కానీ ఇవి గత కొన్నేళ్లుగా ఇబ్బందికరంగా ఉన్న మార్గాన్ని సులభతరం చేస్తాయి. మీరు Current లైన్లో ఉంటే 26.5.0ని ఇప్పుడే పొందండి, మరియు సరైన సమయం వచ్చినప్పుడు మీ LTS వెర్షన్లో ఈ ఫిక్స్లు వస్తాయని ఎదురుచూడండి.
Source: Dev.to – Node.js 26.5.0: What's New for Web Streams and Error Handling
చర్చలో పాల్గొనండి మరియు GyaanSetu community on Telegramతో నేర్చుకోవడం కొనసాగించండి.