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

211–220 of 286 posts

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

#211

Post by 9rx »

bigmutant wrote: post #102

Never really understood the folks pushing for RPC-over-HTTP. RPC is for systems that are close together (ie intra-DC). These simple rules work well: 1. JSON-over-HTTP for over the web 2. RPC (pick your flavor) for internal service-to-service I will say that Amazon's flavor (Coral-RPC) works well and doesn't come with a ton of headache, its mostly "add ${ServiceName}Client to build" and incorporate into the code. Neve…

> 1. JSON-over-HTTP for over the web

So literally gRPC[1]? You make it sound like there is a difference. There isn't, really.

What gRPC tried to bring to the table was establishing conventions around the details neither HTTP or JSON define, where otherwise people just make things up haphazardly with no consistency from service to service.

What gRPC failed on in particular was in trying to establish those conventions on HTTP/2. It was designed beside HTTP/2 with a misguided sense of optimism that browsers would offer support for HTTP/2 once finalized. Of course, that never happened (we only got half-assed support), rendering those conventions effectively unusable there.

[1] I'll grant you that protobufs are more popular in that context, but it is payload agnostic. You can use JSON if you wish. gRPC doesn't care. That is outside of its concern.

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

#212

Post by stickfigure »

rkagerer wrote: post #156
stickfigure wrote: post #113

Earlier quoted context omitted.

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?

Depends what you mean by "similar philosophy". We (largeish household name though not thought of as a tech company) went through a pretty extensive review of the options late last year and standardized on this for our internal serviceservice communication:

https://github.com/stickfigure/trivet

It's the dumbest RPC protocol you can imagine, less than 400 lines of code. You publish a vanilla Java interface in a jar; you annotate the implementation with `@Remote` and make sure it's in the spring context. Other than a tiny bit of setup, that's pretty much it.

The main downside is that it's based on Java serialization. For us this is fine, we already use serialization heavily and it's a known quantity for our team. Performance is "good enough". But you can't use this to expose public services or talk to nonjava services. For that we use plain old REST endpoints.

The main upsides are developer ergonomics, easy testability, spring metrics/spans pass through remote calls transparently, and exceptions (with complete stacktraces) propagate to clients (even through multiple layers of remote calls).

I wrote it some time ago. It's not for everyone. But when our team (well, the team making this decision for the company) looked at the proof-of-concepts, this is what everyone preferred.

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

#213

Post by wstrange »

recursivedoubts wrote: post #210
curt15 wrote: post #49

Earlier quoted context omitted.

How does one even write an API client against a REST API that only publishes the initial entry point? in particular, how should the client discover the resources that can be manipulated by the API or the request/response models?

your browser is a client that works against RESTful entries points that only publish an initial entry point, such as https://news.ycombinator.com from that point forward the client discovers resources (articles, etc) that can be manipulated (e.g. comments posted and updated) via hypermedia responses from the server in responses

The browser is also driven by an advanced wetware AI system that knows which links to click on and how to interpret the results.

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

#214

Post by bellgrove »

crabbone wrote: post #202
stickfigure wrote: post #113

Earlier quoted context omitted.

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

Protobuf is an atrocious protocol. Whatever other problems gRPC has may be worse, but Protobuf doesn't make anything better that's for sure. The reason to use it may be that you are required to by the side you cannot control, or this is the only thing you know. Otherwise it's a disaster. It's really upsetting that a lot of things used in this domain are the first attempt by the author to make something of sorts. So m…

Can you elaborate?

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

#215

Post by mdaniel »

jpc0 wrote: post #150
physicles wrote: post #111

Earlier quoted context omitted.

> There is no difference between OpenAPI and REST, it's a strange distinction. That threw me off too. What the article calls REST, I understand to be closer to HATEOAS. > I've open sourced a Go library for generating your clients and servers from OpenAPI specs As a maintainer of a couple pretty substantial APIs with internal and external clients, I'm really struggling to understand the workflow that starts with gener…

> This is why I created an abomination that uses go/ast and friends to generate the OpenAPI spec from the code OpenAPI is a spec not documentation. Write the spec first then generate the code from the spec. You are doing it backwards, at least in my opinion.

That's conceptually true, and yet if the hundreds of code generators don't support Your Favorite OAPI Feature ™ then you're stuck, whereas the opposite is that unless your framework is braindead it's going to at least support some mapping from your host language down to the OAPI spec. I doubt very seriously it's pretty, and my life experience is that it will definitely not be bright enough to have #/component reuse, but it's also probably closer to 30 seconds to run $(go generate something) than to launch an OAPI editor and now you have a 2nd job

I'd love an OAPI compliance badge (actually what I'm probably complaining about is the tooling's support for JSON Schema) so one could readily know which tools to avoid because they were conceived in a hackathon and worked for that purpose but that I should avoid them for real work

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

#216

Post by spelunker »

pandemic_region wrote: post #154
jitl wrote: post #145

Earlier quoted context omitted.

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.

Arguing the Right Way To Do REST was a favorite passtime amongst people at one of my previous jobs. Huge waste of time.

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

#217

Post by ryathal »

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…

I'd argue just making everything POST is the correct way to do a public Api too. REST tricks you into endpoints no one really wants, or you break it anyway to support functionality needed. SOAP was heavy with it's request/respone, but it was absolutely correct that just sending everything as POST across the wire is easier to work with.

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

#218

Post by mdaniel »

eadmund wrote: post #188
Glyptodon wrote: post #18

According to this, what is GraphQL? This article seems like something written with limited or unusual experience.

> According to this, what is GraphQL? GraphQL is akin to gRPC: a non-HTTP protocol tunnelled over HTTP. Unlike gRPC, I’m unconvinced that GraphQL is ever really a great answer. I think what the latter does can be done natively in HTTP.

For all the people singing the praises of how efficient gRPC is, I enjoy countering that the most efficient response is one which doesn't include 99% of data that the client doesn't care about in the slightest

GCP (and I believe Azure, too) offer `GET /thing?$fields=alpha,beta.charlie` style field selection but now there's a half-baked DSL in a queryparam and it almost certainly doesn't allow me to actually express what I want so I just give up and ask for the top-level key because the frustration budget is real

I for sure think that GraphQL suffers from the same language binding problem as gRPC mentioned elsewhere: if you're stack isn't nodejs, pound sand. And the field-level security problem is horrific to fix for real

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

#219

Post by throwaway127482 »

robertlagrant wrote: post #175
divan wrote: post #152

Earlier quoted context omitted.

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.

Google has massive amounts of code written in Java so one would think the Java tooling would be excellent as well.

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

#220

Post by masterj »

grumbelbart2 wrote: post #187
nithril wrote: post #144

Earlier quoted context omitted.

"Write a protocol and GraphQL", god damn it escalates quickly. Fortunately, there are intermediate steps.

Any suggestions for a good RPC library?

I have had a really good experience with https://connectrpc.com/ so far. Buf is doing some interesting things in this space https://buf.build/docs/ecosystem/
Post reply on HN