Middleware — request-এর পাইপলাইন, cors, json আর নিজের middleware

১ · পাইপলাইন — একটি request-এর সারি পার হওয়া

ডাকঘরে একটি পার্সেল এলে কী হয় ভাবুন। প্রথম টেবিলে সিল পড়ে, কখন এলো তা লেখা হয়। দ্বিতীয় টেবিলে ঠিকানা যাচাই হয়। তৃতীয় টেবিলে ওজন মাপা হয়, বেশি ভারী হলে সেখানেই ফেরত। চতুর্থ টেবিলে দেখা হয় মাশুল দেওয়া আছে কি না। সব পার হলে তবেই পার্সেলটি বাছাই ঘরে যায়।

প্রতিটি টেবিলের কাজ ছোট আর আলাদা। কেউ জানে না তার পরের টেবিলে ঠিক কী হবে। আবার যেকোনো টেবিল পার্সেলটি থামিয়ে ফেরত পাঠাতে পারে। পর্ব ০২-এ অনুরোধের যাত্রায় app server-এর ভেতরে যে “middleware” স্তরটি দেখেছিলেন, সেটি ঠিক এমনই। পর্ব ২৫-এ route লিখেছেন; এবার সেই route-এর সামনের টেবিলগুলো সাজানোর পালা।

নিচের ডায়াগ্রামে বাজারঘরের একটি সত্যিকারের অনুরোধ অনুসরণ করুন। POST /api/orders-এ JSON body আর token গেছে। প্রতিটি ধাপে req আর res-এর কোন মান বদলাল, ডান দিকের ঘরে দেখুন।

২ · (req, res, next) — তিনটি অক্ষর নয়, তিনটি সিদ্ধান্ত

প্রতিটি middleware-এর আকার একই: তিনটি parameter নেওয়া একটি ফাংশন। req হলো আসা অনুরোধ, res হলো যাওয়া উত্তর, আর next হলো “আমার কাজ শেষ, পরের টেবিলে যান” বলার ফাংশন।

Wandbox-এ Express import করা যায় না, তাই নিচের ব্লকে শেখার মডেল হিসেবে ৮ লাইনের একটি runner লেখা হয়েছে। next আসলে কত সাধারণ, সেটা দেখাই উদ্দেশ্য। চালিয়ে দেখুন, “বের হলো” লেখাগুলো কোন ক্রমে আসে।

// শেখার মডেল: Express নয়, ধারণা দেখানোর জন্য হাতে লেখা ছোট runner
function run(stack, req, res) {
  let i = 0;
  function next() {
    const fn = stack[i++];
    if (fn) fn(req, res, next);
  }
  next();
}

const logger = (req, res, next) => {
  console.log("1 logger: ঢুকল", req.url);
  next();
  console.log("1 logger: বের হলো");
};
const shop = (req, res, next) => {
  req.shop = "বাজারঘর";
  console.log("2 shop: req.shop বসাল");
  next();
  console.log("2 shop: বের হলো");
};
const handler = (req, res) => {
  res.body = req.shop + " এর পণ্য";
  console.log("3 handler: উত্তর তৈরি, next ডাকেনি");
};

const req = { url: "/api/products" };
const res = {};
run([logger, shop, handler], req, res);
console.log("শেষ ফল:", res.body);

1 logger: ঢুকল /api/products
2 shop: req.shop বসাল
3 handler: উত্তর তৈরি, next ডাকেনি
2 shop: বের হলো
1 logger: বের হলো
শেষ ফল: বাজারঘর এর পণ্য

logger before
logger after next()
handler sends

৩ · ক্রম আর স্তর — কে কখন, কোথায় চলবে

Express ফাংশনগুলোকে যে ক্রমে লিখেছেন, ঠিক সেই ক্রমে সাজিয়ে রাখে। আলাদা কোনো “priority” নেই। এর ফল কতটা বাস্তব, একটি ছোট সত্যিকারের run-এ দেখুন। প্রথম route express.json()-এর আগে, দ্বিতীয়টি পরে:

// ভুল ক্রম: route আগে, parser পরে
app.post("/wrong", (req, res) => {
  res.json({ typeofBody: typeof req.body, body: req.body ?? null });
});
app.use(express.json());
app.post("/right", (req, res) => {
  res.json({ typeofBody: typeof req.body, body: req.body });
});

সত্যিকারের run, Express 5.3.0, Node 24 (লেখার সময়ের stable version):

$ curl -s -X POST -H 'Content-Type: application/json' -d '{"a":1}' localhost:47328/wrong
{"typeofBody":"undefined","body":null}
$ curl -s -X POST -H 'Content-Type: application/json' -d '{"a":1}' localhost:47328/right
{"typeofBody":"object","body":{"a":1}}

একই request, একই body, শুধু লাইনের জায়গা আলাদা। Error নেই, শুধু খালি ফল। Express 5-এ body parse না হলে req.body হয় undefined; Express 4-এ এটি {} ছিল। পুরোনো কোডে req.body.item লিখলে এখন তাই TypeError আসতে পারে।

তিন স্তরে middleware

Middleware কোথায় বসাবেন, তার ওপর নির্ভর করে সে কতগুলো request দেখবে। স্কুলের গেটের দারোয়ান সবাইকে দেখেন, বিজ্ঞান ভবনের পাহারাদার শুধু সেই ভবনের লোকদের, আর ল্যাবের শিক্ষক শুধু ল্যাবে ঢোকা শিক্ষার্থীদের।

Router-level middleware-এর একটি কাজের ব্যবহার হলো একটি অংশকে শর্তসাপেক্ষে পাশ কাটানো। নিচের router x-beta header না পেলে next("router") ডেকে নিজে থেকে বেরিয়ে যায়, তাই app-এর পুরোনো route উত্তর দেয়:

const beta = express.Router();
beta.use((req, res, next) => (req.get("x-beta") ? next() : next("router")));
beta.get("/feed", (req, res) => res.send("নতুন feed\n"));

app.use(beta);
app.get("/feed", (req, res) => res.send("পুরোনো feed\n"));

$ curl -s localhost:47333/feed
পুরোনো feed
$ curl -s localhost:47333/feed -H 'x-beta: 1'
নতুন feed

পাশাপাশি আরও দুটি বিষয় খেয়াল করুন। app.use("/api", fn) path-এর শুরু মেলায়, আর app.get("/api/x", fn) পুরো path আর method মেলায়। আর mount করা middleware-এর ভেতরে req.url ছোট হয়ে যায়। সত্যিকারের run-এর log:

A all
B /api, req.url = /x baseUrl = /api
C route 1
D route 2

এখানে GET /api/x গিয়েছিল। Mount path বাদ দিয়ে req.url হয়েছে /x, তাই log-এ পুরো ঠিকানা চাইলে req.originalUrl লাগে। আর “C route 1” next("route") ডেকেছিল, তাই তার সঙ্গী ফাংশনটি বাদ পড়ে পরের route “D” চলেছে।

৪ · Built-in middleware — json, urlencoded আর static

Express-এর সঙ্গেই কয়েকটি middleware আসে। আলাদা body-parser package আর ইনস্টল করতে হয় না; express.json() ভেতরে সেটিই ব্যবহার করে।

express.json আর body-র সীমা

এটি request-এর body পড়ে JSON parse করে। মনে রাখবেন, Content-Type JSON না হলে সে কিছুই করে না। সত্যিকারের run-এ text/plain পাঠালে handler পেল {"bodyType":"undefined"}.

সীমা কেন? দোকানের কাউন্টারে কেউ ট্রাকভর্তি মাল ঢোকাতে চাইলে দরজাতেই থামানো সহজ। Body পড়তে memory আর CPU লাগে, তাই সীমার বাইরে হলে আগেই থামানো ভালো। ডিফল্ট সীমা 100kb, মানে 100 × 1024 = 102400 byte. বাজারঘরের order API-তে এত বড় JSON লাগে না, তাই পরীক্ষায় সীমা রাখা হলো 1kb (1024 byte), আর পাঠানো হলো 2014 byte:

app.use("/api", express.json({ limit: "1kb" }));

$ wc -c big.json
2014 big.json
$ curl -s -o /dev/null -w '%{http_code}\n' -X POST localhost:47326/api/orders \
    -H 'Authorization: Bearer example-token' \
    -H 'Content-Type: application/json' --data-binary @big.json
413

Server log-এ expected: 2014, limit: 1024, type: 'entity.too.large' ছিল। ভাঙা JSON পাঠালে entity.parse.failed সহ 400 আসে। দুটিই error পথে যায়, আর ডিফল্ট error পাতায় development mode-এ stack trace দেখা গেছে। পর্ব ২৮-এ এগুলোকে নিরাপদ JSON বার্তায় বদলাবেন।

express.urlencoded

সাধারণ HTML form ডিফল্টভাবে name=rina&age=20 আকারে ডেটা পাঠায়। এই middleware সেটি পড়ে। Express 5-এ extended ডিফল্ট false, তাই nested নাম ভাঙে না:

$ curl -s -X POST localhost:47326/form/deep --data 'user[name]=rina&a=1&a=2'
{"user[name]":"rina","a":["1","2"]}

Express 4-এর অনেক টিউটোরিয়াল extended: true ধরে নেয়, যেখানে user একটি object হতো। দরকার হলে নিজে থেকে চালু করতে হবে, আর তখন যাচাই আরও জরুরি (পর্ব ২৭)।

express.static

একটি folder-এর ফাইল সরাসরি পরিবেশন করে। Disk-এ ফাইল পেলে উত্তর পাঠিয়ে chain থামায়, না পেলে next() ডাকে। Express 5-এ dotfile ডিফল্টভাবে উপেক্ষিত, তাই লুকানো .env ফাইল থাকলেও পাওয়া যায় না:

$ curl -si localhost:47326/assets/site.css
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Content-Type: text/css; charset=utf-8
Content-Length: 15
…
$ curl -s -o /dev/null -w 'env: %{http_code}\n' localhost:47326/assets/.env
env: 404

তবু এই 404-এর ভরসায় .env static folder-এ রাখবেন না। Cache-Control: public, max-age=0 মানে ডিফল্টে প্রতিবার যাচাই হয়; maxAge option দিয়ে বদলানো যায়, যার হিসাব পর্ব ৮৪-তে।

৫ · CORS — আসলে কে কাকে আটকায়

পর্ব ০২-এ দেখেছেন, scheme, host আর port মিলে হয় একটি origin. বাজারঘরের React অ্যাপ চলে localhost:47327-এ, API চলে localhost:47326-এ। Port আলাদা, তাই origin আলাদা। Browser-এর same-origin policy বলে, একটি origin-এর JavaScript অন্য origin-এর উত্তর পড়তে পারবে না। CORS হলো server-এর দেওয়া একটি অনুমতিপত্র: “এই origin আমার উত্তর পড়তে পারে।”

সত্যিকারের cors package

import cors from "cors";

const allowed = ["http://localhost:47327"];
app.use("/api", cors({
  origin: allowed,
  credentials: true,
  methods: ["GET", "POST", "DELETE"],
  allowedHeaders: ["Content-Type", "Authorization"],
  maxAge: 600,
}));

এখন অজানা origin বসিয়ে curl চালাই (cors 2.8.6, সত্যিকারের run; এই পর্বের curl run-গুলোতে ঠিকানা আসলে ছিল 127.0.0.1):

$ curl -si localhost:47326/api/products -H 'Origin: http://evil.example'
HTTP/1.1 200 OK
Vary: Origin
Access-Control-Allow-Credentials: true
Content-Type: application/json; charset=utf-8
…

[{"id":1,"name":"চাল"}]

ডেটা চলে এসেছে! Access-Control-Allow-Origin header শুধু নেই। curl সেটি দেখেই না। কিন্তু Microsoft Edge 156-এ একই কাজ অজানা origin-এর পাতা থেকে করলে console-এ যা এলো:

Access to fetch at 'http://localhost:47326/api/products' from origin
'http://localhost:47329' has been blocked by CORS policy: No
'Access-Control-Allow-Origin' header is present on the requested resource.
JS: TypeError: Failed to fetch

আর server log বলছে, ঠিক সেই সময়ে:

handler চলল, products পাঠানো হচ্ছে
GET /api/products 200 0.8ms

Preflight — আসল অনুরোধের আগের প্রশ্ন

সাধারণ GET বা form-এর মতো POST আগে থেকেই ওয়েবে চলে আসছে, তাই browser সেগুলো সরাসরি পাঠায়। কিন্তু Content-Type: application/json, Authorization header, বা DELETE থাকলে browser আগে OPTIONS দিয়ে জিজ্ঞেস করে নেয়। একেই বলে preflight.

fetch("http://localhost:47326/api/orders", {
  method: "POST",
  credentials: "include",
  headers: { "Content-Type": "application/json",
             "Authorization": "Bearer example-token" },
  body: JSON.stringify({ item: "chal" }),
});

OPTIONS /api/orders HTTP/1.1
Origin: http://localhost:47327
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization,content-type

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:47327
Vary: Origin
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET,POST,DELETE
Access-Control-Allow-Headers: Content-Type,Authorization
Access-Control-Max-Age: 600

POST /api/orders HTTP/1.1
Origin: http://localhost:47327
Authorization: Bearer example-token
Content-Type: application/json

{"item":"chal"}

OPTIONS /api/orders 204 1.3ms
orders router: POST /
POST /api/orders 201 9.5ms
JS: status 201 {"by":7,"item":"chal"}

অজানা origin-এর ক্ষেত্রে cors তালিকা মেলাতে না পেরেও 204 দেয়, শুধু Allow-Origin header বাদ রাখে। সিদ্ধান্ত নেয় browser. নিচের ব্লকে সেই ধাপগুলো দেখুন। এটি শেখার মডেল: Node-এর fetch CORS মানে না, তাই browser-এর হিসাব হাতে লেখা।

// শেখার মডেল: node-এর fetch CORS মানে না, তাই browser-এর সিদ্ধান্ত হাতে লেখা
const http = require("node:http");
const ALLOWED = ["https://shop.example"];
let handlerRuns = 0;
const server = http.createServer((req, res) => {
  const origin = req.headers.origin;
  if (ALLOWED.includes(origin)) {
    res.setHeader("Access-Control-Allow-Origin", origin);
    res.setHeader("Vary", "Origin");
  }
  if (req.method === "OPTIONS") {
    res.setHeader("Access-Control-Allow-Methods", "GET,POST");
    return res.writeHead(204).end();
  }
  handlerRuns++;
  res.end("order saved");
});
async function browserModel(url, origin) {
  const pre = await fetch(url, { method: "OPTIONS", headers: { origin,
    "access-control-request-method": "POST" } });
  const allow = pre.headers.get("access-control-allow-origin");
  console.log(origin, "preflight:", pre.status, "allow-origin:", allow);
  if (allow !== origin) return console.log("  browser: আসল POST পাঠাল না");
  const r = await fetch(url, { method: "POST", headers: { origin } });
  console.log("  browser: POST গেল,", r.status, await r.text());
}
server.listen(0, "127.0.0.1", async () => {
  const url = `http://127.0.0.1:${server.address().port}/api/orders`;
  await browserModel(url, "https://shop.example");
  await browserModel(url, "https://other.example");
  console.log("handler মোট চলল:", handlerRuns);
  server.close();
});

https://shop.example preflight: 204 allow-origin: https://shop.example
  browser: POST গেল, 200 order saved
https://other.example preflight: 204 allow-origin: null
  browser: আসল POST পাঠাল না
handler মোট চলল: 1

Credentials আর *-এর নিয়ম

cors({ origin: "*", credentials: true }) লিখলে package আপত্তি করে না, দুটি header-ই পাঠায়। আপত্তি করে browser. credentials: "include" দিয়ে Edge-এ সত্যিকারের ফল:

Access to fetch at 'http://localhost:47326/open/ping' from origin
'http://localhost:47327' has been blocked by CORS policy: The value of the
'Access-Control-Allow-Origin' header in the response must not be the wildcard
'*' when the request's credentials mode is 'include'.

Credentials ছাড়া একই ঠিকানায় status 200 {"ok":true} এসেছে। নিয়মটির কারণ পরিষ্কার: ব্যবহারকারীর cookie-সহ উত্তর “যে কেউ পড়তে পারে”, এমন অনুমতি বিপজ্জনক। তবে এর চেয়েও খারাপ একটি পথ আছে, যা error দেয় না:

// cors({ origin: true, credentials: true })
$ curl -si localhost:47330/reflect/me -H 'Origin: http://evil.example'
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://evil.example
Vary: Origin
Access-Control-Allow-Credentials: true

origin: true যেকোনো origin ফিরিয়ে দেয়। Browser-এর *-নিষেধ পার হয়ে যায়, কিন্তু কার্যত সবাইকে cookie-সহ পড়ার অনুমতি দেয়। সবসময় জানা origin-এর একটি allowlist রাখবেন। আর dynamic origin ফেরত দিলে Vary: Origin থাকা চাই, যাতে একজনের জন্য cache করা উত্তর অন্যজন না পান। cors এটি নিজেই বসায়।

ক্রমের সত্যিকারের ফাঁদ: auth আগে, cors পরে

// ভুল: auth cors-এর আগে
app.use("/bad", requireAuth, cors({ origin: allowed, credentials: true }));

Token ঠিক থাকলেও Edge-এ এলো preflight error, আর server log-এ দেখা গেল OPTIONS /bad/orders 401 0.4ms. কারণ ধাপ ২-এই বলেছি: preflight-এ Authorization থাকে না। Auth তাকে 401 দিয়ে থামাল, cors পর্যন্ত যাওয়াই হলো না। সমাধান: cors আগে। একই কারণে rate limiter cors-এর আগে বসালে 429 উত্তরে CORS header থাকে না, আর browser-এ ব্যবহারকারী দেখবেন CORS error, আসল 429 নয়।

CORS error দেখলে কোথায় তাকাবেন

Browser-এর error-এর ভাষা দেখলেই অর্ধেক কাজ হয়ে যায়। DevTools-এর Network ট্যাবে OPTIONS অনুরোধটি খুলে নিচের তালিকা মেলান:

একটি ছোট বিষয়ও বহু সময় নষ্ট করে: http://localhost:5173 আর http://127.0.0.1:5173 আলাদা origin, আর শেষে / লেখা origin-ও তালিকায় মিলবে না। উত্তরের কোনো custom header JavaScript-কে পড়াতে চাইলে exposedHeaders option লাগে; ডিফল্টে অল্প কিছু header-ই পড়া যায়।

Preflight-এর খরচ — একটি হিসাব

ধরে নিই browser থেকে server-এর round trip 80 ms, আর একটি session-এ ৩টি আলাদা URL-এ মোট ৩০টি preflight-দরকারি অনুরোধ যায়। Preflight cache-এর key-তে URL থাকে, তাই প্রতিটি URL-এর জন্য আলাদা হিসাব।

• Cache কাজে না লাগলে: ৩০ × 80 ms = 2400 ms বাড়তি অপেক্ষা (মোট যোগফল)।
• ৬০০ সেকেন্ড cache থাকলে এবং সব অনুরোধ সেই সময়ের মধ্যে হলে: ৩ × 80 ms = 240 ms.
• সাশ্রয়: 2400 − 240 = 2160 ms, অর্থাৎ ৯০%.

এখানে 80 ms আর ৩০টি অনুরোধ অনুমান, মাপা ফল নয়। /api/orders/7 আর /api/orders/8 আলাদা URL, তাই পথে id থাকলে cache কম কাজে লাগে। Frontend আর API একই origin-এ রাখলে (যেমন reverse proxy দিয়ে) preflight-ই লাগে না।

৬ · helmet, compression আর rate limit — তিন দরকারি প্রতিবেশী

এগুলোর তত্ত্ব অন্য কোর্সে আছে। এখানে শুধু দেখব middleware হিসেবে কোথায় বসে, আর সত্যিকারের ফল কী।

helmet — security header

helmet নিজে কিছু আটকায় না; সে উত্তরে কিছু header বসায়, যা browser মানে। Helmet 8.3.0-এর ডিফল্টে আসা কয়েকটি header:

$ curl -si localhost:47326/safe/ping
HTTP/1.1 200 OK
Content-Security-Policy: default-src 'self';base-uri 'self';font-src 'self' https: data:;…
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 0
…

প্রতিটি header-এর অর্থ আর ধাপে ধাপে চালুর পথ আছে Web hardening পর্বে। CSP ভিত্তি আছে XSS ও CSP-তে। HTML পরিবেশন করা অ্যাপে ডিফল্ট CSP বাইরের script বা font আটকাতে পারে, তাই চালুর পর পাতা ঘুরে দেখা দরকার।

compression — উত্তর ছোট করা

৫০০টি পণ্যের JSON-এ সত্যিকারের ফল, compression 1.8.2:

plain 29393 bytes
gzip 1368 bytes

Vary: Accept-Encoding
Content-Encoding: gzip

হিসাব: 1368 ÷ 29393 = ০.০৪৬৫, অর্থাৎ আকার প্রায় ৪.৭%, কমেছে প্রায় ৯৫.৩%. এই অনুপাত ফোলানো, কারণ ৫০০টি সারি প্রায় একই লেখা। আসল ডেটায় কম হবে। gzip-এ CPU লাগে, তাই সামনে nginx বা CDN থাকলে অনেকে কাজটি সেখানেই করেন। ছোট উত্তর ডিফল্টে compress হয় না; সীমা 1kb.

express-rate-limit — গতি বাঁধা

একই ঠিকানা থেকে অনেকবার login চেষ্টা থামাতে rate limit লাগে। Express-এর চোখে এটি আর দশটি route-level middleware-এর মতোই:

import { rateLimit } from "express-rate-limit";

const loginLimiter = rateLimit({
  windowMs: 60_000, limit: 3,
  standardHeaders: "draft-8", legacyHeaders: false,
  message: { error: "অনেকবার চেষ্টা হয়েছে" },
});
app.post("/api/login", loginLimiter, loginHandler);

# একই ঠিকানায় চারবার POST (express-rate-limit 8.7.2)
HTTP/1.1 401 Unauthorized
RateLimit: "3-in-1min"; r=2; t=60
HTTP/1.1 401 Unauthorized
RateLimit: "3-in-1min"; r=1; t=60
HTTP/1.1 401 Unauthorized
RateLimit: "3-in-1min"; r=0; t=60
HTTP/1.1 429 Too Many Requests
RateLimit: "3-in-1min"; r=0; t=60
Retry-After: 60

r হলো বাকি চেষ্টা। চতুর্থবার handler চলেইনি। দুটি বাস্তব সতর্কতা:

• Proxy-র পেছনে: Client-এর IP না বুঝলে সবাই একই ঠিকানা মনে হয়। X-Forwarded-For এসেছে অথচ trust proxy সেট নেই দেখে package-টি সত্যিকারের run-এ ERR_ERL_UNEXPECTED_X_FORWARDED_FOR log করেছিল। Proxy-র সংখ্যা জেনে সঠিক মান দিতে হয়; অন্ধভাবে true নয়।
• একাধিক process: ডিফল্ট store প্রতিটি process-এর memory-তে থাকে। ৪টি process-এ সীমা ৪ গুণ হয়ে যায়, তাই ভাগ করা store লাগে (Redis, পর্ব ৪৪)।

কোথায় কত সীমা, quota কী, gateway-র ভূমিকা কী, এগুলো আছে API security আর DDoS প্রতিরক্ষা পর্বে। Login-এর পুরো নিয়ম পর্ব ৪৯-এ।

৭ · নিজের middleware — timer, logger আর auth

নিজের middleware লেখা মানে একটি ফাংশন লেখা। বাজারঘরের তিনটি সত্যিকারের নমুনা, যেগুলো এই পর্বের সব run-এ চলেছে:

import { performance } from "node:perf_hooks";

// ১. Timer + logger: উত্তর শেষে একটি লাইন লেখে
function requestTimer(req, res, next) {
  const start = performance.now();
  res.on("finish", () => {
    const ms = (performance.now() - start).toFixed(1);
    console.log(`${req.method} ${req.originalUrl} ${res.statusCode} ${ms}ms`);
  });
  next();
}

// ২. Router-এর নিজের logger
orders.use((req, res, next) => {
  console.log("orders router:", req.method, req.url);
  next();
});

// ৩. সহজ auth check, শেখার জন্য
function requireAuth(req, res, next) {
  const header = req.get("authorization");
  if (header !== "Bearer example-token") {
    return res.status(401).json({ error: "লগইন দরকার" });
  }
  req.user = { id: 7, role: "seller" };
  next();
}

orders.post("/", requireAuth, createOrder);

এবার ধাপে ধাপে দেখুন, token ছাড়া একটি অনুরোধে কী হয়।

1app.use(requestTimer);2app.use("/api", cors(options));3app.use("/api", express.json());4orders.post("/", requireAuth, createOrder);56function requireAuth(req, res, next) {7  if (header !== "Bearer example-token")8    return res.status(401).json({ ... });9  req.user = { id: 7, role: "seller" };10  next();11}

হাতে লেখা chain-এ একই আচরণ চালিয়ে দেখুন। এটিও শেখার মডেল, কিন্তু HTTP সত্যিকারের: node:http server নিজের সঙ্গে কথা বলছে।

// শেখার মডেল: node:http-এর ওপর হাতে লেখা chain, Express নয়
const http = require("node:http");

function timer(req, res, next) {
  const start = performance.now();
  res.on("finish", () => {
    const ms = performance.now() - start;
    console.log("timer:", req.method, req.url, res.statusCode, ms >= 20 ? ">=20ms" : "<20ms");
  });
  next();
}
function auth(req, res, next) {
  if (req.headers.authorization !== "Bearer example-token") {
    res.statusCode = 401;
    return res.end("login দরকার"); // chain এখানেই শেষ
  }
  req.user = { id: 7 };
  next();
}
function orders(req, res) {
  setTimeout(() => res.end("user " + req.user.id + " এর order"), 25); // database-এর ভান
}
const stack = [timer, auth, orders];
const server = http.createServer((req, res) => {
  let i = 0;
  (function next() { stack[i++]?.(req, res, next); })();
});
server.listen(0, "127.0.0.1", async () => {
  const url = `http://127.0.0.1:${server.address().port}/orders`;
  const a = await fetch(url);
  console.log("token ছাড়া:", a.status, await a.text());
  const b = await fetch(url, { headers: { authorization: "Bearer example-token" } });
  console.log("token সহ:", b.status, await b.text());
  server.close();
});

timer: GET /orders 401 <20ms
token ছাড়া: 401 login দরকার
timer: GET /orders 200 >=20ms
token সহ: 200 user 7 এর order

Option নেওয়া middleware — ফাংশন যে ফাংশন বানায়

express.json({ limit }) বা cors({...}) নিজে middleware নয়; তারা ডাকলে একটি middleware ফেরত দেয়। দর্জির কথা ভাবুন: মাপ নিয়ে তিনি একটি জামা বানান, আর সেই জামা ওই মাপেরই। নিজের কোডেও একই ধাঁচ:

function requireRole(role) {
  return function (req, res, next) {
    if (req.user?.role !== role) {
      return res.status(403).json({ error: "অনুমতি নেই" });
    }
    next();
  };
}

app.delete("/products/:id", requireAuth, requireRole("admin"), removeProduct);

# সত্যিকারের run; এখানে req.user একটি demo middleware বসিয়েছিল
$ curl -s -w ' [%{http_code}]\n' -X DELETE localhost:47333/products/5   # role: seller
{"error":"অনুমতি নেই"} [403]
$ curl -s -w ' [%{http_code}]\n' -X DELETE localhost:47333/products/5   # role: admin
 [204]

এখানে role মনে থাকে closure-এর কারণে। 401 মানে “আপনাকে চিনি না”, 403 মানে “চিনি, কিন্তু অনুমতি নেই”; এই দুটির বিস্তার পর্ব ৩৩-এ। ভুলে app.use(requireRole) লিখবেন না: Express তখন ফাংশন-বানানো ফাংশনটিকেই middleware ধরে ডাকবে, সে শুধু একটি ফাংশন ফেরত দেবে, আর request ঝুলে থাকবে।

৮ · ঝুলে থাকা request, দুইবার উত্তর আর async middleware

ভুলে যাওয়া next

function forgotNext(req, res, next) {
  console.log("forgotNext চলল, কিন্তু next ডাকেনি");
}
app.get("/stuck", forgotNext, (req, res) => res.json({ ok: true }));

$ curl -s --max-time 2 localhost:47326/stuck; echo "curl exit: $?"
curl exit: 28

# server log
forgotNext চলল, কিন্তু next ডাকেনি

কোনো error নেই, কোনো status নেই। Exit 28 মানে curl-এর নিজের timeout শেষ হয়েছে। Server log-এ timer-এর লাইনও নেই, কারণ উত্তর শেষ না হলে finish কখনো চলে না। ব্যবহারকারী শুধু ঘুরতে থাকা চিহ্ন দেখেন। এই ধরনের অনুরোধ connection আটকে রাখে, তাই জমতে থাকলে server-ও ভোগে।

সেজন্য টাইমারে close event-ও শোনা ভালো। সত্যিকারের পরীক্ষায় client সরে যেতেই close fired, writableFinished = false এসেছে, আর finish আসেনি। writableFinished দেখে অসম্পূর্ণ অনুরোধ আলাদা করা যায়। পর্ব ৮৩-এ এমন অনুরোধ monitoring-এ ধরবেন।

উল্টো ভুল: দুইবার উত্তর

উত্তর পাঠিয়ে আবার next() ডাকলে পরের ফাংশনও উত্তর পাঠাতে চায়। Client প্রথম উত্তর {"a":1} পেয়েছিল, কিন্তু server log-এ এলো:

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
    at ServerResponse.setHeader (node:_http_outgoing:642:11)
…

নিয়মটি সহজ: একটি request-এ উত্তর একবার। Middleware হয় উত্তর দেবে, নয় next() ডাকবে; সাধারণত দুটি একসঙ্গে নয়। তাই return res... লেখা ভালো অভ্যাস।

Express 5-এ async middleware

Express 4-এ async ফাংশনের ভেতরে throw করলে Express জানতেই পারত না, তাই প্রতিটি জায়গায় try/catch বা wrapper লাগত। Express 5-এ middleware বা handler একটি rejected promise ফেরত দিলে তা নিজে থেকেই next(err)-এ যায়।

async function loadShop(req, res, next) {
  await new Promise((r) => setTimeout(r, 5));
  if (req.query.shop === "bad") throw new Error("shop পাওয়া যায়নি");
  req.shop = { id: 1 };
  next();
}
app.get("/shop", loadShop, (req, res) => res.json(req.shop));

$ curl -s -w ' [%{http_code}]\n' localhost:47326/shop
{"id":1} [200]
$ curl -s -w ' [%{http_code}]\n' 'localhost:47326/shop?shop=bad'
<!DOCTYPE html> … <pre>Error: shop পাওয়া যায়নি … </pre> … [500]

Process পড়ে যায়নি, request ঝোলেনি, 500 এসেছে। Stack trace পাতায় দেখা যাচ্ছে কারণ এটি development; এই ডিফল্ট পাতা ব্যবহারকারীকে দেখানোর জন্য নয়। নিজের error middleware (err, req, res, next) আর নিরাপদ বার্তা আসছে পর্ব ২৮-এ। ভেতরের কৌশলটি মাত্র এক লাইনের। শেখার মডেলে দেখুন:

// শেখার মডেল: Express 5 ভেতরে যেভাবে rejected promise ধরে, তার ছোট রূপ
const http = require("node:http");
const routes = {
  "/ok": [async (req, res, next) => { req.shop = 1; next(); },
          (req, res) => res.end("shop " + req.shop)],
  "/boom": [async () => { throw new Error("shop পাওয়া যায়নি"); }],
  "/stuck": [(req, res, next) => { /* next ডাকতে ভুলে গেছে */ }],
};
const server = http.createServer((req, res) => {
  const stack = routes[req.url];
  let i = 0;
  const next = (err) => {
    if (err) {
      console.log("  server log:", err.message);
      res.statusCode = 500;
      return res.end("সার্ভারে সমস্যা");
    }
    const r = stack[i++]?.(req, res, next);
    if (r instanceof Promise) r.catch(next); // এই লাইনই আসল জিনিস
  };
  next();
});
server.listen(0, "127.0.0.1", async () => {
  const base = `http://127.0.0.1:${server.address().port}`;
  for (const path of ["/ok", "/boom", "/stuck"]) {
    try {
      const r = await fetch(base + path, { signal: AbortSignal.timeout(400) });
      console.log(path, "->", r.status, await r.text());
    } catch (e) {
      console.log(path, "-> উত্তর এলো না:", e.name);
    }
  }
  server.close();
});

/ok -> 200 shop 1
  server log: shop পাওয়া যায়নি
/boom -> 500 সার্ভারে সমস্যা
/stuck -> উত্তর এলো না: TimeoutError

৯ · AI-এর যুগে middleware

AI middleware লিখতে খুব পটু, কিন্তু তার শেখা ডেটার বড় অংশ Express 4-এর। আর CORS error দেখলে সে প্রায়ই সবচেয়ে চওড়া অনুমতি দিয়ে “সমাধান” করে। এই পর্বে নিচের প্রতিটি সমস্যা সত্যিই চালিয়ে দেখা হয়েছে বা Express 5-এর migration guide-এ মিলিয়ে নেওয়া হয়েছে।

AI-এর middleware হাতে পেলে যাচাইয়ের তালিকা

• package.json-এ Express-এর version দেখেছি, আর কোডটি সেই version-এর docs-এ মিলিয়েছি
• app.use-এর ক্রম পড়েছি: cors, parser, auth, route, error
• প্রতিটি middleware-এর সব পথে next() অথবা উত্তর আছে, দুটি একসঙ্গে নেই
• curl -X OPTIONS দিয়ে জানা ও অজানা দুই origin-ই পরীক্ষা করেছি
• Browser console-এ সত্যিকারের frontend থেকে অনুরোধ চালিয়ে দেখেছি, শুধু curl নয়
• Token ছাড়া, ভুল token-এ আর বড় body পাঠিয়ে 401 ও 413 দেখেছি
• নতুন package সত্যিই আছে কি না npm-এ দেখেছি, আর সেটি লাগে কি না ভেবেছি
• Log-এ token, cookie বা password যাচ্ছে না, আর AI-কে কোনো secret পাঠাইনি