5 ms·

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 defi

by runeks 10y ago

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?

d--b 10y ago
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.
- jayd16 10y ago
  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.
  - deleted 10y ago
    [deleted]
  - d--b 10y ago
    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.
  - bkeroack 10y ago
    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.
- bluejekyll 10y ago
  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.
IshKebab 10y ago
> 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?
- dozzie 10y ago
  > 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?
  - cpburns2009 10y ago
    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".
    - dozzie 10y ago
      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.
- cle 10y ago
  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.
atombender 10y ago
gRPC has some benefits over REST. Since it's declarative, the entire API can be expressed as an RPC block in the .proto file, so your clients in multiple languages can be generated from this spec. With REST, you'd have to tell clients what protobuf structs to use with what endpoints. But of course the end result is roughly the same, once you've built clients and servers. gRPC's built-in streaming and support for out-of-band data ("header" and "trailer" metadata) is also nice. For example, a gRPC server can emit trailing metadata containing an error, if something goes wrong halfway through a streaming request. Without this, you'd have to build a custom "protocol" on top of your Protobuf REST stuff; the stream would/could emit oneOf-structs that contain either payloads or metadata. One downside to gRPC/Protobuf is that it's much less convenient to perform quick and dirty interactions against the servers. There's no standard, I think, for exporting the gRPC API to a client that doesn't already have the .proto file; I could be wrong, but don't think you can build a generic client that can talk to any gRPC server, list its available endpoints and so on.

by runeks 10y ago

d--b 10y ago

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.

jayd16 10y ago
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.
- deleted 10y ago
  [deleted]
- d--b 10y ago
  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.
- bkeroack 10y ago
  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.
bluejekyll 10y ago
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.

IshKebab 10y ago

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

dozzie 10y ago
> 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?
- cpburns2009 10y ago
  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".
  - dozzie 10y ago
    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.
cle 10y ago
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.

atombender 10y ago

gRPC has some benefits over REST. Since it's declarative, the entire API can be expressed as an RPC block in the .proto file, so your clients in multiple languages can be generated from this spec. With REST, you'd have to tell clients what protobuf structs to use with what endpoints. But of course the end result is roughly the same, once you've built clients and servers. gRPC's built-in streaming and support for out-of-band data ("header" and "trailer" metadata) is also nice. For example, a gRPC server can emit trailing metadata containing an error, if something goes wrong halfway through a streaming request. Without this, you'd have to build a custom "protocol" on top of your Protobuf REST stuff; the stream would/could emit oneOf-structs that contain either payloads or metadata. One downside to gRPC/Protobuf is that it's much less convenient to perform quick and dirty interactions against the servers. There's no standard, I think, for exporting the gRPC API to a client that doesn't already have the .proto file; I could be wrong, but don't think you can build a generic client that can talk to any gRPC server, list its available endpoints and so on.