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

71–80 of 139 posts

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

#71

Post by jayd16 »

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…

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 insane CI system that builds every project at once...but any schema would work and you can be generating and checking against a schema for a JSON API as well. You don't need to move past REST and JSON to get what you're asking for.

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

#72

Post by grovesNL »

I'm not sure why you need to modify your serialization or protocol to get type safety.

I've been using NSwag (https://github.com/NSwag/NSwag) to generate TypeScript clients from .ASP.NET controllers and it works great. It can generate TypeScript request/response handlers, and interfaces or classes for any public facing models.

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

#73

Post by rdtsc »

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, Facebook or Amazon , and you don't really do BigData just your know, regular data.

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

#74

Post by dozzie »

cpburns2009 wrote: post #69
dozzie wrote: post #59

Earlier quoted context omitted.

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

I'm pretty sure that's not what he said. He used an argument that is not about how much one can express directly, but about dynamic typing nature of JSON.

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

#75

Post by krona »

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.

Unless you're, you know, streaming anything other than UTF8.

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

#80

Post by [deleted] »

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…

[deleted]
Post reply on HN