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

61–70 of 139 posts

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

#61

Post by kyrra »

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…

Maybe I'm wrong here, but the number of open pull requests isn't a bad thing. If you start poking at them, you will see that people submit pull requests to have the full gRPC test suite run against their changes (which probably includes cross-platform tests). So maybe putting a pull request up is the only way to get Jenkins kicked off, which then means it is part of the standard flow when doing work on the project to test changes.

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

#62

Post by anentropic »

IshKebab wrote: post #55
runeks wrote: post #51

I don't understand this, to be honest. What does type safety have to do with serialization formats or application protocols? I've used Servant (Haskell) to define the REST API for my backend, which gives me type safety, server stubs and generated client code for free. In my view, type safety is about what you internally use to represent your API, and has nothing at all to do with the underlying protocol(s). There's n…

> There's nothing about REST+JSON that prevents type safety, as far as I'm aware. Well, except for the fact that JSON is pretty much untyped? I don't understand what there is to not get. If you want type safe RPC you have to use an RPC system that at least has types ! What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

nothing stops you sending bad data to a gRPC endpoint either

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

#64

Post by davemo »

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…

The author addresses this in the OP:

"We later learned that Google’s gRPC Team was working on a gRPC-Web spec internally. Their approach was eerily similar to ours, and we decided to contribute our experiences to the upstream gRPC-Web spec (currently in early access mode, still subject to change)."

I suspect anyone attempting to adopt this implementation is going to hit similar issues until a release is finalized.

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

#65

Post by [deleted] »

e1g wrote: post #44
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.

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

[deleted]

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

#66

Post by Matthias247 »

daliwali wrote: post #48
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 "coup…

Honestly: The other points are not better if your intention was to make grpc look worse than other HTTP based APIs:

- For all of them you need to know the remote addresses (IP/hostname, port) upfront or use an external service discovery solution.

- For both you can implement some service introspection, which delivers you a list of available services/methods. Afaik for grpc there even exists some standardized introspection mechanism. For other HTTP APIs you might want to download some swagger description from a well-known address. Or WSDL scheme. Or GraphQL schema.

- Standards on which layer? On transport layer you are following the HTTP standard, independent of whether you are using grpc, GraphQL, json-rpc or some handmade REST API. On application layer you are mostly on your own anyway, there's not a lot things one could standardize. There are some exceptions, like the standardization of Webdav on top of HTTP, but most applications have their own specific set of requirements. If we are talking about standardization without meaning offical-standardization, then we can argue that grpc provides a more rigid (standardized) model for an application than the definition of some ad-hoc APIs: It is standardized how APIs and exchanged data types are defined (.proto files), how they can be accessed and how data is transferred over the wire (mapping to HTTP). All of that without the application developers on both sides needing to care for it.

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

#68

Post by throwaway2016a »

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

Also in the Json the "query" is actually a string that is in GraphQL language. So GraphQL is an encoded format embedded inside Json.

{ "query": "mutation Foo() { ... }" }

As such type safety is dependent on the query langauge (graphQL) not Json. As far as the Json goes, it might as well be multi-part form encoded.

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

#69

Post by cpburns2009 »

dozzie wrote: post #59
IshKebab wrote: post #55

Earlier quoted context omitted.

> There's nothing about REST+JSON that prevents type safety, as far as I'm aware. Well, except for the fact that JSON is pretty much untyped? I don't understand what there is to not get. If you want type safe RPC you have to use an RPC system that at least has types ! What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

> If you want type safe RPC you have to use an RPC system that at least has types! If you want a type safe RPC, you have to use proper RPC system in the first place. It doesn't matter if it is gRPC, SOAP, XML-RPC, JSON-RPC, or Apache Thrift. REST doesn't even define serialization format or error reporting. > you have to use an RPC system that at least has types! What stops me sending `{ name: 12, age: "Hello"}` to yo…

JSON's types are limited (object, array, string, number, boolean, and null) and provides no standard way to define new types. It frequently devolves into ad hoc data structures with stringly typed values. I'm pretty sure that's what @IshKebab meant by JSON being "pretty much untyped".

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

#70

Post by BlackFly »

anentropic wrote: post #62
IshKebab wrote: post #55

Earlier quoted context omitted.

> There's nothing about REST+JSON that prevents type safety, as far as I'm aware. Well, except for the fact that JSON is pretty much untyped? I don't understand what there is to not get. If you want type safe RPC you have to use an RPC system that at least has types ! What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

nothing stops you sending bad data to a gRPC endpoint either

On the contrary, generating the client code using the same .proto definition as used by the server stops your client from sending bad data to the gRPC endpoint. Your binding code will fail to compile once the data definitions compiled from the .proto have changed. Then the client that sends bad data cannot be built.

They are talking about a work flow that prevents you from compiling bad clients. Of course if you don't use that workflow, you will still be able to make a bad client.

Post reply on HN