Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cloud.google.com

Post reply on HN
Print view View original

21–30 of 286 posts

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

#21

Post by turnsout »

Octoth0rpe wrote: post #16

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…

Yeah, the author has an extremely idiosyncratic take on the definition of REST which is either based on a misunderstanding, or a fundamentalist view of "pure" REST.

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

#23

Post by kyrra »

swyx wrote: post #2

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

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-type...

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

#24

Post by rednafi »

echelon wrote: post #19
rednafi wrote: post #13

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.

> 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 rea…

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.

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

#25

Post by sitzkrieg »

rednafi wrote: post #13

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.

i agree, was forced to use it at several companies and it was 99% not needed tech debt investment garbage

even in go its a pain in the ass to have to regen and figure out versioning shared protos and it only gets worse w each additional language

but every startup thinks they need 100 microservices and grpc so whatever

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

#26

Post by danpalmer »

echelon wrote: post #19
rednafi wrote: post #13

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.

> 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 rea…

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.

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

#27

Post by dilyevsky »

dlahoda wrote: post #10
swyx wrote: post #2

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

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.

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

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

#28

Post by recursivedoubts »

> 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-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.

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

#29

Post by lmm »

rednafi wrote: post #13

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.

> You can’t just give someone a simple command to call an endpoint—it requires additional tooling that isn’t standardized.

GRPC is a standard in all the ways that matter. It (or Thrift) is a breath of fresh air compared to doing it all by hand - write down your data types and function signatures, get something that you can actually call like a function (clearly separated from an actual function function - as it should be, it behaves differently - but usable like one). Get on with your business logic instead of writing serialisation/deserialisation boilerplate. GraphQL is even better.

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

#30

Post by bitzun »

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.
Post reply on HN