इंजीनियरिंग टीमें आज भी इस बात पर बहस करने में पूरी दोपहर बर्बाद कर देती हैं कि क्या REST खत्म हो चुका है या क्या gRPC ने बाकी सब कुछ बेकार कर दिया है। वह बहस असली मुद्दे को नजरअंदाज कर देती है। आप सबसे अच्छा प्रोटोकॉल नहीं चुन रहे हैं। आप सही सीमा (boundary) चुन रहे हैं। एक ऐसा प्रोटोकॉल जो आपके Kubernetes क्लस्टर के अंदर बेहतरीन काम करता है, वह तब दम तोड़ देगा जब आप उसे हजारों बाहरी डेवलपर्स को सौंप देंगे। एक ऐसा प्रोटोकॉल जो आपके मोबाइल ऐप के कीमती बैंडविड्थ को बचाता है, वह आपके इंफ्रास्ट्रक्चर को कंगाल कर सकता है यदि आप इसे मनमाने सार्वजनिक प्रश्नों (public queries) के लिए खोल देते हैं। यदि आप इस निर्णय को तकनीक की लोकप्रियता की प्रतियोगिता की तरह लेंगे, तो आप ऐसा आर्किटेक्चरल कर्ज (architectural debt) बना लेंगे जो आपकी टीम के हर वर्तमान सदस्य के जाने के बाद भी बना रहेगा।

सीमा का सिद्धांत (The Boundary Principle)

आर्किटेक्चर समझौतों (trade-offs) के बारे में है, विजेताओं के बारे में नहीं। सही सवाल कभी यह नहीं होता कि "कौन सा सबसे तेज़ है?" या "कौन सा सबसे नया है?" बल्कि यह होता है कि "तार (wire) के दूसरी तरफ कौन बैठा है, और वे क्या नियंत्रित करते हैं?" प्रोटोकॉल सीमावर्ती वस्तुएं (boundary objects) हैं। गलत चुनाव करने से आप सिर्फ धीमे नहीं होते, बल्कि यह आपकी प्रणाली में वर्षों तक गलतियों को जड़ बना देता है।

पब्लिक APIs: REST उबाऊ नहीं, बल्कि जिम्मेदार है

जब आपका उपभोक्ता एक बाहरी डेवलपर होता है जिससे आप कभी नहीं मिले, तो आपकी API एक उत्पाद (product) होती है, न कि केवल एक इंटरफ़ेस। वह डेवलपर रात के दो बजे केवल curl और एक Postman कलेक्शन के साथ डिबगिंग कर रहा होता है। यदि उन्हें अपनी पहली सफल कॉल से पहले एक कस्टम क्लाइंट लाइब्रेरी इंस्टॉल करनी पड़ती है या कोई स्कीमा भाषा सीखनी पड़ती है, तो आप उन्हें पहले ही खो चुके हैं।

REST यहाँ इसलिए टिका हुआ है क्योंकि यह स्वयं वेब है। HTTP मेथड्स, स्टेटस कोड और JSON इसकी आम भाषा हैं। कैशिंग (Caching) कोई बाद में सोचा गया विचार नहीं है; यह एक ऐसा इंफ्रास्ट्रक्चर है जो पहले से मौजूद है। ब्राउज़र, CDNs और एज कैश Cache-Control हेडर्स और ETag वैलिडेशन को स्वाभाविक रूप से समझते हैं। आप एक मानक CDN के पीछे REST API रख सकते हैं और कैशिंग लॉजिक की एक भी लाइन लिखे बिना तुरंत बैंडविड्थ की बचत पा सकते हैं। यह तब मायने रखता है जब सार्वजनिक ट्रैफिक अप्रत्याशित हो और आप अपने क्लाउड से निकलने वाले हर गीगाबाइट के लिए भुगतान कर रहे हों।

इसके विपरीत, GraphQL सार्वजनिक सीमा पर एक भारी टैक्स (tax) लाता है। सार्वजनिक GraphQL एंडपॉइंट्स को क्वेरी कॉस्ट एनालिसिस, डेप्थ लिमिटिंग और कॉम्प्लेक्सिटी स्कोरिंग की आवश्यकता होती है ताकि एक अकेली लापरवाह या दुर्भावनापूर्ण क्वेरी आपके डेटाबेस को क्रैश न कर दे। आप केवल एक API नहीं भेज रहे हैं; आप एक क्वेरी निष्पादन इंजन (query execution engine), एक रेट-लिमिटिंग रणनीति और एक कंप्यूट बिलिंग मॉडल बना रहे हैं। जब तक आपके पास सबसे बड़े प्लेटफार्मों जैसी परिचालन क्षमता (operational muscle) न हो, तब तक सार्वजनिक सतह (public surface area) के लिए वह ओवरहेड लापरवाह है। REST डिफ़ॉल्ट रूप से सुरक्षा घेरे (guardrails) तय कर देता है। प्रत्येक एंडपॉइंट एक ही काम करता है। उपभोक्ता वही प्राप्त करते हैं जो आप प्रदान करते हैं, न कि वह जो वे कल्पना कर सकते हैं।

इंटरनल सर्विसेज: पूरे पाइप पर अपना नियंत्रण रखें

आपके संगठन के भीतर, बातचीत बदल जाती है। आप क्लाइंट और सर्वर दोनों को नियंत्रित करते हैं। आप कॉल चेन में प्रत्येक सेवा के लिए टेक्नोलॉजी स्टैक तय कर सकते हैं। यहीं पर gRPC अपनी उपयोगिता साबित करता है।

सबसे पहले, JSON को पवित्र मानना बंद करें। Protocol Buffers, JSON की तुलना में लगभग तीन गुना तेज़ी से सीरियलाइज़ (serialize) होते हैं। पेलोड (payloads) छोटे होते हैं क्योंकि इसका फॉर्मेट बाइनरी होता है। एक व्यस्त इंटरनल नेटवर्क पर, वे मिलीसेकंड और मेगाबाइट वास्तविक पैसे में बदल जाते हैं और टेल लेटेंसी (tail latency) को कम करते हैं। इससे भी महत्वपूर्ण बात यह है कि Protobuf आपको एक सख्त अनुबंध (strict contract) देता है। जब आप किसी फ़ील्ड टाइप को बदलते हैं या किसी मैसेज का नाम बदलते हैं, तो त्रुटि कंपाइल टाइम पर ही पता चल जाती है, न कि रात के तीन बजे प्रोडक्शन में जब कोई डाउनस्ट्रीम सर्विस पार्स एक्सेप्शन (parse exceptions) फेंकना शुरू कर देती है।

gRPC, HTTP/2 पर चलता है, इसलिए आपको हेडर कंप्रेशन, मल्टीप्लेक्सड स्ट्रीम्स और वास्तविक स्ट्रीमिंग सिमेंटिक्स मिलते हैं। यदि आप सेवाओं के बीच हाई-थ्रूपुट इवेंट्स भेज रहे हैं या रीयल-टाइम अपडेट भेज रहे हैं, तो सर्वर-साइड और द्विदिश (bidirectional) स्ट्रीमिंग इसके मूल फीचर्स हैं, न कि रिक्वेस्ट-रिस्पॉन्स फ्रेमवर्क पर जबरदस्ती लगाए गए लॉन्ग-पॉलिंग वर्कअराउंड।

यहाँ एक बड़ी समस्या है: gRPC को सीधे ब्राउज़र की ओर न मोड़ें। ब्राउज़र नेटवर्किंग मॉडल उस तरह से HTTP/2 का उपयोग नहीं करते जैसा gRPC अपेक्षा करता है। एक ब्राउज़र को बैकएंड से बात कराने के लिए आपको अपने स्टैक पर grpc-web और Envoy जैसे प्रॉक्सी को जोड़ना पड़ेगा। यह कोई बग नहीं है; यह एक सीमा का संकेत (boundary signal) है। gRPC को अपने फ़ायरवॉल के पीछे, एक-दूसरे पर भरोसा करने वाली सेवाओं के बीच रखें, और इसकी डिबगिंग जटिलता को गति की कीमत के रूप में स्वीकार करें। बाइनरी पेलोड लॉग फ़ाइल में JSON की तरह आसानी से नहीं देखे जा सकते।

जटिल UI और मोबाइल: GraphQL का विशेष क्षेत्र

आधुनिक मोबाइल स्क्रीन विभिन्न हिस्सों का मिश्रण होती हैं। एक व्यू को यूजर प्रोफाइल की आवश्यकता हो सकती है,