gRPC ও Protocol Buffers
- ●gRPC হলো HTTP/2-র উপর চলা একটি দ্রুত RPC framework, যেখানে দূরের function-কে local-এর মতো call করা যায়।
- ●Protocol Buffers data-কে compact binary-তে serialize করে, যা JSON-এর চেয়ে ছোট ও দ্রুত।
- ●.proto file একটি কঠোর contract দেয় এবং gRPC streaming (এক/দ্বিমুখী) সমর্থন করে।
সমস্যাটা কী?
Microservice-এর যুগে এক service আরেক service-কে অনবরত ডাকে — হয়তো সেকেন্ডে হাজারবার। প্রতিবার যদি বড় JSON text পাঠাও-পড়ো, তাহলে দুটো খরচ: (১) JSON হলো verbose text, প্রতিটা key বারবার পাঠাতে হয়, bandwidth অপচয়; (২) text parse করা CPU-ব্যয়বহুল।
আবার REST API-তে contract আলগা — কোন field আছে, কোন type, সেটা সবসময় স্পষ্ট নয়, ভুল হলে runtime-এ ধরা পড়ে। আর সাধারণ REST-এ streaming (একটানা data প্রবাহ) সহজ নয়। এই সমস্যাগুলো — গতি, কঠোর contract, streaming — সমাধানে এসেছে gRPC + Protocol Buffers।
মূল ধারণা
RPC (Remote Procedure Call) হলো এমন একটা ধারণা যেখানে দূরের কোনো server-এর function-কে এমনভাবে call করা যায় যেন সেটা তোমার নিজের কোডের local function।
তুমি লেখো user = getUser(42) — দেখতে সাধারণ function call, কিন্তু পেছনে network পেরিয়ে অন্য server-এ চলে আসে। নেটওয়ার্কের জটিলতা framework লুকিয়ে রাখে।
gRPC হলো Google-এর তৈরি একটি আধুনিক, উচ্চ-কার্যক্ষম RPC framework যা HTTP/2-র উপর চলে এবং Protocol Buffers দিয়ে data আদান-প্রদান করে।
REST যেখানে "resource ও URL"-কেন্দ্রিক, gRPC সেখানে "function/method"-কেন্দ্রিক।
কীভাবে কাজ করে
.proto contract থেকে কোড
সব শুরু হয় একটা .proto file দিয়ে, যেখানে service ও message সংজ্ঞায়িত:
syntax = "proto3";
message UserRequest {
int32 id = 1;
}
message UserReply {
string name = 1;
string email = 2;
}
service UserService {
rpc GetUser (UserRequest) returns (UserReply);
}
এই file থেকে protoc compiler নানা ভাষায় (Go, Java, Python, ...) client ও server কোড auto-generate করে। ফলে client আর server একই কঠোর contract মেনে চলে — কোনো field-এর নাম/type ভুল হলে compile-time-এই ধরা পড়ে।
Protobuf-এর binary serialization
Protocol Buffers হলো একটি ভাষা-নিরপেক্ষ binary serialization format, যেখানে field-এর নামের বদলে ছোট সংখ্যাসূচক tag ব্যবহার করে data compact রাখা হয়।
.proto-তে যে নম্বরগুলো দেখলে (= 1, = 2) সেগুলোই field tag। data পাঠানোর সময় "name" লেখা যায় না, শুধু tag 1 আর মান যায় — তাই অনেক ছোট।
Protobuf vs JSON
| বিষয় | Protobuf | JSON |
|---|---|---|
| Format | binary | text |
| আকার | ছোট (৩০–৬০% কম) | বড় |
| Parse গতি | দ্রুত | ধীর |
| মানুষ পড়তে পারে | না | হ্যাঁ |
| Schema | বাধ্যতামূলক (.proto) | ঐচ্ছিক |
| Browser-এ সরাসরি | কঠিন | সহজ |
HTTP/2 থেকে যা পায়
gRPC HTTP/2-র উপর চলে বলে পায় multiplexing (একই connection-এ অনেক call), header compression, আর সবচেয়ে গুরুত্বপূর্ণ — streaming।
Streaming-এর ধরন
| ধরন | বর্ণনা | উদাহরণ |
|---|---|---|
| Unary | একটি request, একটি response | সাধারণ getUser |
| Server streaming | একটি request, response-এর stream | বড় ফাইল/feed পাঠানো |
| Client streaming | request-এর stream, একটি response | অনেক sensor data আপলোড |
| Bidirectional | দুই দিকেই stream | live chat, real-time sync |
ভাবো তুমি বিদেশে এক বন্ধুকে চিঠি পাঠাচ্ছ। JSON হলো খামে পুরো বাক্য লিখে পাঠানো — "নাম: করিম, শহর: ঢাকা" — পড়তে সহজ কিন্তু জায়গা বেশি লাগে। Protobuf হলো আগে থেকে দুজনে ঠিক করা একটা code-sheet: "১ মানে নাম, ২ মানে শহর"। এখন শুধু ১:করিম ২:ঢাকা পাঠালেই চলে — অনেক ছোট, দ্রুত। কিন্তু code-sheet (.proto) ছাড়া কেউ পড়তে পারবে না। আর RPC হলো — তুমি যেন পাশের ঘরে ডেকে বললে কাজটা করতে, অথচ আসলে সে অন্য দেশে।
কৌশল — gRPC vs REST
| বিষয় | gRPC | REST |
|---|---|---|
| Transport | HTTP/2 | সাধারণত HTTP/1.1 |
| Data | Protobuf (binary) | JSON (text) |
| Contract | কঠোর (.proto) | আলগা (OpenAPI ঐচ্ছিক) |
| Streaming | চমৎকার, built-in | সীমিত |
| Browser support | সরাসরি কঠিন (gRPC-Web লাগে) | সর্বজনীন |
| গতি/দক্ষতা | উচ্চ | মাঝারি |
| ডিবাগ/পড়া | কঠিন (binary) | সহজ |
কখন ব্যবহার করবে / করবে না
- gRPC ব্যবহার করো — internal microservice-to-microservice যোগাযোগে, যেখানে গতি, কঠোর contract ও streaming দরকার; polyglot (নানা ভাষার) system-এ।
- REST ব্যবহার করো — public API-তে, browser-থেকে সরাসরি call-এ, যেখানে সহজে পড়া/ডিবাগ ও সর্বজনীন support জরুরি।
gRPC ব্রাউজার থেকে সরাসরি call করা যায় না, কারণ browser HTTP/2-র সব নিম্নস্তরের নিয়ন্ত্রণ দেয় না — এর জন্য একটা proxy (gRPC-Web) লাগে। তাই public-facing/browser API-তে অন্ধভাবে gRPC বেছো না; সেখানে REST বা GraphQL প্রায়ই বেশি বাস্তবসম্মত। gRPC-র আসল জায়গা হলো backend service-দের নিজেদের মধ্যে কথা।
বাস্তব উদাহরণ
একটা ride-sharing platform-এ:
- Internal services — pricing, driver-matching, payment service একে অপরকে সেকেন্ডে হাজারবার ডাকে। এখানে gRPC + Protobuf: কম latency, ছোট payload।
- Mobile/Web app → backend — এখানে REST/JSON (বা gRPC-Web), কারণ browser ও সহজ ডিবাগ দরকার।
- Driver location streaming — gRPC-র bidirectional streaming দিয়ে driver অ্যাপ ক্রমাগত অবস্থান পাঠায়, server real-time আপডেট ফেরত দেয়।
- টিম Go, Java, Python মিশিয়ে কাজ করে — একই
.protoথেকে সব ভাষার কোড generate হয়, contract সবার জন্য এক।
Interview-এ "gRPC নাকি REST?" জিজ্ঞেস করলে context চাও: internal service-to-service হলে gRPC (গতি, contract, streaming); public/browser-facing হলে REST (সর্বজনীনতা, সহজতা)। "gRPC সবসময় ভালো" বলাটা ভুল — সঠিক উত্তর হলো trade-off বোঝা। আর Protobuf কেন দ্রুত — binary + field tag + schema — এক লাইনে বলতে পারলে দারুণ।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. gRPC কোন transport protocol-এর উপর চলে?
2. Protobuf-এ data কীভাবে পাঠানো হয়?
3. .proto file-এর কাজ কী?