[IshKebab]

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

[cle]

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.

[IshKebab]

> And the same applies to a typed RPC.

Erm. It clearly doesn't. Because with typed RPC the generated functions will be something like this:

    sendDetails(name: string, age: int);

And you'll get a compile error if you use the wrong type (assuming you are using a language with proper typing - which they are). With JSON you can't do that (without crazy hacks anyway).

[computerex]

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 for you and is likely going to have the best adoption when it comes to interface definition languages like protobuf or Thrift.

[cle]

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.

[stickfigure]

Sure, and gRPC doesn't guarantee that the server is turned on when the client makes a request. Some expectations are unreasonable.

On the other hand, if you publish one set of proto files and all clients & servers consume these artifacts, the system as a whole is more "typesafe" and reliable than if you just post swagger docs and expect all your developers to check them daily for updates.

gRPC means API changes stand a good chance of getting caught by build systems. That seems about as reasonable a definition of "type safe across systems" as can be expected.

[cle]

I agree completely which is why I love proto.

[computerex]

Couldn't have put it better myself.

[kybernetikos]

> fast binary serialization/de-serialization with type safety

I'm not sure about Protobuf3, but certainly the older versions of protobuf could never be as fast as some other formats, because the message layouts were dynamic, meaning that you had to have lots of branches in the reading code.

[deno]

Protocol Buffers can even serialize down to JSON (as does Thrift, for example).

Client code for PB+JSON has been a part of Google’s Closure library in fact (open source), and they used it in production for Gmail’s RPC, but I’m not sure if it’s still supported/recommended for PB 3.

The reason to use JSON instead of compact binary representation has been because JSON.parse is fast and doesn’t require any additional code. But nowadays JS is fast enough in most cases (unlike you’re doing something like streaming with media exts), but you can also ship Web Assembly/NACL library and (soon) delegate parsing to Web Worker with shared memory which should altogether give best possible performance.

[anentropic]

nothing stops you sending bad data to a gRPC endpoint either

[BlackFly]

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't use that workflow, you will still be able to make a bad client.

[scott_karana]

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

[computerex]

Protobuf/gRPC are not specific to any given language.

[scott_karana]

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.

[dozzie]

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

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]

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.