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

71–80 of 286 posts

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

#71

Post by pianoben »

danpalmer wrote: post #26
echelon wrote: post #19

Earlier quoted context omitted.

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

The flexibility of HTTP has advantages, too; it's simple to whip up a `curl` command to try things out. How does Google meet that need for gRPC APIs?

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

#72

Post by est »

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 mapping or repeated key-value pairs, just forget gRPC, use JSON.

Need performance? Use msgpack!

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

#73

Post by reactordev »

nsonha wrote: post #48
lmm wrote: post #29

Earlier quoted context omitted.

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

> GraphQL is even better just a casual sentence at the end? How about no. It's in the name, a query-oriented API, useless if you don't need flexible queries. Why don't you address the problem they talked about, what is the cli tool I can use to test grpc, what about gui client?

Take the protobuf and generate a client… gRPC makes no assumptions on your topography, only that there’s a server, there’s a client, and it’s up to you to fill the logic. Or use grpcurl, or bloomrpc, or kreya.

The client is the easy part if you just want to test calls.

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

#74

Post by eadmund »

mplanchard wrote: post #57
eadmund wrote: post #47

Earlier quoted context omitted.

Real REST is a very, very small minority. Fake REST (i.e., JSON RPC) is really ridiculously common.

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.

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.

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

#75

Post by est »

recursivedoubts wrote: post #28

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

I think the original REST is only suitable for "file" resources, so there's WebDAV and nobody bothers to use it these days.

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

#76

Post by jdwyah »

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.

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

#77

Post by allset_ »

pianoben wrote: post #71
danpalmer wrote: post #26

Earlier quoted context omitted.

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…

The flexibility of HTTP has advantages, too; it's simple to whip up a `curl` command to try things out. How does Google meet that need for gRPC APIs?

Server reflection exists (https://grpc.io/docs/guides/reflection/), but you don't really need to whip out curl when you have the RPC service's definition. It tells you everything you need to know about what to send and what you will receive, so you can just start writing type-safe code.

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

#79

Post by jahewson »

recursivedoubts wrote: post #28

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

This idea of self-describing REST is now better known as HATEOAS. Personally I think it’s bloated and doesn’t solve a real problem.

https://en.m.wikipedia.org/wiki/HATEOAS

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

#80

Post by abalaji »

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.

Post reply on HN