Stack বাছাই — MERN, Next.js, Django, Laravel আর সিদ্ধান্তের ছক

১ · র‍্যাঙ্কিং নয়, trade-off

কোর্সের ৮৪টি পর্বে আমরা বাজারঘর বানিয়েছি React, Express, Prisma আর Next.js দিয়ে, আর মডিউল ১০-এ একই দোকানের টুকরো দেখেছি Vue, Svelte, Django, FastAPI, Laravel, Spring Boot আর Rails-এ। এখন আসল প্রশ্ন: নতুন একটি প্রজেক্ট এলে কোনটি বাছবেন? Facebook গ্রুপে প্রশ্নটি প্রায়ই আসে “২০২৬ সালে কোন stack সেরা?” রূপে। উত্তরটি হতাশাজনক শোনালেও সৎ: প্রশ্নটিই অসম্পূর্ণ।

Tech stack মানে একটি অ্যাপ চালাতে যে প্রযুক্তিগুলো একসাথে বসে: frontend framework, backend framework, ভাষা, ORM, ডেটাবেস, আর কোথায় চলবে। একটি stack বাছাই মানে আসলে কয়েকটি ছোট সিদ্ধান্তের একটি গুচ্ছ, আর প্রতিটির দাম ভিন্ন।

• বদলানো সহজ: CSS-এর পদ্ধতি, state library, test runner. ভুল হলে কয়েক দিনে বদলানো যায়।
• বদলানো মাঝারি কঠিন: frontend framework, ORM. কয়েক সপ্তাহ থেকে কয়েক মাস।
• বদলানো খুব কঠিন: backend-এর ভাষা, ডেটাবেসের ধরন, ডেটার মডেল, আর hosting-এর এমন সেবা যার ওপর অনেক কোড নির্ভর করে। এগুলো প্রায় দরজার তালার মতো, একবার লাগালে খোলা ঝামেলার।

Jeff Bezos-এর শেয়ারহোল্ডার চিঠির “একমুখী দরজা” আর “দুমুখী দরজা”-র ভাগ এখানে প্রায়ই উদ্ধৃত হয়: যে সিদ্ধান্ত ফেরানো যায়, তা দ্রুত নিন; যা ফেরানো কঠিন, তাতে সময় দিন। এই পর্বের কৌশলগুলো, প্রশ্নের তালিকা, কঠিন শর্তের ছাঁকনি, ওজন দেওয়া ছক আর ADR, মূলত একমুখী দরজাগুলোর জন্য।

২ · যে সাতটি প্রশ্ন সিদ্ধান্ত ঠিক করে

কোন framework-এ “বেশি feature” আছে, তা প্রায় কখনো সিদ্ধান্ত ঠিক করে না; আধুনিক বড় framework-গুলো মোটামুটি সব কাজ পারে। সিদ্ধান্ত ঠিক করে আপনার পরিস্থিতি। সাতটি প্রশ্ন লিখে উত্তর দিন, তারপর তবে framework-এর নাম ভাবুন।

1. দল কী জানে? যাঁরা কোড লিখবেন আর রাত দুটোয় bug সারাবেন, তাঁরা কোন ভাষায় আর কোন framework-এ আগে production চালিয়েছেন? পরিচিত stack-এ একজন মাঝারি ডেভেলপার প্রায়ই অপরিচিত “আধুনিক” stack-এ একজন দক্ষ ডেভেলপারের চেয়ে দ্রুত নিরাপদ কোড দেন।
2. নিয়োগের পুকুর কেমন? দল বড় করতে হলে স্থানীয়ভাবে বা দূর থেকে কোন stack-এর মানুষ পাওয়া সহজ। বাংলাদেশে PHP আর Laravel, JavaScript আর React, আর Python-এর ডেভেলপার খুঁজে পাওয়া সাধারণত সহজ বলে অনেকের অভিজ্ঞতা; Rails বা Elixir-এর মানুষ তুলনায় কম বলেই মনে হয়। কিন্তু এর কোনো নির্ভরযোগ্য সংখ্যা আমাদের কাছে নেই। নিজের শহরে চাকরির বিজ্ঞাপন আর পরিচিত মহলে খোঁজ নিয়ে যাচাই করুন।
3. পণ্যটি কোন ধরনের? তথ্যের সাইট (ক্যাটালগ, ব্লগ), দোকান (cart, checkout, payment), ড্যাশবোর্ড (login-এর পেছনে টেবিল আর চার্ট), real-time অ্যাপ (chat, live bid, লাইভ ট্র্যাকিং), নাকি শুধু mobile অ্যাপের জন্য API. প্রতিটির চাপ আলাদা জায়গায়।
4. SEO কতটা জরুরি? Google থেকে ক্রেতা আসা যদি ব্যবসার প্রাণ হয়, তবে server-এ HTML তৈরি করে এমন stack (SSR বা SSG) প্রায় বাধ্যতামূলক। Login-এর পেছনের ড্যাশবোর্ডে SEO প্রায় শূন্য গুরুত্বের; সেখানে একটি SPA পুরোপুরি ঠিক আছে। Rendering-এর মানচিত্র পর্ব ৩-এ, SEO-র কাজ পর্ব ৫৮-এ।
5. বাজেট আর hosting কী আছে? বছরে একবার টাকায় বিল দেওয়া shared hosting, নিজে চালানো একটি VPS, নাকি একটি PaaS? চার জায়গার সীমা পর্ব ৮২-এ বিস্তারিত; এখানে শুধু মনে রাখুন, hosting প্রায়ই stack-কে বাদ দেয়, উল্টোটা নয়।
6. বাজারে আসতে কত সময়? Time to market ছয় সপ্তাহ হলে admin panel, auth আর form নিজে বানানোর সময় নেই; তৈরি জিনিস (batteries included) বেশি মূল্যবান।
7. পাঁচ বছর কে দেখবে? প্রজেক্ট হাতবদল হবে কি না, রক্ষণাবেক্ষণ কে করবেন, framework-এর upgrade পথ কতটা মসৃণ। লম্বা জীবনের অ্যাপে “আজ দ্রুত” বনাম “পাঁচ বছরে শান্ত” প্রায়ই বিপরীত দিকে টানে।

এবার একটি দৃশ্যপটে প্রশ্নগুলোর উত্তর ধাপে ধাপে দেখুন। দৃশ্যপট A: পুরান ঢাকার একটি মুদি দোকানের মালিক বাজারঘর-ধাঁচের একটি ছোট অনলাইন দোকান চান।

৩ · পরিচিত stack-গুলো — সৎ শক্তি আর সীমা

প্রতিটি stack এই কোর্সে কোথাও না কোথাও শেখানো হয়েছে। এখানে আবার শেখাচ্ছি না; শুধু পাশাপাশি রাখছি, যাতে বাছাইয়ের সময় এক নজরে দেখা যায়। “সীমা” কলামটি সমালোচনা নয়, দাম; প্রতিটি শক্তির পাশেই একটি দাম থাকে।

দুটি জিনিস খেয়াল করুন। “এক ভাষা দুই দিকে” (MERN, Next.js, T3) ছোট দলে বাস্তব সুবিধা, কারণ type আর validation-এর schema ভাগ করা যায় (পর্ব ২১)। আর “batteries included” framework (Django, Laravel, Rails) সময় বাঁচায়, কিন্তু তাদের পথের বাইরে গেলে লড়াই করতে হয়। প্রতিটি “দাম” আপনার পরিস্থিতিতে প্রাসঙ্গিক কি না, সেটিই আসল প্রশ্ন।

৪ · কঠিন শর্ত আগে — hosting আর দল

কিছু শর্ত “পছন্দ” নয়, “হয় অথবা না”। শুধু PHP চলে এমন hosting-এ Node server চলবে না, যত ভালো স্কোরই হোক। এগুলোকে বলে কঠিন শর্ত। নিয়ম সোজা: কঠিন শর্ত দিয়ে আগে ছাঁকুন, তারপর যারা টিকে থাকে শুধু তাদের স্কোর দিন। নইলে ছকে একটি অচল বিকল্প জিতে যেতে পারে, আর সবাই তখন hosting বদলানোর যুক্তি খুঁজতে শুরু করেন।

সাধারণ কঠিন শর্তগুলো: hosting কোন runtime চালায় (PHP, Node, Python), সবসময় চলা process রাখা যায় কি না (WebSocket আর queue worker-এর জন্য), ডেটা দেশের ভেতরে রাখার মতো চুক্তি বা নিয়ম আছে কি না, আর প্রতিষ্ঠানের নীতিতে কোনো ভাষা বা লাইসেন্স নিষেধ কি না। নিচের মডেলটি প্রথম দুটি শর্ত পরীক্ষা করে। কোন hosting-এ কী থাকে, তা পর্ব ৮২-এর সাধারণ চিত্র থেকে নেওয়া; আপনার hosting-এর আসল বিবরণ মিলিয়ে নিন।

// কঠিন শর্ত আগে: যে stack চালানোই যাবে না, তাকে স্কোর দেওয়ার মানে নেই
const stacks = [
  { name: 'Laravel + Blade', runtime: 'php' },
  { name: 'Next.js static export', runtime: null },
  { name: 'Next.js SSR + Prisma', runtime: 'node' },
  { name: 'MERN + Socket.IO', runtime: 'node', alwaysOn: true },
  { name: 'Django + HTMX', runtime: 'python' },
  { name: 'Laravel + Reverb chat', runtime: 'php', alwaysOn: true },
];
const hosts = {
  'shared, PHP only': { php: true },
  'shared + Node/Python app': { php: true, node: true, python: true },
  'VPS': { php: true, node: true, python: true, alwaysOn: true },
};
function fits(s, h) {
  if (s.runtime && !h[s.runtime]) return 'NO  (no ' + s.runtime + ' app)';
  if (s.alwaysOn && !h.alwaysOn) return 'NO  (needs always-on process)';
  return 'ok';
}
for (const [hn, h] of Object.entries(hosts)) {
  const ok = stacks.filter(s => fits(s, h) === 'ok').length;
  console.log(`== ${hn}: ${ok} of ${stacks.length} fit`);
  for (const s of stacks) console.log('   ' + s.name.padEnd(22) + fits(s, h));
}

দলও একটি কঠিন শর্ত হতে পারে

“দলে কেউ Python জানেন না, আর তিন মাসে পণ্য চাই” হলে Django বাস্তবে প্রায় কঠিন শর্তে বাদ। নিয়োগ বা প্রশিক্ষণের সময় থাকলে শর্তটি নরম হয়ে স্কোরে যায়। কোন শর্ত কঠিন আর কোনটি শুধু ওজন, তা লিখে আলাদা করাই এই ধাপের কাজ।

৫ · Monolith আগে, তারপর দেখা — আর ডেটাবেস বাছাই

Stack-এর পাশাপাশি আরেকটি একমুখী দরজা হলো অ্যাপটি এক টুকরো হবে, নাকি অনেক সেবায় ভাগ হবে। Monolith মানে পুরো অ্যাপ একটি deploy-যোগ্য একক; microservices মানে আলাদা আলাদা সেবা, প্রত্যেকে নিজে deploy হয়, network-এ কথা বলে। তত্ত্ব আর বড় পরিসরের নকশা System Design কোর্সের Monolith বনাম microservices পর্বে, আর architecture pattern-এর মানচিত্র পর্ব ৪-এ।

Martin Fowler ২০১৫ সালের “MonolithFirst” লেখায় একটি পর্যবেক্ষণ দেন, যা প্রায়ই উদ্ধৃত হয়: তাঁর দেখা সফল microservice-এর গল্পগুলোর বেশিরভাগ শুরু হয়েছিল একটি monolith থেকে, যা বড় হয়ে ভাঙা হয়েছে; আর একদম শুরু থেকে microservice দিয়ে বানানো প্রকল্পে তিনি বেশ সমস্যা দেখেছেন। কারণ শুরুতে সেবার সীমানা কোথায় টানা উচিত, তা জানা থাকে না।

মাঝের পথ: modular monolith

Modular monolith হলো একটি deploy, কিন্তু ভেতরে শক্ত দেয়াল। ক্যাটালগ, cart, অর্ডার আর chat আলাদা module; প্রত্যেকে অন্যের সাথে কথা বলে শুধু একটি ঘোষিত interface দিয়ে, অন্যের টেবিলে সরাসরি হাত দেয় না। পরে কোনো module-কে আলাদা সেবা বানাতে হলে দেয়াল আগে থেকেই টানা থাকে।

বাজারঘরের মতো একটি দোকানের জন্য বাস্তব পরামর্শ: একটি monolith দিয়ে শুরু করুন, ভেতরে module-এর দেয়াল রাখুন। সেবা আলাদা করুন তখনই, যখন একটি মাপা কারণ আছে: একটি অংশের ভিন্ন ধরনের চাপ (chat-এর হাজার খোলা সংযোগ), ভিন্ন deploy-এর ছন্দ, বা আলাদা দল। পর্ব ৮৭-এ ১০০ থেকে ১০ লাখ ব্যবহারকারীর পথে ঠিক কখন কী ভাঙে, তা ধাপে ধাপে আসবে।

ডেটাবেস: সাধারণ উত্তর PostgreSQL, কিন্তু সবসময় নয়

ডেটাবেস stack-এর সবচেয়ে কঠিন একমুখী দরজা, কারণ কোড বদলানো যায়, কিন্তু কোটি সারির ডেটা আর তার ওপর নির্ভর করা query বদলানো অনেক কঠিন। উপভাষার পার্থক্য DBMS কোর্সের SQL-এর উপভাষা পর্বে, আর SQL বনাম NoSQL-এর তত্ত্ব System Design-এ।

৬ · একঘেয়ে প্রযুক্তি আর innovation token

Dan McKinley, যিনি Etsy-তে কাজ করেছেন, ২০১৫ সালের দিকে “Choose Boring Technology” নামে একটি প্রবন্ধ লেখেন, যা পরে একটি বক্তৃতা হিসেবেও ছড়ায়। তাঁর মূল ধারণা: একটি প্রতিষ্ঠানের হাতে অল্প কয়েকটি innovation token থাকে, শুরুতে মোটামুটি তিনটি, আর প্রতিটি নতুন বা অপরিচিত প্রযুক্তি একটি token খরচ করে। তিনি নিজেই বলেছেন হিসাবটি কাল্পনিক, একটি ভাবার উপায় মাত্র। Boring technology মানে খারাপ প্রযুক্তি নয়; মানে এমন প্রযুক্তি, যার ব্যর্থতার ধরন সবাই জানে।

পরিচিত প্রযুক্তির অজানা সমস্যা কম, কারণ হাজারো দল সেগুলো আগেই খুঁজে পেয়েছে আর উত্তর লিখে রেখেছে; নতুন প্রযুক্তিতে প্রতিটি সমস্যা আপনাকে প্রথমবার সমাধান করতে হয়। তাই token খরচ করুন সেখানে, যেখানে নতুনত্ব পণ্যের মূল সুবিধা দেয়।

নিচের খেলনা মডেলে একটি প্রস্তাবিত stack-এর হিসাব। দল আগে production-এ চালিয়েছে React, TypeScript, Express, PostgreSQL আর একটি Linux VPS. প্রস্তাবে নয়টি জিনিস, যার কয়েকটি পণ্যের মূল (core), কয়েকটি “থাকলে ভালো”।

// Innovation token-এর খেলনা হিসাব: দলের কাছে নতুন প্রতিটি জিনিস একটি token খরচ করে
const BUDGET = 3;
const known = new Set(['react', 'typescript', 'express', 'postgresql', 'linux vps']);
const proposal = [
  { tech: 'nextjs',     core: true  },  // দোকানের পাতা আর SEO
  { tech: 'react',      core: true  },
  { tech: 'typescript', core: true  },
  { tech: 'prisma',     core: true  },
  { tech: 'postgresql', core: true  },
  { tech: 'trpc',       core: false },
  { tech: 'mongodb',    core: false },  // PostgreSQL থাকতেই দ্বিতীয় database
  { tech: 'graphql',    core: false },
  { tech: 'kubernetes', core: false },
];
function check(list) {
  const spent = list.filter(p => !known.has(p.tech));
  console.log(`tokens ${spent.length}/${BUDGET}: ${spent.map(p => p.tech).join(', ')}`);
  return spent.length <= BUDGET;
}
console.log('first proposal');
if (!check(proposal)) {
  const trimmed = proposal.filter(p => p.core || known.has(p.tech));
  const dropped = proposal.filter(p => !trimmed.includes(p)).map(p => p.tech);
  console.log('over budget, drop non-core new items: ' + dropped.join(', '));
  console.log('second proposal');
  console.log(check(trimmed) ? 'within budget' : 'still over budget');
}

৭ · ওজন দেওয়া সিদ্ধান্তের ছক — চারটি দৃশ্যপট

কঠিন শর্তের পর একাধিক প্রার্থী টিকে থাকলে decision matrix কাজে লাগে। পদ্ধতি সহজ: কয়েকটি মাপকাঠি বাছুন, প্রতিটিকে ওজন দিন যাতে যোগফল ১০০ হয়, প্রতিটি stack-কে প্রতিটি মাপকাঠিতে ১ থেকে ৫ স্কোর দিন, তারপর স্কোর × ওজন যোগ করে ১০০ দিয়ে ভাগ করুন। ফলাফল ১ থেকে ৫-এর মধ্যে একটি সংখ্যা।

আমরা ছয়টি মাপকাঠি নিয়েছি: দলের দক্ষতা (team), hosting-এর সাথে মিল (hosting), বাজারে আসার গতি (speed), real-time ক্ষমতা (realtime), SEO, আর দীর্ঘমেয়াদি রক্ষণাবেক্ষণ (maintain). প্রথমটি দৃশ্যপট অনুযায়ী বদলায়, কারণ দল বদলায়; বাকি পাঁচটির স্কোর stack-এর নিজের, সব দৃশ্যপটে এক। প্রতিটি স্কোর এই পর্বের লেখকের বিচারে ধরে নেওয়া, মাপা নয়; আপনার দল ভিন্ন স্কোর দিতে পারে, আর দেওয়াই উচিত। Hosting-এর স্কোর মানে কম খরচের hosting-এ চালানোর সহজতা।

চারটি দৃশ্যপট, প্রতিটির নিজের দল আর ওজন:

• A · shared hosting-এ ছোট দোকান: ২ অংশের দৃশ্যপট। দল: একজন Laravel ফ্রিল্যান্সার। ওজন: team ২৫, hosting ৩৫, speed ১৫, realtime ০, SEO ১৫, maintain ১০.
• B · startup-এর MVP: দুজন TypeScript আর React জানা ডেভেলপার, তিন মাসে পণ্য, PaaS-এ চালানোর বাজেট আছে। ওজন: team ৩০, hosting ৫, speed ৩৫, realtime ৫, SEO ১৫, maintain ১০.
• C · chat-সহ real-time marketplace: বিক্রেতা আর ক্রেতা live দরদাম করেন। দল JavaScript-এ সবচেয়ে অভ্যস্ত, VPS চালাতে পারে। ওজন: team ২৫, hosting ৫, speed ১৫, realtime ৩৫, SEO ৫, maintain ১৫.
• D · Python-এর data দলের internal admin tool: তিনজন data analyst, Python আর pandas জানেন, অফিসের ভেতরে ব্যবহার হবে। ওজন: team ৩৫, hosting ৫, speed ৩০, realtime ০, SEO ০, maintain ৩০.

দলের স্কোর (team): A-তে Laravel ৫, Next.js ২, MERN ২, Django ১, FastAPI ১; B-তে ২, ৫, ৪, ২, ২; C-তে ৩, ৪, ৫, ২, ৩; D-তে ১, ২, ২, ৫, ৪. সব দৃশ্যপটের ফল একসাথে (একটি scratch script-এ হিসাব করা, নিচের runnable block-এর একই সূত্রে):

A-র ফলাফল আসলে ছক ছাড়াই জানা ছিল: hosting-এর কঠিন শর্তে Next.js SSR আর Django আগেই বাদ। D-ও পরিষ্কার: Python দল আর Django-র তৈরি admin (পর্ব ৬৮) একে অপরের জন্য তৈরি। আকর্ষণীয় হলো B আর C, যেখানে ব্যবধান মাত্র 0.40. এখানে প্রশ্ন ওঠে: বিজয়ী কতটা মজবুত? নিচের block C-র ছক চালায়, আর খোঁজে realtime থেকে SEO-তে কত পয়েন্ট ওজন সরালে প্রথম স্থান বদলায়। একে বলে sensitivity analysis.

// ওজন দেওয়া সিদ্ধান্তের ছক: real-time marketplace (চ্যাটসহ)। সব স্কোর ধরে নেওয়া, ১ থেকে ৫
const criteria = ['team', 'hosting', 'speed', 'realtime', 'seo', 'maintain'];
const weights  = [  25,      5,       15,       35,       5,       15   ]; // যোগফল 100
const scores = {
  'Laravel':      [3, 5, 5, 3, 5, 4],
  'Next+Prisma':  [4, 2, 4, 3, 5, 4],
  'MERN':         [5, 1, 3, 5, 2, 3],
  'Django':       [2, 2, 5, 3, 5, 5],
  'FastAPI+React':[3, 1, 3, 4, 2, 3],
};
function rank(w) {
  return Object.entries(scores)
    .map(([name, s]) => [name, s.reduce((sum, x, i) => sum + x * w[i], 0)])  // পূর্ণসংখ্যা, ভাগ পরে
    .sort((a, b) => b[1] - a[1]);
}
const table = rank(weights);
table.forEach(([name, total], i) => console.log(`${i + 1}. ${name.padEnd(14)} ${(total / 100).toFixed(2)}`));
// সংবেদনশীলতা: realtime থেকে কত ওজন seo-তে সরালে বিজয়ী বদলায়?
const winner = table[0][0];
for (let d = 1; d <= weights[3]; d++) {
  const w = [...weights]; w[3] -= d; w[4] += d;
  const r = rank(w);
  const old = r.find(([n]) => n === winner)[1];
  if (r[0][0] !== winner && r[0][1] > old) {          // সমান হলে বদল ধরা হয় না
    console.log(`move ${d} points realtime -> seo: winner ${winner} -> ${r[0][0]} (${(r[0][1] / 100).toFixed(2)} vs ${(old / 100).toFixed(2)})`);
    break;
  }
}

৮ · Framework-এর স্বাস্থ্য পড়া — আজকের পাবলিক তথ্য থেকে

একটি framework পাঁচ বছর বাঁচবে কি না, তা কেউ নিশ্চিত বলতে পারে না, কিন্তু কয়েকটি সংকেত পাবলিকভাবে দেখা যায়। GitHub-এর star বা download-এর বড় সংখ্যা জনপ্রিয়তা দেখায়, স্বাস্থ্য নয়; আর আমরা কোনো download সংখ্যা এখানে দিচ্ছি না। কাজের সংকেতগুলো:

• লিখিত support policy আর LTS: কোন version কতদিন security fix পাবে, তা কি তারিখসহ লেখা আছে?
• Release cadence: নিয়মিত patch আসে কি না, আর major version কতদিন পরপর। খুব ধীর মানে মৃত নয়, খুব দ্রুত মানে ভালো নয়।
• রক্ষণাবেক্ষণকারী: একজন মানুষের শখের প্রজেক্ট, নাকি একটি দল, foundation বা প্রতিষ্ঠান? একজন চলে গেলে প্রজেক্ট থামবে কি না, তাকে বলে bus factor.
• Ecosystem: auth, payment, admin, test-এর library আছে কি না, আর সেগুলো নিজেরাও রক্ষণাবেক্ষণ পায় কি না।
• Upgrade-এর পথ: major version-এ breaking change কতটা, upgrade guide আর codemod আছে কি না।

লেখার দিনে (৪ নভেম্বর ২০২৬) আমরা একটি ছোট Node script দিয়ে npm, PyPI, Packagist আর RubyGems-এর পাবলিক registry থেকে প্রতিটি package-এর stable release-গুলো গুনেছি। সত্যিকারের run, Node 24:

~/lab$ node health.mjs
npm @sveltejs/kit          3.1.1     2026-10-29  releases/12m= 56  majors=2,3
npm @trpc/server           11.24.0   2026-11-03  releases/12m= 27  majors=11,10
npm express                5.3.0     2026-10-09  releases/12m=  7  majors=4,5
npm next                   16.4.5    2026-11-03  releases/12m= 90  majors=16,15,14
npm nuxt                   4.6.4     2026-11-02  releases/12m= 31  majors=3,4
npm react                  19.3.1    2026-10-14  releases/12m= 29  majors=19
npm vue                    3.5.44    2026-10-13  releases/12m= 22  majors=3
packagist laravel/framework 13.40.0   2026-11-03  releases/12m=125  majors=12,11,10,13,9
pypi Django                6.1.3     2026-11-03  releases/12m= 34  majors=5,4,6
pypi fastapi               0.162.0   2026-10-23  releases/12m=119  majors=0
rubygems rails             8.1.4     2026-09-24  releases/12m=  5  majors=8,7

একই দিনে তিনটি framework-এর লিখিত নীতি তাদের অফিসিয়াল পাতা থেকে পড়া হয়েছে (তারিখগুলো লেখার সময়ের; বদলাতে পারে, তাই নিজে আবার দেখুন):

পাঁচ বছরের অ্যাপে আপনি অন্তত দুই-তিনবার major upgrade করবেন, framework যেটাই হোক। তাই প্রশ্ন হলো কোনটির upgrade-এর পথ লিখিত আর পূর্বানুমেয়। প্রতিটি LTS-এর শেষ তারিখ ক্যালেন্ডারে লিখে রাখুন; মেয়াদ পার হওয়া framework-এর version-কে বলে end of life, যার পর নতুন security fix আসে না।

খালি ফোল্ডার থেকে “hello products” — একটি local run

শুরু করার গতিও একটি সংকেত, যদিও ছোট। দুটি stack-এ খালি ফোল্ডার থেকে একটি /products পাতা, যা তিনটি পণ্যের তালিকা দেখায়, চালু হওয়া পর্যন্ত সময় মাপা হয়েছে। সত্যিকারের run, একটি Windows যন্ত্রে একবার; ফোল্ডারের পথ বদলে ~/lab লেখা হয়েছে।

~/lab/nx$ npx create-next-app@16.4.5 bazarghar --ts --app --no-tailwind --no-eslint \
           --no-src-dir --no-react-compiler --import-alias "@/*" --use-npm --skip-install --yes
~/lab/nx/bazarghar$ npm install --no-audit --no-fund
~/lab/nx/bazarghar$ # app/products/page.tsx: তিনটি পণ্যের <ul>
~/lab/nx/bazarghar$ npx next dev -p 47851 -H 127.0.0.1
▲ Next.js 16.4.5 (Turbopack)
- Local:         http://127.0.0.1:47851
✓ Ready in 317ms
 GET /products 200 in 226ms (next.js: 130ms, application-code: 96ms)
scaffold+install: 33.9 s
first /products response after dev start: 2.8 s
total: 36.8 s
next 16.4.5 react 19.3.0      node_modules: 378M

~/lab/dj$ python -m venv .venv && .venv/Scripts/python -m pip install -q "Django==6.1.3"
~/lab/dj$ .venv/Scripts/django-admin startproject bazarghar .
~/lab/dj$ # bazarghar/products.py আর urls.py-তে একটি path
~/lab/dj$ .venv/Scripts/python manage.py runserver 127.0.0.1:47852 --noreload
~/lab/dj$ curl -s http://127.0.0.1:47852/products/
<ul><li>Chal 5kg - 450 taka</li><li>Dal 1kg - 140 taka</li><li>Tel 1L - 190 taka</li></ul>
venv+install+startproject: 15.0 s
first /products/ response after runserver: 0.6 s
total: 15.8 s
django 6.1.3 python 3.14.4    .venv: 56M

৯ · ভুল বাছাইয়ের দাম, দরজা খোলা রাখা আর ADR

সতর্ক থাকলেও কখনো কখনো stack ভুল প্রমাণ হয়: দল বদলায়, পণ্য বদলায়, বা framework থেমে যায়। তখন সরে যাওয়ার খরচ কতটা, তা মূলত তিনটি জিনিসের ওপর নির্ভর করে, যা আজই নিয়ন্ত্রণ করা যায়।

• পরিষ্কার API boundary: UI আর ব্যবসার logic যদি একটি লিখিত API (REST, পর্ব ৩৫-এর OpenAPI) দিয়ে আলাদা থাকে, তবে একদিকে বদলালে অন্যদিক টেকে। পাতার ভেতরে SQL আর logic মেশানো থাকলে সব একসাথে নতুন করে লিখতে হয়।
• Standard database: PostgreSQL বা MySQL-এর সাধারণ টেবিল যেকোনো ভাষা আর framework পড়তে পারে। একটি platform-এর নিজস্ব database বা নিজস্ব query ভাষায় বাঁধা থাকলে ডেটা সরানো আলাদা একটি প্রকল্প হয়ে যায়।
• Test আর lock-in কম রাখা: আগের আচরণ test-এ লেখা থাকলে নতুন stack-এ তা মিলিয়ে দেখা যায় (পর্ব ৭৫)। Platform-এর নিজস্ব queue, KV store বা cron-এর ওপর অনেক কোড থাকলে একটি পাতলা নিজের interface-এর পেছনে রাখুন।

নিচের মডেলে বাজারঘরের ছয়টি module নতুন stack-এ লেখার খরচ, চারটি পরিস্থিতিতে। সব সংখ্যা ধরে নেওয়া উদাহরণ: module-প্রতি দিন, জটের গুণক, ডেটা সরানোর দিন, আর আচরণ যাচাইয়ের বাড়তি অংশ।

// ভুল stack থেকে সরার খরচ: সব সংখ্যা ধরে নেওয়া উদাহরণ, মাপা নয়
const modules = { catalog: 8, cart: 6, checkout: 10, orders: 7, admin: 12, auth: 5 }; // নতুন stack-এ লেখার দিন
const DEVS = 2, DAYS_PER_WEEK = 5;
function estimate({ boundary, database, testsExist }) {
  const base = Object.values(modules).reduce((a, b) => a + b, 0);
  const tangle = boundary === 'clean' ? 1.0 : 1.6;   // UI আর logic জট পাকানো থাকলে বাড়তি
  const data = database === 'same' ? 3 : 15;          // ডেটা সরানো, যাচাই, rollback-এর মহড়া
  const verify = testsExist ? 0.10 : 0.35;            // আগের আচরণ মিলিয়ে দেখার খরচ
  const days = Math.round((base * tangle + data) * (1 + verify));
  return { days, weeks: (days / DEVS / DAYS_PER_WEEK).toFixed(1) };
}
const cases = [
  ['clean API, same DB, tests', { boundary: 'clean', database: 'same', testsExist: true }],
  ['clean API, new DB, tests',  { boundary: 'clean', database: 'move', testsExist: true }],
  ['tangled, same DB, no tests', { boundary: 'tangled', database: 'same', testsExist: false }],
  ['tangled, new DB, no tests',  { boundary: 'tangled', database: 'move', testsExist: false }],
];
for (const [label, c] of cases) {
  const e = estimate(c);
  console.log(`${label.padEnd(27)} ${String(e.days).padStart(3)} dev-days  ~${e.weeks} weeks for ${DEVS} devs`);
}

সরে যাওয়ার পথও গুরুত্বপূর্ণ। পুরোটা একবারে নতুন করে লেখার বদলে Martin Fowler-এর ২০০৪ সালের লেখায় বর্ণিত strangler fig কৌশল: নতুন অংশগুলো পুরোনোর পাশে একটি একটি করে বসানো, সামনে একটি proxy বা router দিয়ে অনুরোধ নতুন দিকে ঘোরানো, যতক্ষণ না পুরোনোটি খালি হয়। বিস্তারিত Software Engineering কোর্সের technical debt আর legacy code পর্বে।

এক পাতার সিদ্ধান্তের দলিল: ADR

Michael Nygard ২০১১ সালে একটি ব্লগ লেখায় Architecture Decision Record বা ADR-এর একটি সহজ রূপ প্রস্তাব করেন: প্রতিটি গুরুত্বপূর্ণ সিদ্ধান্তের জন্য repository-তে একটি ছোট ফাইল, যাতে থাকে শিরোনাম, অবস্থা, প্রেক্ষাপট, সিদ্ধান্ত আর পরিণাম। ছয় মাস পরে “MongoDB কেন নয়?” প্রশ্নের উত্তর লেখা থাকে। পুরোনো ADR মুছে বা বদলে দেওয়া হয় না; নতুন সিদ্ধান্তে নতুন ADR লিখে পুরোনোটিকে “বাতিল, ADR-00X দিয়ে প্রতিস্থাপিত” চিহ্ন দেওয়া হয়। ADR-এর তত্ত্ব Software architecture পর্বে। নিচের stepper-এ দৃশ্যপট B-র ADR তৈরি হতে দেখুন।

# ADR-0001: বাজারঘর MVP-র stack
অবস্থা: প্রস্তাবিত · ২০২৬-১১-০৪
## প্রেক্ষাপট
দুজন ডেভেলপার, দুজনেই TypeScript আর React-এ
production চালিয়েছেন। ৩ মাসে প্রথম সংস্করণ।
ক্যাটালগের পাতা Google-এ আসা জরুরি।
PaaS-এ চালানোর মাসিক বাজেট আছে।

## বিবেচিত বিকল্প
১. Next.js + Prisma + PostgreSQL
২. Laravel + Inertia (React) + PostgreSQL
৩. Django + React + PostgreSQL
৪. Vite SPA + Express + MongoDB

## কঠিন শর্ত
SEO জরুরি → শুধু SPA (৪) দুর্বল, বাদ
PaaS-এ Node, PHP, Python সব চলে → বাকি সবাই টেকে
টিকে আছে: ১, ২, ৩

ওজন: team 30 · hosting 5 · speed 35
      realtime 5 · seo 15 · maintain 10
Next.js 4.30 · Laravel 3.90 · Django 3.85
সংবেদনশীলতা: team→hosting ১০ পয়েন্টে
Laravel 4.20, Next.js 4.00

## সিদ্ধান্ত
Next.js 16 (App Router) + Prisma 7 + PostgreSQL,
একটি modular monolith.
## পরিণাম
+ দলের পরিচিত ভাষা, এক type দুই দিকে
− shared hosting-এ চলবে না; PaaS বা VPS লাগবে
− version বদলের সাথে Next.js-এর API বদলায়
## আবার ভাবব যদি
দল PHP-ভিত্তিক হয়, বা hosting shared-এ নামাতে হয়

পুরো ADR একসাথে, যা আপনি নিজের repository-র docs/adr/ ফোল্ডারে রাখতে পারেন। কাঠামোটি Nygard-এর রূপের সাথে “বিবেচিত বিকল্প” আর “আবার ভাবব যদি” যোগ করা; অনেক দল এমন ছোট সংযোজন করে।

# ADR-0001: বাজারঘর MVP-র stack

অবস্থা: গৃহীত · ২০২৬-১১-০৪ · সিদ্ধান্তদাতা: দুই ডেভেলপার + পণ্যের মালিক

## প্রেক্ষাপট
- দল: দুজন, TypeScript আর React-এ production-এর অভিজ্ঞতা; Python বা PHP-তে নয়
- পণ্য: ক্যাটালগ, cart, checkout, অর্ডারের ইতিহাস; real-time নেই
- SEO: ক্যাটালগের পাতা search-এ আসা জরুরি
- সময়: ৩ মাসে প্রথম সংস্করণ
- Hosting: একটি PaaS-এ web + managed PostgreSQL, মাসিক বাজেট আছে

## বিবেচিত বিকল্প
1. Next.js 16 + Prisma 7 + PostgreSQL
2. Laravel 13 + Inertia (React) + PostgreSQL
3. Django 6 + React + PostgreSQL
4. Vite SPA + Express + MongoDB  (SEO-র শর্তে বাদ)

## মূল্যায়ন
ওজন (স্কোরের আগে লেখা): team 30, hosting 5, speed 35, realtime 5, seo 15, maintain 10
ফল (স্কোর ধরে নেওয়া, ১–৫): Next.js 4.30, Laravel 3.90, Django 3.85
সংবেদনশীলতা: team থেকে hosting-এ ১০ পয়েন্ট সরালে Laravel 4.20 বনাম Next.js 4.00

## সিদ্ধান্ত
Next.js 16 (App Router) + Prisma 7 + PostgreSQL, একটি modular monolith
(catalog, cart, orders, auth আলাদা module). Innovation token: Next.js আর Prisma (২/৩)।

## পরিণাম
+ দলের পরিচিত ভাষা; Zod schema আর type client ও server-এ ভাগ
+ SSR/SSG দিয়ে SEO; PostgreSQL standard, তাই পরে অন্য backend পড়তে পারবে
− shared hosting-এ চলবে না
− Next.js-এর major version-এ API বদলায়; বছরে একবার upgrade-এর সময় রাখতে হবে
− admin panel নিজে বানাতে হবে (Django বা Laravel-এ যা প্রায় তৈরি)

## আবার ভাবব যদি
- দলের বেশিরভাগ PHP বা Python-ভিত্তিক হয়ে যায়
- hosting shared-এ নামাতে হয়
- live chat বা দরদাম পণ্যের মূল feature হয়ে ওঠে

১০ · AI-এর যুগে stack বাছাই

“আমার অনলাইন দোকানের জন্য সেরা stack কোনটি?” লিখলে AI সাধারণত আত্মবিশ্বাসের সাথে একটি নাম দেয়, সাথে চকচকে কিছু কারণ। সমস্যা হলো, AI আপনার দল, hosting বা বাজেট জানে না, যদি না আপনি বলেন; আর জনপ্রিয় লেখায় যা বেশি এসেছে, সেটিই তার উত্তরে বেশি আসে। এই বিষয়ে AI-এর সাধারণ ভুলগুলো:

AI-এর stack-পরামর্শ হাতে পেলে

• নিজের সাত প্রশ্নের উত্তর আর কঠিন শর্ত আগে লিখেছি, তারপর AI-কে দিয়েছি
• প্রতিটি version আর support-এর তারিখ অফিসিয়াল পাতায় মিলিয়েছি
• প্রতিটি package-এর নাম registry-তে খুঁজে দেখেছি, আর সাম্প্রতিক release আছে কি না দেখেছি
• প্রস্তাবিত প্রতিটি নতুন অংশের জন্য একটি token গুনেছি, বাজেটের মধ্যে আছি
• ছোট একটি “hello products” নিজে চালিয়ে দেখেছি; শুধু পড়ে বিশ্বাস করিনি
• Prompt-এ কোনো secret, আসল গ্রাহকের ডেটা বা প্রতিষ্ঠানের গোপন তথ্য দিইনি