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

11–20 of 286 posts

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

#11

Post by tempest_ »

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

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.

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

#12

Post by NAHWheatCracker »

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.

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

#13

Post by rednafi »

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.

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

#14

Post by limaoscarjuliet »

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

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.

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

#15

Post by echelon »

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

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

#16

Post by Octoth0rpe »

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

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

#17

Post by silisili »

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…

You're being way too polite. The article is garbage and completely incorrect about what REST and OpenAPI even are.

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

#19

Post by echelon »

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

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

#20

Post by cyberax »

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.

Post reply on HN