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

41–50 of 139 posts

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

#41

Post by fishnchips »

lyschoening wrote: post #21
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.

Ruby too was pretty bad - more so Protocol Buffers than gRPC itself though. In my previous place, I had to fork the Ruby library and write a non-trivial amount of C code so that instances of Protocol Buffers messages could be treated as regular Ruby objects by their callers. Once I opened a PR against upstream it was quickly accepted but took some 6 months to be published to Ruby Gems. I'm not saying to stay away, but please be prepared for surprises.

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

#42

Post by andrewingram »

ddorian43 wrote: post #40
rco8786 wrote: post #29

Earlier quoted context omitted.

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

it uses json ? so you compare it to that

The default is JSON, but the spec doesn't mandate that it be JSON over the wire, or that even that it be over HTTP.

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

#43

Post by mwitkow »

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…

Totally agreed. There are cases where you basically want to deal with well structured web resources: HTML, images etc. For these, HTTP is a perfect fit.

What we're replacing with gRPC is usage of REST (URL-encoded resources) + JSON for application APIs, not really Web-resources.

What we found is that gRPC is really good at capturing both a resource-oriented API (we use similar conventions to Google's excellent API Design handbook https://cloud.google.com/apis/design/resource_names#resource...) and imperative ones. The major difference we no longer have a weird POST method with `/books/do_recalculation` that breaks the RESTfulness of the API.

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

#44

Post by e1g »

rco8786 wrote: post #29
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.

GraphQL defaults to JSON over HTTP, but you can funnel it through sockets or protobuf or anything else. The conflict here is that gRPC goes beyond a serialization protocol - it's a full strongly typed RPC layer. You define your objects, methods, fields, types, relationships, data resolvers, execution pathways, etc. Just like GraphQL.

I see no meaningful advantage in binary serialization - JSON is fast enough not to be an issue, and HTTP2/GZIP minimize any bandwidth advantage. I do see a bit advantage of GraphQL in tooling and query composition, but I gRPC provides the building blocks required to rebuild that. gRPC-web is GraphQL of 12 months ago - it's definitely on the right path to help with complex data wrangling. My question is - does it do something important better/differently to GraphQL to warrant new players to enter the game and catch up to make it a strong competitor?

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

#45

Post by shaklee3 »

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…

I've been using c++ for the server and python for the client, and it's worked well what issues did you hit?

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

#46

Post by linkmotif »

This kind of stuff couldn't happen soon enough. REST is so arbitrary and less than useful for building UIs. It's just bad.

I've got Relay talking to a GraphQL service built in graphql-java which then talks to a gRPC service layer. The gRPC service layer is a great fit for GraphQL. Some type safety all around, but there could always be more. And there could always be less JSON. Please, no more JSON. The only thing it's good for is debug logging.

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

#47

Post by mwitkow »

TimMeade wrote: post #36

Just saw this during the morning reading. Without a deep dive, this looks very promising. We have recently been moving to k8s and grpc for our node work and the last piece was how to get to the browser. If this ties it all as one straight protocol from db to browser it will be very welcome and could not have come at a better time. We were evaluating the alternative (GraphQL etc) but our experiences with node and grpc…

That sounds very much what we're doing, except our microservice stack is in Go. For nodeJS you probably want to front your pods with grpcwebproxy (https://github.com/improbable-eng/grpc-web/tree/master/go/gr...)

If you hit any snafus, please file bug reports in https://github.com/improbable-eng/grpc-web We're happy to help :)

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

#48

Post by daliwali »

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…

I made a small mistake in the first point, got downvoted to oblivion and people seemed to stop reading there: the binary serialization indeed has backwards and forwards compatibility. However, the textual serialization lacks this compatibility. I can't remember a petty detail of a vendor specification apparently. Pedants with encyclopedic knowledge of Google are out in full force today!

I should have stopped at "coupled server and client", the point is that they both rely on an agreed upon external schema since the messages are not self-descriptive.

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

#49

Post by TimMeade »

mwitkow wrote: post #47
TimMeade wrote: post #36

Just saw this during the morning reading. Without a deep dive, this looks very promising. We have recently been moving to k8s and grpc for our node work and the last piece was how to get to the browser. If this ties it all as one straight protocol from db to browser it will be very welcome and could not have come at a better time. We were evaluating the alternative (GraphQL etc) but our experiences with node and grpc…

That sounds very much what we're doing, except our microservice stack is in Go. For nodeJS you probably want to front your pods with grpcwebproxy ( https://github.com/improbable-eng/grpc-web/tree/master/go/gr... ) If you hit any snafus, please file bug reports in https://github.com/improbable-eng/grpc-web We're happy to help :)

Much thanks. I'll add it to the immediate list.

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

#50

Post by sideband »

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…

I agree. As much as I really wanted to use gRPC on Go for a current project, this bug ultimately scared me away: https://github.com/grpc/grpc-go/issues/1043

Big kudos to everyone working on it (most of which are Google engineers, some very senior) but I can't help wonder what other issues might be lurking if that one went unnoticed for so long.

Post reply on HN