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

171–180 of 286 posts

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

#171

Post by drtse4 »

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…

As someone that used it for years with the same problems he describes... spot on analysis, the library does too much for you (e.g. reconnection handling) and handling even basic recovery is a bit a nuisance for newbies. And yes, when you get random failures good luck figuring out that maybe is just a router in the middle of the path dropping packets because their http2 filtering is full of bugs.

I like a lot of things about it and used it extensively instead of the inferior REST alternative, but I recommend to be aware of the limitations/nuisances. Not all issues will be simply solved looking at stackoverflow.

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

#172

Post by drtse4 »

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…

In my opinion, you shouldn't expose it to a browser, it's not what is good at, build something custom that converts to json. Like using REST to talk between backend services, makes no sense using a human readable protocol/api especially if there are performance requirements (not a call every now and then with a small amount of data returned).

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

#173

Post by zigzag312 »

dtquad wrote: post #116
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…

Your problems has more to do with some implementations than the grpc/protobuf specs themselves. The modern .NET and C# experience with gRPC is so good that Microsoft has sunset its legacy RPC tech like WCF and gone all in on gRPC.

I would really like if proto to C# compiler would create nullable members. Hasers IMO give poor DX and are error prone.

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

#175

Post by robertlagrant »

divan wrote: post #152
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…

I use gRPC with Go+Dart stack for years and never experienced these issues. Is it something specific to Java+gRPC?

Go and Dart are probably the languages most likely to work well with gRPC, given their provenance.

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

#176

Post by jon_richards »

thayne wrote: post #151
jon_richards wrote: post #86

I've been having fun with connectrpc https://connectrpc.com/ It fixes a lot of the problematic stuff with grpc and I'm excited for webtransport to finally be accepted by safari so connectrpc can develop better streaming. I initially thought https://buf.build was overkill, but the killer feature was being able to import 3rd party proto files without having to download them individually: deps: - buf.build/landeed/proto…

It still uses protocol buffers though, which is where many of the problems I have with gRPC comes from

The auto-generated SDKs are very useful here. An API customer doesn't have to learn protobuf or install any tooling. Plus they can fall back to JSON without any fuss. Connectrpc is much better at that than my envoy transcoder was.

If you're thinking from the API author's point of view, I might agree with you if there was a ubiquitous JSON annotation standard for marking optional/nullable values, but I am sick of working with APIs that document endpoints with a single JSON example and I don't want to inflict that on anyone else.

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

#177

Post by jon_richards »

rfw300 wrote: post #148
toprerules wrote: post #44

As someone who has worked at a few of the FAANGs, having thrift/grpc is a godsend for internal service routing, but a lot of the complexity is managed by teams building the libraries, creating the service discovery layers, doing the routing etc. But using an RPC protocol enables those things to happen on a much greater scale and speed than you could ever do with your typical JSON/REST service. I've also never seen a…

What do you mean by “leak verbs”?

Not OP, but https://cloud.google.com/blog/products/api-management/restfu...

The problem is that clients generally have a bunch of verbs they need to do. You have to design your objects and permissions just right such that clients can do all their verbs without an attacker being able to PATCH "payment_status" from "Requires Payment" to "Payment Confirmed".

RPC uses verbs, so that could just be the SubmitPayment RPC's job. In REST, the correct design would be to give permission to POST a "Payment" object and base "payment_status" on whether that has been done.

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

#178

Post by piva00 »

bborud wrote: post #161
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?

It's not Java itself, it's design decisions on the tooling that Google provides for Java, mostly the protobuf-gen plugin.

At my company we found some workarounds to the issues brought up on GP but it's annoying the tooling is a bit subpar.

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

#179

Post by robertlagrant »

rollulus wrote: post #167

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

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

It helps by trying to map standard metaphors to your company's concepts instead of inventing bespoke return types for your company's concepts. You still need to decide whether or not to indicate that the resource is either not there, or was never there.

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

#180

Post by happyweasel »

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…

Buggy/incomplete Openapi codegen for rust was a huge disappointment for me. At least with grpc some languages are first class citizens. Of course generated code has some uglyness. Kinda sad http2 traffic can be flaky due to bugs in network hardware.
Post reply on HN