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.
Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
31–40 of 286 posts
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#32always 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.
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.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#33Unless 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…
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.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#34My 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 an…
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.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#35Unless 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…
Bidirectional streaming is generally a bad idea for anything you’re going to want to run “at scale” for what it’s worth.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#36unless 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)
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#37Oof, 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…
This stood out to me as well. The author must have a particular understanding of REST that differs from the usual sense in which it’s used. He might be technically correct — I haven’t read the primary sources related to REST — but it distracted from the meat and potatoes of the article, which is really a comparison of gRPC and OpenAPI. It seemed very strange for this reason.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#38always 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
You should check out https://connectrpc.com/ It's based on grpc but works a lot better with web tooling
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#39REST 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 desc…
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.
Re: Understanding gRPC, OpenAPI and REST and when to use them in API design (2020)
#40This 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.