14 ms·

Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)

• swyx 2y ago
  always felt like grpc was unnecessarily inaccessible to the rest of us outside google land. the grpc js client unnecessarily heavy and kinda opaque. good idea but poorly executed compared to people who are familiar with the "simplicity" of REST
  • rgbrgb 2y ago
    yes! REST is kind of like HTML... source available by default, human-readable, easy to inspect GRPC is for machines efficiently talking to other machines... slightly inconvenient for any human in the loop (whether that's coding or inspecting requests and responses) The different affordances make sense given the contexts and goals they were developed in, even if they are functionally very similar.
  • pphysch 2y ago
    How could gRPC be simpler without sacrificing performance?
    • liontwist 2y ago
      What kind of performance? Read? Write? Bandwidth?
      • dlahoda 2y ago
        grpc "urls" and data are binary. binary with schema separation. 3x smaller payload.
    • jeeyoungk 2y ago
      There's two parts to gRPC's performance - 1. multiplexing protocol implemented on top of HTTP/2 - 2. serialization format via protobuf For most companies, neither 1 or 2 is needed, but the side effect of 2 (of having structured schema) is good enough. This was the idea behind twrip - https://github.com/twitchtv/twirp https://github.com/twitchtv/twirp - not sure whether this is still actively used / maintained, but it's protobuf as json over HTTP.
  • dlahoda 2y ago
    there are well working (official) generators of openapi/json schemas for grpc. so once you wrote grpc, you get open api rpc for free.
  • dlahoda 2y ago
    afaik grpc did callbacks before we got sse/ws/webrtc/webtransport. so grpc was needed kind of. and also canonical content streaming was in grpc. in http there was no common accepted solution at old times.
    • dilyevsky 2y ago
      Im old enough to have worked with asn.1 and its various proprietary “improvements” as well as SOAP/wsdl and compared to that working with protobuf/stubby (internal google predecessor to grpc) was the best thing since sliced bread
    • coder543 2y ago
      Your memory appears to be incorrect. SSE was first built into a web browser back in 2006. By 2011, it was supported in all major browsers except IE. SSE is really just an enhanced, more efficient version of long polling, which I believe was possible much earlier. Websocket support was added by all major browsers (including IE) between 2010 and 2012. gRPC wasn't open source until 2015.
    • kybernetikos 2y ago
      Even in 2025 grpc is still awful for streaming to browsers. I was doing Browser streaming via a variety of different methods back in 2006, and it wasn't like we were the only ones doing it back then.
  • tempest_ 2y ago
    GRPC is a nice idea weighed down by the fact that it is full of solutions to google type problems I dont have. It seems like a lot of things have chosen it because a "binary" like rpc protocol with a contract is a nice thing to have but the further away from GoLang you get the worse it is.
  • limaoscarjuliet 2y ago
    There are uses where gRPC shines. Streaming is one of them - you can transparently send a stream of messages in one "connection". For simple CRUD service, REST is more than enough indeed.
  • echelon 2y ago
    The frontend / backend split is where you have the REST and JSON camps fighting with the RPC / protobuf / gRPC factions. RPCs have more maintainable semantics than REST as a virtue of not trying to shoehorn your data model (cardinality, relationships, etc.) into a one-size-fits-all prescriptive pattern. Very few entities ever organically evolve to fit cleanly within RESTful semantics unless you design everything upfront with perfect foresight. In a world of rapidly evolving APIs, you're never going to hit upon beautiful RESTful entities. In bigger teams with changing requirements and ownership, it's better to design around services. The frontend folks don't maintain your backend systems. They want easy to reason about APIs, and so they want entities they can abstract into REST. They're the ultimate beneficiaries of such designs. The effort required for REST has a place in companies that sell APIs and where third party developers are your primary customers. Protobufs and binary wire encodings are easier for backend development. You can define your API and share it across services in a statically typed way, and your services spend less time encoding and decoding messages. JSON isn't semantic or typed, and it requires a lot of overhead. The frontend folks natively deal with text and JSON. They don't want to download protobuf definitions or handle binary data as second class citizens. It doesn't work as cleanly with their tools, and JSON is perfectly elegant for them. gRPC includes excellent routing, retry, side channel, streaming, and protocol deprecation semantics. None of this is ever apparent to the frontend. It's all for backend consumers. This is 100% a frontend / backend tooling divide. There's an interface and ergonomic mismatch.
    • eadmund 2y ago
      Protobufs vs. JSON are orthogonal to REST vs. RPC: you can have REST where the representations are protobufs or JSON objects; you can have RPC where the requests and responses are protobufs or JSON objects.
  • kyrra 2y ago
    The official grpc JavaScript implementation is sort of bad. The one by buf.build is good from what I've seen. https://buf.build/blog/protobuf-es-the-protocol-buffers-typescript-javascript-runtime-we-all-deserve https://buf.build/blog/protobuf-es-the-protocol-buffers-type...
  • masterj 2y ago
    You should check out https://connectrpc.com/ https://connectrpc.com/ It's based on grpc but works a lot better with web tooling
• npalli 2y ago
  (2020)
• NAHWheatCracker 2y ago
  My only work experience with gRPC was on a project where another senior dev pushed for it because we "needed the performance". We ended up creating a JSON API anyways. Mostly because that's what the frontend could consume. No one except for that developer had experience with gRPC. He didn't go any deeper than the gRPC Python Quick start guide and wouldn't help fix bugs. The project was a mess for a hundred reasons and never got any sort of scale to justify gRPC. That said, I've used gRPC in bits outside of work and I like it. It requires lot more work and thought. That's mostly because I've worked on so many more JSON APIs.
  • lordofgibbons 2y ago
    That sounds more like a critique of the "senior" developer who didn't know grpc isn't compatible with browsers before adopting it than grpc itself.
    • NAHWheatCracker 2y ago
      Correct, I wasn't critiquing gRPC. I was critiquing a type of person who might push for gRPC. That developer probably thought of it as a novelty and made up reasons to use it. It was a big hassle that added to that teams workload with no upside.
      • reactordev 2y ago
        When all you have is a hammer… gRPC is fantastic for its use case. Contract first services with built in auth. I can make a call to a service using an API that’s statically typed due to code generation and I don’t have to write it. That said, it’s not for browsers so Mr gRPC dev probably had no experience in browser technologies. A company I worked for about 10 years ago was heavy gRPC but only as a service bridge that would call the REST handler (if you came in over REST, it would just invoke this handler anyway). Everything was great and dtos (messages) were automatically generated! Downside was the serialization hit.
        • whoevercares 2y ago
• rednafi 2y ago
  Google somehow psyoped the entire industry to use gRPC for internal service communications. The devex of gRPC is considerably worse than REST. You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized. Plus, the generated client-side code is some of the ugliest gunk you’ll find in any language.
  • echelon 2y ago
    > The devex of gRPC is considerably worse than REST. Hard disagree from the backend world. From one protocol change you can statically determine which of your downstream consumers needs to be updated and redeployed. That can turn weeks of work into a hour long change. You know that the messages you accept and emit are immediately validated. You can also store them cheaply for later rehydration. You get incredibly readable API documentation with protos that isn't muddled with code and business logic. You get baked in versioning and deprecation semantics. You have support for richer data structures (caveat: except for maps). In comparison, JSON feels bloated and dated. At least on the backend.
    • rednafi 2y ago
      My perspective stems from working with it in backend services as well. The type safety and the declarative nature of protobufs are nice, but writing clients and servers isn’t. The tooling is rough, and the documentation is sparse. Not saying REST doesn’t have its fair share of faults, but gRPC feels like a weird niche thing that’s hard to use for anything public-facing. No wonder none of the LLM vendors offer gRPC as an alternative to REST.
    • danpalmer 2y ago
      I also disagree, at Google everything is RPCs in a similar way to gRPC internally, and I barely need to think about the mechanics of them most of the time, whereas with REST/raw HTTP, you need to think about so much of the process – connection lifecycle, keepalive, error handling at more layers, connection pools, etc. However, I used to work in a company that used HTTP internally, and moving to gRPC would have sucked. If you're the one adding gRPC to a new service, that's more of a pain than `import requests; requests.get(...)`. There is no quick and hacky solution for gRPC, you need a fully baked, well integrated solution, rolled out across everyone who will need it.
• Octoth0rpe 2y ago
  Oof, I strongly disagree with this article's description of how REST apis are used, and the distinction between openAPI and rest. If I design a REST api in 2023, and in 2024 produce an openapi yaml or json file for that API with no other changes, is it somehow no longer a REST api? of course not. The article seems to be predicated on this distinction. > The least-commonly used API model is REST Is that true? I don't think it is frankly, though I suppose if any API that would be a REST api _if it didn't have an openapi spec_ is somehow no longer a REST api, then maybe? But as previously stated, I just don't think that's true. > A signature characteristic of [REST APIs] is that clients do not construct URLs from other information I don't think this is true in practice. Let us consider the case of a webapp that uses a REST api to fetch/mutate data. The client is a browser, and is almost certainly using javascript to make requests. Javascript doesn't just magically know how to access resources, your app code is written to construct urls (example: getting an ID from the url, and then constructing a new url using that extracted ID to make an api call to fetch that resource). In fact, the only situation where I think this description of how a REST api is used is _defensibly_ true (and this is hella weak), is where the REST api in question has provided an openapi spec, and from that spec, you've converted that into a client library (example: https://openapi-ts.dev https://openapi-ts.dev). In such a situation, the client has a nice set of functions to call that abstract away the construction of the URL. But somewhere in the client, _urls are still being constructed_. And going back to my first complaint about this article, this contrived situation combines what the article states are two entirely distinct methods for designing apis (rest vs openapi). Re: the article's description of rpc, I actually don't have any major complaints.
  • silisili 2y ago
    You're being way too polite. The article is garbage and completely incorrect about what REST and OpenAPI even are.
    • mvdtnz 2y ago
      You're wrong. The author is using "REST" to mean an API at Level 3 on the Richardson Maturity Model[0] - this was the original conception of what it meant to be a "REST API" before the wider internet decided "REST" meant "nice looking URLs". What he refers to as "OpenAPI APIs" could be called Level 2 Web APIs on the same model. He uses "REST" correctly. He uses "OpenAPI" as a shorthand for the class of web APIs that are resource-based and use HTTP verbs to interact with these resources. [0] https://en.wikipedia.org/wiki/Richardson_Maturity_Model https://en.wikipedia.org/wiki/Richardson_Maturity_Model
• Glyptodon 2y ago
  According to this, what is GraphQL? This article seems like something written with limited or unusual experience.
  • eadmund 2y ago
    > According to this, what is GraphQL? GraphQL is akin to gRPC: a non-HTTP protocol tunnelled over HTTP. Unlike gRPC, I’m unconvinced that GraphQL is ever really a great answer. I think what the latter does can be done natively in HTTP.
    • mdaniel 2y ago
      For all the people singing the praises of how efficient gRPC is, I enjoy countering that the most efficient response is one which doesn't include 99% of data that the client doesn't care about in the slightest GCP (and I believe Azure, too) offer `GET /thing?$fields=alpha,beta.charlie` style field selection but now there's a half-baked DSL in a queryparam and it almost certainly doesn't allow me to actually express what I want so I just give up and ask for the top-level key because the frustration budget is real I for sure think that GraphQL suffers from the same language binding problem as gRPC mentioned elsewhere: if you're stack isn't nodejs, pound sand. And the field-level security problem is horrific to fix for real
      • mplanchard 2y ago
        Efficient in terms of wire transfer sure, but GraphQL tends to wind up generating queries that are quite difficult to optimize at the DB layer, so you wind up spending way more computer and time than you would otherwise need. If you're in an organization where folks with no database knowledge are writing the GraphQL queries, this winds up being a never-ending game of whack-a-mole. For anything performance sensitive, I'd much rather have a nice, optimized endpoint that returns more data than the client needs rather than have the client be able to issue any query they want.
• cyberax 2y ago
  REST is just pure bullshit. Avoid it like a plague. It's a fundamentally flawed model, as it smears the call details across multiple different layers: 1. The URL that contains path and parameters 2. The HTTP headers 3. The request body that can come in multiple shapes and forms (is it a JSON or is it a form?) As a result, OpenAPI descriptions end up looking horrifying, in the best traditions of the early EJB XML descriptors in Java. And don't get me started on leaky abstractions when you want to use streaming and/or bulk operations. In comparison, gRPC is _simple_. You declare messages and services, and that's it. There's very little flexibility, the URLs are fixed. A service can receive and return streams of messages. The major downside of gRPC is its inability to fully run in browsers. But that's fixed by ConnectRPC that adds all the missing infrastructure around the raw gRPC. Oh, and the protobuf description language is so much more succinct than OpenAPI.
  • lordofgibbons 2y ago
    Yeah, I never understood the blind worship of REST. It's just another API style.. and not a good one at that. It is the way it is due to browser limitations. To avoid the complexity you mentioned, one would have to adopt some other tool like OpenAPI and it's code generators. At that point, you might as well use something simpler and plain better: like gRPC.
  • voiceofunreason 2y ago
    "REST is just pure bullshit. Avoid it like a plague." No it isn't. Evidence: I'm reading this in a web browser. "...REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them." Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics? Yeah, _that_ is certainly plague bullshit.
    • cyberax 2y ago
      > No it isn't. Evidence: I'm reading this in a web browser. And you might not that this site is _not_ REST-ful. It's certainly HTTP, but not REST. > Bikeshedding the spelling of resource identifiers? Or what "verb" should be used to express specialized domain semantics? Or whether we want to use If-Modified-Since header or explicitly specify the condition in the JSON body. And 6 months later, with some people asking for the latter because their homegrown REST client doesn't support easy header customization on a per-request basis. Or people trying (and failing) to use multipart uploads because the generated Ruby client is not actually correct. There is _way_ too much flexibility in REST (and HTTP in general). And REST in particular adds to this nonsense by abusing the verbs and the path.
• tyre 2y ago
  > The least-commonly used API model is REST—only a small minority of APIs are designed this way brother.
  • eadmund 2y ago
    Real REST is a very, very small minority. Fake REST (i.e., JSON RPC) is really ridiculously common.
    • deleted 2y ago
      [deleted]
    • mplanchard 2y ago
      I’ve never liked the no true scotsman nature of REST (which is exacerbated by the fact that its canonical “specification” is a broad PhD dissertation with a lot of other concepts thrown in), so I have adopted a fairly lax definition: if your URLs are subjects and you use HTTP verbs for the verbs, I feel like it qualifies.
      • eadmund 2y ago
        Language is a means of communication, and we have to have some sort of agreement on terms. REST had an original meaning; that is a useful thing to be able to discuss. JSON-RPC is also a useful thing to discuss. But the two things are different. It’s confusing to use the one word or phrase to mean two different things (like ‘inflammable’!). Granted, language is to some extent defined by usage: if enough people use a term incorrectly, and few enough people use it correctly, then the incorrect usage becomes correct and the correct incorrect. Fine, we can use ‘REST’ to mean ‘RPC over HTTP with a JSON encoding.’ But could the advocates of that usage propose a term we can all use for what Fielding described in his thesis? Potrzebie? The thing that worries me, is if we start using ‘REST’ to mean JSON-RPC, and ‘Potrzebie’ to mean ‘the style formerly known as REST’: will people start using ‘Potrzebie’ to mean JSON-RPC? Perhaps worse, maybe they will start using it to mean ‘gRPC with JSON encoding.’ I propose that it’s best to use words and phrases for what they originally mean, for as long as one can, and to fight strenuously against changing them. Otherways wun May nyet wit was kood hap.
• recursivedoubts 2y ago
  > If your API is a REST API, then your clients never have to understand the format of your URLs and those formats are not part of the API specification given to clients. Roy Fielding, who coined the term REST: "A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations." https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... I know it's a dead horse, but it's so funny: the "API specification" given to clients, in a truly RESTful system, should only be the initial entry point URI/URL.
  • resonious 2y ago
    Classic case of a good idea going viral, followed by people misunderstanding the idea but continuing to spread it anyway.
  • eadmund 2y ago
    You both agree: when he writes ‘format of your URLs,’ he literally means the format of the URLs, not the format of the resources. Like you, I clicked on the article expecting yet another blogger who doesn’t understand REST but it appears this author has at least some basic knowledge of the concepts. Good for him! I like gRPC too, and honestly for a commercial project it is pretty compelling. But for a personal or idealistic project I think that REST is preferable.
  • curt15 2y ago
    How does one even write an API client against a REST API that only publishes the initial entry point? in particular, how should the client discover the resources that can be manipulated by the API or the request/response models?
    • AdieuToLogic 2y ago
• bitzun 2y ago
  Unless you are doing bidirectional streaming (for which it seems pretty well suited, but I haven't used it, so it might be a fucking mess), grpc is usually a waste of time. Runtime transitive dependency hell, toolchain hell, and the teams inside Google that manage various implementations philosophically disagree on how basic features should work. Try exposing a grpc api to a team that doesn't use your language (particularly if they're using a language that isn't go, python or java, or is an old version of those.) Try exposing a grpc api to integrate with a cots product. Try exposing a grpc api to a browser. All will require a middleware layer.
  • deleted 2y ago
    [deleted]
  • lordofgibbons 2y ago
    I've used grpc at multiple companies and teams within these companies, all of them 100-500ish engineering team size, and never had these dependency and tool chain issues. It was smooth sailing with grpc.
    • hamandcheese 2y ago
      I have worked full time at now two companies of that size making the dependency and tool chain problems not be a problem for all the normies.
  • aaomidi 2y ago
    Bidirectional streaming is generally a bad idea for anything you’re going to want to run “at scale” for what it’s worth.
    • mvdtnz 2y ago
      Why do you say that? I'm involved in the planning for bidi streaming for a product that supports over 200M monthly active users. I am genuinely curious what landmines we're about to step on.
• gghoop 2y ago
  I dislike the use of gRPC within the data center. People reach for it citing performance, but gRPC is not high performance and the quality of the available open source clients is very poor, particularly outside of the core C++/Java implementations like the nodejs implementation. I am not against the use of protobuf as an API spec but it should be possible to use it with a framing protocol over TCP, there just isn't a clear dominant choice for that way of doing RPC. When it comes to web based APIs I am more in favour of readable payloads, but there are issues here since we tend to use JSON but the type specificity is loose, which leads to interop problems between backend languages, particularly in nodejs where JSON parse is used to implement a schema mapping. In order to do this properly, encoders and decoders need to be generated explicitly from schemas, which somewhat diminishes the use of JSON within the context of JS.
  • jahewson 2y ago
    I agree, though Zod greatly helps with the JS schema issue. I’m keeping an eye on Microsoft’s TypeSpec project too: typespec.io for interoperable schema generation.
  • mvdtnz 2y ago
    In what situation is performance enough of a concern that you would consider gRPC but not enough of a concern that you would let nodeJS anywhere near your stack?
    • gghoop 2y ago
      No one is picking Nodejs for high performance, but when it is chosen for other reasons it's still expected to perform well. The Nodejs gRPC library performs poorly relatively to the overall performance characteristics of Nodejs, and this is a problem because most of the work performed by typical Nodejs services is API-related work (sending data, encoding and decoding payloads, managing sockets etc). That's not even touching on the bugs in the http2 implementation in node core or the grpc library itself, but much of the selling point of gRPC is supposedly the language interop, and this seems like false advertising to me.
• awinter-py 2y ago
  unless you want to be locked into a cursed ecosystem where you spend all your time reimplementing libraries that have existed for decades in rest land, fighting code generators that produce hideous classes that will randomly break compatibility, and debugging random edge-casey things in your hosting stack bc nobody truly supports h2, steer clear of grpc 'rest' isn't anything (complementary)
• jijji 2y ago
  This article is more of a marketing / paid endorsement for"gRPC" than something that is speaking any truth. The article mentions that "the least used" API method is REST, and I would argue, as would almost any developer (except google employees) would argue that gRPC is the least used and REST is by far the most widely adopted method.
  • 9rx 2y ago
    The article is using REST in the original sense, and defines it as such to dispel any confusion with any other usage. There is no way it is the most widely adopted method. To ever get to see a REST service in the wild is like winning the lottery.
• turnsout 2y ago
  I like this article format. Here, let me try. In my opinion, there are three significant and distinct formats for serializing data: - JSON - .NET Binary Format for XML (NBFX) - JSON Schema JSON: The least-commonly used format is JSON—only a small minority use it, even though the word JSON is used (or abused) more broadly. A signature characteristic of JSON is that the consumer of JSON can never know anything about the data model. NBFX: A second serialization model is NBFX. The great thing about NBFX is that nobody has to worry about parsing XML text—they just have to learn NBFX. JSON Schema: Probably the most popular way to serialize data is to use something like JSON Schema. A consumer of JSON Schema just reads the schema, and then uses JSON to read the data. It should be obvious that this is the total opposite of JSON, because again, in JSON it's illegal to know the format ahead of time.
  • jackman3005 2y ago
    This is great. I feel like this speaks to the strangeness of how this article was written perfectly.
• toprerules 2y ago
  As someone who has worked at a few of the FAANGs, having thrift/grpc is a godsend for internal service routing, but a lot of the complexity is managed by teams building the libraries, creating the service discovery layers, doing the routing etc. But using an RPC protocol enables those things to happen on a much greater scale and speed than you could ever do with your typical JSON/REST service. I've also never seen a REST API that didn't leak verbs. If I need to build a backend service mesh or wire two local services together via an networked stream, I will always reach for grpc. That said, I absolutely would not use grpc for anything customer or web facing. RPC is powerful because it locks you into a lot of decisions and gives you "the one way". REST is far superior when you have many different clients with different technology stacks trying to use your service.
  • jitl 2y ago
    For a public API I wouldn’t do this, but for private APIs we just do POST /api/doThingy with a JSON body, easy peasy RPC anyone can participate in with the most basic HTTP client. Works great on every OS and in every browser, no fucking around with “what goes in the URL path” vs “what goes in query params” vs “what goes in the body”. You can even do this with gRPC if you’re using Buf or Connect - one of the server thingies that try not to suck; they will accept JSON via HTTP happily.
    • pandemic_region 2y ago
      This. The amount of time lost debating correct rest semantics for a use case is staggering.
      • spelunker 2y ago
        Arguing the Right Way To Do REST was a favorite passtime amongst people at one of my previous jobs. Huge waste of time.
      • porridgeraisin 2y ago
        Yeah, when it matters in close to 0% of cases. Everyone reads the docs for everything anyways, any shared knowledge granting implicit meaning to things is very close to useless in practice with REST APIs.
• ray_v 2y ago
  Is this basically gaslighting us on what REST APIs are, it is it just me?
  • deathanatos 2y ago
    No. Most people, when they use "REST", do so incorrectly. The article is right, for example, that one of the requirements in the definition of REST was the use of URLs to identify resources: > REST uses a resource identifier to identify the particular resource involved in an interaction between components. (And it goes on to cite URLs as an example of a resource identifier in REST as applied to the modern web; note that "REST" is an architectural style to describe the design of systems, the web is an application of that style.) Many allegedly RESTful APIs simply don't do that, and instead you'll see something like, {"id": 32, …} Particularly so when combined with tightly coupled URL construction. There are other facets of REST that you could compare to most JSON/HTTP APIs and find that they don't obey that facet, either.
• msoad 2y ago
  I think everyone who worked at Google in the past has PTSD from having to migrate gRPC schemas. What a mess! Type safety doesn't have to be this costly
• toasted-subs 2y ago
  If google offer the ability to fuck up other people's lives should they be financially liable for the costs associated to return the individual to the state prior of the abuse?
• kittikitti 2y ago
  Security usually allows simple HTTP requests and REST is the quickest way to get started.
• 0xbadcafebee 2y ago
  Keep in mind gRPC is not stable over the internet; middleboxes love to break it (looking at you, Google Cloud, exposing some of your services as gRPC-only APIs)
• est 2y ago
  If you don't have a monorepo in your org, don't use gRPC. Specifically, if you can't maintain those .proto mess inside one single source of truth, you're probably fucked. If devs are afraid of updating .proto and adding many `context` or `extra` or `extension` fields, you are fucked. Get rid of gRPC ASAP! Look are your .proto definitions, if there are tons of <str,str> mapping or repeated key-value pairs, just forget gRPC, use JSON. Need performance? Use msgpack!
• jdwyah 2y ago
  If I could go back in time I would stop myself from ever learning about gRPC. I was so into the dream, but years later way too many headaches. Don’t do it to yourself. Saying gRPC hides the internals is a joke. You’ll get internals all right, when you’re blasting debug logging trying to figure out what the f is going on causing 1/10 requests to fail and fine tuning 10-20 different poorly named and timeout / retry settings. Hours lost fighting with maven plugins. Hours lost debugging weird deadline exceeded. Hours lost with LBs that don’t like the esoteric http2. Firewall pain meaning we had to use Standard api anyway. Crappy docs. Hours lost trying to get error messages that don’t suck into observability. I wish I’d never heard of it.
  • hedora 2y ago
    The biggest project I’ve used it with was in Java. Validating the output of the bindings protoc generated was more verbose and error prone than hand serializing data would have been. The wire protocol is not type safe. It has type tags, but they reuse the same tags for multiple datatypes. Also, zig-zag integer encoding is slow. Anyway, it’s a terrible RPC library. Flatbuffer is the only one that I’ve encountered that is worse.
    • TeeWEE 2y ago
      What do you mean with validating the bindings? GRPC is type safe. You don’t have to think about that part anymore. But as the article mentions OpenAPI is also an RPC library with stub generation. Manual parsing of the json is imho really Oldskool. But it depends on your use case. That’s the whole point: it depends.
    • matrix87 2y ago
      > The wire protocol is not type safe. It has type tags, but they reuse the same tags for multiple datatypes. When is this ever an issue in practice? Why would the client read int32 but then all of a sudden decide to read uint32?
      • sagarm 2y ago
        I guess backwards incompatible changes to the protocol? But yeah, don't do that if you're using protobuf; it's intentionally not robust to it.
• abalaji 2y ago
  Everyone is hating on gRPC in this thread, but I thought I'd chime in as to where it shines. Because of the generated message definition stubs (which require additional tooling), clients almost never send malformed requests and the servers send a well understood response. This makes stable APIs so much easier to integrate with.
  • inetknght 2y ago
    > Because of the generated message definition stubs (which require additional tooling), clients almost never send malformed requests and the servers send a well understood response. Sure. Until you need some fields to be optional. > This makes stable APIs so much easier to integrate with. Only on your first iteration. After a year or two of iterating you're back to JSON, checking if fields exist, and re-validating your data. Also there's a half dozen bugs that you can't reproduce and you don't know why they happen, so you just work around them with retries.
    • hedora 2y ago
      There’s also a gaping security hole in its design. They don’t have sane support for protocol versioning or required fields, so every field of every type ends up being optional in practice. So, if a message has N fields, there are 2^N combinations of fields that the generated stubs will accept and pass to you, and its up to business logic to decide which combinations are valid. It’s actually worse than that, since the other side of the connection could be too new for you to understand. In that case, the bindings just silently accept messages with unknown fields, and it’s up to you to decide how to handle them. All of this means that, in practice, the endpoints and clients will accumulate validation bugs over time. At that point maliciously crafted messages can bypass validation checks, and exploit unexpected behavior of code that assumes validated messages are well-formed. I’ve never met a gRPC proponent that understands these issues, and all the gRPC applications I’ve worked with has had these problems.
      • kybernetikos 2y ago
        > every field of every type ends up being optional in practice. This also means that you cant write a client without loads of branches, harming performance. I find it odd that grpc had a reputation for high performance. Its at best good performance given a bunch of assumptions about how schemas will be maintained and evolved.
• jon_richards 2y ago
  I've been having fun with connectrpc https://connectrpc.com/ https://connectrpc.com/ It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming. I initially thought https://buf.build https://buf.build was overkill, but the killer feature was being able to import 3rd party proto files without having to download them individually: deps: - buf.build/landeed/protopatch - buf.build/googleapis/googleapis The automatic SDK creation is also huge. I was going to grab a screenshot praising it auto-generating SDKs for ~9 languages, but it looks like they updated in the past day or two and now I count 16 languages, plus OpenAPI and some other new stuff. Edit: I too was swayed by false promises of gRPC streaming. This document exactly mirrored my experiences https://connectrpc.com/docs/go/streaming/ https://connectrpc.com/docs/go/streaming/
  • thayne 2y ago
    It still uses protocol buffers though, which is where many of the problems I have with gRPC comes from
    • jon_richards 2y ago
      The auto-generated SDKs are very useful here. An API customer doesn't have to learn protobuf or install any tooling. Plus they can fall back to JSON without any fuss. Connectrpc is much better at that than my envoy transcoder was. If you're thinking from the API author's point of view, I might agree with you if there was a ubiquitous JSON annotation standard for marking optional/nullable values, but I am sick of working with APIs that document endpoints with a single JSON example and I don't want to inflict that on anyone else.
    • masterj 2y ago
      You can also choose to use JSON instead. Works great with curl and browser dev tools.
    • 9rx 2y ago
      It doesn't use protocol buffers any more than gRPC does, which is to say it only uses them if you choose to use them. gRPC is payload agnostic by design. Use CSV if you'd rather. It's up to you.
• 0xbadcafebee 2y ago
  What's funny is none of these are very good, but they're now the most common standards. They are designs to be sure. But they lack the one thing that makes a standard valuable: not having to do a bunch more work every time you want to work with a single new application. The idea many of you were literally raised with, that you have to look up an application's specific functions, and write your own code to specifically map to the other application's specific functions? That basically didn't exist before, like, 2000. Look at any network protocol created before HTTP (that wasn't specific to a single application). A huge number of them (most of them?) are still in wide use today. And basically none of them require application-specific integration. FTP, SSH, Telnet, SMTP, DNS, TFTP, HTTP, POP3, SUNRPC, NNTP, NTP, NetBIOS, IMAP, SNMP, BGP, Portmap, LDAP, SMB, LDP, RIP, etc. All layer-7, all still used today, decades after they were created. And every single application that uses those protocols, is not custom-built to be aware of every other application that uses that protocol. They all just work together implicitly. There's almost no benefit to even using gRPC, OpenAPI, REST, etc. You could come up with a completely new L7 protocol, and just say "if you want to be compatible with my app, you have to add support for my new protocol. here's my specification, good luck.". Sure there are benefits on the backend for transmogrifying, manipulating, re-routing, authenticating, monitoring, etc the underlying protocols. But as far as the apps themselves are concerned, they still have to do a ton of work before they can actually communicate with another app. One other app. Now it's a feature. People brag about how many integrations they did to get app A to work with apps B, C, D, E, F, G. Like Oprah for protocols. "You get custom code, and you get custom code, and you get custom code, and you get custom code! You all need custom code to work with my app!" You could say, oh, this is actually wonderful, because they're using a common way to write their own layer-8 protocols! But they're not even protocols. They're quirky, temporary, business logic, in a rough specification. Which is the way the big boys wanted it. Corporations didn't want to have to abide by a specification, so they decided, we just won't support any applications at all, except the ones we explicitly add code to support. So application A can talk to apps B and C, but nothing else. It's ridiculous. We regressed in technical capability. But it has to be this way now, because the OS is no longer the platform, the Web Browser is. No protocol can exist if it's not built into the browser. The bullshit people try to sell you about "middleboxes" is bullshit because middleboxes only matter when all the apps are on a Web Browser. Take away the web browser and middleboxes have no power. If the entire internet tomorrow stopped using HTTP, there would literally be no choice but to do away with middleboxes. But we won't go there, because we won't get rid of the web browser, because we like building abstractions on abstractions on abstractions on abstractions on abstractions. People get dumber, choices get smaller, solutions get more convoluted. C'est la vie. The enshittification of technology marches on.
• whoevercares 2y ago
  Netflix, Coinbase, Spotify and several big/medium tech company pretty much all in gRPC. I guess there must be a problem with the haters here who could not get the value
• oppositelock 2y ago
  I've been building API's for a long time, using gRPC, and HTTP/REST (we'll not go into CORBA or DCOM, because I'll cry). To that end, I've open sourced a Go library for generating your clients and servers from OpenAPI specs (https://github.com/oapi-codegen/oapi-codegen https://github.com/oapi-codegen/oapi-codegen). I disagree with the way this article breaks down the options. There is no difference between OpenAPI and REST, it's a strange distinction. OpenAPI is a way of documenting the behavior of your HTTP API. You can express a RESTful API using OpenAPI, or something completely random, it's up to you. The purpose of OpenAPI is to have a schema language to describe your API for tooling to interpret, so in concept, it's similar to Protocol Buffer files that are used to specify gRPC protocols. gRPC is an RPC mechanism for sending protos back and forth. When Google open sourced protobufs, they didn't opensource the RPC layer, called "stubby" at Google, which made protos really great. gRPC is not stubby, and it's not as awesome, but it's still very efficient at transport, and fairly easy too extend and hook into. The problem is, it's a self-contained ecosystem that isn't as robust as mainstream HTTP libraries, which give you all kinds of useful middleware like logging or auth. You'll be implementing lots of these yourself with gRPC, particularly if you are making RPC calls across services implemented in different languages. To me, the problem with gRPC is proto files. Every client must be built against .proto files compatible with the server; it's not a discoverable protocol. With an HTTP API, you can make calls to it via curl or your own code without having the OpenAPI description, so it's a "softer" binding. This fact alone makes it easier to work with and debug.
  • physicles 2y ago
    > There is no difference between OpenAPI and REST, it's a strange distinction. That threw me off too. What the article calls REST, I understand to be closer to HATEOAS. > I've open sourced a Go library for generating your clients and servers from OpenAPI specs As a maintainer of a couple pretty substantial APIs with internal and external clients, I'm really struggling to understand the workflow that starts with generating code from OpenAPI specs. Once you've filled in all those generated stubs, how can you then iterate on the API spec? The tooling will just give you more stubs that you have to manually merge in, and it'll get harder and harder to find the relevant updates as the API grows. This is why I created an abomination that uses go/ast and friends to generate the OpenAPI spec from the code. It's not perfect, but it's a 95% solution that works with both Echo and Gin. So when we need to stand up a new endpoint and allow the front end to start coding against it ASAP, the workflow looks like this: 1. In a feature branch, define the request and response structs, and write an empty handler that parses parameters and returns an empty response. 2. Generate the docs and send them to the front end dev. Now, most devs never have to think about how to express their API in OpenAPI. And the docs will always be perfectly in sync with the code.
• eichi 2y ago
  We should use gRPC only after conducting proper domain driven architect. Properly categorizing classes into domain/services/infra is more important.
• bigmutant 2y ago
  Never really understood the folks pushing for RPC-over-HTTP. RPC is for systems that are close together (ie intra-DC). These simple rules work well: 1. JSON-over-HTTP for over the web 2. RPC (pick your flavor) for internal service-to-service I will say that Amazon's flavor (Coral-RPC) works well and doesn't come with a ton of headache, its mostly "add ${ServiceName}Client to build" and incorporate into the code. Never mind its really odd config files Related note, I've never understood why Avro didn't take off over GRPC, I've used Avro for one project and it seems much easier to use (no weird id/enumerations required for fields) while maintaining all the code-gen/byte-shaving
  • khana 2y ago
    [dead]
  • 9rx 2y ago
    > 1. JSON-over-HTTP for over the web So literally gRPC[1]? You make it sound like there is a difference. There isn't, really. What gRPC tried to bring to the table was establishing conventions around the details neither HTTP or JSON define, where otherwise people just make things up haphazardly with no consistency from service to service. What gRPC failed on in particular was in trying to establish those conventions on HTTP/2. It was designed beside HTTP/2 with a misguided sense of optimism that browsers would offer support for HTTP/2 once finalized. Of course, that never happened (we only got half-assed support), rendering those conventions effectively unusable there. [1] I'll grant you that protobufs are more popular in that context, but it is payload agnostic. You can use JSON if you wish. gRPC doesn't care. That is outside of its concern.
• TeeWEE 2y ago
  It depends. That’s the whole point. I see a lot of people here saying one is better than the other. But it depends on your use case and company size. GRPC is a lot more complex to start using and hides internals. However it has some major advantages too like speed, streaming, type safety, stub generation. Once you have it in place adding a function is super easy. The same can be said of OpenAPI. It’s easier to understand. Builds upon basic REST tech. However JSON parsing is slow, no streaming and has immature stub generation. From my experience a lot of users who use OpenAPI only use it to generate a spec from the handwritten endpoints and do manual serialization. This is the worst of the two worlds. - manual code in mapping json to your objects - manual code mapping function parameters to get params or json - often type mapping errors in clients Those engineers often don’t understand that OpenAPI is capable of stub generation. Let alone understand GRPC. GRPC saves a lot of work once in place. And is technical superior. However it comes at a cost. I’ve seen OpenAPI generated from routes, with generated clients libs work really well. This requires some time to setup because you can hardly use OpenAPIGenerator out of the box. But once setup I think it hits a sweet spot: - simple: http and json - can be gradually introduced from hardcoded manual json serialization endpoint (client and server) - can be used as an external api - allows for client lib generation But it really depends on your use case. But to dismiss GRPC so easily mainly shows you have never encountered a use case where you need it. Once you have it in place it is such a time saver. But the same holds for proper OpenAPI RPC use. However my inner engineer hates how bad the tooling around OpenAPI is, the hardcoded endpoints often done instead of server stubs, and the amount of grunt work you still need todo to have proper client libs.
• eichi 2y ago
  And only needed when the product is good and company's size scaled.
• justinl33 2y ago
  I disagree that OpenAPI is just RPC mapped to HTTP. A well-designed OpenAPI spec can be quite RESTful. The problem is many developers don't take the time to design good resource models and just slap RPC-style operations into URL paths.
• justinl33 2y ago
  entity-oriented models are more stable over time compared to procedure-oriented RPC. In my experience, starting with resources/entities and mapping operations to them does lead to cleaner APIs that are easier to evolve.
• matrix87 2y ago
  I feel like this article just discusses API semantics, which just feels like a bunch of pedantic best-practices with no actual substance. It doesn't mention any of the things that gRPC offers that the alternatives don't offer, which you would expect from a google article of all places Would've been nice if they talked about how schema evolution is different in both cases, bidirectional streaming, or performance differences for different workloads
• bushbaba 2y ago
  gRPC is an anti-pattern for 99% of services. HTTP + JSON is the better choice in 99% of decisions. For high scale, HTTP + <Binary Payload> gets you most the way there. gRPC's design while a great technical achievement, is overly complex.
• larusso 2y ago
  I generally like the article. I wished the REST concept would have been explained with some code / payload examples though. Other the that it managed to steer me away from gRPG. All the cons he mentioned are huge deal breakers in my opinion. I would only consider if I can control both server and client and its implementation details (tech stack in this case). But he addressed some issues with OpenAPI I constantly struggle with. And the fact that seemingly none is able to say what the standard is for certain patterns. And don’t get me started with OData …
• rswail 2y ago
  The problem with gRPC is the "R". It's been the same with JMI, Corba, ONC-RPC and all the others. Making "procedure calls" remote and hiding them underneath client libraries means that programmers do not consider the inherent problems of a networked environment. Problems like service discovery, authentication, etc are hidden beneath something that "looks like" a local procedure call. That's one problem, the other is that procedure calls are focusing on the verbs, not the nouns (called "entities" or "resources" in the article). If you can't express an FSM about a noun and what causes its state to change, then how the hell do you know what it does or how changes to its environment affect it? If you don't know whether some procedure call is idempotent, how the hell can you write code that handles the various network failure modes that you have to deal with?
  • thayne 2y ago
    That is a problem, certainly, but not the only one.
    • rswail 2y ago
      My point is that "procedure calls" have always covered up failure modes and making them "remote" papers over all of the problems of distributed computing. The other problem with "procedure calls" is they are imperative and grow without any constraints on their implementation without very careful design and review. The functionality of the "procedure" is unbound and has unknown dependencies and side effects.
  • divan 2y ago
    https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf
• thayne 2y ago
  My experience with grpc was not good. I was writing some python code to interface with etcd. At least at the time there wasn't a library compatible with etcd 3 that met my needs, and I only needed to call a couple of methods, so I figured I'd just use grpc directly, no big deal right? So I copied the proto files from the etcd project to mine, then tried to figure out how to use protoc to generate python client code. The documentation was a little lackluster, especially on how to generate annotations for use with mypy or pyright, but whatever, it wasn't too hard to figure out the right incantation. Except it didn't work. The etcd proto files had some annotations or includes or something that worked fine with the golang implementation, but didn't work with the Python implementation. I thought the proto files were supposed to be language agnostic. Well after a couple hours of trying to get the files working as is, I gave up and just modified the proto files. I deleted most of it, except for the types and methods I actually needed, got rid of some annotations, and I think I ended up needing to add some python specific annotations as well. Then I finally got some python code, and a separate file for type annotations. But I still have issues. Eventually, I figured out that what was happening was that the package hierarchy of the proto files, and imports in those files has to match the python package names, and it uses absolute, rather than relative, imports. Ok, so surely there is an option to pass to protoc to add a prefix package to that, so I can use thes files under my own namespace right? Nope. Alright, I guess I have to update these protoc files again. It'll be a pain if I ever need to update these to match changes upstream. Ok, now the code is finally working, let's make sure the types check. No. MyPy gives me errors. In the generated code. At first I assume I did something wrong, but after much investigation, I determine that protoc just generates type annotations that are not just wrong, but invalid. It annotates global variables as class variables, which MyPy, rightly, complains doesn't make sense. To fix this I resort to some hackery that I saw another python project use to fix the import issue I mentioned earlier: I use sed to fix the pyi file. Is it hacky? Yes, but at this point, I don't care. I assume that other people have had a better experience, given its popularity, but I can't say I would be happy to use it again.
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• nprateem 2y ago
  The lack of first class js support just kills it. Having to use middleware that doesn't work too well on AWS is the nail in the coffin. It's different if you've drunk the microservices koolaid but for normal projects it doesn't help generate front-end client API libs like you'd hope.
• bborud 2y ago
  One thing that plagues almost all API solutions where you have to generate code is that the vast majority of code generators are bad, and often the code they generate is ugly. I've never understood why so many code generators are so fiddly. They are supposed to parse text and produce text as output. You would think that it would be possible to do this without involving all manner of junk dependencies. It reminds me of what I refer to as "the most important slide in software engineering". It was a slide by Sterling Hughes (PHP, MyNewt etc) from a presentation I can no longer remember the details of. But the slide simply said "nobody cares if it works for you". In the sense that if you write code that other people are supposed to use, do make an effort to put yourself in their place. Sterling was probably 16-17 at the time, and worked as a paid intern where I worked. But despite his young age, he managed to express something that most of us will never fully take on board. Whenever I get an OpenAPI yaml file instead of a client library for some system I know things are going to be frustrating.
• rollulus 2y ago
  Lot of gRPC hate here. I like gRPC in terms of an API specification, because one only needs to define the “what”, whereas OpenAPI specs are about the “how”: parameter in path, query, body? I don’t care. Etc. Plus the tooling: we ran into cases where we could only use the lowest common denominator of OpenAPI constructs to let different tech stacks communicate because of orthogonal limitations across OpenAPI codegenerators. Plus, Buf’s gRPC linter that guarantees backwards compatibility. Plus fewer silly discussions with REST-ish purists: “if an HTTP endpoint is idempotent should deleting the same resource twice give a 404 twice?” - dude, how’s that helping the company to make money? Plus, easier communication of ideas and concepts between human readers of the (proto) spec.
  • robertlagrant 2y ago
    > Plus fewer silly discussions with REST-ish purists: “if an HTTP endpoint is idempotent should deleting the same resource twice give a 404 twice?” - dude, how’s that helping the company to make money? It helps by trying to map standard metaphors to your company's concepts instead of inventing bespoke return types for your company's concepts. You still need to decide whether or not to indicate that the resource is either not there, or was never there.
• zigzag312 2y ago
  Does anyone use gRPC-Web? What do you use it for and how would you rate your experience with it?
• daco 2y ago
  Question: I have a really simple game, but seeing latency issue when users aren't near the servers. Using websocket w json format to send data. Would moving to protobuff help?
  • nprateem 2y ago
    No
• lpapez 2y ago
  I've come to the conclusion that whatever the question is, gRPC isn't the answer unless you are working on Google backend. The performance benefit they mention comes at the cost of (un)debugability of the binary protocol, and the fact that the interface definition language requires client code generation just further deepens the existing moats between teams because of diverging tooling and explicit boundaries drawn up by said contract. IMO gRPC mostly ends up used as a band-aid for poor cross-team collaboration, and long-term worsens the symptoms instead of fixing the core issue. The fact that it's PITA to use is secondary, but significant too.
• jillesvangurp 2y ago
  What a load of nonsense. OpenAPI is a documentation standard for HTTP APIs. So, this is an apples and oranges comparison that starts off on the wrong premise. Some of those APIs might be REST APIs in the strict hypermedia/ HATEOAS sense as popularized twenty years ago by some proponents of this. However, looking back that mostly did not get very popular. I actually met with Jim Webber a couple of times. He co-authored "REST in Practice", which is sort of the HATEOAS bible together with the og. HTTP spec by mr. REST Roy Fielding. Lovely guy but I think he moved on from talking a lot about that topic. He's been at neo4j for more than a decade now. They don't do a lot of HATEOAS over there. I remember having pointless debates about the virtues of using the HTTP Patch method with people. Thankfully that's not a thing anymore. Even Jim Webber was on the fence about that one. Most people these days are less strict on this stuff and might create generic HTTP REST APIs that may or may not do silly things as making every request an HTTP POST like SOAP, Graphql, and indeed Grpc tend to do. Which is very un HATEOAS like but perfectly reasonable if you are doing some kind of RPC. Most APIs trying to do some of notion of REST can and probably should be documented. For example using OpenAPI. Most modern web frameworks support OpenAPI directly or indirectly and are nominally intended to support creating such REST APIs. There's very little reason not to support that if you use those. Things like Spring Boot, FastAPI, etc. all make this pretty easy. Your mileage may vary with other frameworks. Grpc is a binary RPC protocol that gets used a lot for IMHO mostly invalid reasons and assumptions. Some of those assumptions relate to assuming applications spend a lot of time waiting for network responses and parsing to happen and that making responses smaller and easier to parse makes a significant impact. That's only true for a very narrow set of use cases. In reality, textual responses compress pretty well and things like JSON parsers are pretty fast. Those two together mean that the amount of bytes transferred over the network does not really change significantly when you use Grpc and the time waiting for parsing relative to waiting for the network IO is typically orders of magnitudes less. Which leaves plenty of CPU time for parsing and decompressing stuff. This was a non issue 20 years ago. And it still is. I routinely added compression headers to web servers twenty years ago because there were no downsides to doing that at the time (minimal CPU overhead, meaningful network bandwidth savings). Parsers were pretty decent 20 years ago. Etc. Using RPC style APIs (not just grpc) has two big issues: - RPC protocols tend to be biased to specific implementations and languages and rely on code generation tools. This can make them hard to use and limited at the same time. - They tend to leak internal implementation details because the APIs they expose are effectively internal APIs. The two combined makes for lousy APIs. If you want an API that is still relevant in a decade or so, you might want to sit down and think a little. A decade is not a lot of time. There are lots of REST APIs that have been around for that long. Most RPC APIs from that long ago are a bit stale at this point. Even some of the RPC frameworks themselves have gone a bit stale. Good luck interfacing with DCOM or Corba services these days. Or SOAP. I'm sure there's a poor soul out there wasting time on supporting that shit in e.g. Rust or some other newish language. But don't get your hopes up.
• robertlagrant 2y ago
  This article seems to make the mistake of thinking that things are either full Roy Fielding REST or it's RPC. OpenAPI is not similar to gRPC because it's noun-oriented, not verb-oriented. gRPC is more like SOAP: ignore HTTP semantics and write method calls and we'll sort it out. OpenAPI is somewhere on the path to full REST: few verbs; lots of nouns.
• bilekas 2y ago
  > The problem is that MVPs don’t actually establish whether the team /could/ get to a finished product, and in practice many can’t. Isn't that WHY you go to investors? To get the funding to hire to get it to market?
• crabbone 2y ago
  This post is exactly how I imagine people who only ever worked at Google to think. This has been my experience from having to work at Google and to work with Google. Bizarre definitions of commonly used words. Huge emphasis on in-house tech, which is mediocre at best. Extraordinary claims supported by fictional numbers. I think, there used to be a culture where employees scored some brownie points by publishing blogs. You'd need those points to climb the ranks or to just even keep your job. This blog reads as one of those: nothing of substance, bunch of extraordinary claims and some minutia about Google's internal stuff that's of little consequence to anyone outside the company. I mean... choosing gRPC of all things to illustrate RPC, when there's actual Sun's RPC in every Linux computer is just the cherry on top.
• afiodorov 2y ago
  I’ve generally regarded gRPC as a high-performance protocol mainly suited for connecting microservices—something you’d keep internal rather than expose publicly. But it shines in use cases like live captioning, where a transcription service has to stay in sync with a video feed and can’t afford dropped messages. In my experience, using plain WebSockets for high-throughput internal communication was a mistake because while WebSockets use TCP underneath, they don’t inherently handle reconnection or message acknowledgments. With gRPC, those features come built-in, saving you from implementing them yourself.
• taeric 2y ago
  By far the worst part of OpenAPI is how aspirational the documentation seems to remain. It seems it is always leveraging things that almost worked in the previous version with advice on how it should be done. But if you do the new way, expect that about half of the tooling you find won't work. It really is WSDL all over again. Where if you buy in to a specific vendor's tooling, and don't leave it, things actually do mostly work as advertised. You want to piecemeal anything, and holy crap at the unexpected pitches.
• bmilleare 2y ago
  I'm not sure why the article picks these 3 options as if that's it. An RPC API can happily exist over plain old HTTP/1 (no protobuf required) and it also doesn't mention the primary benefit of RPC over REST/RESTish (IMO) - and that's the ability to stack multiple RPC calls into a single request.
• fxgvx 2y ago
  Tgfgyvvvgggggvv
• fxgvx 2y ago
  C rtrrgehevvrrhg33g
• quentinlemcode 2y ago
  > The least-commonly used API model is REST IMHO that's not true. We could argue that the REST name is abused, but it's the word commonly used to describe a stateless API that use HTTP with URI trough verbs (GET, POST, PUT, DELETE, PATCH). This article seems opinionated towards gRPC