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

81–90 of 139 posts

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

#81

Post by bluejekyll »

d--b wrote: post #54
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…

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…

To change this without breaking existing users, including internal ones, you shouldn't redefine the method signature, you should add a new one and deprecate the old one.

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

#82

Post by daliwali »

Matthias247 wrote: post #66
daliwali wrote: post #48

Earlier quoted context omitted.

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 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 because HTML is a standard.

- Standards at the application layer, not specifications. You mentioned specs only.

Let me just clarify that RPC is a great fit if you are constrained to a single vendor and don't care about third-party clients. On the web, every browser is a third-party. For HTTP APIs to take off, they need to be built more like websites, or else vendor specs will fill every niche.

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

#83

Post by scott_karana »

BlackFly wrote: post #70
anentropic wrote: post #62

Earlier quoted context omitted.

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

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

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

#84

Post by d--b »

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…

I am aware this is not a real life scenario, I'm just saying what he calls type-safe, is actually something like cross-language-static-typing.

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

#85

Post by ejona86 »

sideband wrote: post #50
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.

The thing that went unnoticed with that issue is that grpc-go didn't have an option to manually increase the window size. Both the Java and C implementations had the option much earlier; I see a commit adding it in Java in March 2015.

At least by August 2015 I was working on automatic window size tuning, which I've not seen in another HTTP/2 implementation to date. July 2016 it was implemented in Java, but remains disabled due to interoperability concerns that we need to spend time addressing. C now implements something similar and it may be enabled in 1.3.

For flow control to work promptly the window size should be only as large as necessary, so there is cause for keeping it small. Since the lower value is appropriate for many networks, it isn't completely outrageous.

I think the biggest failure on gRPC's part here is not having a notice in a widely-read part of documentation informing users to be aware of the limitation. That's easier said than done, but that doesn't negate its importance.

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

#88

Post by shaklee3 »

grizzles wrote: post #11

Personally I'd prefer a promise based api. eg. stub.QueryBooks(qbr).then(...) A benefit of grpc coming to the web means someone will inevitably build a tool to parse a .proto file and generate a ui to test your microservices during dev. That will be cool.

Not exactly a promise, but grpc has an asynchronous API.

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

#89

Post by ska »

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…

   and it does the job.
It does some jobs admirably. Because of the tooling and familiarity, it's often asked to do other jobs, and here the results are decidedly mixed.

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

#90

Post by pspeter3 »

One cautionary tale is to avoid generating code that exists at run time with Typescript. We managed to cause a severe page load regression for a while by generating Typescript for each DbObject and Projection (similar to a persistent GraphQL query).

My advice is to only generate types and interfaces if possible.

Post reply on HN