What Is Full-Stack — ফুল-স্ট্যাক ও framework বাংলায় | পর্ব ০১

এক নজরে · TL;DR

একটি পণ্য, চারটি স্তর: frontend, backend, database আর infrastructure. “কার্টে যোগ করুন” বাটনের একটি ক্লিক চারটিকেই ছুঁয়ে যায়।
ফুল-স্ট্যাক মানে সব জানা নয়: সৎ অর্থে এটি T-আকৃতির দক্ষতা। একটি দিকে গভীর জ্ঞান, বাকি স্তরে কাজ চালানোর মতো জ্ঞান।
Library বনাম framework: library-কে আপনি ডাকেন, framework আপনাকে ডাকে। এই উল্টে যাওয়াকে বলে inversion of control.
Framework-এর দাম আছে: সত্যিকারের একটি build-এ একই ছোট কার্টের JavaScript ছিল 0.48 kB (plain) আর 68.77 kB (React), দুটোই gzip করা।
এই কোর্সের পথ: TypeScript, React, Next.js, Node.js, Express, Prisma আর PostgreSQL বা SQLite দিয়ে ধাপে ধাপে “বাজারঘর” নামের একটি কাল্পনিক অনলাইন দোকান বানানো।

এই পর্বে যা শিখবেন

একটি ওয়েব পণ্যের চারটি স্তর, আর একটি ক্লিক কোন কোন স্তর পার হয়
“ফুল-স্ট্যাক ডেভেলপার” কথাটির সৎ অর্থ
Library আর framework আলাদা করার একটি পরিষ্কার পরীক্ষা
Framework যা দেয়, আর তার বিনিময়ে যা নেয়
একই কার্ট plain JavaScript আর React-এ লিখে তুলনা
১৪ মডিউলের মানচিত্র, পূর্বশর্ত আর নিজের স্তর অনুযায়ী লক্ষ্য

১ · একটি পণ্য, চারটি স্তর

একটি রেস্তোরাঁর কথা ভাবুন। আপনি বসেন সাজানো ঘরে, মেনু দেখেন, ওয়েটারকে অর্ডার দেন। রান্নাঘর আপনি দেখেন না, কিন্তু আসল কাজ সেখানেই হয়। চাল-ডাল থাকে গুদামে। আর পুরো রেস্তোরাঁ চলে ভবন, বিদ্যুৎ আর গ্যাসের লাইনের ওপর। একটি ওয়েব পণ্যও ঠিক এভাবে সাজানো।

স্তর	রেস্তোরাঁয়	কাজ	কোথায় চলে
Frontend	সাজানো ঘর আর ওয়েটার	ব্যবহারকারী যা দেখেন ও চাপেন	ব্যবহারকারীর browser-এ
Backend	রান্নাঘর	নিয়ম যাচাই, হিসাব, অনুমতি দেখা	আপনার server-এ
Database	গুদাম আর হিসাবের খাতা	তথ্য টিকিয়ে রাখা	database server-এ
Infrastructure	ভবন, বিদ্যুৎ, গ্যাসের লাইন	সব কিছু চালু রাখা ও পৌঁছে দেওয়া	hosting, network, deployment-এর ব্যবস্থায়

এক পণ্যের চার স্তর

Frontend, backend, database and the infrastructure under them

ছবি ১.১ — ওপরের তিনটি স্তরের প্রতিটি সবার নিচের স্তরের ওপর চলে।

এবার একটি বাস্তব ক্লিক অনুসরণ করা যাক। আমাদের কাল্পনিক দোকান বাজারঘর-এ একজন ক্রেতার কার্টে আগে থেকে ১ কেজি মসুর ডাল আছে (দাম ৳১২০)। তিনি আরেকটি যোগ করলেন। নিচে “পরে” চেপে দেখুন।

ক্লিকbrowser
Frontendঅনুরোধ বানায়
Infrastructureপৌঁছে দেয়
Backendনিয়ম দেখে
Databaseতথ্য বদলায়
উত্তরJSON ফেরে
নতুন স্ক্রিনbrowser

স্ক্রিনক্লিকের মুহূর্তে

মসুর ডাল ১ কেজি   ৳120   [ কার্টে যোগ করুন ]
কার্টে: 1টি · মোট: ৳120

Frontendbrowser-এ চলা কোড

fetch('/api/cart/items', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ productId: 17, qty: 1 }),
});

Infrastructureপথে যা হয়

DNS: bazarghar.example → server-এর ঠিকানা
TLS: পথের তথ্য এনক্রিপ্ট করা
POST /api/cart/items → app server-এ পৌঁছাল

Backendতিনটি যাচাই

session থেকে ক্রেতা চেনা   → userId 9
qty ঠিক আছে?              → 1 ≥ 1, হ্যাঁ
browser-এর দাম মানা হয় না → দাম আসবে database থেকে

DatabaseParameter দিয়ে নিরাপদ query

SELECT price, stock FROM products WHERE id = $1;
-- [17] → price 120, stock 8
UPDATE cart_items SET qty = qty + 1
 WHERE user_id = $1 AND product_id = $2;
-- [9, 17] → qty 1 থেকে 2

ResponseBackend-এর উত্তর

HTTP/1.1 200 OK
Content-Type: application/json

{"items":[{"productId":17,"qty":2}],"total":240}

স্ক্রিনউত্তর পাওয়ার পরে

মসুর ডাল ১ কেজি   ৳120   [ কার্টে যোগ করুন ]
কার্টে: 2টি · মোট: ৳240

ধাপ ১ — ক্লিক। স্ক্রিনে কার্টে ১টি পণ্য, মোট ৳১২০. ক্রেতা বাটন চাপলেন। এখন পর্যন্ত সব কিছু তাঁর ফোনের browser-এর ভেতরে।
ধাপ ২ — Frontend. কোড একটি HTTP অনুরোধ বানায়: পণ্য ১৭, পরিমাণ ১। খেয়াল করুন, দাম পাঠানো হচ্ছে না। দাম ঠিক করার অধিকার browser-এর নেই।
ধাপ ৩ — Infrastructure. অনুরোধটি domain, TLS আর network পেরিয়ে server-এ যায়। ক্রেতা বা কোড লেখক সাধারণত এই ধাপ দেখেন না, কিন্তু এখানে গোলমাল হলে পুরো সাইট বন্ধ।
ধাপ ৪ — Backend. Server দেখে: কে অনুরোধ করেছেন (userId ৯), পরিমাণ ঠিক আছে কি না। Browser থেকে আসা কোনো কিছুই বিশ্বাস করা হয় না।
ধাপ ৫ — Database. দাম ১২০, stock ৮, তাই যোগ করা যায়। কার্টে পরিমাণ ১ থেকে ২ হলো। মান সরাসরি SQL-এ জোড়া হয়নি, parameter হিসেবে গেছে।
ধাপ ৬ — উত্তর। Backend জানায়: পরিমাণ ২, মোট ২ × ১২০ = ৳২৪০। এই হিসাব server-এর, browser-এর নয়।
ধাপ ৭ — নতুন স্ক্রিন। Frontend উত্তর পেয়ে কার্টের সংখ্যা ২ আর মোট ৳২৪০ দেখায়। একটি ক্লিক চারটি স্তরই ছুঁয়ে গেল। এই যাত্রার প্রতিটি মিলিসেকেন্ড পর্ব ০২-এ দেখবেন।

মূল ধারণা

স্তরগুলো ভাগ করা হয় কোথায় চলে আর কাকে বিশ্বাস করা যায়, তা দিয়ে। Browser-এর কোড ব্যবহারকারীর হাতে থাকে, তাই সেখানে থাকে সুবিধা। নিয়ম আর নিরাপত্তা থাকে server-এ।

২ · “ফুল-স্ট্যাক ডেভেলপার” আসলে কে

চাকরির বিজ্ঞপ্তি পড়লে মনে হতে পারে, ফুল-স্ট্যাক ডেভেলপার মানে একাই পুরো কোম্পানি। সত্যি কথা হলো, চারটি স্তরের প্রতিটিতে একজন মানুষ সমান গভীর হতে পারেন না। প্রতিটি স্তরই একটি পূর্ণ পেশা। Database-এর গভীরে কাজ করেই অনেকে সারা জীবন কাটান।

সৎ সংজ্ঞাটি হলো: ফুল-স্ট্যাক ডেভেলপার একটি ফিচার শুরু থেকে শেষ পর্যন্ত নিজে নিয়ে যেতে পারেন, আর কোথায় থেমে বিশেষজ্ঞের সাহায্য নিতে হবে তা জানেন। ক্রিকেটের অলরাউন্ডারের মতো। তিনি মূলত ব্যাটার বা বোলার, একটিতে সত্যিই ভালো, অন্যটিতে দলের কাজে লাগার মতো।

T-আকৃতির দক্ষতা

T-shaped skill: broad across the stack, deep in one area

ছবি ১.২ — আড়াআড়ি দণ্ড সবার সাথে কথা বলার ভাষা দেয়, খাড়া দণ্ড আপনার আসল মূল্য তৈরি করে।

তাই এই কোর্স একসাথে সব শেখার ডাক দেয় না। আগে আড়াআড়ি দণ্ডটি বানান: একটি ছোট অ্যাপ শুরু থেকে deployment পর্যন্ত নিয়ে যান। তারপর যে স্তর ভালো লাগে, সেখানে গভীরে যান।

৩ · Library বনাম framework — কে কাকে ডাকে

দুটি শব্দ প্রায়ই গুলিয়ে যায়। পার্থক্যটি আকারে নয়, নিয়ন্ত্রণে।

নিজের বাড়িতে বিয়ের আয়োজন করছেন। দরকার হলে ডেকোরেটরকে ডাকলেন, দরকার হলে বাবুর্চিকে। সিদ্ধান্ত আর সময়সূচি আপনার। এটি library. এবার ভাবুন, একটি কমিউনিটি সেন্টার ভাড়া নিলেন। সূচি, হলের নিয়ম, পরিবেশনের ধরন সব তাদের। আপনি শুধু মেনু আর অতিথির তালিকা দিয়ে দিলেন, সময় হলে তারাই সেগুলো কাজে লাগাল। এটি framework.

এই উল্টে যাওয়া নিয়ন্ত্রণের নাম inversion of control. চলতি নাম Hollywood principle: “Don't call us, we'll call you.” Framework-এর ফাঁকা জায়গায় আপনি নিজের কোড বসান, চালানোর সময় ঠিক করে framework.

1// Library: আপনি ডাকেন2const text = taka(1250);3console.log(text);45// Framework: সে ডাকে6app.get('/products', list);7app.listen(3000);89function list(req, res) {10  res.json(rows);11}

এই মুহূর্তের অবস্থা

নিয়ন্ত্রণ
কে ডাকল

আপনি ডাকলেন। আপনার কোড চলছে। লাইন ২-এ আপনি নিজে taka ফাংশনটি ডাকলেন, কখন ডাকবেন তা আপনারই সিদ্ধান্ত।
Library কাজ করল। অল্প সময়ের জন্য নিয়ন্ত্রণ library-র হাতে। সে সংখ্যাটি সাজিয়ে "৳1,250" ফেরত দিল, তারপর সরে গেল।
নিয়ন্ত্রণ আপনার কাছে ফিরল। এই হলো library-র চরিত্র: ডাকলে কাজ করে, শেষ হলে ফিরে আসে। আপনি ফল ছাপালেন।
এবার framework. app.get লাইনে list ফাংশনটি চলল না। আপনি শুধু জানালেন: “/products-এর অনুরোধ এলে এটি ডাকবেন।”
নিয়ন্ত্রণ চলে গেল। app.listen ডাকার পর আপনার লেখা ক্রম শেষ। Framework এখন অনুরোধের অপেক্ষায়। পরের কাজ কখন, আপনি আর ঠিক করছেন না।
Framework আপনাকে ডাকল। একটি অনুরোধ এল। Framework নিজেই list(req, res) ডাকল, সাথে তৈরি req আর res দিয়ে দিল। আপনি কোথাও list() লেখেননি।
আবার framework-এর হাতে। উত্তর পাঠানো শেষে নিয়ন্ত্রণ framework-এ ফেরে, সে পরের অনুরোধের অপেক্ষা করে। মূল চক্রটি তার, আপনার কোড শুধু তার ফাঁকা জায়গায় বসা।

এবার ধারণাটি চালিয়ে দেখুন। নিচে একটি খুব ছোট “framework” হাতে লেখা হয়েছে। আসল Express-এর এটি কেবল ছায়া, কিন্তু নিয়ন্ত্রণের দিকটি একই।

// Library: আমি ডাকি, কাজ শেষে নিয়ন্ত্রণ ফেরে
const lib = { taka: n => '৳' + n.toLocaleString('en-IN') };
console.log('--- library ---');
console.log('আমি ডাকলাম:', lib.taka(1250));

// খুব ছোট একটি framework: সে আমার কোড ডাকে
function miniFramework() {
  const routes = {};
  return {
    get(path, handler) { routes[path] = handler; },
    handle(path) {
      console.log('framework: অনুরোধ এল', path);
      const handler = routes[path];
      if (!handler) { console.log('framework: 404'); return; }
      console.log('framework: উত্তর ->', handler({ path }));
    },
  };
}

const app = miniFramework();
app.get('/products', () => {
  console.log('আমার handler চলল');
  return '3 products';
});

console.log('--- framework ---');
app.handle('/products');
app.handle('/about');

আউটপুটে আমার handler চলল ছাপা হয় --- framework ----এর পরে, যদিও handler লেখা হয়েছে তার আগে। লেখার সময় সেটি শুধু জমা পড়েছিল। ডেকেছে handle. শেষ লাইনে framework: 404 এসেছে আমাদের কোনো সিদ্ধান্ত ছাড়াই, কারণ না পাওয়া path সামলানোও framework-এর চক্রের অংশ।

React কোনটি? React নিজেকে library বলে, কারণ routing বা data আনার মতো অনেক কিছু তার নিজের নেই। তবু component আপনি নিজে ডাকেন না, React ডাকে। সরু অর্থে সেখানে inversion of control আছে। Next.js পুরোদস্তুর framework: ফাইল কোথায় রাখলে কী হবে, সেটিও সে ঠিক করে। বিতর্কটি ভাবনার প্রশ্ন ২-এ আছে।

৪ · Framework কেন জন্মাল

প্রতিটি ওয়েব অ্যাপ প্রায় একই পাঁচটি সমস্যায় পড়ে। সবাই নিজে নিজে সমাধান লিখলে একই ভুল হাজারবার হয়। Framework হলো সেই বারবার করা কাজের জমা অভিজ্ঞতা।

সমস্যা	Framework ছাড়া	Framework দিলে	কোর্সে
Routing	URL ভেঙে লম্বা `if`-এর সারি	URL আর handler-এর পরিষ্কার তালিকা	পর্ব ২০, ২৫, ৫১
State	তথ্য বদলালে স্ক্রিন হাতে মেলানো	তথ্য বদলান, স্ক্রিন নিজে মেলে	পর্ব ১০, ১৬
Validation	প্রতিটি ফর্মে আলাদা যাচাই	এক schema, দুই দিকে ব্যবহার	পর্ব ২১, ২৭
নিরাপত্তার ডিফল্ট	প্রতিবার মনে রাখতে হয়	নিরাপদ পথটিই সহজ পথ	পর্ব ৫০
Convention	প্রতিটি প্রজেক্টের গঠন আলাদা	নতুন সদস্য দ্রুত ধরতে পারেন	পর্ব ৫, ২৯

নিরাপত্তার ডিফল্ট কথাটি কয়েকটি উদাহরণে পরিষ্কার হবে। React, JSX-এর ভেতরের লেখাকে escape করে দেখায়, ফলে সাধারণ লেখায় ঢোকানো script চলে না। Prisma-র সাধারণ query-তে মান parameter হিসেবে যায়। Django আর Laravel-এর নতুন প্রজেক্টে CSRF সুরক্ষা শুরু থেকেই থাকে। তবে ডিফল্ট মানে জাদু নয়। dangerouslySetInnerHTML বা Prisma-র unsafe raw query ব্যবহার করলে সেই সুরক্ষা আপনি নিজেই সরিয়ে দিচ্ছেন। Express-ও অনেক কিছু নিজে করে না, সেগুলো আপনাকে জুড়তে হয়। তত্ত্ব আছে XSS আর CSP পর্বে।

সংক্ষিপ্ত ইতিহাস: ২০০৪ সালে Ruby on Rails convention-এর ধারণাটি জনপ্রিয় করে। ২০০৫ সালে Django প্রকাশ পায়। ২০০৬ সালে jQuery ব্রাউজারের পার্থক্য ঢেকে দেয়। ২০০৯ সালে Node.js JavaScript-কে server-এ আনে। ২০১৩ সালে Facebook React প্রকাশ্যে আনে, আর ২০১৬ সালে Vercel (তখনকার নাম ZEIT) Next.js প্রকাশ করে। প্রতিটি ধাপে আগের দিনের কোনো একটি বিরক্তিকর কাজ যন্ত্রের হাতে গেছে।

৫ · একই কার্ট দুইভাবে — plain JavaScript আর React

কথার চেয়ে কোড ভালো বোঝায়। বাজারঘরের একটি ছোট কার্ট: যোগ করার বাটন, খালি করার বাটন, সংখ্যা, মোট দাম আর একটি বার্তা। প্রথমে framework ছাড়া, সরাসরি DOM বদলে। Run চেপে বাটনগুলো চাপুন, কোডও বদলে দেখতে পারেন।

<button id="add">মসুর ডাল যোগ করুন</button>
<button id="clear">খালি করুন</button>
<p>কার্টে: <b id="count">0</b>টি</p>
<p>মোট: <b id="total">৳0</b></p>
<p id="msg">কার্ট খালি</p>
<script>
const PRICE = 120;
let qty = 0;
const countEl = document.getElementById('count');
const totalEl = document.getElementById('total');
const msgEl = document.getElementById('msg');

document.getElementById('add').onclick = () => {
  qty += 1;
  countEl.textContent = qty;
  totalEl.textContent = '৳' + qty * PRICE;
  msgEl.textContent = 'কার্টে পণ্য আছে';
  console.log('হাতে ৩টি জায়গা বদলালাম, qty =', qty);
};

document.getElementById('clear').onclick = () => {
  qty = 0;
  countEl.textContent = 0;
  totalEl.textContent = '৳0';
  msgEl.textContent = 'কার্ট খালি';
  console.log('হাতে ৩টি জায়গা বদলালাম, qty =', qty);
};
console.log('পাতা প্রস্তুত, qty =', qty);
</script>

Run করলেই নিচে দেখবেন পাতা প্রস্তুত, qty = 0. একবার “যোগ করুন” চাপলে যোগ হবে হাতে ৩টি জায়গা বদলালাম, qty = 1. একটি পরীক্ষা করুন: totalEl.textContent-এর লাইনটি যোগের handler থেকে মুছে আবার চালান। সংখ্যা বাড়বে, কিন্তু মোট ৳0-তেই আটকে থাকবে। কোনো error আসবে না। একে বলে স্ক্রিন আর তথ্যের অমিল। এই অমিলই framework জন্মের প্রধান কারণগুলোর একটি।

এবার একই কার্ট React-এ। এটি আসল React 19, এই পাতার ভেতরেই চলছে।

<div id="root"></div>
<script src="../course-kit/vendor/react-lab.js"></script>
<script type="text/jsx">
const PRICE = 120;

function Cart() {
  const [qty, setQty] = useState(0);
  console.log('render, qty =', qty);
  return (
    <div>
      <button onClick={() => setQty(qty + 1)}>মসুর ডাল যোগ করুন</button>
      <button onClick={() => setQty(0)}>খালি করুন</button>
      <p>কার্টে: <b>{qty}</b>টি</p>
      <p>মোট: <b>৳{qty * PRICE}</b></p>
      <p>{qty > 0 ? 'কার্টে পণ্য আছে' : 'কার্ট খালি'}</p>
    </div>
  );
}

createRoot(document.getElementById('root')).render(<Cart />);
</script>

Run করলে আসে render, qty = 0. প্রতিটি ক্লিকে Cart component ফাংশনটি আবার চলে, নতুন লাইন আসে render, qty = 1. এখানে কোথাও “মোট বদলাও” লেখা নেই। আপনি শুধু বলেছেন স্ক্রিন তথ্য থেকে কেমন দেখাবে। তাই মোট আর সংখ্যার অমিল হওয়ার কোনো লাইনই নেই। useState একটি hook; এসব পর্ব ০৭ থেকে ধাপে ধাপে শিখবেন।

প্রথম ধরনকে বলে imperative: “কীভাবে করতে হবে” প্রতিটি ধাপ বলা। দ্বিতীয়টি declarative: “কী দেখতে চাই” বলা। রিকশাওয়ালাকে প্রতিটি মোড়ে বাঁয়ে-ডানে বলা এক জিনিস, শুধু গন্তব্য বলা আরেক জিনিস। একটি ক্লিকে ভেতরে কী হয়, ধাপে ধাপে দেখুন।

1// Plain DOM: আপনি মেলান2qty += 1;3countEl.textContent = qty;4totalEl.textContent = '৳' + qty * 120;56// React: React মেলায়7setQty(qty + 1);8Cart() আবার চলে, নতুন JSX9আগের সাথে তুলনা (diff)10বদলানো অংশটুকু DOM-এ বসে

তথ্য আর স্ক্রিন

qty (তথ্য)
স্ক্রিনে সংখ্যা
স্ক্রিনে মোট
মিলছে?

Plain: তথ্য বদলাল। qty ০ থেকে ১ হলো। কিন্তু স্ক্রিন এখনো ০ আর ৳০ দেখাচ্ছে। JavaScript-এর একটি ভ্যারিয়েবল বদলালে DOM নিজে থেকে কিছুই জানে না।
Plain: প্রথম জায়গা। আপনি হাতে সংখ্যা বসালেন, স্ক্রিনে ১। মোট এখনো ৳০। এই মুহূর্তে স্ক্রিন নিজের সাথেই অমিল।
Plain: দ্বিতীয় জায়গা। মোট ৳১২০ হলো। এবার মিলেছে, কিন্তু শুধু এই কারণে যে আপনি কোনো লাইন ভোলেননি। তৃতীয়, চতুর্থ জায়গা এলে দায়িত্বও বাড়বে।
React: state বদলের অনুরোধ। এবার পরের ক্লিক, শুরুর মান qty ১, স্ক্রিন ১ আর ৳১২০। setQty(2) DOM ছোঁয় না, শুধু React-কে জানায় যে নতুন মান ২ চাই।
React: render. React আবার Cart ডাকে, এবার qty ২। ফাংশনটি নতুন বর্ণনা ফেরত দেয়: সংখ্যা ২, মোট ৳২৪০। স্ক্রিন এখনো আগের মতো। Render মানে হিসাব করা, স্ক্রিন বদলানো নয়।
React: তুলনা। React আগের আর নতুন বর্ণনা মিলিয়ে দেখে শুধু দুটি লেখা বদলেছে, বাটনগুলো একই আছে। এই তুলনার ভেতরের কাজ আছে পর্ব ১৫-এ।
React: commit. React শুধু সেই দুটি লেখা DOM-এ বদলায়, স্ক্রিনে ২ আর ৳২৪০। আপনি “কোন জায়গা বদলাবে” তা একবারও লেখেননি। ফর্মের ঘরে লেখা বা focus-ও নষ্ট হয় না।

State বাড়লে হিসাব কেমন বদলায়

দুই-তিনটি জায়গায় plain কোড চমৎকার। সমস্যা শুরু হয় বাড়লে। একটি সরল মডেল ধরা যাক। E = ব্যবহারকারীর কাজের সংখ্যা, T = প্রতিটি কাজে গড়ে কতগুলো জায়গা বদলায়, V = স্ক্রিনে মোট কতগুলো জায়গায় তথ্য দেখানো হয়। তাহলে হাতে লেখা DOM বদলের লাইন ≈ E × T. Declarative ধরনে প্রতিটি জায়গা একবার বর্ণনা করলেই হয়, তাই লাইন ≈ V + E. সংখ্যাগুলো উদাহরণের জন্য ধরে নেওয়া, মাপা নয়।

// সরল অনুমান-মডেল: সংখ্যাগুলো ধরে নেওয়া, মাপা নয়
// E = কাজের সংখ্যা, T = প্রতি কাজে বদলানো জায়গা, V = স্ক্রিনের জায়গা
const stages = [
  ['small cart',       2, 3,  3],
  ['+ coupon',         4, 4,  5],
  ['+ stock, login',   8, 5,  9],
  ['full checkout',   16, 6, 14],
];

console.log('stage'.padEnd(17), 'E'.padStart(3), 'T'.padStart(3),
  'V'.padStart(3), 'manual'.padStart(7), 'declar.'.padStart(8), 'ratio'.padStart(6));

for (const [name, E, T, V] of stages) {
  const manual = E * T;       // প্রতিটি কাজে সব জায়গা হাতে বদলানো
  const declared = V + E;     // প্রতিটি জায়গা একবার + প্রতিটি কাজে state বদল
  console.log(name.padEnd(17), String(E).padStart(3), String(T).padStart(3),
    String(V).padStart(3), String(manual).padStart(7),
    String(declared).padStart(8), (manual / declared).toFixed(1).padStart(6));
}

শেষ সারি হাতে মেলান: ১৬ × ৬ = ৯৬ লাইন, বনাম ১৪ + ১৬ = ৩০। অনুপাত ৯৬ ÷ ৩০ = ৩.২. প্রথম সারিতে পার্থক্য প্রায় নেই (৬ বনাম ৫, অনুপাত ১.২)। মূল কথা শেষ সংখ্যাটি নয়, বৃদ্ধির ধরন। E × T হলো গুণ, V + E হলো যোগ। অ্যাপ বড় হলে গুণ অনেক দ্রুত বাড়ে, আর প্রতিটি হাতে লেখা লাইন ভুলে যাওয়ার একটি সুযোগ।

সৎ পাল্টা যুক্তি: plain JavaScript-এও একটি render() ফাংশন লিখে সব কিছু একবারে নতুন করে আঁকা যায়, তখন E × T সমস্যা কমে। কিন্তু innerHTML দিয়ে সব বদলালে input-এর focus হারায়, আর অসাবধান হলে XSS-এর পথ খোলে। ওই সমস্যা সমাধান করতে করতে যা দাঁড়ায়, তা অনেকটা একটি ছোট framework. JavaScript কোর্সের framework পর্বে আরও তুলনা আছে।

৬ · Framework-এর দাম

বিনা মূল্যে কিছুই আসে না। Framework চারভাবে দাম নেয়।

Churn

Churn মানে সবসময় বদল। নতুন version, নতুন নিয়ম, পুরোনো টুল বন্ধ। যা শিখলেন তার একটি অংশ কয়েক বছরে পুরোনো হয়।

Abstraction

Abstraction জটিলতা ঢেকে রাখে, মুছে দেয় না। সব ঠিক থাকলে আরাম, কিন্তু গোলমাল হলে নিচের স্তর না জানলে আটকে যাবেন।

Lock-in

Lock-in মানে সরে যাওয়া কঠিন হওয়া। কোড যত framework-এর নিজস্ব ধাঁচে লেখা, অন্য জায়গায় নিতে খরচ তত বেশি।

Bundle size

Bundle হলো browser-এ পাঠানো JavaScript. Framework-এর কোডও ব্যবহারকারীকে নামাতে হয়, আর ফোনকে চালাতে হয়।

শেষেরটি সরাসরি মাপা যায়। ওপরের ধরনের একটি কার্ট (একটি বাটন, সংখ্যা আর মোট) দুইভাবে আলাদা প্রজেক্টে লিখে Vite দিয়ে production build করা হয়েছিল। নিচে সত্যিকারের run (Vite 8.3.5, React 19.3.1). এটি একটি যন্ত্রে একবারের মাপ, সাধারণ ফল নয়।

~/bazarghar/cart-plain$ npm run build
vite v8.3.5 building client environment for production...
✓ 4 modules transformed.
dist/index.html                0.34 kB │ gzip: 0.26 kB
dist/assets/index-sP9Onq3K.js  0.86 kB │ gzip: 0.48 kB

~/bazarghar/cart-react$ npm run build
vite v8.3.5 building client environment for production...
✓ 14 modules transformed.
dist/index.html                  0.22 kB │ gzip:  0.18 kB
dist/assets/index-D68WZMMB.js  219.83 kB │ gzip: 68.77 kB

দুই প্রজেক্টে নিজের লেখা লাইন প্রায় সমান (২২ আর ২৫), কিন্তু gzip করা JavaScript 0.48 kB বনাম 68.77 kB, প্রায় ১৪৩ গুণ। এবার সময়ের হিসাব। ধরে নিন সংযোগের গতি 1 Mbps, মানে প্রতি সেকেন্ডে 1,000 kilobit. 1 kB = 8 kilobit.

React bundle: 68.77 × 8 = 550.16 kilobit → 550.16 ÷ 1,000 ≈ 0.55 সেকেন্ড
Plain: 0.48 × 8 = 3.84 kilobit → ≈ 0.004 সেকেন্ড

5 Mbps-এ React bundle নামাতে লাগবে প্রায় 0.11 সেকেন্ড। এটি শুধু নামানোর হিসাব; latency, unzip আর চালানোর সময় আলাদা। তাহলে কি React খারাপ? না। এই খরচের বড় অংশ একবারের। অ্যাপ বড় হলে এটি আর গুণ আকারে বাড়ে না, আর plain কোডের লাইনও তখন জমতে থাকে। কিন্তু একটি চায়ের দোকানের এক পাতার সাইটে এই খরচের বিনিময়ে কিছুই মেলে না। কমানোর উপায়ও আছে: code splitting (পর্ব ২৩, ৭৯) আর Server Component (পর্ব ৫২)।

Framework বেছে নেওয়া মানে একটি dependency নয়, শত শত dependency নেওয়া। সেগুলোর কোনোটিতে নিরাপত্তা-ত্রুটি বেরোলে সেটি আপনার সমস্যা। তাই লাভের পাশে এই ঝুঁকিও লিখে রাখুন, আর আপডেট নিয়মিত করুন (পর্ব ৫০)।

আরও গভীরে: Joel Spolsky ২০০২ সালে এই অভিজ্ঞতাকে নাম দেন “Law of Leaky Abstractions”: যেকোনো অ-তুচ্ছ abstraction কোথাও না কোথাও ফুটো হয়। Framework-এর ক্ষেত্রেও তাই। Hydration mismatch বা ORM-এর N+1 query হলো সেই ফুটো, যেখানে নিচের স্তর ওপরে উঠে আসে (পর্ব ৪২, ৫৬)। এজন্য এই কোর্সে প্রতিটি টুলের নিচে কী চলছে, তাও দেখানো হবে। React-এর মতো declarative UI-র মূল সূত্র প্রায়ই লেখা হয় UI = f(state).

৭ · এই কোর্সের stack আর “বাজারঘর”

সব কিছু একসাথে শেখা যায় না, তাই একটি মূল পথ বেছে নেওয়া হয়েছে। বাছাইয়ের কারণ তিনটি: এক ভাষায় (TypeScript) দুই দিক লেখা যায়, শেখার উপকরণ অনেক, আর ধারণাগুলো অন্য stack-এও কাজে লাগে। এটি “সেরা stack” দাবি নয়। অনেক ভালো দল Django বা Laravel দিয়ে চমৎকার পণ্য বানান।

টুল	কাজ	কেন	লেখার সময়ে
TypeScript	JavaScript-এ type	ভুল চালানোর আগেই ধরা পড়ে; frontend-backend-এর ভাগ করা type	7.0.2
React	UI library	Component-এ ভাবতে শেখায়, চর্চা ও কাজ দুটোই বেশি	19.3.1
Next.js	React-এর ফুল-স্ট্যাক framework	Routing, server rendering, SEO এক জায়গায়	16.4.3
Node.js	Server-এ JavaScript চালানো	Frontend-এর ভাষাই backend-এ	LTS version
Express	ছোট backend framework	ন্যূনতম, তাই ভেতরের কাজ চোখে পড়ে	5.3.0
Prisma	ORM	Schema থেকে type-সহ query আর migration	7.10.1
PostgreSQL বা SQLite	Database	SQLite শেখা ও পরীক্ষায় সহজ; PostgreSQL production-এ শক্তপোক্ত	—

Version-গুলো npm view দিয়ে দেখা (সত্যিকারের run, নভেম্বর ২০২৬)। Prisma-র latest ট্যাগে তখন একটি release candidate (8.0.0-rc.29) ছিল, তাই সর্বশেষ স্থিতিশীল version লেখা হয়েছে। আপনি পড়ার সময় সংখ্যা বদলে যেতে পারে; নিজে দেখে নিন:

npm view react version
npm view next version
npm view prisma dist-tags

মূল পথের বাইরেও চোখ খোলা থাকবে। মডিউল ১০-এ দেখবেন Vue, Nuxt, Angular, Svelte, Django, FastAPI, Laravel, Spring Boot আর Rails-এ একই ধারণা কেমন দেখায়। পর্ব ৮৫-এ থাকবে stack বাছাইয়ের ছক।

বাজারঘর একটি কাল্পনিক অনলাইন দোকান, পাড়ার মুদি দোকান অনলাইনে এলে যেমন হয়। পণ্যের তালিকা, খোঁজা, কার্ট, login, অর্ডার, stock, পেমেন্টের প্রবাহ, অ্যাডমিন প্যানেল। এক একটি মডিউলে দোকানের এক একটি অংশ তৈরি হবে, আর পর্ব ৮৮-এর ক্যাপস্টোনে সব জোড়া লাগবে। আলাদা আলাদা খেলনা উদাহরণের বদলে একটি বাড়ন্ত পণ্য নিলে বোঝা যায় সিদ্ধান্তগুলো পরে কী ফল দেয়।

৮ · ১৪ মডিউলের মানচিত্র আর পূর্বশর্ত

মডিউল	বিষয়	পর্ব	বাজারঘরে যা আসে
১	ফুল-স্ট্যাকের মানচিত্র	০১–০৬	ধারণা, টুল, প্রজেক্টের কঙ্কাল
২	React-এর ভিত্তি	০৭–১৫	পণ্যের কার্ড, তালিকা, কার্টের UI
৩	বড় React অ্যাপ	১৬–২৩	পাতা বদল, global কার্ট, server থেকে ডেটা
৪	Node.js আর Express backend	২৪–৩১	পণ্য আর অর্ডারের API
৫	API নকশা	৩২–৩৭	Pagination, error format, API-র চুক্তি
৬	ডেটাবেস আর ORM	৩৮–৪৪	আসল ডেটা মডেল, stock, cache
৭	Authentication আর নিরাপত্তা	৪৫–৫০	Login, role, নিরাপত্তা তালিকা
৮	Next.js	৫১–৫৯	SEO-বান্ধব দোকান, বাংলা সাইট
৯	Real-time আর background কাজ	৬০–৬৫	অর্ডারের খবর, email, ছবি, পেমেন্ট
১০	অন্য framework	৬৬–৭১	একই ধারণা অন্য ভাষায়
১১	Testing	৭২–৭৭	Unit, API আর end-to-end test
১২	Production-এ পাঠানো	৭৮–৮৪	Docker, CI/CD, hosting, monitoring
১৩	Stack বাছাই আর ক্যাপস্টোন	৮৫–৮৮	পূর্ণ অনলাইন বাজার
১৪	পরীক্ষা ও ইন্টারভিউ প্রস্তুতি	৮৯–৯৩	Numerical, MCQ, ভাইভা, ইন্টারভিউ

শুরুর আগে যা জানা দরকার

এই কোর্স ভাষা শেখায় না, ভাষা ধরে নিয়ে এগোয়। নিচের কোর্সগুলো পুরো শেষ করতে হবে না। লেখা অংশগুলো জানা থাকলেই চলবে।

HTML & CSS: semantic ট্যাগ, form, flexbox, grid.
JavaScript: function, array method, object, DOM, Promise, async/await, module.
DBMS & SQL: table, primary key, join-এর মৌলিক ধারণা। মডিউল ৬-এর আগে হলেও চলবে।

নির্ভরতার ক্রম মোটামুটি মেনে চলুন: মডিউল ১ → ২ → ৩ আর ৪ → ৫ → ৬ → ৭। আপনি অভিজ্ঞ হলে সরাসরি মডিউল ৮ বা ১২-তে যেতে পারেন, বাজারঘরের সিদ্ধান্তগুলো সেখানে সংক্ষেপে মনে করিয়ে দেওয়া হবে। বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষার জন্য মডিউল ১৪ শেষে পড়ুন, তখন প্রশ্নগুলো মুখস্থ নয়, চেনা লাগবে।

৯ · আপনার লক্ষ্য — স্তর আর পেশার পথ

আপনার স্তর	কোর্সে কী লক্ষ্য রাখবেন	নিজেকে যাচাই
শুরু করছেন	মডিউল ১–৪ ধীরে; প্রতিটি কোড নিজে চালানো	একটি ছোট CRUD অ্যাপ বানিয়ে প্রতিটি লাইন ব্যাখ্যা করতে পারেন
মাঝারি	মডিউল ৫–৯, ১১; নকশার সিদ্ধান্ত, test, নিরাপত্তা	Login, payment-এর প্রবাহ আর test-সহ অ্যাপ deploy করতে পারেন
অভিজ্ঞ	“আরও গভীরে” বাক্স, পর্ব ১৫, ৫৬, ৮৭; trade-off আর ভেতরের কাজ	Stack-এর সিদ্ধান্ত যুক্তি দিয়ে লিখে দলকে বোঝাতে পারেন

কোন পথে কাজ করা যায়

Frontend ডেভেলপার

UI, accessibility, performance. মডিউল ২, ৩, ৮ আর পর্ব ৮৪ বেশি কাজে লাগবে।

Backend ডেভেলপার

API, database, নিরাপত্তা, background কাজ। মডিউল ৪–৭ আর ৯ আপনার মূল জায়গা।

ফুল-স্ট্যাক ডেভেলপার

ছোট দল বা স্টার্টআপে এক ফিচার পুরো নিজে সামলান। পুরো কোর্স, এক দিকে গভীরতা।

Freelance

পুরো পণ্য একা দিতে হয়, ক্লায়েন্টের সাথে কথাও বলতে হয়। মডিউল ১২-এর deployment আর পর্ব ৮৫-র stack বাছাই বিশেষ জরুরি।

কোন পথে কত উপার্জন, এই কোর্স তার কোনো দাবি করে না, কারণ তা অভিজ্ঞতা, জায়গা আর বাজারের ওপর নির্ভর করে। যা নিশ্চিতভাবে বলা যায়: চালু থাকা একটি নিজের প্রজেক্ট, যার প্রতিটি সিদ্ধান্ত আপনি ব্যাখ্যা করতে পারেন, যেকোনো পথেই শক্ত প্রমাণ।

পরীক্ষা ও ইন্টারভিউতে:

Library আর framework-এর পার্থক্য? Library-কে আপনার কোড ডাকে; framework আপনার কোড ডাকে (inversion of control).
Frontend-এ যাচাই থাকলে backend-এ কেন? Browser ব্যবহারকারীর হাতে, তাই অনুরোধ জাল করা যায়। আসল যাচাই server-এ।
Declarative UI মানে? ধাপ নয়, state অনুযায়ী ফল বর্ণনা করা; DOM বদল framework করে।
Framework-এর অসুবিধা? Churn, abstraction-এর ফুটো, lock-in, bundle size, dependency-র ঝুঁকি।
T-shaped developer? বিস্তৃত সাধারণ জ্ঞান আর একটি বিষয়ে গভীর দক্ষতা।

১০ · AI-এর যুগে কীভাবে শিখবেন

AI এখন কয়েক মিনিটে একটি কাজ করা অ্যাপের কঙ্কাল লিখে দেয়। তাহলে এত শেখা কেন? কারণ “চলছে” আর “ঠিক আছে” এক কথা নয়। কার্টের দাম browser থেকে নিলে কোড দিব্যি চলবে, আর যে কেউ ৳১ দিয়ে কিনতে পারবে। এই ভুল দেখতে হলে ধাপ ৪-এর যুক্তি জানতে হয়।

AI-এর সাধারণ ভুল	যেভাবে ধরবেন
পুরোনো API: Next.js-এর পুরোনো pages router, বাতিল React ধরন, Create React App	আপনার version-এর অফিসিয়াল docs মেলানো
নেই এমন package বা option বানানো	`npm view <নাম>` দিয়ে দেখা, docs-এ খোঁজা
কোড চলে, কিন্তু secret ফাঁস বা authorization নেই	Diff পড়া: “এই route কে ডাকতে পারে?”
অপ্রয়োজনীয় dependency যোগ	`package.json`-এর বদল আলাদা করে দেখা
`try/catch` দিয়ে error চাপা দেওয়া	ভুল ইনপুট দিয়ে চালিয়ে দেখা, test লেখা

শেখার একটি কার্যকর নিয়ম: AI-কে উত্তর লেখার আগে শিক্ষক বানান। প্রথমে নিজে চেষ্টা করুন, তারপর AI-কে দিয়ে নিজের কোড সমালোচনা করান। নিচের প্রম্পটটি কাজে লাগবে।

এই প্রম্পটে version বলা আছে, উত্তর সরাসরি চাওয়া হয়নি, আর যাচাইয়ের দাবিও আছে। তিনটিই গুরুত্বপূর্ণ।

আমি React 19 আর Express 5 শিখছি। নিচে আমার লেখা "কার্টে যোগ করুন" ফিচারের কোড দিলাম। [এখানে কোড পেস্ট করুন, কোনো secret বা .env-এর মান ছাড়া] ১. পুরো কোড নতুন করে লিখো না। ২. কোন নিয়মটি frontend-এ আছে কিন্তু backend-এ থাকা উচিত, বলো। ৩. কোন লাইনে authorization বা input যাচাই বাদ পড়েছে, দেখাও। ৪. যে API ব্যবহার করতে বলছ, তা এই version-এ আছে কি না অফিসিয়াল docs-এর কোন পাতায় মিলিয়ে দেখব, বলো। নিশ্চিত না হলে সেটি বলো।

AI-এর লেখা ওয়েব কোড হাতে পেলে

নিজের version মিলিয়ে অফিসিয়াল docs দেখেছি
নিজে চালিয়েছি, ভুল ইনপুটেও চালিয়েছি
পুরো diff পড়েছি, প্রতিটি নতুন dependency-র কারণ জানি
দেখেছি কোন যাচাই server-এ হচ্ছে, কে কার তথ্য দেখতে পারে
অন্তত একটি test লিখেছি বা হাতে পরীক্ষার ধাপ লিখে রেখেছি
AI-কে কোনো আসল password, API key বা ক্রেতার তথ্য দিইনি

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিয়ে নিজে কিছুক্ষণ ভাবুন, তারপর “→ উত্তর” চাপুন।

প্র ০১jQuery দিয়েই তো ওয়েব চলছিল। তাহলে React-এর মতো declarative UI-র দরকার পড়ল কেন?

২০০৬ সালে John Resig-এর jQuery যে সমস্যা সমাধান করেছিল, তা ছিল ব্রাউজারের পার্থক্য। এক লাইনে element খোঁজা, event জোড়া, animation করা গেল সব ব্রাউজারে। পরে ব্রাউজার নিজেই querySelector আর fetch-এর মতো সুবিধা দিল, ফলে jQuery-র মূল প্রয়োজন অনেকটা কমে গেল।

কিন্তু একটি সমস্যা jQuery সমাধান করেনি, আর সেটি ছিল তার কাজের বাইরেই: তথ্য বদলালে স্ক্রিনের কোন কোন জায়গা বদলাবে, তার হিসাব রাখা। অ্যাপ যত বড় হলো, পাতা তত দীর্ঘ সময় খোলা থাকল, আর একই তথ্য তত বেশি জায়গায় দেখা গেল। Facebook-এর প্রকৌশলীরা ২০১৪ সালের একটি আলোচনায় বলেছিলেন, না-পড়া বার্তার সংখ্যা ভুল দেখানোর একটি bug বারবার ফিরে আসত। একবার ঠিক করলে অন্য পথে আবার দেখা দিত, কারণ একই তথ্য একাধিক জায়গায় আলাদাভাবে মেলানো হচ্ছিল।

২০১৩ সালে প্রকাশ্যে আসা React একটি সাহসী কথা বলল: প্রতিবার পুরো UI নতুন করে বর্ণনা করুন, কী বদলাল তা আমি হিসাব করব। শুরুতে অনেকেই এটিকে ধীর আর অদ্ভুত ভেবেছিলেন, JSX দেখেও আপত্তি উঠেছিল। কিন্তু এই ভাবনায় পুরো এক শ্রেণির bug প্রায় অসম্ভব হয়ে গেল, কারণ দুই জায়গায় আলাদা করে মেলানোর লাইনটিই আর নেই।

তার মানে এই নয় যে সব সাইটে React দরকার। যে পাতায় বদল সামান্য, সেখানে plain JavaScript এখনো ভালো উত্তর। আজকের browser আগের চেয়ে অনেক বেশি কিছু নিজেই পারে, তাই ছোট কাজের জন্য বাইরের কোড না আনাই প্রায়ই বুদ্ধিমানের কাজ।

মূল উপলব্ধি: একটি টুলের ইতিহাস মানে সে কোন যন্ত্রণা দূর করতে এসেছিল তার ইতিহাস। যন্ত্রণাটি আপনার প্রজেক্টে না থাকলে, সেই টুলের দামও আপনার দেওয়ার দরকার নেই।

প্র ০২“Inversion of control” কথাটি কোথা থেকে এলো, আর React কি library না framework?

ধারণাটি ওয়েবের চেয়ে পুরোনো। Martin Fowler তাঁর লেখায় দেখান, “inversion of control” শব্দটি পাওয়া যায় Ralph Johnson আর Brian Foote-এর ১৯৮৮ সালের প্রবন্ধ “Designing Reusable Classes”-এ। “Hollywood principle” নামটিও ১৯৮০-এর দশকের, Richard Sweet-এর Mesa পরিবেশ নিয়ে লেখায়। মূল কথাটি GUI প্রোগ্রাম থেকে এসেছে। আগের প্রোগ্রাম ব্যবহারকারীকে প্রশ্ন করে উত্তরের অপেক্ষা করত। GUI-তে উল্টো: event loop ঘোরে, আপনি শুধু বলে রাখেন বাটন চাপলে কোন ফাংশন চলবে। Fowler-এর ভাষায়, এই ডাকার দিকটাই framework-কে library থেকে আলাদা করে।

এই পরীক্ষায় React-কে ফেললে উত্তর ঝাপসা। আপনি <Cart /> লেখেন, কিন্তু Cart() ডাকে React, কখন ডাকবে তাও সে ঠিক করে। এই অর্থে সে framework-এর মতো। আবার React routing, data আনা বা build-এর পথ নিজে ঠিক করে দেয় না, আর আপনি একটি পাতার ছোট অংশেও তাকে বসাতে পারেন। এই অর্থে সে library, এবং React দল নিজেরাও তাকে library বলেন।

মজার ব্যাপার, ২০২৫ সালের ফেব্রুয়ারিতে React দল Create React App নতুন অ্যাপের জন্য deprecate করার সময় Next.js বা React Router-এর মতো framework ব্যবহারের পরামর্শ দেন। অর্থাৎ দলটি মনে করে, আসল অ্যাপের routing, data আর code splitting-এর সিদ্ধান্ত কোনো না কোনো framework-এ থাকাই ভালো। অনেকে আবার Vite আর নিজের বাছাই করা library-তে বেশি স্বস্তি পান। তাঁরা বলেন, নিজের বাছাই করা টুলে বাড়তি জাদু কম থাকে, আর ভেতরের কাজ বোঝা সহজ হয়। দুই পক্ষেই যুক্তি আছে, আর উত্তর নির্ভর করে দলের অভিজ্ঞতা ও অ্যাপের প্রয়োজনের ওপর।

মূল উপলব্ধি: শব্দের লড়াইয়ের চেয়ে প্রশ্নটি জরুরি: এই টুলে আপনার কোডের চক্র কে চালায়, আর কোন সিদ্ধান্তগুলো আর আপনার হাতে নেই? সেই উত্তরই বলে দেয় সরে যেতে কত খরচ হবে।

প্র ০৩Framework এত দ্রুত বদলায়। আজ শেখা জিনিস কি কয়েক বছর পরে অকেজো হবে?

ভয়টি অমূলক নয়। AngularJS ২০১০ সালে আসে, আর ২০১৬ সালের Angular 2 ছিল প্রায় নতুন করে লেখা framework, পুরোনো কোড সরাসরি চলত না। AngularJS-এর দীর্ঘমেয়াদি সমর্থন শেষ হয় ২০২১ সালের ৩১ ডিসেম্বর। বহু দলকে তখন বড় কোডবেস নতুন করে লিখতে হয়েছে বা ঝুঁকি নিয়ে থাকতে হয়েছে। React-এর জগতে Create React App একসময় ডিফল্ট শুরুর পথ ছিল; ২০২৫ সালের ফেব্রুয়ারিতে সেটি নতুন অ্যাপের জন্য deprecate হয়, কারণ দলের ভাষায় তার সক্রিয় maintainer ছিল না। Next.js-এ ২০২৩ সালে App Router স্থিতিশীল ঘোষণার পর শেখার অনেক উপকরণ এক ধাক্কায় পুরোনো হয়ে গেছে।

উল্টো উদাহরণও আছে। Express 5 এসেছে ২০২৪ সালে, আগের প্রধান version-এর প্রায় এক দশক পরে। SQL কয়েক দশক ধরে টিকে আছে, HTTP-র মূল ধারণাও।

একটি কাজের ছবি হলো স্তরের গতি। ওপরের স্তর (framework-এর API, build tool) দ্রুত বদলায়। মাঝের স্তর (component, state, routing, cache, transaction-এর ধারণা) ধীরে বদলায়। নিচের স্তর (HTTP, SQL, DOM, JavaScript) খুব ধীরে বদলায়, আর বদলালেও সাধারণত পুরোনোটা ভাঙে না। শেখার সময় তাই ওপরের স্তরের নাম মুখস্থ না করে নিচের দুই স্তরে বিনিয়োগ করা ভালো।

পেশাদার অভ্যাসও সাহায্য করে: version লিখে রাখা, ছোট ছোট আপডেট নিয়মিত করা, test রাখা, ব্যবসার নিয়ম framework-এর ভেতরে না মেশানো (পর্ব ২৯)। এতে বড় বদল এলেও পুরো অ্যাপ নতুন করে লিখতে হয় না, ধীরে ধীরে এক একটি অংশ সরানো যায়।

মূল উপলব্ধি: ধারণা স্থানান্তরযোগ্য, syntax নয়। React থেকে Vue-তে গেলে আপনার syntax অনেকটা নতুন হবে, কিন্তু “state বদলালে UI” চিন্তাটি সাথেই যাবে। এজন্য এই কোর্স বারবার জিজ্ঞেস করে, ভেতরে কী ঘটছে।

প্র ০৪Framework নিরাপত্তা বাড়ায়, আবার সবার ঝুঁকি এক জায়গায় জমা করে। এই দুটি কথা একসাথে সত্য কীভাবে?

প্রথম কথাটি সত্য, কারণ নিরাপত্তার বেশিরভাগ ভুল মনোযোগের অভাবে হয়। প্রতিটি লেখা escape করতে, প্রতিটি query-তে parameter বসাতে মনে রাখতে হলে একদিন ভুল হবেই। Framework সেই সিদ্ধান্তটি একবারে নিয়ে নিলে হাজারো অ্যাপ একই সাথে নিরাপদ হয়। হাজার চোখের সামনে থাকা কোডের ভুলও তুলনামূলকভাবে তাড়াতাড়ি ধরা পড়ে।

দ্বিতীয় কথাটিও সত্য। ২০২৫ সালের ডিসেম্বরে React Server Components-এর একটি গুরুতর ত্রুটি (CVE-2025-55182, প্রচলিত নাম React2Shell) প্রকাশ পায়। প্রকাশিত advisory-গুলোতে একে CVSS 10.0 মাত্রার, লগইন ছাড়াই দূর থেকে কোড চালানোর মতো ত্রুটি বলা হয়, আর React-এর কয়েকটি 19.x version-সহ এর ওপর দাঁড়ানো framework-গুলো প্রভাবিত হয়। একটি ভুল, আর একসাথে অগণিত সাইটকে তাড়াহুড়ো করে আপডেট করতে হয়। যাঁরা নিজে Server Function লেখেননি, তাঁদের অনেকেও ঝুঁকিতে ছিলেন বলে জানানো হয়েছিল।

ঝুঁকি শুধু বড় framework-এ নয়। ২০১৬ সালের মার্চে একজন ডেভেলপার npm থেকে নিজের ছোট left-pad package সরিয়ে নিলে, প্রায় ১১ লাইনের সেই কোডের ওপর নির্ভরশীল অনেক build কিছু সময়ের জন্য ভেঙে যায়। আপনার node_modules-এ এমন শত শত অপরিচিত লেখকের কোড থাকে।

তাহলে করণীয় কী? নিজে সব লিখলে সমস্যা মেটে না, কারণ একজনের লেখা নিরাপত্তা-কোড সাধারণত হাজারজনের পরীক্ষিত কোডের চেয়ে দুর্বল। ভালো পথ হলো: কম dependency, lockfile, নিয়মিত আপডেট, নিরাপত্তা-বার্তা অনুসরণ, আর কোন version চলছে তা জানা।

মূল উপলব্ধি: Framework ছোট ছোট অনেক ঝুঁকিকে একটি বড় কিন্তু দ্রুত ঠিক করা যায় এমন ঝুঁকিতে বদলে দেয়। সেই সুবিধা পেতে হলে আপডেট দ্রুত করার ক্ষমতা আপনার থাকতে হবে।

প্র ০৫AI সব স্তরের কোড লিখতে পারলে ফুল-স্ট্যাক ডেভেলপারের মূল্য কি কমছে, না বাড়ছে?

“ফুল-স্ট্যাক” কথাটি নতুন হলেও ধারণাটি পুরোনো। ওয়েবের প্রথম দিকে এক-দুজন মানুষই পুরো সাইট চালাতেন। ১৯৯০-এর দশকের শেষে LAMP (Linux, Apache, MySQL, PHP) নামে একটি পুরো stack পরিচিত হয়, আর সেটি একজনের মাথায় ধরার মতো ছিল। পরে frontend আর backend এত জটিল হলো যে আলাদা পেশা হয়ে গেল।

Melvin Conway ১৯৬৮ সালে লক্ষ করেন, প্রতিষ্ঠান যেভাবে যোগাযোগ করে, তার তৈরি সিস্টেমের নকশাও তেমন হয়ে ওঠে। আলাদা frontend আর backend দল মানে মাঝখানে একটি কঠিন সীমানা। প্রতিটি ছোট বদলে দুই দলের সমন্বয় লাগে। ছোট দল ফুল-স্ট্যাক মানুষ চায় এই সমন্বয়ের খরচ কমাতে, কোনো জাদু ক্ষমতার জন্য নয়।

AI এই হিসাবকে দুইভাবে বদলাচ্ছে। এক দিকে, অচেনা স্তরে কাজ শুরু করা সহজ হয়েছে: একজন frontend ডেভেলপার AI-র সাহায্যে একটি API-র খসড়া লিখতে পারেন। আড়াআড়ি দণ্ডের নিচের অংশটি সস্তা হচ্ছে। অন্য দিকে, ঠিক সেই কারণেই বিপদ বাড়ছে। যে স্তর আপনি বোঝেন না, সেখানে AI-এর ভুল আপনি ধরতে পারবেন না। Authorization বাদ পড়া, transaction ছাড়া stock কমানো, secret frontend-এ চলে যাওয়া: এসব কোড চলে, পরীক্ষায় হয়তো পাসও করে, ব্যর্থ হয় পরে।

তাই মূল্য সরে যাচ্ছে লেখা থেকে বিচারের দিকে: সিস্টেমের সীমানা কোথায়, কোন ঝুঁকি কোন স্তরে, কীভাবে যাচাই হবে। এই পূর্বাভাস একটি যুক্তিসংগত মত, প্রমাণিত সত্য নয়; বাজার কোন দিকে যাবে তা কেউ নিশ্চিত জানেন না।

মূল উপলব্ধি: AI আড়াআড়ি দণ্ড চওড়া করে দেয়, কিন্তু খাড়া দণ্ড ছাড়া আপনি জানবেন না কোথায় সে ভুল করছে। গভীরতাই আপনার যাচাইয়ের ক্ষমতা।

অনুশীলন

আগে নিজে করুন, তারপর উত্তর মেলান।

Numerical: একটি অ্যাপে ১০টি কাজ আছে, প্রতিটিতে গড়ে ৫টি জায়গা বদলায়, আর স্ক্রিনে মোট ১২টি জায়গায় তথ্য দেখানো হয়। (ক) E × T আর V + E মডেলে লাইন কত? (খ) gzip করা bundle 150 kB হলে 2 Mbps সংযোগে শুধু নামাতে কত সময় লাগবে?

(ক) হাতে: ১০ × ৫ = ৫০ লাইন। Declarative: ১২ + ১০ = ২২ লাইন। অনুপাত ৫০ ÷ ২২ ≈ ২.৩.

(খ) 150 × 8 = 1,200 kilobit. 2 Mbps = 2,000 kilobit প্রতি সেকেন্ডে। সময় = 1,200 ÷ 2,000 = 0.6 সেকেন্ড। Latency আর JavaScript চালানোর সময় এর বাইরে।
নকশা ও সমালোচনা: একজন বললেন, “সব ওয়েবসাইট React আর Next.js-এ বানানো উচিত।” তিনটি কাজ ভাবুন: (ক) একটি চায়ের দোকানের এক পাতার ঠিকানা-সাইট, (খ) বাজারঘরের মতো লগইন-সহ দোকান, (গ) একটি পাতার ছোট দাম-হিসাবের ফর্ম। প্রতিটিতে কী বেছে নেবেন, আর কেন?

(ক) Plain HTML আর CSS. State নেই, তাই framework-এর দাম দিয়ে কিছু মেলে না। Hosting-ও সহজ ও সস্তা হয়।

(খ) Framework যুক্তিসংগত: অনেক state, routing, login, নিরাপত্তা, দল বড় হওয়ার সম্ভাবনা। Next.js একটি পথ, Laravel বা Django-ও একই রকম ভালো হতে পারে; দলের দক্ষতা এখানে বড় বিষয়।

(গ) ২-৩টি ঘর হলে plain JavaScript যথেষ্ট। অনেক পরস্পরনির্ভর ঘর হলে একটি পাতায় ছোট library ভাবা যায়।

দাবিটির ভুল হলো “সব”। সিদ্ধান্ত আসে প্রয়োজন থেকে: কতটা state, কারা রক্ষণাবেক্ষণ করবেন, কত ধীর সংযোগে চলবে।
আউটপুট অনুমান: কোডটি চালানোর আগে আউটপুটের ক্রম লিখুন। const q = []; const on = f => q.push(f); console.log('A'); on(() => console.log('B')); console.log('C'); q.forEach(f => f());

আউটপুট A, C, B. on ফাংশনটি চালায় না, শুধু তালিকায় জমা রাখে। শেষ লাইনে “framework” (forEach) তাকে ডাকে। ঠিক এভাবেই route handler জমা থাকে, অনুরোধ এলে চলে। নিজে নিশ্চিত হতে ওপরের who-calls-whom.js ব্লকে কোডটি বসিয়ে চালান।
স্তর ভাগ: বাজারঘরের “অর্ডার বাতিল” ফিচারে নিচের কাজগুলো কোন স্তরে হওয়া উচিত? (ক) বাতিলের বাটন দেখানো (খ) এই অর্ডার এই ক্রেতার কি না যাচাই (গ) stock ফেরত যোগ করা (ঘ) server ডাউন হলে সতর্কবার্তা পাওয়া।

(ক) Frontend. (খ) Backend: বাটন লুকিয়ে রাখা নিরাপত্তা নয়, যে কেউ সরাসরি অনুরোধ পাঠাতে পারেন। (গ) Backend নির্দেশ দেয়, Database-এ একটি transaction-এর ভেতরে হয় (পর্ব ৪৩)। (ঘ) Infrastructure: monitoring (পর্ব ৮৩)।

নিজেকে যাচাই করুন

ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।

ক্রম“কার্টে যোগ করুন” ক্লিকের পরের ঘটনাগুলো সঠিক ক্রমে সাজান (▲▼ চেপে সরান)

Browser-এ ক্রেতা বাটন চাপেন
Frontend একটি HTTP অনুরোধ পাঠায়
Backend ক্রেতা ও ইনপুট যাচাই করে
Database-এ কার্টের পরিমাণ বদলায়
Backend JSON উত্তর ফেরত পাঠায়
Frontend নতুন সংখ্যা ও মোট দেখায়

Library আর framework-এর মূল পার্থক্য কোনটি?

Framework সবসময় আকারে বড়
কে কাকে ডাকে, অর্থাৎ নিয়ন্ত্রণের দিক
Library বিনা মূল্যে, framework-এ দাম লাগে
Library browser-এ চলে, framework server-এ

একটি অনলাইন দোকানে পণ্যের দাম কোথা থেকে নিয়ে মোট হিসাব করা উচিত?

Browser-এর পাঠানো দাম থেকে
localStorage থেকে
Server-এ database থেকে
পাতার HTML থেকে

“ফুল-স্ট্যাক ডেভেলপার” কথাটির সৎ ব্যাখ্যা কোনটি?

প্রতিটি স্তরে বিশেষজ্ঞের সমান দক্ষ
যিনি React জানেন
যিনি পাঁচটি প্রোগ্রামিং ভাষা জানেন
একটি ফিচার শুরু থেকে শেষ পর্যন্ত নিতে পারেন, আর এক দিকে গভীর

Plain JavaScript-এ qty += 1; চলল, কিন্তু DOM বদলানোর কোনো লাইন নেই। স্ক্রিনে কী হবে?

স্ক্রিনে আগের মানই থাকবে
স্ক্রিন নিজে থেকেই বদলাবে
একটি error দেখাবে
পাতা reload হবে

React bundle-এর gzip করা আকার 80 kB. শুধু নামানোর সময় হিসাব করলে 4 Mbps সংযোগে কত লাগবে?

0.02 সেকেন্ড
1.6 সেকেন্ড
0.16 সেকেন্ড
20 সেকেন্ড

AI একটি package-এর নাম দিল, যা আপনি আগে শোনেননি। প্রথমে কী করবেন?

সরাসরি npm install চালাবেন
npm view আর অফিসিয়াল docs দিয়ে যাচাই করবেন
AI-কেই জিজ্ঞেস করবেন package-টি আসল কি না
আসল API key দিয়ে চালিয়ে দেখবেন

শব্দকোষ

লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন, অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:

মনে রাখুন

একটি পণ্যের চারটি স্তর: frontend, backend, database, infrastructure; আসল নিয়ম থাকে server-এ।
ফুল-স্ট্যাক মানে T-আকৃতির দক্ষতা, সব কিছুতে বিশেষজ্ঞ হওয়া নয়।
Library-কে আপনি ডাকেন, framework আপনাকে ডাকে: inversion of control.
Framework দেয় routing, state, validation, নিরাপদ ডিফল্ট আর convention; নেয় churn, abstraction, lock-in, bundle size.
প্রয়োজন থেকে টুল বাছুন, আর AI-এর লেখা কোড docs, run, diff, test দিয়ে যাচাই করুন।

পরের পর্বে: আজ “কার্টে যোগ করুন” ক্লিকটি ওপর থেকে দেখলেন। এবার সেই একটি অনুরোধের পুরো যাত্রা browser থেকে database হয়ে ফিরে আসা পর্যন্ত খুঁটিয়ে দেখবেন।

ফুল-স্ট্যাক কী — framework কেন লাগে আর এই কোর্সের পথ