gRPC বনাম REST: কোন API স্টাইল বাছবেন
REST সহজ ও সর্বজনীন। gRPC দ্রুত ও strongly typed। লেনদেনগুলো এবং কোনটি সিস্টেমের কোথায় মানায়, জানুন।
REST সাধারণত মানে resource ও verb সহ HTTP-র ওপর JSON (GET /users/42)। gRPC Google-এর remote procedure call framework, যা HTTP/2-র ওপর Protocol Buffers (ছোট binary ফরম্যাট) ব্যবহার করে।
gRPC কীভাবে কাজ করে
.proto ফাইলে service ও message ঠিক করেন। টুল অনেক ভাষায় client-server কোড বানিয়ে দেয়। তখন দূরের method ডাকা strong type-সহ local function ডাকার মতো লাগে।
gRPC-র শক্তি
- ছোট ও দ্রুত: binary encoding JSON-এর চেয়ে ছোট, আর HTTP/2 এক connection-এ অনেক call চালায়।
- Streaming: server, client ও দ্বিমুখী stream বিল্ট-ইন।
- কড়া চুক্তি ও code generation: service-দের মধ্যে অমিল কম, versioning-এর নিয়ম সহজ।
- Deadline, cancellation ও metadata প্রথম শ্রেণির।
REST-এর শক্তি
- সর্বজনীন: প্রতিটি ভাষা, browser ও টুল বোঝে।
- মানুষ পড়তে পারে: curl বা browser দিয়ে debug সহজ।
- Cacheable:
GET-এর সাথে HTTP caching ও CDN স্বাভাবিকভাবে চলে। - শেখা ও public করা সহজ।
দুর্বলতা
- gRPC: browser সরাসরি ডাকতে পারে না (gRPC-Web বা gateway লাগে), binary payload দেখা কঠিন, আর বাইরের ডেভেলপার REST পছন্দ করে।
- REST: payload বড়, streaming বিল্ট-ইন নেই, আর OpenAPI না যোগ করলে চুক্তি ঢিলা।
বাস্তব নিয়ম
| পরিস্থিতি | বাছুন |
|---|---|
| Public API, browser client, তৃতীয় পক্ষ | REST (বা GraphQL) |
| বিশাল volume-এর অভ্যন্তরীণ service-থেকে-service call | gRPC |
| Service-দের মধ্যে streaming data | gRPC |
| দ্রুত prototype বা সহজ CRUD | REST |
অনেক সিস্টেম দুটোই ব্যবহার করে: বাইরের client-এর জন্য প্রান্তে REST, অভ্যন্তরীণ service-দের মধ্যে gRPC, মাঝে API gateway অনুবাদ করে।
মূল কথা: public API-তে ডিফল্ট REST, আর অভ্যন্তরীণ, পারফরম্যান্স-সংবেদনশীল বা streaming call-এ gRPC ভাবুন।
System Design সিরিজ, পর্ব ২ (building block): 7 নম্বর (মোট 14)। আগের লেখা: WebSocket বনাম Server-Sent Events বনাম long polling.
