gRPC, OpenAPI, REST को समझना और API डिज़ाइन में कब इस्तेमाल करें (2020)

 (cloud.google.com)
1 पॉइंट द्वारा GN⁺ 2025-01-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • API डिज़ाइन की शुरुआत RPC और REST के अंतर से होती है; तीनों तरीके HTTP से जुड़े हो सकते हैं, लेकिन कॉल बनाने और क्लाइंट को संरचित करने के मॉडल अलग हैं
  • REST सर्वर द्वारा दिए गए URL को follow करने वाला hypertext मॉडल है, इसलिए यह OpenAPI-style API से अलग है जहाँ क्लाइंट URL format compose करता है
  • OpenAPI URL path templates और HTTP methods से operations define करता है; यह practical और व्यापक रूप से इस्तेमाल होता है, लेकिन REST की तुलना में HTTP पर mapped RPC model के ज्यादा करीब है
  • gRPC IDL, code generation, binary payloads और HTTP/2 connection management के जरिए RPC API को सीधे define करता है और HTTP details छिपाता है
  • gRPC में दोनों तरफ special software चाहिए और proxy enhancement, concurrent update prevention, partial updates में सीमाएँ हैं; इसलिए यह internal APIs या Cloud Endpoints जैसी conversion layer इस्तेमाल कर सकने पर खास तौर पर उपयुक्त है

HTTP आधारित API को देखने के तीन मॉडल

  • HTTP को API transport layer के रूप में इस्तेमाल करने के प्रमुख तरीके REST, OpenAPI, और gRPC में बंटते हैं
  • कई public APIs और private distributed APIs के HTTP इस्तेमाल करने की एक वजह यह है कि organizations port 80 और 443 पर HTTP traffic की security issues से परिचित हैं
  • तीनों तरीके HTTP से जुड़ सकते हैं, लेकिन किस चीज़ को address बनाया जाता है और client call कैसे बनाता है, यह अलग होता है

REST: URL को compose नहीं, follow करने का तरीका

  • REST में client server द्वारा दिए गए URL को वैसा ही इस्तेमाल करता है; वह URL format को API specification का हिस्सा मानकर समझता या compose नहीं करता
  • Browser current page, bookmark, या user द्वारा enter किए गए URL को follow करता है, और URL से HTTP request information निकालने या relative URL को absolute URL में बदलने जितना ही काम करता है
  • REST API का core, resources के बीच references को दूसरे resources के URL के रूप में व्यक्त करने वाले hypertext/hypermedia का उपयोग है
  • REST तरीके में सभी identifiers URL के रूप में आदान-प्रदान किए जाते हैं
    • POST /accounts → account_URL
    • POST /subscriptions में account_URL pass करना → subscription_URL
    • GET {account_URL} → account data tree return
  • REST के फायदे web की अपनी stability, consistency और universality के करीब हैं, और HTTP/REST का entity-oriented model API को अधिक सरल और नियमित बना सकता है

OpenAPI: HTTP पर सीधे mapped RPC के करीब

  • OpenAPI paths के नीचे URL path templates define करता है, और path व HTTP method के combination को operation कहता है
  • /pets/{petId} जैसा path client से अपेक्षा करता है कि वह {petId} value जानकर उसे URL template में डालकर HTTP request बनाए
  • इस तरीके में client को URL format की details जाननी पड़ती हैं, इसलिए यह REST के hypertext model के उलट है
  • OpenAPI के व्यापक इस्तेमाल की वजह स्पष्ट है
    • यह traditional RPC model जैसा है, इसलिए programmers को familiar लगता है
    • RPC concepts को HTTP requests पर सीधे map किया जा सकता है
  • Public APIs में standard HTTP technologies से लगभग हर language और environment में access मिलना बड़ा फायदा है
  • लेकिन URL paths, HTTP methods, और parameter mapping design करनी पड़ती है, इसलिए API providers और consumers दोनों के लिए सीखने वाली details बढ़ जाती हैं

gRPC: HTTP/2 को छिपाने वाली RPC implementation technology

  • gRPC HTTP/2 को transport layer के रूप में इस्तेमाल करता है, लेकिन API designers और client/server code के सामने HTTP details expose नहीं करता
  • gRPC client का call flow सरल है
    • call करने वाली procedure तय करता है
    • इस्तेमाल होने वाली parameter values compute करता है
    • code-generated stub के जरिए parameters pass करके call करता है
  • gRPC interface description language के आधार पर remote procedures define करता है, इसलिए OpenAPI की तरह URL path, parameters, और HTTP method mappings को साथ में express करने की जरूरत नहीं होती
  • Code generation, frameworks, और libraries के जरिए client libraries और server implementations बनाना आसान हो सकता है
  • Binary payloads और HTTP/2 connection management का इस्तेमाल करके performance benefits मिलते हैं; वही technologies gRPC के बिना सीधे भी इस्तेमाल की जा सकती हैं, लेकिन इसके लिए अधिक technical सीखने की जरूरत होती है

OpenAPI के बजाय gRPC पर कब विचार करें

  • OpenAPI से API design करते समय operations और parameters को URL paths और HTTP methods के combinations से express करना पड़ता है, और विकल्प ज्यादा होने से यह tricky हो सकता है
  • अगर RPC-style model जारी रखना है, तो gRPC HTTP के लिए custom mapping खुद design करने का बोझ कम करता है
  • gRPC और OpenAPI के basic API models मिलते-जुलते हैं, लेकिन HTTP exposure का तरीका अलग है
    • OpenAPI HTTP transport details को client के सामने expose करता है और designer mapping control करता है
    • gRPC predefined mapping और generated code के जरिए HTTP details छिपाता है
  • OpenAPI का बड़ा फायदा यह है कि client standard HTTP tools और technologies को जस का तस इस्तेमाल कर सकता है, और कई API designers के लिए यह फायदा extra design cost को justify करता है

RPC में entity-oriented model जोड़ना

  • gRPC या OpenAPI इस्तेमाल करते हुए भी अगर RPC methods को entities के आसपास सीमित रखा जाए, तो REST के कुछ फायदे मिल सकते हैं
  • Procedures define करने से शुरू करने के बजाय पहले resource types define करें, फिर हर type के लिए standard entity operations map करें
  • Basic operations Create, Retrieve, Update, Delete, List हैं, जिन्हें अक्सर CRUD plus List माना जा सकता है
  • जरूरत पड़ने पर additional operations रखे जा सकते हैं, लेकिन entity-oriented concepts और procedure-oriented concepts मिलाने पर कुछ फायदे कमजोर हो सकते हैं
  • Procedures को entity type के हिसाब से group करना object-oriented languages के core ideas में से एक भी है

gRPC की सीमाएँ और सावधानियाँ

  • gRPC में client और server दोनों पर special software चाहिए, और generated code को दोनों तरफ के build process में integrate करना पड़ता है
  • JavaScript या Python जैसी dynamic languages के users के लिए, जहाँ development environment में build process बहुत कम या न के बराबर हो सकता है, यह requirement बोझ बन सकती है
  • Google Cloud Endpoints gRPC API को HTTP और JSON के जरिए access करने देता है और client choices बहाल करता है, लेकिन सभी users इसे इस्तेमाल या इसके बराबर feature build नहीं कर सकते
  • REST API में metadata के बिना भी पूरे API को crawl करने वाला bot बनाना आसान है, लेकिन gRPC या OpenAPI जैसी RPC-style APIs में हर entity type के लिए अलग API और metadata या custom software चाहिए
  • HTTP APIs में Apigee Edge जैसे API management tools और proxies के जरिए security features, input validation, data format mapping, header/body modification आदि जोड़े जाते हैं, लेकिन gRPC में ऐसी proxy enhancement कहीं ज्यादा कठिन हो सकती है
  • gRPC concurrent updates से data loss रोकने का standard mechanism define नहीं करता
    • HTTP इसके लिए Etag और If-Match headers देता है
  • gRPC partial updates का mechanism भी define नहीं करता
    • HTTP में PATCH है, और JSON के लिए standards के रूप में JSON merge patch और JSON patch हैं
    • JSON merge patch सरल है, लेकिन array updates जैसे सभी cases handle नहीं कर पाता
    • JSON patch ज्यादा cases handle करता है, लेकिन इस्तेमाल में अधिक complex है

चयन के मानदंड

  • अगर आप REST hypertext model पहले से design करना जानते हैं या सीखने को तैयार हैं, तो stability, consistency और universality को लक्ष्य बनाने वाला यह अच्छा option हो सकता है
  • OpenAPI standard HTTP technologies भर से accessible APIs बना सकता है, लेकिन RPC concepts को HTTP पर map करने के design choices बढ़ जाते हैं, जिससे design, implementation और learning मुश्किल हो सकते हैं
  • जिन APIs के लिए OpenAPI पर विचार हो रहा है, उनके लिए gRPC भी साथ में review करने लायक है। दोनों तरीकों के basic API models comparable हैं, और gRPC HTTP mapping खुद बनाने की जरूरत कम करता है
  • gRPC निम्न स्थितियों में खास तौर पर आकर्षक है
    • जब Cloud Endpoints जैसे products से clients को gRPC technology अनिवार्य रूप से adopt न करनी पड़े
    • जब server और सभी clients की technology choices control की जा सकती हों, यानी internal API हो
  • gRPC को OpenAPI या REST के बजाय adopt करते समय यह ध्यान रखना चाहिए कि Apigee Edge जैसे API management tool-based proxies से API behavior को enhance या correct करने के अवसर काफी सीमित हो सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-24
Hacker News की राय

  • अगर समय को पीछे ले जा पाता, तो मैं खुद को शुरुआत में gRPC सीखने से ही रोकना चाहता
    शुरू में मैं उसके vision से प्रभावित हो गया था, लेकिन कुछ साल बाद देखा तो सिरदर्द बहुत ज़्यादा थे। यह कहना कि यह internals को छिपा देता है, लगभग मज़ाक जैसा है; 10 में से 1 बार fail होने वाली request की वजह खोजने के लिए debug logs की बाढ़ लानी पड़ती है और अस्पष्ट नाम वाले 10–20 timeout/retry settings tweak करने पड़ते हैं
    Maven plugins, अजीब deadline exceeded, HTTP/2 को नापसंद करने वाले load balancers, firewalls की वजह से आखिरकार standard API इस्तेमाल करने की नौबत, कमज़ोर documentation, observability में उपयोगी error messages हासिल करना—इन सबने समय खा लिया

    • gRPC की समस्या protocol या protobuf से ज़्यादा, कम-से-कम Java toolchain के खराब होने में है
      generated code का developer experience खराब है, client stubs final concrete classes होते हैं इसलिए tests में mocking मुश्किल है, और server implementation में भी interface नहीं बल्कि concrete class को extend करना पड़ता है
      server methods की async signature होती है, जिससे @Transactional जैसी AOP-based behavior टूट जाती है; exception support भी नहीं है, और immutable value classes अच्छी हैं लेकिन सब कुछ builder से बनाना पड़ता है
      आखिरकार SOA में gRPC इस्तेमाल करना हो तो gRPC noise छिपाने और testable, साफ़ code पाने के लिए बहुत सारा plumbing code लिखना पड़ता है, और Thrift के RPC compiler में भी मिलती-जुलती समस्याओं के साथ कुछ और समस्याएँ जुड़ी हुई हैं
    • वे समस्याएँ gRPC/protobuf spec से ज़्यादा किसी खास implementation की समस्या लगती हैं
      modern .NET और C# में gRPC experience काफ़ी अच्छा है, इसलिए Microsoft ने भी WCF जैसी पुरानी RPC technologies बंद कर gRPC पर focus किया
    • जिस सबसे बड़े project में मैंने इसे इस्तेमाल किया वह Java में था, और protoc से generated bindings के output को verify करना, सीधे serialization करने की तुलना में ज़्यादा लंबा-चौड़ा और error-prone था
      wire protocol type-safe नहीं है; type tags तो हैं, लेकिन कई data types में वही tag reuse होता है। zig-zag integer encoding भी slow है
      RPC library के तौर पर यह खराब है, और मेरे अनुभव में इससे भी बदतर सिर्फ FlatBuffers था
    • Maven का ज़िक्र देखकर लगता है कि आप Java इस्तेमाल कर रहे हैं; लेकिन पिछले करीब 8 साल से Go में programming करते हुए मेरा gRPC experience काफ़ी अलग रहा है
      मुझे जिज्ञासा है कि यह फर्क Java की वजह से है या gRPC technology खुद ऐसी है
    • Go+Dart stack में मैं कई साल से gRPC इस्तेमाल कर रहा हूँ, लेकिन ऐसी समस्याएँ कभी नहीं झेलीं
      जानना चाहूँगा कि क्या यह Java+gRPC specific problem है

  • मैंने लंबे समय से API बनाए हैं, gRPC और HTTP/REST दोनों इस्तेमाल किए हैं, और OpenAPI spec से Go क्लाइंट और सर्वर generate करने वाली library https://github.com/oapi-codegen/oapi-codegen भी रिलीज़ की है
    लेख में OpenAPI और REST को अलग-अलग बताने के तरीके से सहमत होना मुश्किल है। OpenAPI, HTTP API के व्यवहार को document करने का तरीका है, और यह RESTful API हो या पूरी तरह arbitrary API, दोनों को व्यक्त कर सकता है। tools द्वारा समझी जा सकने वाली API को describe करने वाली schema language होने के लिहाज से यह gRPC protocol specify करने वाली Protocol Buffer file से conceptually मिलता-जुलता है
    gRPC proto का आदान-प्रदान करने वाला RPC mechanism है, लेकिन जब Google ने protobuf को public किया, तो उसने अपनी internal RPC layer Stubby को public नहीं किया, और gRPC, Stubby जितना बेहतरीन नहीं है। फिर भी transport efficiency ज्यादा है और इसे extend करना भी अपेक्षाकृत आसान है
    हालांकि gRPC का ecosystem mainstream HTTP libraries जितना robust नहीं है, इसलिए logging या authentication जैसे middleware अक्सर खुद implement करने पड़ते हैं, और अलग-अलग languages में implemented services के बीच RPC में यह खासकर सच है
    मेरे हिसाब से gRPC की असली समस्या proto file है। हर client को server से compatible .proto file के साथ build होना पड़ता है, इसलिए यह discoverable protocol नहीं है। HTTP API को OpenAPI description के बिना भी curl या खुद लिखे code से call किया जा सकता है, इसलिए coupling ज्यादा loose होती है, और इसी वजह से काम करना और debug करना आसान होता है

    • यह blog जिसे “OpenAPI” कहता है और सही मायने वाले REST के बीच अंतर है। हालांकि असल में वास्तविक REST API बनाने वाली जगहें बहुत कम हैं, और ज्यादातर OpenAPI-style approach अपनाती हैं
      Roy Fielding के 2000 के PhD dissertation में defined REST में, root URL पर GET करने पर 200 OK response के अंदर links होने चाहिए थे, और उन links को follow करते हुए API द्वारा provide किए गए सभी resources explore किए जा सकने चाहिए थे। hierarchical structure allowed था, लेकिन सब कुछ link tree में कहीं न कहीं से accessible होना चाहिए था, और इसका मकसद discoverability देना था
      पिछले 20 सालों में जिन जगहों पर मैंने काम किया, वे लगभग सभी POST resource_name/resource_id/sub_resource/sub_resource_id/mutation_type या company के idempotency handling के तरीके के हिसाब से PUT resource_name/resource_id/sub_resource/sub_resource_id इस्तेमाल करती थीं, और client Swagger/OpenAPI जैसी structural knowledge के आधार पर magic URLs assemble करता था
      इसलिए strict लोग, Fielding की REST definition implement न करने के अर्थ में, practical तरीके को “REST” नहीं बल्कि “RESTful” कहा करते हैं
    • OpenAPI और REST को अलग करने वाला हिस्सा मुझे भी confusing लगा। लेख में जिसे REST कहा गया है, वह HATEOAS के ज्यादा करीब लगता है
      internal/external clients वाली काफी बड़ी APIs manage करने के नजरिये से, OpenAPI spec से code generate करने वाला flow भी समझना मुश्किल है। generated stubs भरने के बाद API spec को iteratively improve करें, तो tool फिर नए stubs बना देता है, manual merge की जरूरत पड़ती है, और API बड़ी होती जाए तो related changes ढूंढना कठिन हो जाता है
      इसलिए मैंने go/ast आदि का उपयोग करके code से OpenAPI spec generate करने वाला एक monster बनाया। perfect नहीं है, लेकिन Echo और Gin दोनों में काम करने वाला 95% solution है; नया endpoint चाहिए तो request/response structs और खाली handler बनाकर docs generate करते हैं और frontend developer को भेज देते हैं, जिससे तेजी से आगे बढ़ा जा सकता है
      ज्यादातर developers को यह सोचने की जरूरत नहीं पड़ती कि OpenAPI में API को कैसे represent करें, और documentation भी हमेशा code से match करती है
    • आजकल discovery के लिए gRPC reflection है: https://grpc.io/docs/guides/reflection/
    • OpenAPI spec का उपयोग करके generated types के साथ SQL-जैसा query syntax भी बना रहा हूं। इससे किसी भी third-party API को एक जैसी feeling के साथ handle किया जा सकता है
      Apipe.new(GitHun) |> from("search/repositories") |> eq(:language, "elixir") |> order_by(:updated) |> limit(1) |> execute()
      उपलब्ध gRPC functions या third-party API की RESTful quirks जानने की जरूरत नहीं रहती, और built-in documentation और type access भी बनाए रखे जा सकते हैं
      https://github.com/cpursley/apipe
      JS/TS project में Supabase की तरह जोड़ने के लिए TypeScript adapter layer पर भी विचार कर रहा हूं
      const { data, error } = await apipe.from('search/repositories').eq('language', 'elixir').order_by('updated').limit(1)
      यह call Elixir proxy के जरिए async processing या rate limiting जैसे भारी काम सौंप सकता है
    • यह कहना पूरी तरह सही नहीं है कि gRPC discoverable protocol नहीं है
      Protobuf के JSON serialization के आधार पर OpenAPI description बनाई जा सकती है और Swagger के जरिए provide की जा सकती है, और gRPC खुद भी built-in reflection और इसका उपयोग करने वाली grpcurl utility provide करता है

  • FAANG की कुछ जगहों पर काम करने के अनुभव से कहूं तो Thrift/gRPC internal service routing के लिए वाकई उपयोगी है
    हालांकि इसकी जटिलता का बड़ा हिस्सा उन teams द्वारा manage किया जाता है जो libraries, service discovery layer, routing आदि बनाती हैं। RPC protocol इस्तेमाल करने पर ये चीज़ें उस scale और speed पर संभव हो जाती हैं जो सामान्य JSON/REST service से करना मुश्किल है
    मैंने ऐसा REST API भी कभी नहीं देखा जिसमें verbs बाहर न झलकते हों, और अगर backend service mesh बनाना हो या दो local services को network stream से जोड़ना हो, तो मैं हमेशा gRPC चुनूंगा
    लेकिन customer-facing या web-exposed use case के लिए मैं gRPC कभी इस्तेमाल नहीं करूंगा। RPC शक्तिशाली है क्योंकि यह कई decisions को fixed कर देता है और “एक ही तरीका” enforce करता है। उल्टा, अगर अलग-अलग tech stacks के कई तरह के clients को service इस्तेमाल करनी हो, तो REST कहीं बेहतर है

    • public API के लिए तो नहीं करूंगा, लेकिन private API में बस POST /api/doThingy पर JSON body भेजने जैसा तरीका अपनाता हूं
      यह आसान RPC है जिसमें सबसे basic HTTP client होने पर कोई भी शामिल हो सकता है, और यह सभी OS और browsers पर अच्छी तरह चलता है। URL path में डालें, query parameters में डालें या body में डालें—इससे जूझने की जरूरत भी नहीं होती
      Buf या Connect जैसी server families इस्तेमाल करें जो इसे कम असुविधाजनक बनाने की कोशिश करती हैं, तो gRPC में भी HTTP के जरिए JSON खुशी-खुशी accept कर लिया जाता है
    • web नहीं, बल्कि client/server applications का क्या, यह जानने की उत्सुकता है
      online games या MMO जैसे cases याद आते हैं जहां REST से कहीं ज्यादा real-time communication चाहिए होता है, लेकिन आजकल socket connection के ऊपर कुछ रखकर इस्तेमाल करते हैं या नहीं, यह ठीक से नहीं जानता
    • अगर internal service routing में Thrift/gRPC वरदान है, तो यह जानना चाहूंगा कि किससे तुलना में ऐसा है
      यह भी जानना चाहता हूं कि आपने और क्या-क्या try किया
    • “verbs बाहर झलकते हैं” का मतलब क्या है, यह जानना चाहूंगा

  • अगर bidirectional streaming नहीं कर रहे हैं, तो मेरी नजर में gRPC ज्यादातर समय की बर्बादी है
    runtime transitive dependency hell, toolchain hell है, और Google के अंदर हर implementation manage करने वाली teams भी शायद इस बात पर philosophical agreement नहीं रखतीं कि basic features को कैसे काम करना चाहिए
    अपनी भाषा इस्तेमाल न करने वाली teams—खासकर Go/Python/Java न हों, या वे भी पुराने versions पर हों—को gRPC API expose करके देखिए, या किसी commercial off-the-shelf product से integrate करके देखिए, या browser में expose करके देखिए; हर जगह intermediate layer चाहिए हो जाती है

    • कई companies और teams में gRPC इस्तेमाल किया है, और हर company में engineers की संख्या लगभग 100–500 के बीच थी, लेकिन dependency और toolchain वाली problems नहीं झेलीं
      gRPC कुल मिलाकर smoothly चला
    • मुझे लगता है इसे सीधे browser में expose नहीं करना चाहिए। वह gRPC का मजबूत area नहीं है, और JSON में convert करने वाली custom layer बनाना बेहतर है
      backend services के बीच communication के लिए REST इस्तेमाल करना भी performance requirements हों तो खास मायने नहीं रखता, और अगर कभी-कभार छोटा data लेने वाली call नहीं है, तो human-readable protocol/API इस्तेमाल करने की वजह कमजोर है
    • मुझे याद है कि browser में gRPC API expose करने की कोशिश करते समय मुझसे पूछा गया था कि “JSON जैसा” interface क्यों नहीं बनाया
      oneof subtype में मौजूदा field न होने वाला type return करने पर automatic conversion का result { "id": "id", "sub_type_two": { } } जैसा आया
      functionally यह काम करता है, और बाद में field आ भी जाए तो वह code चलता रहेगा। लेकिन web world में empty object से response type दिखाना अजीब है, और protobuf लिखते समय यह समस्या आसानी से नजर नहीं आती
    • bidirectional streaming को “scale पर” operate करने वाली चीजों के लिए आम तौर पर खराब idea मानता हूं
    • Protobuf streaming के लिए उपयुक्त नहीं है
      कल्पना किए जा सकने वाले लगभग हर binary protocol से तुलना करें, तो यह anti-streaming के करीब है

  • company में gRPC इस्तेमाल करने का मेरा इकलौता अनुभव एक project था जिसे दूसरे senior developer ने “performance चाहिए” कहकर push किया था
    आखिर में frontend को consume कर पाना था, इसलिए JSON API भी बनानी पड़ी, और उस developer के अलावा किसी को gRPC का अनुभव नहीं था। असल में वह developer भी gRPC Python quick start guide से आगे नहीं गया था और bug fixes में भी मदद नहीं की
    project कई वजहों से messy था, और gRPC justify करने लायक scale के करीब भी नहीं पहुंचा
    फिर भी personally थोड़ा इस्तेमाल किया हुआ gRPC मुझे पसंद आया, और लगा कि इसमें कहीं ज्यादा काम और सोच-विचार चाहिए। यह शायद इसलिए भी हो सकता है कि मैंने JSON API बहुत ज्यादा की हैं

    • यह gRPC की खुद की आलोचना से ज्यादा उस “senior” developer पर criticism जैसा लगता है जिसे adoption से पहले यह भी नहीं पता था कि यह browser-compatible नहीं है

  • ConnectRPC https://connectrpc.com/ को मजे से इस्तेमाल कर रहा हूं
    यह gRPC की कई problematic parts को ठीक कर देता है, और उम्मीद है कि Safari अगर WebTransport अपनाएगा तो ConnectRPC बेहतर streaming develop कर सकेगा
    शुरुआत में मुझे https://buf.build overkill लगा था, लेकिन third-party proto files को एक-एक करके download किए बिना import कर पाने वाली capability decisive रही
    deps:
    - buf.build/landeed/protopatch
    - buf.build/googleapis/googleapis
    automatic SDK generation भी बड़ी चीज है। पहले मैं कहने वाला था कि यह करीब 9 languages के लिए SDK auto-generate करता है, लेकिन पिछले एक-दो दिनों में update हुआ है और अब 16 languages, OpenAPI और दूसरी नई features भी दिख रही हैं
    मैं भी gRPC streaming के झूठे वादे से प्रभावित हुआ था, और यह document मेरे अनुभव से बिल्कुल मेल खाता था: https://connectrpc.com/docs/go/streaming/

    • ReactNative में चलाने के लिए ConnectRPC streaming का एक छोटा WebSocket-based wrapper बनाया
      इसके चलते browser में भी bidirectional streaming इस्तेमाल कर सकते हैं
    • फिर भी Protocol Buffers इस्तेमाल कर रहा है, और gRPC में मुझे होने वाली कई समस्याएं वहीं से आती हैं
    • Safari के WebTransport support पर कोई recent update है क्या, यह जानना चाहूंगा

  • ऐसा लगता है जैसे Google ने पूरी industry पर कोई psychological game चला दिया हो, ताकि internal service communication के लिए gRPC इस्तेमाल कराया जाए
    gRPC का developer experience REST से काफी खराब है
    आप किसी को endpoint call करने के लिए एक simple command नहीं दे सकते, और non-standard extra tools की जरूरत पड़ती है। ऊपर से generated client-side code किसी भी language में एक दुर्लभ रूप से बदसूरत ढेर जैसा होता है

    • backend के नजरिये से, मैं इस बात से सख्त असहमत हूं कि gRPC का developer experience REST से खराब है
      protocol में एक बदलाव से static रूप से पता चल जाता है कि किन downstream consumers को update और redeploy करना होगा, जिससे कई हफ्तों का काम एक घंटे के बदलाव में घट सकता है
      यह भी पता रहता है कि जो messages accept और emit होते हैं वे तुरंत validated हैं, और उन्हें बाद में restore करने के लिए सस्ते में store भी किया जा सकता है
      proto से बहुत readable API documentation मिलती है, जो code या business logic में धुंधली नहीं होती। versioning और deprecation semantics भी built-in हैं, और maps को छोड़ दें तो ज्यादा rich data structures भी support होते हैं
      तुलना करें तो backend में JSON bloated और पुराना दिखता है
    • gRPC अहम मायनों में एक standard है
      data types और function signatures लिख दें तो कुछ ऐसा मिलता है जिसे real function की तरह call किया जा सकता है, और serialization/deserialization boilerplate की जगह business logic पर focus कर सकते हैं
      Thrift भी इसी तरह सब कुछ खुद बनाने के मुकाबले बहुत बेहतर है, और मेरे हिसाब से GraphQL और भी अच्छा है
    • कई कंपनियों में मजबूरी में इस्तेमाल किया, लेकिन 99% मामलों में यह अनावश्यक technical debt investment था
      Go में भी regeneration और shared proto version management समझना झंझट है, और हर नई language जुड़ने के साथ यह और खराब होता जाता है
      फिर भी लगता है हर startup को लगता है कि उसे 100 microservices और gRPC चाहिए

  • “अगर API REST API है, तो client को URL format समझने की जरूरत नहीं है, और वह format client को दी जाने वाली API specification का हिस्सा नहीं है” वाला वाक्य Roy Fielding की REST definition से जुड़ता है
    Fielding ने लिखा था कि REST API में initial URI और standardized media types के set के अलावा किसी पूर्व जानकारी के बिना entry होनी चाहिए, और उसके बाद application state के सभी transitions ऐसे होने चाहिए कि client server द्वारा दिए गए विकल्पों में से चुने
    https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
    यह बात पहले ही काफी चर्चा में रही है, लेकिन यह अब भी दिलचस्प है कि असली RESTful system में client को दी जाने वाली “API specification” सिर्फ initial entry point URI/URL होनी चाहिए

    • self-descriptive REST का विचार अब HATEOAS के नाम से ज्यादा जाना जाता है
      निजी तौर पर मुझे यह bloated लगता है और यह असली problem solve नहीं करता
      https://en.m.wikipedia.org/wiki/HATEOAS
    • मुझे जिज्ञासा है कि ऐसी REST API के लिए API client कैसे लिखा जाता है जिसमें सिर्फ initial entry point expose किया गया हो
      खासकर यह समझ नहीं आता कि client manipulable resources या request/response models कैसे discover करे
    • मैं इससे पूरी तरह सहमत नहीं हूं कि असली RESTful system में client को दी जाने वाली API specification सिर्फ initial entry point URI/URL होनी चाहिए
      configuration के लिए ऐसा हो सकता है, लेकिन API specification URL से कहीं ज्यादा होनी चाहिए और system द्वारा इस्तेमाल किए जाने वाले media types को detail में explain करना चाहिए। यानी HTTP request/response bodies का description ज्यादातर जरूरी है
      link में भी कहा गया है कि “REST API को अपना लगभग पूरा descriptive effort उन media type definitions पर लगाना चाहिए जो resources को represent करती हैं और application state को drive करती हैं”
      आखिरकार आप सिर्फ application/json return नहीं कर रहे होते, बल्कि किसी specific +json जैसी चीज return कर रहे होते हैं, और ज्यादातर cases में वह plain JSON नहीं बल्कि application को समझने लायक business data रखता है
      popular discussions में focus सिर्फ initial URL पर रह जाता है, और Fielding ने जो “media type explain करो” कहा था, वह अधिकांश काम गायब हो जाता है। इसलिए “एक URL काफी है” सुनने वाला अगर पूछे “बाकी specification कहां है?” तो यह स्वाभाविक है
    • दोनों एक ही बात पर सहमत हैं। यहां “URL format” का मतलब सचमुच URL का format है, resource format नहीं
      मुझे भी लगा था कि शायद फिर कोई blogger REST नहीं समझ रहा, इसलिए article खोला, लेकिन author कम से कम basic concept जानता लगता है
      मुझे gRPC भी पसंद है और commercial projects में यह काफी आकर्षक है, लेकिन personal या idealistic project हो तो मुझे REST बेहतर लगता है
    • यह उस classic case जैसा है जहां कोई अच्छा idea popular होने के बाद लोग उसे गलत समझकर लगातार फैलाते रहते हैं

  • datacenter के अंदर gRPC इस्तेमाल करना मुझे पसंद नहीं है
    लोग performance के कारण इसे चुनते हैं, लेकिन gRPC को high-performance कहना मुश्किल है, और public client quality भी खासकर C++/Java core implementations के बाहर बहुत कम है। उदाहरण के लिए Node.js implementation ऐसा ही है
    protobuf को API specification के रूप में इस्तेमाल करने के खिलाफ नहीं हूं, लेकिन इसे TCP के ऊपर framing protocol के साथ use किया जा सकना चाहिए। हालांकि उस तरह के RPC में कोई साफ dominant choice नहीं है
    web-based APIs में मैं readable payloads को ज्यादा पसंद करता हूं, लेकिन आमतौर पर JSON इस्तेमाल करने पर type specificity ढीली हो जाती है, जिससे backend languages के बीच interoperability issues पैदा होते हैं। खासकर Node.js में JSON.parse को schema mapping implementation की तरह इस्तेमाल किया जाता है
    इसे ठीक से करने के लिए schema से encoders और decoders explicitly generate करने होंगे, और तब JS context में JSON इस्तेमाल करने का फायदा कुछ हद तक कम हो जाता है

    • अगर performance की चिंता में gRPC consider कर रहे हैं, तो साथ ही Node.js को stack के आसपास रखना क्यों ठीक है, यह जानना चाहूंगा
    • सहमत हूं, और JS schema problem में Zod बहुत मदद करता है
      Microsoft के TypeSpec project पर भी नजर रख रहा हूं: typespec.io
    • proto का मुख्य फायदा कई languages के बीच interoperability है
      single-language tech stack हो तो इसकी अहमियत घट जाती है। और अगर आप Google की main languages के बाहर कुछ इस्तेमाल करते हैं, तो experience उतना अच्छा न होने की संभावना ज्यादा है
    • 2023 में datacenter RPC के लिए non-TCP-based protocol Homa पर एक presentation था: https://youtu.be/xQQT8YUvWg8?si=g3u5TogBe0_QpPpj

  • gRPC, Google के बाहर बाकी लोगों के लिए बेवजह कम accessible लगा
    gRPC JS client बेवजह भारी और काफ़ी opaque है। idea अच्छा है, लेकिन REST की “simplicity” के आदी लोगों की तुलना में execution कमजोर लगता है

    • frontend/backend boundary पर REST/JSON camp और RPC/protobuf/gRPC camp टकराते हैं
      RPC semantically ज़्यादा maintainable है, क्योंकि इसमें data model की cardinality या relationships को किसी एक prescribed pattern में जबरन fit नहीं करना पड़ता। ऐसी दुनिया में जहाँ API तेज़ी से बदलते हैं, सुंदर RESTful entities को सही बैठाना मुश्किल है, और बड़ी teams व बदलती requirements/ownership में service-centric design बेहतर होता है
      frontend side backend systems maintain नहीं करती। वे ऐसा API चाहते हैं जिसे समझना आसान हो, और ऐसी entities चाहते हैं जिन्हें REST से abstract किया जा सके। ऐसे design के असली लाभार्थी वही होते हैं
      REST पर लगने वाली मेहनत उन companies में समझ आती है जो API बेचती हैं और जिनके मुख्य customers third-party developers हैं
      backend development के लिए protobuf और binary wire encoding आसान हैं। API define करके उसे static type तरीके से services के बीच share किया जा सकता है, और message encoding/decoding time भी घटता है। JSON न semantic है, न typed, और overhead भी बड़ा है
      उलट, frontend text और JSON को natively handle करता है। वे protobuf definitions download करना या binary data को second-class citizen की तरह treat करना नहीं चाहते, और यह tools के साथ भी साफ़-सुथरा fit नहीं बैठता
      gRPC में routing, retry, side channels, streaming, protocol deprecation semantics अच्छी तरह शामिल हैं, लेकिन frontend में ये लगभग दिखाई नहीं देते। ये सब backend consumers के लिए हैं
      आखिरकार यह 100% frontend/backend tooling gap है, और interfaces व usability का mismatch है
    • REST, HTML जैसा है
      मूल रूप से source देखा जा सकता है, यह human-readable है, और inspect करना आसान है
      gRPC machines के बीच efficient बातचीत के लिए है, और coding हो या request/response inspection, इंसान के बीच में आने पर यह थोड़ा असुविधाजनक हो जाता है
      context और goals अलग थे, इसलिए usability का यह अंतर समझ में आता है
    • official gRPC JavaScript implementation कुछ खास नहीं है
      मेरी नज़र में buf.build वाली implementation अच्छी है
      https://buf.build/blog/protobuf-es-the-protocol-buffers-type...
    • gRPC अच्छा idea है, लेकिन यह ऐसे Google-style problems के solutions से भारी हो गया है जो मेरे पास नहीं हैं
      लगता है कई लोगों ने इसे इसलिए चुना क्योंकि contract वाला binary RPC जैसा protocol चाहिए था, लेकिन GoLang से जितना दूर जाते हैं, यह उतना ही खराब होता जाता है
    • gRPC के चमकने वाले use cases हैं। streaming उनमें से एक है, जहाँ एक ही “connection” के भीतर message streams को transparently भेजा जा सकता है
      simple CRUD service हो तो REST भी काफ़ी है