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

161–170 of 286 posts

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

#161

Post by bborud »

jdwyah wrote: post #76

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

Since you mention Maven I'm going to make the assumption that you are using Java. I haven't used Java in quite a while. The last 8 years or so I've been programming Go.

Your experience of gRPC seems to be very different from mine. How much of the difference in experience do you think might be down to Java and how much is down to gRPC as a technology?

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

#162

Post by kybernetikos »

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.

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.

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

#163

Post by joatmon-snoo »

mvdtnz wrote: post #87
aaomidi wrote: post #35

Earlier quoted context omitted.

Bidirectional streaming is generally a bad idea for anything you’re going to want to run “at scale” for what it’s worth.

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.

bidi streaming screws with a whole bunch of assumptions you rely on in usual fault-tolerant software:

- there are multiple ways to retry - you can retry establishing the connection (e.g. say DNS resolution fails for a 30s window) _or_ you can retry establishing the stream

- your load-balancer needs to persist the stream to the backend; it can't just re-route per single HTTP request/response

- how long are your timeouts? if you don't receive a message for 1s, OK, the client can probably keep the stream open, but what if you don't receive a message for 30s? this percolates through the entire request path, generally in the form of "how do I detect when a service in the request path has failed"

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

#164

Post by kybernetikos »

hedora wrote: post #99
inetknght wrote: post #85

Earlier quoted context omitted.

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

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…

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

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

#165

Post by bborud »

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.

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

#166

Post by txdv »

bitzun wrote: post #30

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

> Try exposing a grpc api to a browser

I remember being grilled for not creating "jsony" interfaces:

message Response { string id = 1; oneof sub { SubTypeOne sub_type_one = 2; SubTypeTwo sub_type_two = 3; } }

message SubTypeOne { string field = 1; }

message SubTypeTwo { }

In your current model you just don't have any fields in this subtype, but the response looked like this with our auto translator: { "id": "id", "sub_type_two": { } }

Functionally, it works, and code written for this will work if new fields appear. However, returning empty objects to signify the type of response is strange in the web world. But when you write the protobuf you might not notice

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

#167

Post by rollulus »

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.

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

#168

Post by bborud »

mandevil wrote: post #115
oppositelock wrote: post #98

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

There is a distinction between (proper) REST and what this blog calls "OpenAPI". But the thing is, almost no one builds a true, proper REST API. In practice, everyone uses the OpenAPI approach. The way that REST was defined by Roy Fielding in his 2000 Ph.D dissertation ("Architectural Styles and the Design of Network-based Software Architectures") it was supposed to allow a web-like exploring of all available resourc…

I tend to prefer RESTish rather than RESTful since RESTful almost suggests attempting to implement Fielding's ideas but not quite getting there. I think the subset of approaches that try and fail to implement Fielding's ideas is an order of magnitude (or two) smaller than those who go for something that is superficially similar, but has nothing to do with HATEOAS :-).

REST is an interesting idea, but I don't think it is a practical idea. It is too hard to design tools and libraries that helps/encourages/forces the user implement HATEOAS sensibly, easily and consistently.

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

#169

Post by physicles »

deathanatos wrote: post #133
physicles wrote: post #118

Earlier quoted context omitted.

Maybe I've been educated in a strange part of the internet, but I assume that this ship already sailed ~10 years ago: when most people (90%+) hear REST, they imagine something vaguely like JSON-RPC. (and this is how ChatGPT, a sort of average of all opinions on the Internet, understands it) So if you say REST and mean something other than that, then you're committing to being misunderstood by most people.

> So if you say REST and mean something other than that, then you're committing to being misunderstood by most people. Perhaps, but TFA is clearly written in that it is using the actual, real meaning of REST, not the value-drift corruption the laity have wrought. (The upthread comment snips out the surrounding context that brings that clarity.) Which brings us right back to the problem at hand: Potrzebie.

This is true. And the comments are full of people confused about how the article is using the term REST.

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

#170

Post by bjackman »

stickfigure wrote: post #113
jdwyah wrote: post #76

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

IMO the problem with gRPC isn't the protocol or the protobufs, but the terrible tooling - at least on the Java end. It generates shit code with awful developer ergonomics. When you run the protobuf builder... * The client stub is a concrete final class. It can't be mocked in tests. * When implementing a server, you have to extend a concrete class (not an interface). * The server method has an async method signature.…

> The client stub is a concrete final class. It can't be mocked in tests.

I believe this is deliberate, you are supposed to substitute a fake server. This is superior in theory since you have much less scope to get error reporting wrong (since errors actually go across a gRPC transport during the test).

Of course.. at least with C++, there is no well-lit-path for actually _doing_ that, which seems bonkers. In my case I had to write a bunch of undocumented boilerplate to make this happen.

IIUC for Stubby (Google's internal precursor to gRPC) those kinda bizarre ergonomic issues are solved.

Post reply on HN