ইঞ্জিনিয়ারিং টিমগুলো এখনও সারা দুপুর এই তর্কে ব্যয় করে যে REST কি মৃত নাকি gRPC বাকি সব কিছুকে অপ্রাসঙ্গিক করে ফেলেছে। এই বিতর্কটি মূল বিষয়টি এড়িয়ে যায়। আপনি সেরা প্রোটোকল বেছে নিচ্ছেন না। আপনি সঠিক সীমানা (boundary) বেছে নিচ্ছেন। একটি প্রোটোকল যা আপনার Kubernetes ক্লাস্টারের ভেতরে চমৎকার কাজ করবে, তা হাজার হাজার এক্সটার্নাল ডেভেলপারের কাছে পৌঁছে দিলে দমবন্ধ হয়ে যেতে পারে। আর যেটি আপনার মোবাইল অ্যাপের মূল্যবান ব্যান্ডউইথ বাঁচাবে, সেটি যদি আপনি অনিয়ন্ত্রিত পাবলিক কুয়েরির জন্য উন্মুক্ত করে দেন, তবে তা আপনার ইনফ্রাস্ট্রাকচারকে দেউলিয়া করে দিতে পারে। এই সিদ্ধান্তটিকে যদি আপনি কেবল একটি প্রযুক্তিগত জনপ্রিয়তার লড়াই হিসেবে দেখেন, তবে আপনি এমন একটি আর্কিটেকচারাল ডেট (architectural debt) তৈরি করবেন যা আপনার টিমের বর্তমান সদস্যদের চেয়েও বেশিদিন টিকে থাকবে।
সীমানা নীতি (The Boundary Principle)
আর্কিটেকচার হলো ট্রেড-অফ নিয়ে, কোনো চ্যাম্পিয়ন খোঁজা নয়। সঠিক প্রশ্নটি কখনোই "কোনটি দ্রুততম?" বা "কোনটি নতুনতম?" নয়। প্রশ্নটি হলো "অন্য প্রান্তের মানুষটি কে, এবং তারা কী নিয়ন্ত্রণ করে?" প্রোটোকল হলো বাউন্ডারি অবজেক্ট। ভুল প্রোটোকল বেছে নেওয়া মানে শুধু আপনার গতি কমিয়ে দেওয়া নয়; এটি আপনার সিস্টেমের মধ্যে বছরের পর বছর ধরে ভুলগুলোকে গেঁথে দেয়।
পাবলিক API: REST বিরক্তিকর নয়, এটি দায়িত্বশীল
যখন আপনার ব্যবহারকারী এমন একজন এক্সটার্নাল ডেভেলপার যার সাথে আপনার কখনো দেখা হয়নি, তখন আপনার API একটি প্রোডাক্ট, কেবল একটি ইন্টারফেস নয়। সেই ডেভেলপার রাত দুটোর সময় curl এবং একটি Postman collection ছাড়া আর কিছুই না দিয়ে ডিবাগিং করছেন। যদি তাদের প্রথম সফল কলের আগে কোনো কাস্টম ক্লায়েন্ট লাইব্রেরি ইনস্টল করতে হয় বা কোনো স্কিমা ল্যাঙ্গুয়েজ শিখতে হয়, তবে আপনি তাদের আগেই হারিয়ে ফেলেছেন।
REST এখানে টিকে আছে কারণ এটি নিজেই ওয়েব। HTTP মেথড, স্ট্যাটাস কোড এবং JSON হলো সাধারণ ভাষা। ক্যাশিং এখানে কোনো afterthought নয়; এটি এমন একটি ইনফ্রাস্ট্রাকচার যা ইতিমধ্যে বিদ্যমান। ব্রাউজার, CDN এবং এজ ক্যাশগুলো Cache-Control হেডার এবং ETag ভ্যালিডেশন নেটিভলি বোঝে। আপনি একটি স্ট্যান্ডার্ড CDN-এর পেছনে REST API রাখতে পারেন এবং ক্যাশিং লজিকের একটি লাইনও না লিখে তাৎক্ষণিক ব্যান্ডউইথ সাশ্রয় করতে পারেন। যখন পাবলিক ট্রাফিক অনির্দেশ্য এবং আপনার ক্লাউড থেকে বেরিয়ে যাওয়া প্রতিটি গিগাবাইটের জন্য আপনাকে অর্থ দিতে হয়, তখন এটি অত্যন্ত গুরুত্বপূর্ণ।
বিপরীতে, GraphQL পাবলিক বাউন্ডারিতে একটি ভারী ট্যাক্স বা বোঝা নিয়ে আসে। পাবলিক GraphQL এন্ডপয়েন্টগুলোর জন্য কোয়েরি কস্ট অ্যানালাইসিস, ডেপথ লিমিটিং এবং কমপ্লেক্সিটি স্কোরিং প্রয়োজন, যাতে একটি মাত্র অসাবধান বা ক্ষতিকারক কুয়েরি আপনার ডাটাবেসকে ধসিয়ে না দেয়। আপনি কেবল একটি API সরবরাহ করছেন না; আপনি একটি কোয়েরি এক্সিকিউশন ইঞ্জিন, একটি রেট-লিমিটিং স্ট্র্যাটেজি এবং একটি কম্পিউট বিলিং মডেল তৈরি করছেন। আপনার যদি বড় বড় প্ল্যাটফর্মগুলোর মতো অপারেশনাল সক্ষমতা না থাকে, তবে পাবলিক সারফেস এরিয়ার জন্য এই ওভারহেড অত্যন্ত ঝুঁকিপূর্ণ। REST ডিফল্টভাবেই গার্ডরেল সেট করে দেয়। প্রতিটি এন্ডপয়েন্ট একটি নির্দিষ্ট কাজ করে। ব্যবহারকারীরা ঠিক ততটুকুই ফেচ করে যা আপনি অফার করছেন, তারা যা খুশি তা কল্পনা করে নিতে পারে না।
ইন্টারনাল সার্ভিসেস: পুরো পাইপলাইন নিয়ন্ত্রণ করুন
আপনার প্রতিষ্ঠানের ভেতরে আলোচনার প্রেক্ষাপট বদলে যায়। আপনি ক্লায়েন্ট এবং সার্ভার উভয়ই নিয়ন্ত্রণ করেন। কল চেইনের প্রতিটি সার্ভিসের জন্য আপনি টেকনোলজি স্ট্যাক নির্ধারণ করতে পারেন। এখানেই gRPC তার উপযোগিতা প্রমাণ করে।
প্রথমত, JSON-কে পবিত্র মনে করা বন্ধ করুন। Protocol Buffers JSON-এর চেয়ে প্রায় তিনগুণ দ্রুত সিরিয়ালাইজ করতে পারে। যেহেতু ফরম্যাটটি বাইনারি, তাই এর পেলোডও ছোট হয়। একটি ব্যস্ত ইন্টারনাল নেটওয়ার্কে, এই মিলিসেকেন্ড এবং মেগাবাইটগুলো জমা হয়ে প্রকৃত অর্থ সাশ্রয় করে এবং টেইল ল্যাটেন্সি (tail latency) কমায়। আরও গুরুত্বপূর্ণ বিষয় হলো, Protobuf আপনাকে একটি কঠোর চুক্তি (strict contract) প্রদান করে। যখন আপনি কোনো ফিল্ড টাইপ পরিবর্তন করেন বা মেসেজের নাম পরিবর্তন করেন, তখন সেই সমস্যাটি কম্পাইল টাইমেই ধরা পড়ে; প্রোডাকশনে রাত তিনটার সময় নয় যখন কোনো ডাউনস্ট্রিম সার্ভিস পার্স এক্সসেপশন (parse exception) ছুড়তে শুরু করে।
gRPC চলে HTTP/2-এর ওপর, তাই আপনি হেডার কম্প্রেশন, মাল্টিপ্লেক্সড স্ট্রিম এবং রিয়েল স্ট্রিমিং সেমান্টিক্স পান। আপনি যদি সার্ভিসের মধ্যে উচ্চ-থ্রুপুট ইভেন্ট পাস করেন বা রিয়েল-টাইম আপডেট পাঠান, তবে সার্ভার-সাইড এবং বাইডাইরেকশনাল স্ট্রিমিং হলো এর নেটিভ ফিচার, কোনো রিকোয়েস্ট-রেসপন্স ফ্রেমওয়ার্কে জোড়াতালি দেওয়া লং-পোলিং সমাধান নয়।
তবে একটি কঠিন বিষয় আছে: gRPC সরাসরি ব্রাউজারের দিকে নির্দেশ করবেন না। ব্রাউজার নেটওয়ার্কিং মডেলগুলো gRPC প্রত্যাশা অনুযায়ী HTTP/2 বোঝে না। একটি ব্রাউজারকে ব্যাকএন্ডের সাথে কথা বলানোর জন্য আপনাকে আপনার স্ট্যাকে grpc-web এবং Envoy-এর মতো একটি প্রক্সি যুক্ত করতে হবে। এটি কোনো বাগ নয়; এটি একটি বাউন্ডারি সিগন্যাল। gRPC-কে আপনার ফায়ারওয়ালের পেছনে, একে অপরকে বিশ্বাস করে এমন সার্ভিসের মধ্যে রাখুন এবং এর ডিবাগিং জটিলতাকে গতির মূল্য হিসেবে গ্রহণ করুন। বাইনারি পেলোডগুলো JSON-এর মতো লগ ফাইলে সহজে পড়া যায় না।
জটিল UI এবং মোবাইল: GraphQL-এর বিশেষ ক্ষেত্র
আধুনিক মোবাইল স্ক্রিনগুলো হলো বিভিন্ন জিনিসের সংমিশ্রণ। একটি ভিউতে হয়তো একটি ইউজার প্রোফাইল প্রয়োজন,