REST vs RPC vs GraphQL

সমস্যাটা কী?

তোমার mobile app আর backend server কথা বলবে। App বলবে "এই user-এর তথ্য দাও", "নতুন order তৈরি করো"। এই কথা বলার নিয়ম-কানুনকেই বলে API design।

কিন্তু API বানানোর একাধিক ধরন আছে, আর প্রতিটার দর্শন আলাদা:

1. REST — সবকিছুকে "resource" হিসেবে দেখে, URL ও HTTP method দিয়ে কাজ করে।
2. RPC / gRPC — দূরের server-এ একটা function কল করার মতো করে কাজ করে।
3. GraphQL — একটা query language, client ঠিক যা চায় তা-ই চেয়ে নেয়।

ভুল বাছাই করলে হয় API ধীর হয়, নয়তো অকারণে জটিল। চলো তিনটে বুঝি।

প্রথমটা: REST

REST (Representational State Transfer)-এর মূল ধারণা: সবকিছু একটা resource, আর প্রতিটা resource-এর একটা URL আছে। কাজ কী হবে তা ঠিক করে HTTP method:

• GET /users/123 → ১২৩ নম্বর user-কে এনে দাও।
• POST /users → নতুন user বানাও।
• PUT /users/123 → আপডেট করো। DELETE /users/123 → মুছে দাও।

সুবিধা:

• সহজ ও সর্বজনীন। HTTP-র ওপর, browser/মোবাইল/যেকোনো ভাষা সহজে ব্যবহার করে। Public API-র জন্য আদর্শ।
• পড়তে সহজ, cache করা সহজ, debugging সহজ।

অসুবিধা:

• Over-fetching ও Under-fetching। Over-fetching = দরকারের চেয়ে বেশি data আসা (শুধু নাম চাই, কিন্তু পুরো user object এল)। Under-fetching = এক call-এ কম পড়ে, তাই একাধিক call দিতে হয় (user, তারপর তার order, তারপর প্রতিটা order-এর item — তিন ধাপ)।
• জটিল সম্পর্কিত data টানতে অনেকগুলো round-trip লাগে।

দ্বিতীয়টা: RPC / gRPC এবং GraphQL

RPC / gRPC

RPC (Remote Procedure Call)-এর দর্শন: resource নিয়ে না ভেবে সরাসরি একটা action/function কল করো — যেন function-টা তোমার নিজের code-এ আছে, কিন্তু আসলে চলছে দূরের server-এ। যেমন getUser(123) বা createOrder(...)।

gRPC হলো Google-এর জনপ্রিয় আধুনিক RPC framework। এটা data পাঠায় compact binary ফরম্যাটে (Protocol Buffers), JSON text-এর চেয়ে অনেক ছোট ও দ্রুত।

• সুবিধা: খুব দ্রুত, কম latency, কড়া contract (কোন function কী নেয়/দেয় আগে থেকে নির্ধারিত), streaming সমর্থন।
• অসুবিধা: browser থেকে সরাসরি ব্যবহার করা কঠিন, binary বলে চোখে পড়ে না (debug কম সহজ), শেখার বাড়তি ধাপ।

GraphQL

GraphQL একটা query language। এখানে সাধারণত একটাই endpoint, আর client নিজে বলে দেয় তার ঠিক কোন field দরকার:

{ user(id: 123) { name orders { total } } }

এতে যা চাইবে ঠিক ততটুকুই আসবে — তাই over-fetching নেই; আর এক query-তেই user + তার order একসাথে — তাই under-fetching/বহু round-trip নেই।

• সুবিধা: client-এর নিয়ন্ত্রণে নমনীয় query, over/under-fetching কমে, এক request-এ সম্পর্কিত data।
• অসুবিধা: server-এ বানানো ও cache করা জটিল, দুষ্ট query খুব ভারী হতে পারে, ছোট API-র জন্য overkill।

পাশাপাশি তুলনা

কখন কোনটা বেছে নেবে

• REST — public API, সাধারণ CRUD, যেখানে সরলতা ও সহজ caching দরকার। সন্দেহ থাকলে এটাই নিরাপদ ডিফল্ট।
• gRPC — internal microservice-দের নিজেদের মধ্যে কথা, যেখানে গতি ও কম latency সবচেয়ে জরুরি।
• GraphQL — যখন client (বিশেষত mobile) ভিন্ন ভিন্ন রকম data চায় আর over/under-fetching বড় সমস্যা।

বাস্তব উদাহরণ

• Stripe, Twitter, GitHub-এর public API মূলত REST — সহজ, সর্বজনীন, ব্যাপকভাবে ব্যবহৃত (GitHub-এর GraphQL API-ও আছে)।
• Google ও Netflix internal microservice যোগাযোগে gRPC ব্যবহার করে — হাজার হাজার service-এর মধ্যে দ্রুত call দরকার বলে।
• Facebook GraphQL তৈরিই করেছিল mobile app-এর জন্য, যাতে ধীর network-এ ঠিক প্রয়োজনীয় data এক request-এ আসে; GitHub-ও এটা public API-তে এনেছে।