সপ্তাহ ১-এর API-টা এখনো খেলনা পর্যায়ের - আলাদা আলাদা সহজ query। আজ সেটাকে আসল কাজের চেহারা দেবেন: এমন endpoint, যেখানে একসাথে অনেকগুলো ধারণা লাগে - join বা include, filter, হিসাব, pagination। ঠিক যেমন আসল project-এ হয়।
আজকের লক্ষ্য - Order list endpoint
একটা order list বানান যেখানে প্রতিটা order-এর সাথে তার user-এর নাম, items-এর তালিকা আর মোট টাকা আসবে। সাথে থাকবে status দিয়ে filter, তারিখের range, আর pagination। এই একটা endpoint বানাতে গেলেই দেখবেন এই সপ্তাহের প্রায় সব শেখা কাজে লাগছে:
- Relation একসাথে আনা - N+1 ছাড়া (include বা JOIN)
- Filter - status, তারিখ, user ধরে WHERE শর্ত
- Total হিসাব - হয় database দিয়ে SUM, নয়তো সংরক্ষিত total field
- যেই column দিয়ে filter হচ্ছে, সেটায় index আছে কিনা যাচাই
- অর্ডার তৈরির পুরো flow transaction-এর ভিতরে
// Prisma দিয়ে এক টানে
const orders = await prisma.order.findMany({
where: {
status: status ?? undefined,
createdAt: { gte: from, lte: to },
},
include: { user: { select: { name: true } }, items: true },
orderBy: { createdAt: "desc" },
skip: (page - 1) * limit,
take: limit,
});লক্ষ্য করুন - select দিয়ে user-এর শুধু নামটাই আনা হয়েছে, পুরো user object না। যা লাগবে না তা আনবেন না - এটাও performance-এরই অংশ। শেষে নিজেকে যাচাই করুন: এই endpoint-টা ১০ লাখ order হলেও কি টিকবে? Index ঠিক আছে তো? Query সংখ্যা মেপেছেন তো?
সবাই যে ভুলটা করে
সব data এনে কোডে filter করা। 'আগে সব order এনে তারপর JavaScript দিয়ে status মেলাব' - data ছোট থাকলে এটা চলে, বড় হলেই শেষ। Filter সবসময় database-এর কাছে - সেই জন্যই WHERE আর $match আছে।
আজকের Practice
উপরের order list endpoint-টা পুরোপুরি বানান - filter, pagination, relation সহ। তারপর সপ্তাহের তিনটা interview প্রশ্ন মুখে বলুন: N+1 query কী আর ঠিক করবেন কীভাবে, SQL vs NoSQL কখন কোনটা, index বেশি হলে কী ক্ষতি।
Interview-এ কীভাবে বলবেন
নিজেকে যাচাই করুন: 'জটিল query-তে আমি প্রথমে ভাবি কোন data একসাথে লাগবে, filter database-এর কাছেই দিই, relation include করে N+1 এড়াই, আর যেই column দিয়ে filter হচ্ছে সেটায় index রাখি। তারপর EXPLAIN বা query log দিয়ে অনুমানটা যাচাই করি।'