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

91–100 of 139 posts

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

#91

Post by wstrange »

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…

Practically speaking, most REST based servers and clients are tightly coupled anyways.

That is why SDKs are so popular with developers. They just want to call a method and not be concerned with how the bits get across the wire.

And please do not cite the browser as a good example of a REST client. The browser is driven by an advanced AI (namely a human). We are not there yet with machine to machine interactions, and it isn't clear that REST is the magic bullet that will enable this kind of system.

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

#92

Post by computerex »

cle wrote: post #60
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?

JSON is just a serialization format. Everything you send over the wire is just a bunch of bytes, including JSON and protobuf. JSON has types, and you can use it with a typed RPC system just fine. Whether or not clients can deserialize something you send them can't be known statically, even with protobuf. > What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system? Nothing. And the same applies to a ty…

Yes you don't have the guarantees of statically compiled/linked code but the entire point of using protobufs is that if you use the generated interfaces, you'll end up with fast binary serialization/de-serialization with type safety. That's a lot better than just using JSON. Which is very verbose.

You could of course make your own protocol and type system and use JSON for transmission. Why bother when this is done for you and is likely going to have the best adoption when it comes to interface definition languages like protobuf or Thrift.

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

#94

Post by computerex »

scott_karana wrote: post #83
BlackFly wrote: post #70

Earlier quoted context omitted.

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

"Bad clients" in your example don't include malicious ones, who'll see a gRPC endpoint generating JSON to be consumed in a JavaScript app. With no runtime type checking, JS's casting problems, and potential bugs caused by leaning on "type safe" serialization, there could be lots of black hat opportunities...

Protobuf/gRPC are not specific to any given language.

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

#95

Post by euyyn »

decwakeboarder wrote: post #34
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…

> Speaks protocol buffers, a fast and compact format compared to JSON This is definitely important at Google-scale, but for the rest of us compressed JSON typically isn't that bad.

If your users access your website from their phones, the latency and CPU benefits of proto become important for them.

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

#96

Post by euyyn »

al2o3cr wrote: post #52
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…

Allows clients to use the same APIs as backend services. Whether this counts as a bug or a feature depends on your APIs. I'm currently unfucking a suite of applications which bought into "your SPAs can just call backend services directly!" without getting a better security model - so the SPAs use hard-coded tokens that don't do any authorization, just like the backend services... facepalm

Sounds like those backend services needed better security too. It seems orthogonal to whether you have 3 different API surfaces (one for web, one for mobile app, one for backend servers), or the same for all. At Google, gRPC allowed us to move from the former to the latter.

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

#98

Post by deno »

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?

Protocol Buffers can even serialize down to JSON (as does Thrift, for example).

Client code for PB+JSON has been a part of Google’s Closure library in fact (open source), and they used it in production for Gmail’s RPC, but I’m not sure if it’s still supported/recommended for PB 3.

The reason to use JSON instead of compact binary representation has been because JSON.parse is fast and doesn’t require any additional code. But nowadays JS is fast enough in most cases (unlike you’re doing something like streaming with media exts), but you can also ship Web Assembly/NACL library and (soon) delegate parsing to Web Worker with shared memory which should altogether give best possible performance.

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

#99

Post by ctiller »

kyrra wrote: post #61
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…

I own about 15% of those PR's at any given time... and you're right: our Jenkins instance looks at open GitHub PR's, so to run all the tests somewhere, and to verify performance, we open a PR. Many of mine are lower priority things (or exploratory enhancements) and so they'll stay open for even a quarter at a time before it really makes sense to land them.

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

#100

Post by deno »

j_s wrote: post #79

Don't forget to protect against malicious user input! There are both pros/cons for 'non-human-readable' in the security department for sure. Finding a $5,000 Google Maps XSS by fiddling with Protobuf | https://news.ycombinator.com/item?id=13829925

You can easily write an extension to in-browser Dev Tools to show human-friendly representation of any binary protocol for development/debugging purpose.
Post reply on HN