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

51–60 of 139 posts

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

#51

Post by runeks »

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 nothing about REST+JSON that prevents type safety, as far as I'm aware.

I plan to switch to protobuf3 for the serialization format, since this offers both a JSON and binary representation. Why would I want to choose gRPC+proto3 over REST+proto3?

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

#52

Post by al2o3cr »

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

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

#54

Post by d--b »

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 server will adapt, and shout at compile time if the types don't match. This wasn't the case when the server was sending JSON to a web listener. You'd have to hunt down the dependency to that method and change it.

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

#55

Post by IshKebab »

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?

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

#56

Post by andrewingram »

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

Personally I consider it a bug, but I was trying to avoid being too dogmatic in my comment, given it's clear i'm already decidedly biased in favour of GraphQL.

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

#57

Post by neon_electro »

IshKebab wrote: post #53

They sure do like spikes... whatever that means.

"A spike is a product-testing method that is used to determine how much work will be required to solve or work around a software issue." [1]

[1] https://en.wikipedia.org/wiki/Spike_(software_development)

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

#58

Post by billsmithaustin »

lstroud wrote: post #26

Stub generation? Remote access protocols? CORBA all over again? So, now I know the next big thing. Portable distributed objects. :-P

It's wrong to assume that just because gRPC shares some design features with CORBA that it shares every CORBA feature or every CORBA shortcoming.

There have been technologies to generate stubs, skeletons, and protocols from specification files for at least 30 years. Some of the older designs sprung out of a client/server world, whereas newer designs deal with today's reality, e.g. interoperability with today's web and the need for horizontal scalability.

What hasn't changed is that it's still useful to describe a communication protocol in a declarative way and then rely on a code generator to provide the code to work with that protocol.

Google protocol buffers offer advantages beyond that, but you may need to look beyond any preconceived CORBA biases to appreciate them.

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

#59

Post by dozzie »

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?

> 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 your JSON RPC system?

So you claim that JSON doesn't have types, right? And, by extension, Python and Lisp don't have types, too, because of the very same arguments? You know you're being ridiculous now, right?

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

#60

Post by cle »

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?

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 typed RPC. You don't have to use the typed client. Or you could be using an old version, or it could be misconfigured, etc. You can enforce schema on the server and client side, but you'll never really know if it works statically, since you don't compile and deploy the server and client atomically.

Post reply on HN