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

261–270 of 286 posts

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

#261

Post by lmm »

mplanchard wrote: post #238
cloverich wrote: post #222

Earlier quoted context omitted.

> a query-oriented API, useless if you don't need flexible queries Right but, the typical web service at the typical startup does need flexible queries. I feel people both overestimate its implications and under estimate its value. - Standard "I need everything" in the model call - Simplified "I need two properties call", like id + display name for a dropdown - I need everything + a few related fields, which maybe re…

GraphQL is fine until you have enough data to care about performance, at which point you have to go through and figure out where some insane SQL is coming from, which ultimately is some stitched together hodgepodge of various GraphQL query types, which maybe you can build some special indexes to support or maybe you have to adjust what's being queried. Either way, you patch that hole, and then a month later you have…

> maybe you can build some special indexes to support or maybe you have to adjust what's being queried. Either way, you patch that hole, and then a month later you have a new page that's failing to load because it's generating a query that is causing your DB CPU to jump to 90%.

> To me it also makes no sense at startups, which don't generally have such a high wall between frontend and backend engineering.

Startups are where I've seen it work really well, because it's the same team doing it and you're always solving the same problem either way: this page needs this data, so we need to assemble this data (and/or adjust what we actually show on this page) out of the database we have, and add appropriate indices and/or computed pre-aggregations to make that work. Even if you make a dedicated backend endpoint to provide that data for that page, you've still got to solve that same problem. GraphQL just means less boilerplate and more time to focus on the actual business logic - half the time I forgot we were even using it.

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

#262

Post by jon_richards »

cyberax wrote: post #253
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 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. We developed a small WebSocket-based wrapper for ConnectRPC streaming, just to make it work with ReactNative. But it also allows us to use bidirectional streaming in the browser.

Awesome! Could you share? I also use react native.

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

#263

Post by nazcan »

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…

Is there recent news on safari supporting webtransport?

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

#264

Post by cyberax »

jon_richards wrote: post #262
cyberax wrote: post #253

Earlier quoted context omitted.

> 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. We developed a small WebSocket-based wrapper for ConnectRPC streaming, just to make it work with ReactNative. But it also allows us to use bidirectional streaming in the browser.

Awesome! Could you share? I also use react native.

https://gist.github.com/Cyberax/3956c935a7971627e2ce8e2df3fa...

I'll do a proper write-up in a couple of days.

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

#265

Post by allset_ »

bootsmann wrote: post #159
allset_ wrote: post #77

Earlier quoted context omitted.

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.

As the linked docs mention, grpcurl is a thing if you want to use it.

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

#266

Post by rswail »

thayne wrote: post #149
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…

That is a problem, certainly, but not the only one.

My point is that "procedure calls" have always covered up failure modes and making them "remote" papers over all of the problems of distributed computing.

The other problem with "procedure calls" is they are imperative and grow without any constraints on their implementation without very careful design and review.

The functionality of the "procedure" is unbound and has unknown dependencies and side effects.

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

#267

Post by p_l »

9rx wrote: post #254
throwaway127482 wrote: post #219

Earlier quoted context omitted.

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

Doesn't Google mostly use Stubby internally, only bridging it with gRPC for certain public-facing services?

Google also uses a completely different protocol stack to actually send Stubby/Protobuf/gRPC around, including protocols on the wire and bypassing the kernel (according to open access papers about PonyExpress etc)

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

#268

Post by p_l »

stickfigure wrote: post #212
rkagerer wrote: post #156

Earlier quoted context omitted.

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 service service 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; y…

Yes, it's good for internal use.

Caveat is when you need to go elsewhere. I still remember the pain of Hadoop ecosystem having this kind of API

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

#269

Post by robertlagrant »

cyberax wrote: post #236
robertlagrant wrote: post #183

Earlier quoted context omitted.

> It's certainly HTTP, but not REST. How isn't it RESTful? It's a single entrypoint using content types to tell the client how to interpret it, and with exploratory clues to other content in the website.

The "R" letter means "Representational". It requires a certain style of API. E.g. instead of "/item?id=23984792834" you have "/items/comments/23984792834". HN doesn't have this.

Representational is to do with being able to deal with different representations of data via a media type[0]. There is stuff about resource identification in ReST, but it's just about being able to address resources directly and permanently rather than the style of the resource identifier:

> Traditional hypertext systems [61], which typically operate in a closed or local environment, use unique node or document identifiers that change every time the information changes, relying on link servers to maintain references separately from the content [135]. Since centralized link servers are an anathema to the immense scale and multi-organizational domain requirements of the Web, REST relies instead on the author choosing a resource identifier that best fits the nature of the concept being identified.

[0] https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...

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

#270

Post by jitl »

porridgeraisin wrote: post #235
ryathal wrote: post #217

Earlier quoted context omitted.

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.

Yeah, I like doing this as well. And all the data goes in the request body. No query parameters. Especially when the primary intended client is an SPA, where the URL shown is decoupled with the API URL. Little bit of a memory jolt: I once built a (not for prod) backend in python as follows: write a list of functions, one for each RPC, in a file `functions.py` then write this generic function for flask: import server.…

Use a decorator to expose functions explicitly, otherwise sounds like security issue waiting to happen. All your decorator needs to do is add the function to an __exposed__ set, then when you’re looping over the dict, only expose keys who’s values are in the __exposed__ set
Post reply on HN