Node.js 26.5.0 اب دستیاب ہے۔ یہ ایک Current ریلیز ہے، LTS برانچ نہیں، اس لیے یہ اس پلیٹ فارم کی جدید ترین صلاحیتوں کے دہانے پر ہے۔ یہ فرق اہمیت رکھتا ہے۔ آپ کو اسے اندھا دھند کسی ایسے پروڈکشن فلیٹ (production fleet) میں استعمال نہیں کرنا چاہیے جو اٹھارہ ماہ کے استحکام کی توقع رکھتا ہو۔ لیکن یہ چھوٹی اور تیز رفتار ریلیز وہ جگہ ہیں جہاں آپ مستقبل کو تشکیل پاتے ہوئے دیکھتے ہیں۔ یہ ظاہر کرتی ہیں کہ مینٹینرز کن APIs کو بہتر بنا رہے ہیں اور رن ٹائم (runtime) کس سمت میں آگے بڑھ رہا ہے۔ 26.5.0 میں، اہم کام Web Streams API میں کیا گیا ہے، جس میں دو مخصوص اصلاحات (fixes) شامل ہیں جو Node کو براؤزر کے برابر (parity) لانے کی طرف ایک قدم بڑھاتی ہیں۔ یہ ریلیز فائل سسٹم اور URL ہینڈلنگ لیئرز میں دو خامیوں کو بھی دور کرتی ہے۔
Node.js میں Web Streams کیا کر رہے ہیں؟
اگر آپ نے کافی عرصے تک Node میں اسٹریمنگ کوڈ لکھا ہے، تو آپ جانتے ہوں گے کہ بلٹ ان stream ماڈیول کی اپنی ایک الگ پہچان ہے۔ Readable, Writable, Transform, اور Duplex برسوں سے اس ایکو سسٹم کے اہم ستون رہے ہیں۔ یہ طاقتور ہیں، لیکن یہ ان اسٹریمز (streams) کے برابر نہیں ہیں جن سے آپ براؤزر میں ملتے ہیں۔ جب آپ ایک فرنٹ اینڈ سروس ورکر اور ایک بیک اینڈ روٹ ہینڈلر کے درمیان لاجک شیئر کرنے کی کوشش کرتے ہیں، تو یہ فرق رکاوٹ بن جاتا ہے۔ آپ کو ایڈاپٹرز دوبارہ لکھنے پڑتے ہیں، ڈیٹا کو غیر مانوس شکلوں میں کاپی کرنا پڑتا ہے، یا پھر مشترکہ کوڈ سے مکمل طور پر بچنا پڑتا ہے۔
Web Streams API کا مقصد اسی فرق کو ختم کرنا ہے۔ یہ وہی معیار ہے جو براؤزر میں fetch باڈی ہینڈلنگ کو طاقت فراہم کرتا ہے۔ اسے Node میں لا کر، یہ پروجیکٹ آپ کو ایک ہی بار اسٹریمنگ لاجک لکھنے اور اسے کسی بھی ماحول میں چلانے کی اجازت دیتا ہے۔ یہ API ReadableStream, WritableStream, اور TransformStream آبجیکٹس کے ذریعے کام کرتی ہے جو ایک یکساں انٹرفیس کے ذریعے چنکس (chunks) پاس کرتے ہیں۔ ورژن 26.5.0 اس انٹرفیس کو دوبارہ نہیں لکھتا، بلکہ یہ دو اہم پیچوں کو مزید مضبوط کرتا ہے۔
releaseLock کی اصلاح اور BYOB Readers کی صفائی
اس ریلیز میں ایک ٹھوس تبدیلی WritableStreamDefaultWriter پر releaseLock میتھڈ کی اصلاح ہے۔ Web Streams ماڈل میں، ایک رائٹر لاک (writer lock) متعدد صارفین کو ایک ہی وقت میں ایک ہی اسٹریم پر اثر انداز ہونے سے روکتا ہے۔ جب آپ releaseLock() کال کرتے ہیں، تو آپ یہ اشارہ دے رہے ہوتے ہیں کہ آپ کا رائٹر اپنا کام مکمل کر چکا ہے اور بنیادی اسٹریم اگلے آپریشن کے لیے آزاد ہے۔ یہاں ایک غلط امپلیمنٹیشن اسٹریم کو معلق (limbo) چھوڑ سکتی ہے، جہاں وہ یہ سمجھتی رہتی ہے کہ اس کا مالک موجود ہے حالانکہ رائٹر ختم ہو چکا ہوتا ہے۔ اپ لوڈز کو پارس کرنے یا ڈیٹا کو اسٹوریج میں منتقل کرنے والے مصروف سرور میں، اس قسم کا پرانا لاک پائپ لائن کو روک سکتا ہے یا ایسے ایررز پیدا کر سکتا ہے جن کا اصل ذریعہ تلاش کرنا مشکل ہوتا ہے۔ 26.5.0 میں کی گئی اصلاح ہینڈ آف (handoff) کو دوبارہ قابلِ پیش گوئی بناتی ہے۔
دوسرا Web Streams بدلاؤ اس بات کو بہتر بناتا ہے کہ ReadableStream اور TransformStream BYOB ریڈرز کے ساتھ کیسے کام کرتے ہیں۔ BYOB کا مطلب ہے Bring Your Own Buffer۔ اسٹریم کے ہر بار ڈیٹا فراہم کرتے وقت میموری کا نیا حصہ مختص کرنے کے بجائے، آپ اسے ایک ایسا بفر (buffer) دیتے ہیں جو آپ پہلے ہی الگ کر چکے ہوتے ہیں۔ اسٹریم اس بفر کو بھر دیتی ہے، آپ بائٹس (bytes) کو پروسیس کرتے ہیں، اور پھر اسی بفر کو دوبارہ استعمال کے لیے واپس کر دیتے ہیں۔ یہ ایک چھوٹا سا میکانیکی فرق ہے جو بڑے پیمانے پر ڈیٹا منتقل کرتے وقت غیر معمولی نتائج دیتا ہے۔
Node میں کچھ عرصے سے BYOB سپورٹ موجود ہے، لیکن ReadableStream اور TransformStream میں کچھ خاص صورتحال (edge cases) میں BYOB ریڈر منسلک ہونے پر مسائل پیدا ہو سکتے تھے۔ اصلاح کی تفصیلات سے زیادہ اس کا عملی نتیجہ اہم ہے: اب وہ اسٹریمز جو واضح بفرز کا استعمال کرتی ہیں، ریڈنگ اور ٹرانسفارمیشن دونوں مراحل میں زیادہ قابلِ اعتماد ہیں۔ اگر آپ نے بیک پریشر (backpressure) کے واقعات کے دوران عجیب و غریب ایررز کی وجہ سے BYOB ریڈرز سے پرہیز کیا ہے، تو یہ ریلیز اس سے دور رہنے کی ایک اور وجہ ختم کر دیتی ہے۔
BYOB اصل میں کہاں نظر آتا ہے
تجریدی طور پر بفر کے دوبارہ استعمال کے بارے میں بات کرنا آسان ہے۔ زیادہ مفید یہ سوچنا ہے کہ یہ کہاں اہمیت رکھتا ہے۔
تصور کریں کہ آپ ایک ایسی سروس لکھ رہے ہیں جو ٹیلی میٹری (telemetry) اپ لوڈز قبول کرتی ہے۔ وہ اپ لوڈز کمپریسڈ لاگز یا خام سینسر ڈمپس ہو سکتے ہیں، جن میں سے ہر ایک کئی سو میگا بائٹس کا ہو سکتا ہے۔ اگر اسٹریم ڈیٹا کے ہر حصے کے لیے ایک نیا Node Buffer مختص کرتی ہے، تو گاربیج کلیکٹر (garbage collector) کو ضرورت سے زیادہ کام کرنا پڑتا ہے اور میموری کا استعمال تیزی سے بڑھ جاتا ہے۔ BYOB ریڈر کے ساتھ، آپ اسٹارٹ اپ پر بفرز کا ایک مناسب پول (pool) مختص کرتے ہیں۔ اسٹریم انہیں بھرتی ہے، آپ کا پارسر انہیں استعمال کرتا ہے، اور وہ دوبارہ استعمال کے لیے واپس آ جاتے ہیں۔ میموری کا استعمال مستحکم رہتا ہے۔ یہی پیٹرن اس وقت بھی لاگو ہوتا ہے جب آپ دو ساکٹس (sockets) کے درمیان نیٹ ورک ٹریفک کو پراکسی کر رہے ہوں یا پوری فائل کو RAM میں لوڈ کیے بغیر بڑی CSV فائلوں کو لائن بہ لائن پارس کر رہے ہوں۔
ٹرانسفارم اسٹریمز (Transform streams) بھی یہاں اتنی ہی اہم ہیں۔ ایک TransformStream پائپ لائن کے درمیان میں ہوتا ہے، شاید gzip اسٹریم کو ڈی کمپریس کر رہا ہو یا چنکس (chunks) کو آن دی فلائی انکرپٹ کر رہا ہو۔ اگر ٹرانسفارم مرحلہ BYOB بفرز کو غلط طریقے سے ہینڈل کرتا ہے، تو آپ کو کرپٹ شدہ آؤٹ پٹ، ڈراپ شدہ چنکس، یا لوڈ کے دوران تعطل (stalls) نظر آ سکتے ہیں۔ 26.5.0 کے فکسز بالکل اسی طرح کے پائپ لائن کے مسائل کو حل کرتے ہیں، یہی وجہ ہے کہ ہائی تھرو پٹ I/O استعمال کرنے والے ہر شخص کو اس پر توجہ دینی چاہیے۔
خاموش کامیابیاں: فائل سسٹم اور ایرر کی وضاحت
26.5.0 میں سب کچھ صرف اسٹریمنگ کے بارے میں نہیں ہے۔ یہ ریلیز fs.rm اور fs.rmSync کے رویے کو بھی درست کرتی ہے جب recursive آپشن کو false پر سیٹ کیا گیا ہو۔ پہلے، ڈائریکٹری پاتھ کے ساتھ recursive: false بھیجنے سے صفائی (cleanup) کے دوران غیر متوقع نتائج مل سکتے تھے۔ یہ میتھڈ ایسے طریقوں سے کام کر سکتا تھا جو کالر کے واضح مقصد سے مطابقت نہیں رکھتے تھے، جیسے کہ توقع سے زیادہ چیزیں ڈیلیٹ کرنا یا پلیٹ فارم کے لحاظ سے غیر مستقل طریقے سے فیل ہونا۔ فائلوں کی صفائی ایک ایسا آپریشن ہے جسے بورنگ اور قابلِ پیش گوئی ہونا چاہیے۔ بورنگ ہونا اچھی بات ہے۔ یہ فکس اس قابلِ پیش گوئی ہونے کو بحال کرتا ہے، تاکہ آپ کے عارضی ڈائریکٹری کلین اپ اسکرپٹس یا ڈیپلائمنٹ ٹیئر ڈاؤن لاجک بالکل ویسے ہی کام کریں جیسا کہ کوڈ بتاتا ہے۔
URL.canParse کے ذریعے ناکامی کی رپورٹ کرنے کے طریقے میں بھی استعمال میں آسانی کے لیے بہتری لائی گئی ہے۔ یہ میتھڈ غلط فارمیٹ والے ان پٹ پر ایرر تھرو کیے بغیر چیک کرتا ہے کہ آیا اسٹرنگ ایک درست URL ہے یا نہیں۔ 26.5.0 میں، اب جب کچھ غلط ہوتا ہے تو یہ بہتر Error.cause معلومات فراہم کرتا ہے۔ اصل وجہ کو نظر انداز کرنے کے بجائے، ایرر آبجیکٹ وجوہاتی سلسلہ (causal chain) کو محفوظ رکھتا ہے۔ اس کا مطلب ہے کہ جب کسی ویلیڈیشن ہیلپر کے اندر URL پارس کرنے میں ناکامی ہوتی ہے، تو آپ کا لاگ شدہ اسٹیک (stack) آپ کو بتاتا ہے کہ مسئلہ غلط پروٹوکول کا تھا، ہوسٹ نیم (hostname) غائب تھا، یا کوئی اور ساختی مسئلہ تھا۔ اس طرح آپ کو ہر کال سائٹ پر دستی طور پر ڈی بگ لاگز لگانے میں کم وقت صرف کرنا پڑے گا۔
کیا آپ کو اپ گریڈ کرنا چاہیے؟
اس کا جواب اس بات پر منحصر ہے کہ آپ کیا چلا رہے ہیں۔
اگر آپ کے پروڈکشن ورک لوڈز کسی LTS ورژن جیسے کہ v20.x لائن پر ہیں، تو وہیں رہیں۔ یہ فکسز آخر کار بیک پورٹ کر دیے جائیں گے یا اگلی ایکٹو LTS میں پہنچ جائیں گے۔ استحکام اور قابلِ پیش گوئی سپورٹ ٹائم لائنز اس فائدے پر بھاری ہیں کہ ایک ایسے سرور پر اسٹریم لاک کو تھوڑا ہموار کیا جائے یا URL ایرر کو واضح کیا جائے جو پہلے سے ہی کام کر رہا ہے۔
اگر آپ کوئی نئی سروس بنا رہے ہیں، ریئل ٹائم ڈیٹا پائپ لائن کا پروٹو ٹائپ بنا رہے ہیں، یا کارکردگی کے لحاظ سے اہم I/O کے لیے Web Streams API کا فعال طور پر استعمال کر رہے ہیں، تو 26.5.0 پر منتقل ہونا فائدہ مند ہے۔ Node اسٹریمز اور براؤزر Web Streams کے درمیان بتدریج ہم آہنگی محض مطابقت (compatibility) کی جیت نہیں ہے۔ یہ ایک زیادہ متحد JavaScript runtime پر داؤ ہے جہاں ڈیٹا منتقل کرنے کا وہی لاجک ترجمہ کرنے والے لیئرز (translation layers) کے بغیر سرور اور کلائنٹ کے درمیان سفر کر سکتا ہے۔ یہ ذہنی بوجھ (cognitive load) کو کم کرتا ہے اور جب آپ کی ٹیم دونوں ماحول میں کوڈ بھیجتی ہے تو بگ کے امکانات کو بھی کم کرتا ہے۔
یہ ریلیز چھوٹی ہے، لیکن سمت واضح ہے۔ Node ان اسٹینڈرڈز پر مبنی APIs میں سرمایہ کاری جاری رکھے ہوئے ہے جو ہر اس جگہ کام کرتی ہیں جہاں JavaScript چلتی ہے۔ Web Streams کی بہتری کوئی بڑی سرخیوں والی فیچر نہیں ہے، لیکن یہ اس راستے کو ہموار کرتی ہے جو برسوں سے دشوار گزار رہا ہے۔ اگر آپ Current لائن پر ہیں تو 26.5.0 حاصل کریں، اور ان فکسز کے آپ کے LTS ورژن میں آنے کا انتظار کریں جب صحیح وقت آ جائے۔
Source: Dev.to – Node.js 26.5.0: What's New for Web Streams and Error Handling
Join the discussion and keep learning with the GyaanSetu community on Telegram.