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

101–110 of 139 posts

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

#101

Post by didibus »

I acknowledge it could just be me and the specific projects I worked on, but I've never been encumbered by an API style. RPC, Rest, GraphQL, I almost find them all to simply differ in syntax.

I've managed to solve all my use cases using all three with equal effort, time and with comparable outcomes.

There's value in compression and faster serialization/deserializarion formats when and only when micro-performance becomes an issue. Other then that, I think programmers spend way too much time debating over these, where I don't see any one of them providing an ROI advantage over the others.

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

#102

Post by deno »

u320 wrote: post #97
progx wrote: post #5

There is a reason why more and more people left RPC and use REST. And for me "the next big thing" is something like GraphQL.

REST isn't very widely used. Handwritten RPC protocols using HTTP/JSON is, though.

REST has been a complete failure from the very beginning. At best it maybe introduced some people to HTTP caching headers. Sad!

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

#103

Post by euyyn »

rdtsc wrote: post #73

REST + JSON is simple, easy to debug, and it does the job. Web clients speak JSON, servers speak JSON, humans can read JSON usually. JSON can be gzipped so you get some benefit there. gRPC is another large pile of foreign C code that's essentially a black box. If there is a buffer overflow there that your code hits only somehow, you'd have to know how to debug it and fix it. Also chances are you are not Google, Faceb…

> gRPC is another large pile of foreign C code that's essentially a black box

Not for web, as this is generating Typescript code on top of the fetch API.

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

#104

Post by andrewingram »

didibus wrote: post #101

I acknowledge it could just be me and the specific projects I worked on, but I've never been encumbered by an API style. RPC, Rest, GraphQL, I almost find them all to simply differ in syntax. I've managed to solve all my use cases using all three with equal effort, time and with comparable outcomes. There's value in compression and faster serialization/deserializarion formats when and only when micro-performance beco…

REST (in the pure sense) vs RPC is a valid comparison, but GraphQL solves a different problem. GraphQL is an alternative to other gateway API or backend-for-frontend solutions.

The benefits of a gateway API to both developers AND users are hugely significant. These are decidedly NOT micro-optimisation.

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

#105

Post by euyyn »

andrewingram wrote: post #28
vardump wrote: post #25

Earlier quoted context omitted.

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

so everything is optional?

Except primitive types. So this is avoided:

> 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.

Absent primitive values default to zero, while absent message fields are mapped to what makes most sense in the specific programming language (in most of them, "null" or "nil").

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

#106

Post by cle »

computerex wrote: post #92
cle wrote: post #60

Earlier quoted context omitted.

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

I agree, I love protobuf and JSONSchema and Thrift, I think they're great ideas that solve important problems.

But the hype is getting carried away--they aren't a silver bullet for distributed systems, they're just a way to manage schema. Define a schema in an IDL, and Protobuf/Thrift/whatever generate schema validators and serializer/deserializers for clients and servers. But they are not type safe across systems, and that they compile doesn't imply anything about whether they will actually work at runtime.

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

#107

Post by euyyn »

daliwali wrote: post #82
Matthias247 wrote: post #66

Earlier quoted context omitted.

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

Actually gRPC is about the same as other HTTP based APIs, it is just a more efficient RPC. All of them are lacking what made the web scalable in the first place. - HTTP APIs are worse than websites of the 90s. At least a browser could be expected to view a few websites. HTTP APIs require a custom client for each one. - Document media types, not APIs. This isn't such a novel concept, browsers (fancy HTTP clients) work…

I don't understand your point about third-party clients. APIs defined in .proto files can have both clients and servers implemented by anybody.

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

#108

Post by bkeroack »

jayd16 wrote: post #71
d--b wrote: post #54

Earlier quoted context omitted.

I think what they mean is by defining the contract first as a .proto file, and by having type-safe languages automatically read them and generate code, they are able to have a sort of cross language type safety. If you create a method like double GetThing(); and then you want to change it to: int GetThing(); All you have to do is change it in your proto, then both the typescript in the browser and the go code in the…

But unless you control all client code, you can't check the client code at server compile time. You're still breaking and forcing a refactor by all your clients and there's no way to track that with type safety. That said, this use case seems to be for a single web front end and go back end but that part is left out of the title. Protos are fine, google likes protos, gRPC works for Google because they have that insan…

GP was a bad example. You probably wouldn't have an RPC returning a simple type. It would instead return a message (aka a Go struct, or an object in JS) which has various fields (or even just a single field). Protobuf messages have built-in backwards compatibility as long as you don't change field numbers. That way you can incrementally change your messages without breaking older clients.

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

#109

Post by scott_karana »

computerex wrote: post #94
scott_karana wrote: post #83

Earlier quoted context omitted.

"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.

Well aware. I was answering mainly with regard to GP's quote, agreeing with IshKebab:

> There's nothing about REST+JSON that prevents type safety, as far as I'm aware.

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

#110

Post by j_s »

deno wrote: post #100
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.

Nice. Are you aware of any Chrome extension for decoding Flash's 'application/x-amf' Action Message Format like Burp, Charles, and this Firefox extension do?

https://addons.mozilla.org/en-US/firefox/addon/amf-explorer/

Post reply on HN