Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

spatialos.improbable.io

Post reply on HN
Print view View original

21–30 of 139 posts

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#21

Post by lyschoening »

grw_ wrote: post #7

The reference implementation of gRPC on github[0] has 998 open issues and 215 open pull requests. Every time I've tried to use this package I have encountered a previously-reported issue which has remained unfixed for months. If you need to interact with Google platform it's hard to avoid using gRPC, since many "official" libraries seem to be migrating towards this library, while it remains fragile and bug-ridden. My…

It is worth pointing out that the Python implementation is particularly bad. Perhaps gRPC is really pleasant to use with Java and Go, but the Python implementation is neither usable nor stable enough for it to be worth considering its use for one's own services.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#22

Post by andrewingram »

aristidb wrote: post #19
daliwali wrote: post #16

RPC has its own set of limitations, which if your application qualifies, might be a good fit: * Coupled server and client. gRPC uses protocol buffers which have zero backwards compatibility. * Zero discoverability. The client knows in advance what the server can do. * No standards to follow. You make up your own specs, like Google did. These constraints are orthogonal to REST, the architectural principles behind the…

"protocol buffers which have zero backwards compatibility" Either I misunderstand you, or this is _remarkably_ wrong: Protocol buffers were designed to make it easy to define protocols which are both backward and forward compatible.

My understanding is the same. Though I had also come to believe that the primary way to achieve this is via loose constraints, i.e. required fields should be used VERY sparingly.

This compatibility pattern also leads me to conclude that protocol buffers aren't a suitable model for generating a client-side type system. You'll just end up with structures where everything is a Maybe type, so you end up needing tons of bespoke client-side code to handle the possible permutations.

You need a layer on top of of them to express the true type system suitable for clients, and I believe GraphQL does a great job of this (but I hasten to add that even GraphQL's type system is relatively limited and isn't a magic bullet).

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#24

Post by mvitorino »

cshenton wrote: post #17
mvitorino wrote: post #10

I think I like gRPC, but have several reservations regarding replacing REST with it. REST web services often return multiple mime formats, not just pure structured data. Some services return images, others return HTML, and then you also have cache... Maybe I just don't know enough about gRPC, but I can already imagine many people passing images around as byte arrays inside protocol buffers and when we look back, we h…

gRPC generates rpc server and client stubs based off a protocol buffer definition. Saying it's a replacement for REST makes little sense since it's possible to define a REST API within it. It's also possible to write a totally not RESTful API in a modern http api framework. In fact that's what Google's API design guide does. Encourages RESTful API design then describes how to implement them using proto and gRPC. The…

Interesting! When I first looked at gRPC I missed the option(google.api.http). Are you aware of the reason why REST mapped gRPC is not possible in GAE (http 1 only on the server end of our code)?

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#25

Post by vardump »

andrewingram wrote: post #22
aristidb wrote: post #19

Earlier quoted context omitted.

"protocol buffers which have zero backwards compatibility" Either I misunderstand you, or this is _remarkably_ wrong: Protocol buffers were designed to make it easy to define protocols which are both backward and forward compatible.

My understanding is the same. Though I had also come to believe that the primary way to achieve this is via loose constraints, i.e. required fields should be used VERY sparingly. This compatibility pattern also leads me to conclude that protocol buffers aren't a suitable model for generating a client-side type system. You'll just end up with structures where everything is a Maybe type, so you end up needing tons of b…

gRPC is based on protobuf3, which doesn't support "required" or "optional" in the first place.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#27

Post by vertex-four »

pjmlp wrote: post #15
grizzles wrote: post #12

Earlier quoted context omitted.

Imo it was mainly poor language / framework support for asynchronicity. That's not really an issue anymore.

So how is the modern way to work around issues like network partitions, servers not responding, going off and on on network connections, duplicate answers,....?

Futures-oriented programming - helped by the "async" or "generators" support in quite a few modern languages. Wrap timeouts and retries around everything, and process the timeout errors accordingly.

RPC doesn't mean that a remote function call looks exactly like a local one. That was a mistake. Modern RPC systems return composable futures which make it trivial to do timeouts and retries, send off many requests at once and wait for all/some of them to return, and so on and so forth.

If you're doing something that shouldn't happen more than once, generate a transaction ID to identify it by.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#28

Post by andrewingram »

vardump wrote: post #25
andrewingram wrote: post #22

Earlier quoted context omitted.

My understanding is the same. Though I had also come to believe that the primary way to achieve this is via loose constraints, i.e. required fields should be used VERY sparingly. This compatibility pattern also leads me to conclude that protocol buffers aren't a suitable model for generating a client-side type system. You'll just end up with structures where everything is a Maybe type, so you end up needing tons of b…

gRPC is based on protobuf3, which doesn't support "required" or "optional" in the first place.

so everything is optional?

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#29

Post by rco8786 »

andrewingram wrote: post #6

I first saw this one a few weeks ago, and have been trying to weigh up its pros and cons over GraphQL (my tool of choice). gRPC-Web: * Speaks protocol buffers, a fast and compact format compared to JSON * Allows clients to use the same APIs as backend services. GraphQL: * Enables a client-centric view of the system. I have abstractions in my GraphQL server that only make sense to clients. It's a query-centric impleme…

does graphql come with its own serialization protocol? I would have thought that the comparison of gRPC to GraphQL is apples/oranges.

Re: gRPC-Web: Moving past REST+JSON towards type-safe Web APIs

#30

Post by mwitkow »

jupp0r wrote: post #23

There is also Google's own implementation of this that has been in the works for some time. See https://github.com/grpc/grpc/issues/8682

Yea, we actually work closely with the gRPC-Web team at Google to make sure our implementations are interoperable and we have plans for cross-integration-testing.
Post reply on HN