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

151–160 of 286 posts

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

#151

Post by thayne »

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

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

#152

Post by divan »

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?

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

#153

Post by divan »

rswail wrote: post #146

The problem with gRPC is the "R". It's been the same with JMI, Corba, ONC-RPC and all the others. Making "procedure calls" remote and hiding them underneath client libraries means that programmers do not consider the inherent problems of a networked environment. Problems like service discovery, authentication, etc are hidden beneath something that "looks like" a local procedure call. That's one problem, the other is…

https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf

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

#154

Post by pandemic_region »

jitl wrote: post #145
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…

For a public API I wouldn’t do this, but for private APIs we just do POST /api/doThingy with a JSON body, easy peasy RPC anyone can participate in with the most basic HTTP client. Works great on every OS and in every browser, no fucking around with “what goes in the URL path” vs “what goes in query params” vs “what goes in the body”. You can even do this with gRPC if you’re using Buf or Connect - one of the server th…

This. The amount of time lost debating correct rest semantics for a use case is staggering.

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

#155

Post by jpc0 »

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.

Not going to give you any proper advice but rather a question to have an answer for. It's not unsolvable or even difficult but needs an answer at scale.

How do you scale horizontally?

User A connects to server A. User A's connection drops. User A reconnects to your endpoint. Did you have anything stateful you had to remember? Did they loadbalancer need to remember to reconnect user A to server A? What happens if the server dropped, how do you reconnect the user?

Now if your streaming is server to server over gRPC on your own internal backend then sure, build actors with message passing, you will probably need an orchestration layer (not k8s, that's for ifra, you need an orchestrator for your services probably written by you), for the same reason as above. What happens if Server A goes down but instead of User A it was Server B. The orchestrator acts as your load balancer would have but it just remembers who exists and who they need to speak to.

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

#156

Post by rkagerer »

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

Any alternatives that take a similar philosophy but get the tooling right?

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

#159

Post by bootsmann »

allset_ wrote: post #77
pianoben wrote: post #71

Earlier quoted context omitted.

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.

>you don't really need to whip out curl when you have the RPC service's definition

Following up a "how do I experiment with this in my workflow" with "oh you don't need to" is not the greatest look. There is a vast portion of programming bugs that stem from someone misunderstanding what a given API does, so the ability to quickly self-verify that one is doing things right is essential.

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

#160

Post by nprateem »

The lack of first class js support just kills it. Having to use middleware that doesn't work too well on AWS is the nail in the coffin.

It's different if you've drunk the microservices koolaid but for normal projects it doesn't help generate front-end client API libs like you'd hope.

Post reply on HN