ওয়েবঅ্যাসেম্বলি: ব্রাউজার ছাড়িয়ে সার্ভার ও এজে

ধরুন আপনি একটা সার্ভারলেস ফাংশনসার্ভারলেস ফাংশনযে ছোট প্রোগ্রাম নিজে থেকে সার্ভার পরিচালনা না করে ক্লাউড প্রোভাইডারের অবকাঠামোতে চাহিদা অনুযায়ী চালানো হয় ডিপ্লয় করলেন, আর ব্যবহারকারী রিকোয়েস্ট পাঠানোর সঙ্গে সঙ্গে সেটা কোল্ড-স্টার্টকোল্ড-স্টার্টদীর্ঘদিন নিষ্ক্রিয় থাকা একটি প্রোগ্রাম নতুন করে চালু হতে যে বাড়তি সময় নেয় নিয়ে কয়েকশ মিলিসেকেন্ড আটকে থাকল। ছোট মনে হলেও, স্কেলে এই বিলম্বটাই আপনার প্রোডাক্টের অভিজ্ঞতা নষ্ট করে দিতে পারে। ২০১৯ সালের ডিসেম্বরে ওয়ার্ল্ড ওয়াইড ওয়েব কনসর্টিয়াম (W3C) যখন WebAssembly-কে HTML, CSS ও JavaScript-এর পাশে ওয়েবের চতুর্থ ভিত্তি হিসেবে স্বীকৃতি দিল, তখন কেউ হয়তো ভাবেনি যে এই একই প্রযুক্তি একদিন ঠিক এই সমস্যাটার সমাধান হয়ে উঠবে।

শুরুতে Wasm-কে দেখা হয়েছিল ব্রাউজারের মধ্যে JavaScript-এর দ্রুত বিকল্প হিসেবে — একটা সংকীর্ণ পরিচয়। ছয় বছর পর সেই পরিচয় অনেক পেছনে ফেলে এসেছে প্রযুক্তিটা। এখন Wasm চলছে সার্ভারে, এজ কম্পিউটিং নোডে, সার্ভিস মেশে, এমনকি প্লাগইন সিস্টেমে। আমার মতে, এই সম্প্রসারণটাই বলে দেয় Wasm-এর আসল প্রতিশ্রুতি কী ছিল — প্রায়-নেটিভ পারফরম্যান্স, শক্তিশালী স্যান্ডবক্সিংস্যান্ডবক্সিংপ্রোগ্রামকে একটি বিচ্ছিন্ন, সীমিত পরিবেশে চালানো, যাতে সেটি বাইরের সিস্টেমে ক্ষতি করতে না পারে এবং ভাষা-নিরপেক্ষতা। Rust, Go, C/C++, TinyGo, AssemblyScript-সহ একাধিক ভাষা থেকে Wasm বাইনারি কম্পাইল করা যায়, আর সেই একই মডিউল চলে যেকোনো Wasm-সক্ষম হোস্টে। ভাবুন তো — একবার লেখা কোড, যেকোনো জায়গায় চালানো — এই স্বপ্ন কতবার ভাঙল, আবার কতবার ফিরে এল?

WASI: ব্রাউজারের বাইরে বেরোতে গিয়ে কোন সমস্যাটা সমাধান হলো?

ব্রাউজারের বাইরে Wasm চালাতে হলে ফাইল, নেটওয়ার্ক বা ক্লক-এর মতো সিস্টেম রিসোর্স অ্যাক্সেস দরকার হয়। এই সমস্যার সমাধান দিয়েছে WASI (WebAssembly System Interface)WASI (WebAssembly System Interface)Wasm প্রোগ্রামকে ব্রাউজারের বাইরে ফাইল, নেটওয়ার্কের মতো সিস্টেম রিসোর্সে নিয়ন্ত্রিতভাবে অ্যাক্সেস দেওয়ার মানদণ্ড — স্যান্ডবক্সড, ক্যাপাবিলিটি-ভিত্তিক অ্যাক্সেস। ২০২৪ সালে প্রকাশিত WASI Preview 2 নিয়ে এসেছে কম্পোনেন্ট মডেলকম্পোনেন্ট মডেলছোট ছোট স্বতন্ত্র Wasm মডিউলকে একসঙ্গে জুড়ে বড় অ্যাপ্লিকেশন গঠনের কাঠামো, যেখানে ছোট ছোট Wasm মডিউল একসঙ্গে রচনা করে (compose) বড় অ্যাপ্লিকেশন তৈরি করা যায়। এটা শুধু কারিগরি উন্নতি নয় — এটা ডেভেলপারদের চিন্তার ধরনও বদলে দিচ্ছে।

কন্টেইনারের চেয়ে দ্রুত হলে সেটাই কি যথেষ্ট কারণ?

এজ ও সার্ভারলেস প্রোভাইডাররা Wasm গ্রহণ করছে বিস্ময়কর গতিতে — মূলত কোল্ড-স্টার্ট সময় মিলিসেকেন্ডের ভগ্নাংশে নেমে আসার কারণে, যা কন্টেইনার বা VM-এর তুলনায় অনেক দ্রুত। আমার কাছে এটা শুধু গতির প্রশ্ন নয়, বরং কী ধরনের ওয়ার্কলোড আমরা কীভাবে ভাবছি তার প্রশ্ন। উদাহরণগুলো দেখুন:

• Fastly Compute@Edge — Wasm-ভিত্তিক, বিশ্বের সবচেয়ে বড় বাণিজ্যিক Wasm এজ প্ল্যাটফর্মগুলোর একটি।
• Cloudflare Workers — প্রধানত V8 isolates-এ চললেও Wasm সাপোর্ট আছে।
• Fermyon Cloud — Spin ফ্রেমওয়ার্কে ভিত্তি করে তৈরি, পুরোপুরি Wasm-ফার্স্ট।
• wasmCloud ও WasmEdge — CNCF-পৃষ্ঠপোষিত, distributed Wasm রানটাইম।

প্লাগইন সিস্টেমে Wasm কেন এত জনপ্রিয় হয়ে উঠল?

কারণটা আমার কাছে সহজ — Wasm-এর নিরাপদ স্যান্ডবক্সিং আপনাকে একটা সুবিধা দেয় যা আগে সহজে পাওয়া যেত না, আপনি ডেভেলপারকে ব্যক্তিগতভাবে বিশ্বাস না করেও তাঁর কোড নিরাপদে চালাতে পারেন। এই কারণেই Envoy প্রক্সি ও Istio সার্ভিস মেশেসার্ভিস মেশেমাইক্রোসার্ভিসগুলোর মধ্যে যোগাযোগ পরিচালনা ও নিয়ন্ত্রণ করার একটি অবকাঠামো স্তর Wasm ফিল্টার চলে; টার্মিনাল মাল্টিপ্লেক্সার Zellij-এর প্লাগইন Wasm-এ লেখা; Figma-র প্লাগইন সিস্টেম, Shopify-র ফাংশন এক্সটেনশন, Veracode-এর নিরাপত্তা স্ক্যানার — সবাই একই যুক্তিতে Wasm বেছে নিয়েছে।

Docker কি Wasm-কে প্রতিদ্বন্দ্বী নাকি সহযোগী হিসেবে দেখছে?

২০২২ সালে Docker ঘোষণা দেয় তারা Wasm কন্টেইনার চালাবে — কন্টেইনার প্রতিস্থাপন হিসেবে নয়, পরিপূরক হিসেবে, আর এই অবস্থানটাই আমার কাছে সবচেয়ে বাস্তবসম্মত মনে হয়। Kubernetes ইকোসিস্টেমে runwasi, containerd-shim-wasm-এর মতো প্রকল্প Wasm-কে Pod-এর মধ্যে চালানোর সুযোগ দিচ্ছে। ছোট ইভেন্ট-ড্রিভেন ফাংশন বা প্লাগইনের মতো কাজে Wasm কন্টেইনারের চেয়ে উল্লেখযোগ্যভাবে দক্ষ — কিন্তু ভারী, দীর্ঘস্থায়ী অ্যাপ্লিকেশনের জন্য কন্টেইনার এখনো অপ্রতিদ্বন্দ্বী। দুটোর সহাবস্থানই বাস্তবতা, একটার জয়-পরাজয় নয়।

Bytecode Alliance: ইকোসিস্টেম কে ধরে রাখছে?

Wasm-এর ইকোসিস্টেম-স্তরের সমন্বয় করছে Bytecode Alliance — যার সদস্যদের মধ্যে আছে Mozilla, Fastly, Intel, Microsoft এবং আরও অনেকে। WASI, component model, wit-bindgen-এর মতো প্রকল্প তাদের ছাতার নিচে এগোচ্ছে, আর এই কেন্দ্রীভূত সমন্বয়টাই Wasm-কে একটা এলোমেলো স্ট্যান্ডার্ডের বদলে সুসংগঠিত প্রযুক্তি হিসেবে টিকিয়ে রাখছে।

বাংলাদেশের ডেভেলপারদের জন্য এটা কেন শুধু বিদেশি প্রযুক্তি নয়?

বাংলাদেশের কিছু আর্লি-অ্যাডপ্টার ডেভেলপার ইতিমধ্যে ব্যাকএন্ড পারফরম্যান্সের জন্য Wasm পরীক্ষা করছেন — বিশেষত যাঁরা Cloudflare Workers বা Fastly-তে ওয়েব অ্যাপ হোস্ট করেন। Wasm-ভিত্তিক এজ ফাংশনের কোল্ড-স্টার্ট প্রায় শূন্য হওয়ায় পেমেন্ট গেটওয়ে, ওয়েবহুক-হ্যান্ডলিং ও লাইটওয়েট API-এর জন্য এটা সাশ্রয়ী পথ। স্থানীয় হোস্টিং প্রদানকারীরাও ধীরে ধীরে Wasm-সক্ষম প্ল্যাটফর্মের কথা ভাবছেন — বুয়েট ও আইইউটির কিছু ছাত্রদল ইতিমধ্যে TinyGo-তে Wasm নিয়ে হাত পাকাচ্ছেন। আমার মনে হয়, এখনই সময় এই ছাত্রদলগুলোকে গুরুত্ব দিয়ে দেখার — কারণ পরবর্তী প্রজন্মের ব্যাকএন্ড ইঞ্জিনিয়াররা এখান থেকেই তৈরি হবেন।

WebAssembly কি কন্টেইনারকে সম্পূর্ণ প্রতিস্থাপন করবে? আমার উত্তর — সম্ভবত না। কিন্তু যেসব কাজের জন্য দ্রুত কোল্ড-স্টার্ট, নিরাপদ স্যান্ডবক্স ও ভাষা-নিরপেক্ষ এক্সিকিউশন দরকার, সেই কাজগুলোতে Wasm ক্রমেই ডিফল্ট পছন্দ হয়ে উঠছে। "Write once, run anywhere"-এর পুরনো প্রতিশ্রুতি নতুন রূপে ফিরে এসেছে — আর এবার, আমার বিশ্বাস, প্রতিশ্রুতিটা আগের চেয়ে বেশি বাস্তবসম্মত।