gRPC আর GraphQL — Protocol Buffers, streaming আর schema-ভিত্তিক API

১ · REST-এর পরেও কেন নতুন API ধারা — over-fetching, under-fetching আর আলাপী অ্যাপ

পর্ব ০৮-এ (REST API নকশা) দেখেছেন, REST-এ প্রতিটি জিনিস একটি resource, প্রতিটির নিজের URL, আর HTTP-র method দিয়ে কাজ। পাবলিক API-র জন্য এটি চমৎকার: যেকোনো ভাষা, ব্রাউজার আর curl দিয়ে চালানো যায়, CDN সহজে cache করে। তবু দুটি জায়গায় REST-এর ঘর্ষণ চোখে পড়ে।

প্রথম জায়গা: সার্ভিসের সাথে সার্ভিসের কথা। একটি বড় অ্যাপের ভেতরে কয়েক ডজন microservice একে অপরকে প্রতি সেকেন্ডে হাজারো বার ডাকে। সেখানে প্রতিবার JSON লেখা আর পড়ার CPU খরচ, হাতে লেখা client কোড, আর “এই field-টা string না number?” জাতীয় ভুল জমতে জমতে বড় হয়। দরকার একটি টাইপ-করা চুক্তি — যা দুই পক্ষের কোড নিজে থেকেই মেনে চলে।

দ্বিতীয় জায়গা: মোবাইল অ্যাপের একটি পাতা। ধরুন একটি খাবার-ডেলিভারি অ্যাপের হোম স্ক্রিন (কাল্পনিক)। তাতে দেখাতে হবে ব্যবহারকারীর নাম আর wallet-এর টাকা, সাম্প্রতিক ৩টি অর্ডার, সুপারিশ করা ১০টি পণ্য, আর ৩টি অফার। চারটি তথ্য আসে চারটি আলাদা সার্ভিস থেকে। Resource ধরে বানানো REST API-তে দুটি সমস্যা দেখা দেয়:

• Over-fetching — দরকারের চেয়ে বেশি ডেটা আনা। GET /orders পুরো ২০টি অর্ডারের সব খুঁটিনাটি দেয়, অথচ পর্দায় লাগে ৩টির তিনটি field.
• Under-fetching — এক অনুরোধে যথেষ্ট না পাওয়া। GET /recommendations দেয় শুধু ১০টি পণ্যের id; নাম আর দাম জানতে আরও ১০টি অনুরোধ। একের ফলের ওপর অন্যটি নির্ভর করে বলে round trip বাড়ে।

সংখ্যায় দেখা যাক। মোবাইল নেটওয়ার্কে একটি round trip (RTT) ধরা যাক ১২০ ms; ডেটা সেন্টারের ভেতরে মাত্র ১ ms. নিচের হিসাবে পাঁচটি উপায়ের তুলনা — প্রতিটি সংখ্যা ধরা যাক, বদলে চালিয়ে দেখুন:

// Home screen = 4 services. Bytes and round trips under different API styles.
// EVERY number below is an assumption — change one and run again.
const RTT = 120;     // ms, phone <-> server round trip (mobile network)
const DC = 1;        // ms, round trip inside the data centre
const SVC = 30;      // ms, one service's own work per call
const BPMS = 500;    // bytes per ms the phone downloads (about 4 Mbit/s)
const HDR = 500;     // header bytes per request + response
const need = { profile: 300, orders: 3 * 120, products: 10 * 150, offers: 300 };
const useful = Object.values(need).reduce((a, b) => a + b, 0);   // what the screen shows

// waves = phone round trips one after another; inner = service waves behind one call
const restBody = 2400 + 20 * 850 + 400 + 10 * 1600 + 1800;  // full objects + id list
const styles = [
  ["REST one by one",   14, 14, 0, restBody],
  ["REST in parallel",  14,  2, 0, restBody],
  ["REST /home (BFF)",   1,  1, 2, useful + 100],
  ["GraphQL query",      1,  1, 2, useful + 100 + 700],   // + query text in the POST
  ["GraphQL persisted",  1,  1, 2, useful + 100 + 64],    // + a 64-char hash only
];
const pad = (s, n) => String(s).padStart(n);
console.log("useful bytes on screen: " + useful);
console.log("style              reqs  waves   bytes  useful%   time ms");
for (const [name, reqs, waves, inner, body] of styles) {
  const bytes = body + reqs * HDR;
  const ms = waves * (RTT + (inner ? 0 : SVC)) + inner * (DC + SVC) + bytes / BPMS;
  console.log(name.padEnd(18) + pad(reqs, 5) + pad(waves, 7) + pad(bytes, 8) +
    pad((100 * useful / bytes).toFixed(1), 9) + pad(ms.toFixed(0), 10));
}

useful bytes on screen: 2460
style              reqs  waves   bytes  useful%   time ms
REST one by one      14     14   44600      5.5      2189
REST in parallel     14      2   44600      5.5       389
REST /home (BFF)      1      1    3060     80.4       188
GraphQL query         1      1    3760     65.4       190
GraphQL persisted     1      1    3124     78.7       188

২ · RPC-র ধারণা — দূরের function যেন হাতের কাছের

REST ভাবে “জিনিস” (resource) দিয়ে; RPC (Remote Procedure Call) ভাবে “কাজ” দিয়ে। RPC-র স্বপ্নটা সরল: অন্য যন্ত্রে থাকা একটি function ডাকা হবে ঠিক নিজের প্রোগ্রামের function-এর মতো — order = orders.GetOrder("A-1029"). Network, বাইট আর সংযোগের ঝামেলা লুকিয়ে রাখে মাঝখানের একটি stub: সে argument-কে বাইটে বদলায় (serialization), পাঠায়, উত্তরের বাইট আবার object বানিয়ে ফেরত দেয়।

কিন্তু “কাছের মতো” ভাবাটাই বিপদ। ১৯৯৪ সালে Sun Microsystems-এর Jim Waldo ও সহকর্মীরা “A Note on Distributed Computing” লেখায় দেখান, দূরের call আর কাছের call মৌলিকভাবে আলাদা, আর পার্থক্য লুকালে ভুল নকশা হয়:

৩ · gRPC আর Protocol Buffers — আগে চুক্তি, তারপর কোড

gRPC একটি open-source RPC framework. Google ২০১৫ সালের দিকে এটি প্রকাশ্যে আনে; gRPC-র প্রকাশিত নকশা-নীতি অনুযায়ী এর পেছনে ছিল Google-এর ভেতরে বহু বছর ব্যবহৃত Stubby নামের RPC ব্যবস্থার অভিজ্ঞতা। এখন এটি Cloud Native Computing Foundation (CNCF)-এর একটি প্রকল্প। তিনটি জিনিস মিলে gRPC: চুক্তির ভাষা Protocol Buffers, চুক্তি থেকে code generation, আর পরিবহনে HTTP/2.

Protocol Buffers (সংক্ষেপে Protobuf) একটি IDL (Interface Definition Language) — সার্ভিস কী কী কাজ দেয় আর প্রতিটি বার্তার গঠন কী, তা ভাষা-নিরপেক্ষভাবে লেখার নিয়ম। Google-এর ভেতরে বহু বছর ব্যবহারের পর ২০০৮ সালে এটি open-source হয়। নিচে একটি কাল্পনিক খাবার-ডেলিভারি অ্যাপের অর্ডার সার্ভিসের চুক্তি:

syntax = "proto3";
package shop.v1;

import "google/protobuf/timestamp.proto";

service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);              // unary
  rpc WatchOrder (GetOrderRequest) returns (stream OrderUpdate); // server streaming
}

message GetOrderRequest {
  string order_id = 1;
}

enum OrderStatus {
  ORDER_STATUS_UNSPECIFIED = 0;   // proto3: the first value must be 0
  ORDER_STATUS_PLACED = 1;
  ORDER_STATUS_COOKING = 2;
  ORDER_STATUS_ON_THE_WAY = 3;
  ORDER_STATUS_DELIVERED = 4;
}

message Order {
  string order_id = 1;
  OrderStatus status = 2;
  int64 total_paisa = 3;          // money as whole paisa, never a float
  repeated LineItem items = 4;
  google.protobuf.Timestamp placed_at = 5;
}

message LineItem {
  string name = 1;
  int32 quantity = 2;
}

message OrderUpdate {
  OrderStatus status = 1;
  google.protobuf.Timestamp at = 2;
}

ফাইলটি পড়ার চাবি কয়েকটি:

• service আর rpc: সার্ভিস কোন কোন method দেয়, প্রতিটি কোন বার্তা নেয় আর কোনটি ফেরত দেয়। stream শব্দটি থাকলে সেই দিকে একাধিক বার্তা যাবে।
• Field number (= 1, = 2 …): তারে field-এর নাম যায় না, যায় এই নম্বর। তাই নাম বদলানো যায়, কিন্তু একবার ব্যবহৃত নম্বর আর কখনো অন্য অর্থে নয়; মুছে ফেলা field-এর নম্বর reserved করে রাখা ভালো অভ্যাস।
• টাকা পয়সায়, পূর্ণসংখ্যায়: int64 total_paisa — দশমিক ভগ্নাংশের (float) গোলমাল এড়াতে।

এবার protoc নামের compiler (সাথে ভাষাভিত্তিক plugin) এই একটি ফাইল থেকে Go, Java, Python, C++, Kotlin, TypeScript ইত্যাদি ভাষায় তৈরি করে দেয় বার্তার class, ক্লায়েন্টের stub আর সার্ভারের ফাঁকা কাঠামো। Go-তে লেখা অর্ডার সার্ভিসকে Kotlin-এর অ্যাপ সার্ভার বা Python-এর সুপারিশ সার্ভিস ডাকতে পারে, কারও হাতে client লিখতে হয় না। ভুল ধরনের field পাঠালে ভুলটা ধরা পড়ে compile-এর সময়েই, production-এ নয়।

তারে Protobuf বার্তা ছোট আর binary. ওপরের Order-এ order_id = "A-1029", status ৩ আর total ৪৫,০০০ পয়সা থাকলে Protobuf-এ লাগে মাত্র ১৪ বাইট; একই তথ্য JSON-এ — {"order_id":"A-1029","status":"ORDER_STATUS_ON_THE_WAY","total_paisa":45000} — ৭৬ বাইট। কারণ JSON প্রতিবার field-এর নাম লেখে, Protobuf শুধু ছোট নম্বর। দাম হলো চোখে পড়া যায় না; বাইটগুলো বুঝতে .proto ফাইল লাগে। বাইট কীভাবে সাজানো থাকে (varint, wire type), আর পুরোনো-নতুন সংস্করণ একসাথে চালানোর নিয়ম (schema evolution) — দুটিই বিস্তারিত আছে পর্ব ১২-এ (Data format আর serialization পর্বে)।

৪ · gRPC-র ভেতরে — HTTP/2 stream, চার ধরনের call, status code আর metadata

gRPC চলে HTTP/2-এর ওপর। HTTP/2-এ একটি TCP (সাথে TLS) সংযোগের — যাদের মূল কথা পর্ব ০৭-এ — ভেতরে অনেকগুলো স্বাধীন stream একসাথে চলে — একে বলে multiplexing; frame আর header compression-এর বিস্তারিত Computer Networks কোর্সের HTTP/2 আর HTTP/3 পর্বে। gRPC-র নিয়ম সরল: একটি call মানে একটি stream. নিচে একটি unary call-এর পুরো যাত্রা, তারের আসল বাইটসহ:

const order = await orderClient.getOrder(
  { orderId: "A-1029" },
  { deadline: Date.now() + 300 }   // ms
);

GetOrderRequest { order_id: "A-1029" }
0a 06 41 2d 31 30 32 39
0a = field 1, wire type 2 (দৈর্ঘ্যসহ)
06 = দৈর্ঘ্য ৬, তারপর "A-1029"

:method       POST
:scheme       https
:path         /shop.v1.OrderService/GetOrder
:authority    orders.internal
content-type  application/grpc
te            trailers
grpc-timeout  300m
x-request-id  7f3a9c

00            compressed? না
00 00 00 08   বার্তার দৈর্ঘ্য = 8
0a 06 41 2d 31 30 32 39

path    → OrderService.GetOrder
bytes   → GetOrderRequest{order_id:"A-1029"}
timeout → এখন + 300 ms, handler-এর context-এ
handler → DB থেকে অর্ডার পড়ল

HEADERS  :status 200
         content-type application/grpc
DATA     00 00 00 00 0e
         0a 06 41 2d 31 30 32 39
         10 03 18 c8 df 02
HEADERS  grpc-status 0   (trailers, END_STREAM)

grpc-status 0 = OK
Order { order_id: "A-1029",
        status: ON_THE_WAY, total_paisa: 45000 }
stream 1 বন্ধ; সংযোগ খোলা থাকে
পরের call: stream 3, 5, 7 …

চার ধরনের call

Length-prefixed বার্তা আর দীর্ঘস্থায়ী stream মিলে gRPC চার রকম call দেয়। .proto-তে কোন দিকে stream লেখা, তা-ই ঠিক করে ধরন:

Status code — ব্যর্থতার নির্দিষ্ট নাম

gRPC-র নিজের status code আছে, মোট ১৭টি (০ থেকে ১৬)। HTTP-র 404 বা 503-এর সাথে এদের গুলিয়ে ফেলবেন না — HTTP status সাধারণত 200-ই থাকে, আসল ফল grpc-status-এ। সবচেয়ে বেশি দেখা কয়েকটি:

Metadata — চিঠির খামের ওপরের লেখা

বার্তার বাইরে কিছু বাড়তি তথ্য যায় metadata-তে: key-value জোড়া, যা আসলে HTTP/2 header (শুরুতে) বা trailer (শেষে)। Key ছোট হাতের অক্ষরে; binary মান হলে key-এর শেষে -bin. সাধারণ ব্যবহার: পরিচয়ের token (authorization), প্রতিটি অনুরোধের id, আর distributed tracing-এর header (observability, পর্ব ৫০)। ডাকঘরের চিঠির মতো — ভেতরের চিঠি (message) পড়ে প্রাপক, খামের ওপরের ঠিকানা আর সিল (metadata) দেখে ডাকঘরের প্রতিটি হাত।

৫ · gRPC-কে production-এ টেকানো — deadline, cancellation, load balancing আর ব্রাউজার

Deadline আর cancellation: সময়সীমা পুরো শিকলে

Timeout বলে “আমি কতক্ষণ অপেক্ষা করব”; deadline বলে “কোন মুহূর্তের পরে উত্তরের আর দাম নেই”। পার্থক্যটা বোঝা যায় শিকলে। ক্লায়েন্ট ৩০০ ms অপেক্ষা করবে; A ডাকে B-কে, B ডাকে C-কে। ক্লায়েন্ট হাল ছাড়ার পরেও যদি B আর C কাজ করে যায়, সেই কাজের ফল কেউ নেবে না। পর্ব ০৪-এ (Latency, throughput আর percentile) যে deadline propagation-এর কথা এসেছিল, gRPC তা প্রায় নিজে থেকেই করে: প্রতিটি সার্ভিস বাকি সময়টা পরের call-এর grpc-timeout-এ পাঠায়। আর ক্লায়েন্ট call বাতিল করলে বা সময় ফুরালে সার্ভার সেই খবর পায় (cancellation); handler-এর context বাতিল হয়, আর সেই context দিয়ে করা নিচের call-গুলোও বাতিল হয়। Go-তে context, Java-তে Context এ কাজ সহজ করে; ভাষা আর library-ভেদে খুঁটিনাটি আলাদা।

নিচের simulator একটি শিকল চালায়: ক্লায়েন্ট → A (BFF) → B (অর্ডার) → C (stock সার্ভিস)। C ধীর — তার ২৫০ ms লাগে। তিনটি নীতি: none — সার্ভিসগুলো ক্লায়েন্টের সময়সীমা জানে না; propagate — সবাই জানে, সময় ফুরালেই থামে; early — জানে, আর হাতে যথেষ্ট সময় না থাকলে কাজ শুরুই করে না।

// client -> A -> B -> C, 300 ms client deadline. Model: one shared absolute deadline, 5 ms hops.
const DEADLINE = 300, HOP = 5;
const svc = [{ name: "A (BFF)", pre: 40, post: 20 }, { name: "B (orders)", pre: 60, post: 30 },
             { name: "C (stock)", pre: 250, post: 0 }];   // pre = work before calling the next
function run(policy) {             // "none" | "propagate" | "early" (= propagate + early reject)
  const work = [0, 0, 0], notes = []; let late = 0;   // late = work after the client gave up
  const busy = (i, from, ms) => {
    let end = from + ms;
    if (policy !== "none") end = Math.min(end, Math.max(from, DEADLINE));   // stop at deadline
    work[i] += end - from; late += Math.max(0, end - Math.max(from, DEADLINE));
    return end;
  };
  const expired = (i, t) => {
    if (policy === "none" || t < DEADLINE) return false;
    notes.push(`${svc[i].name} DEADLINE_EXCEEDED at ${t}`); return true;
  };
  const call = (i, t) => {         // the request reaches service i at time t
    const s = svc[i], left = DEADLINE - t;
    if (policy === "early" && left < s.pre + s.post) {
      notes.push(`${s.name} rejects at ${t} (needs ${s.pre + s.post}, has ${left})`); return { t, ok: false };
    }
    let now = busy(i, t, s.pre);
    if (expired(i, now)) return { t: now, ok: false };
    if (i + 1 === svc.length) return { t: now, ok: true };
    const r = call(i + 1, now + HOP);
    if (!r.ok) return { t: Math.min(r.t + HOP, DEADLINE), ok: false };
    now = busy(i, r.t + HOP, s.post);
    return expired(i, now) ? { t: now, ok: false } : { t: now, ok: true };
  };
  const r = call(0, HOP), at = Math.min(r.t + HOP, DEADLINE), ok = r.ok && r.t + HOP <= DEADLINE;
  console.log(`${policy.padEnd(9)} client ${ok ? "OK" : "DEADLINE_EXCEEDED"} at ${ok ? r.t + HOP : at} ms`
    + ` | work A/B/C ${work.join("/")} = ${work[0] + work[1] + work[2]} | after give-up ${late}`);
  notes.forEach((n) => console.log("          " + n));
}
["none", "propagate", "early"].forEach(run);

none      client DEADLINE_EXCEEDED at 300 ms | work A/B/C 60/90/250 = 400 | after give-up 115
propagate client DEADLINE_EXCEEDED at 300 ms | work A/B/C 40/60/185 = 285 | after give-up 0
          C (stock) DEADLINE_EXCEEDED at 300
early     client DEADLINE_EXCEEDED at 130 ms | work A/B/C 40/60/0 = 100 | after give-up 0
          C (stock) rejects at 115 (needs 250, has 185)

দীর্ঘস্থায়ী HTTP/2 সংযোগ আর load balancing-এর ফাঁদ

HTTP/2-এর শক্তি — একটি সংযোগে হাজারো call — load balancing-এ সমস্যা তৈরি করে। একটি L4 (TCP-স্তরের) load balancer ভাগ করে সংযোগ, call নয়। ক্লায়েন্ট একবার সংযোগ খুলে রাখলে তার সব call চিরকাল একই সার্ভারে যায়; নতুন সার্ভার যোগ হলেও পুরোনো সংযোগের ভার সরে না। Kubernetes-এর সাধারণ Service-এও একই কারণে একটি gRPC সংযোগ একটি Pod-এ আটকে থাকে (Computer Networks কোর্সের Cloud আর container নেটওয়ার্কিং পর্বে আছে)। প্রচলিত তিনটি সমাধান:

• L7 proxy: HTTP/2 বোঝে এমন proxy (যেমন Envoy) প্রতিটি call আলাদাভাবে বিভিন্ন সার্ভারে পাঠায়।
• Client-side load balancing: ক্লায়েন্ট নিজেই সব সার্ভারের ঠিকানা জেনে প্রত্যেকের সাথে সংযোগ রাখে আর call ঘুরিয়ে পাঠায় (gRPC-তে round_robin নীতি; ডিফল্ট নীতি সাধারণত pick_first, যা একটিতেই যায়)।
• সংযোগের বয়সসীমা: সার্ভার নির্দিষ্ট সময় পরপর ক্লায়েন্টকে নতুন সংযোগ খুলতে বলে (max connection age), যাতে ভার আবার ছড়ায়।

L4 আর L7-এর বিস্তারিত পর্ব ১৪-এ (load balancing), আর service discovery ও service mesh পর্ব ৪৭-এ (monolith বনাম microservices পর্বে)।

ব্রাউজার আর gRPC-Web

ব্রাউজারের JavaScript সরাসরি HTTP/2-এর frame নিয়ন্ত্রণ করতে পারে না, আর response-এর trailer পড়ার নির্ভরযোগ্য উপায়ও নেই — অথচ gRPC-র ফল থাকে trailer-এ। তাই ব্রাউজারের জন্য আছে gRPC-Web: একটু ভিন্ন একটি protocol, যা সাধারণত মাঝখানের একটি proxy (যেমন Envoy-এর gRPC-Web filter) আসল gRPC-তে বদলে দেয়। লেখার সময়ে gRPC-Web-এ unary আর server streaming চলে; client streaming আর bidirectional চলে না (সংস্করণভেদে আলাদা হতে পারে, ডকুমেন্টেশন দেখে নিন)। ব্রাউজারের দিকে দুই দিকের real-time যোগাযোগের প্রচলিত পথ WebSocket — পর্ব ১০-এ (Real-time যোগাযোগ)।

৬ · GraphQL — ক্লায়েন্ট নিজেই বলে দেয় ঠিক কী চাই

GraphQL একটি query ভাষা আর API-র নিয়ম। Facebook-এ ২০১২ সালের দিকে মোবাইল অ্যাপের news feed-এর জন্য এর জন্ম, আর ২০১৫ সালে এর spec আর একটি reference implementation প্রকাশ্যে আসে; এখন এটি Linux Foundation-এর অধীনের GraphQL Foundation-এ। মূল ভাবনা: সার্ভার একটি টাইপ-করা schema-তে জানায় কী কী পাওয়া যায়, আর ক্লায়েন্ট একটি query-তে লিখে দেয় ঠিক কোন field চাই — উত্তরের আকার হুবহু query-র আকারের মতো।

type Query {
  me: User!
  recommendations(first: Int = 10): [Product!]!
  offers(first: Int = 3): [Offer!]!
}

type Mutation {
  placeOrder(input: PlaceOrderInput!): Order!
}

type Subscription {
  orderStatusChanged(orderId: ID!): Order!
}

type User {
  id: ID!
  name: String!
  avatarUrl: String
  walletPaisa: Int!
  recentOrders(first: Int = 3): [Order!]!
}

type Order   { id: ID!  status: OrderStatus!  totalPaisa: Int! }
type Product { id: ID!  name: String!  pricePaisa: Int!  thumbnailUrl: String }
type Offer   { id: ID!  title: String!  discountPercent: Int! }
enum OrderStatus { PLACED COOKING ON_THE_WAY DELIVERED }

input PlaceOrderInput {
  restaurantId: ID!
  productIds: [ID!]!
  idempotencyKey: String!
}

! মানে মান কখনো ফাঁকা (null) হবে না; [Product!]! মানে পণ্যের একটি তালিকা, যা নিজেও null নয়, ভেতরের কোনোটিও নয়। তিনটি বিশেষ টাইপ তিন রকম কাজের দরজা: Query — পড়া; mutation — লেখা বা বদলানো; subscription — কিছু বদলালেই সার্ভার থেকে খবর, সাধারণত WebSocket-এর ওপর (পর্ব ১০)। এবার হোম স্ক্রিনের পুরো চাহিদা একটি query-তে:

query HomeScreen {
  me {
    name
    walletPaisa
    recentOrders(first: 3) { id status totalPaisa }
  }
  recommendations(first: 10) { id name pricePaisa }
  offers { title discountPercent }
}

# answer (trimmed): same shape as the query, nothing extra
{
  "data": {
    "me": {
      "name": "Nusrat",
      "walletPaisa": 125000,
      "recentOrders": [ { "id": "A-1029", "status": "ON_THE_WAY", "totalPaisa": 45000 } ]
    },
    "recommendations": [ { "id": "p7", "name": "Kacchi biryani", "pricePaisa": 32000 } ],
    "offers": [ { "title": "Free delivery", "discountPercent": 100 } ]
  }
}

এক অনুরোধ, এক round trip, আর কোনো বাড়তি field নেই — অংশ ১-এর over-fetching আর under-fetching দুটোরই উত্তর। নতুন একটি স্ক্রিনের ভিন্ন field লাগলে সার্ভারে নতুন endpoint লাগে না; ক্লায়েন্ট শুধু query বদলায়। লেখার উদাহরণ: mutation { placeOrder(input: {...}) { id status } } — এখানেও ফেরত কোন field আসবে, ক্লায়েন্ট বলে দেয়। Mutation-এ retry নিরাপদ রাখতে idempotencyKey-এর মতো field দেওয়া ভালো (পর্ব ০৮ আর পর্ব ৩৪)।

Resolver — প্রতিটি field-এর পেছনে একটি ছোট function

সার্ভার query পেলে প্রথমে schema মিলিয়ে যাচাই করে, তারপর গাছের মতো ওপর থেকে নিচে নামে। প্রতিটি field-এর জন্য একটি resolver function চলে: Query.me প্রোফাইল সার্ভিস থেকে ব্যবহারকারী আনে, User.recentOrders অর্ডার সার্ভিস ডাকে, Query.recommendations সুপারিশ সার্ভিস ডাকে। ফলে GraphQL সার্ভার হয়ে ওঠে অনেক সার্ভিসের সামনের একটি সমন্বয়ের জায়গা — অনেকটা রেস্তোরাঁর ওয়েটারের মতো, যিনি একটি অর্ডার-স্লিপ নিয়ে রান্নাঘরের তিন কাউন্টার থেকে তিনটি পদ এনে এক থালায় সাজান।

৭ · N+1 query সমস্যা আর DataLoader-এর batching

Resolver-এর সরলতা একটি লুকানো ফাঁদ তৈরি করে। Query: “৫টি post আর প্রতিটির লেখকের নাম।” Query.posts একটি query চালায়; তারপর প্রতিটি post-এর জন্য Post.author আলাদা করে চলে, প্রতিবার নিজের query নিয়ে। মোট ১ + ৫ = ৬ — একে বলে N+1 query সমস্যা. ১০০টি post হলে ১০১টি query. ধাপে ধাপে দেখুন:

Query: { posts: () => db.posts(5) }
Post:  { author: (post) =>
           db.user(post.authorId) }

Query: { posts: () => db.posts(5) }
Post:  { author: (post, args, ctx) =>
           ctx.userLoader.load(post.authorId) }
// userLoader = new DataLoader(ids => db.usersIn(ids))

একই ঘটনা কোডে, সত্যিকারের query log-সহ:

// query { posts(first: 5) { title author { name } } } — two ways to resolve it.
const users = { 1: "Rahim", 2: "Nusrat", 3: "Tanvir" };
const posts = [[101, "Metro rail tips", 1], [102, "Ferry schedule", 2],
  [103, "Rickshaw fares", 1], [104, "Eid bus tickets", 3], [105, "Load-shedding", 2]];
let log = [];
const db = {
  posts: (n) => { log.push(`SELECT * FROM posts LIMIT ${n}`); return posts.slice(0, n); },
  user: (id) => { log.push(`SELECT * FROM users WHERE id = ${id}`); return { name: users[id] }; },
  usersIn: (ids) => { log.push(`SELECT * FROM users WHERE id IN (${ids.join(", ")})`);
    return ids.map((id) => ({ name: users[id] })); },   // same order as ids
};
// Naive resolvers: Post.author runs once per post, each with its own query.
const naive = () => db.posts(5).map(([, title, aid]) => ({ title, author: db.user(aid).name }));
// DataLoader-style: load() only notes the key; dispatch() runs ONE batch for all keys.
function makeLoader(batchFn) {
  const waiting = new Map();                      // key -> callbacks (duplicates merge)
  return {
    load(key, cb) { if (!waiting.has(key)) waiting.set(key, []); waiting.get(key).push(cb); },
    dispatch() { const keys = [...waiting.keys()], rows = batchFn(keys);
      keys.forEach((k, i) => waiting.get(k).forEach((cb) => cb(rows[i]))); waiting.clear(); },
  };
}
function batched() {
  const authors = makeLoader(db.usersIn);         // a new loader for every request
  const out = db.posts(5).map(([, title, aid]) => {
    const row = { title, author: null };
    authors.load(aid, (u) => { row.author = u.name; }); return row;
  });
  authors.dispatch(); return out;    // real DataLoader dispatches at the end of the tick
}
for (const [name, fn] of [["naive resolvers", naive], ["DataLoader-style", batched]]) {
  log = []; const result = fn();
  console.log(`${name}: ${log.length} queries`); log.forEach((q) => console.log("   " + q));
  console.log("   result[3] = " + JSON.stringify(result[3]));
}

naive resolvers: 6 queries
   SELECT * FROM posts LIMIT 5
   SELECT * FROM users WHERE id = 1
   SELECT * FROM users WHERE id = 2
   SELECT * FROM users WHERE id = 1
   SELECT * FROM users WHERE id = 3
   SELECT * FROM users WHERE id = 2
   result[3] = {"title":"Eid bus tickets","author":"Tanvir"}
DataLoader-style: 2 queries
   SELECT * FROM posts LIMIT 5
   SELECT * FROM users WHERE id IN (1, 2, 3)
   result[3] = {"title":"Eid bus tickets","author":"Tanvir"}

৮ · GraphQL-এর দাম — caching, query-র খরচ আর federation

Caching কেন কঠিন

REST-এ GET /products/p7-এর উত্তর URL ধরে CDN, proxy আর ব্রাউজার নিজে থেকেই cache করে। GraphQL-এ সাধারণত সব অনুরোধ যায় একটিই ঠিকানায় — POST /graphql — আর আসল প্রশ্ন থাকে body-তে। HTTP cache URL দেখে চেনে, body নয়; আবার একই ডেটার দুটি query সামান্য ভিন্ন হলেই উত্তরও ভিন্ন। প্রচলিত উপায়গুলো:

• Persisted query: query-গুলো আগে থেকে সার্ভারে নিবন্ধিত থাকে; ক্লায়েন্ট পাঠায় শুধু তার id বা hash, প্রায়ই GET দিয়ে, যেমন GET /graphql?id=HomeScreen_v3&variables=…. এখন URL দিয়েই চেনা যায়, তাই CDN cache করতে পারে; বাইটও কমে। ঠিক রূপ টুলভেদে আলাদা (যেমন Apollo-র ধরনে query-র SHA-256 hash যায়)।
• ক্লায়েন্টের ভেতরের cache: Apollo Client বা Relay-এর মতো library উত্তর ভেঙে টাইপ আর id ধরে সাজিয়ে রাখে, তাই অন্য স্ক্রিনে একই অর্ডার আবার আনতে হয় না।
• সার্ভারের ভেতরে: resolver-এর পেছনে সাধারণ cache (পর্ব ২৮–৩০)।

নিরাপত্তা: একটি query কতটা ভারী হতে পারে

REST-এ একটি endpoint কতটা কাজ করবে, সার্ভার জানে। GraphQL-এ ক্লায়েন্ট যা খুশি জোড়া লাগাতে পারে — “প্রতিটি বন্ধুর প্রতিটি বন্ধুর প্রতিটি post-এর সব মন্তব্য” — এক লাইনের একটি query সার্ভারের লাখো সারি টেনে আনতে পারে। এটা ইচ্ছাকৃত হোক বা ভুলে, সুরক্ষা সার্ভারের দায়িত্ব:

উদাহরণ: GitHub-এর পাবলিক GraphQL API-র প্রকাশিত ডকুমেন্টেশন অনুযায়ী প্রতিটি query-র একটি point-খরচ হিসাব হয়, আর প্রতিটি ব্যবহারকারীর নির্দিষ্ট সময়ে point-এর বাজেট থাকে — ঠিক এই cost analysis-এর বাস্তব রূপ (সীমার সংখ্যা সময়ে সময়ে বদলায়)।

অনেক দল, একটি graph — federation

একটি GraphQL সার্ভারে সব schema রাখলে সেটি একটি বড় বাধা হয়ে দাঁড়ায় — প্রতিটি দলের পরিবর্তন একই কোডে। Federation-এ প্রতিটি দল নিজের অংশের schema (subgraph) নিজের সার্ভিসে রাখে, আর সামনের একটি gateway বা router সব মিলিয়ে একটি graph দেখায় আর query ভাগ করে ঠিক সার্ভিসে পাঠায়। Apollo ২০১৯ সালের দিকে এই ধারণা জনপ্রিয় করে। সামনের দরজার এই ভূমিকা — gateway, BFF — পর্ব ১১-এ (Reverse proxy, API gateway আর BFF), আর দলের সীমানা অনুযায়ী সার্ভিস ভাগ পর্ব ৪৭-এ।

৯ · তিনটির তুলনা আর একটি নকশা — চার সার্ভিসের হোম স্ক্রিন

এবার অংশ ১-এর হোম স্ক্রিনে ফিরি এবং simulator-এর সংখ্যা ধরে একটি সিদ্ধান্তে পৌঁছাই। প্রতিটি ধাপে কোন বিকল্প বিবেচনায়, তা আলোকিত:

১০ · AI-এর যুগে API style বাছাই — খসড়া AI-র, যাচাই আপনার

“আমাদের অ্যাপের জন্য gRPC না GraphQL?” — AI-কে জিজ্ঞেস করলে আত্মবিশ্বাসী উত্তর আসে, প্রায়ই সুন্দর তুলনার টেবিলসহ। কিন্তু এই বিষয়ে কয়েকটি ভুল বারবার দেখা যায়:

AI-এর প্রস্তাব নেওয়ার আগে — চেকলিস্ট

• ক্লায়েন্ট কারা আর কতগুলো স্ক্রিন — এই প্রশ্নের উত্তর থেকে API style এসেছে, ফ্যাশন থেকে নয়
• round trip আর বাইট নিজে বা simulator-এ আবার গুনেছি
• প্রতিটি call-এ deadline আছে, আর তা নিচের সার্ভিসে যায়
• resolver-এর query log দেখে N+1 নেই নিশ্চিত হয়েছি
• status code, message-এর সীমা আর ব্রাউজার-সমর্থন অফিশিয়াল ডকুমেন্টেশনে মিলিয়েছি
• একটি সার্ভিস বন্ধ ধরে failure-mode review করেছি — পাতা আংশিক হলেও খোলে কি না