No reason you can't implement schemas over JSON. In fact, you typically implicitly do
Right, that's the point -- since in normal use you impose a set of "schema" requirements over all data interchange formats, even schemaless ones, it's a strictly good thing to have that schema explicitly written out. It means the compiler can verify your types are correct and the runtime can verify your messages have all the fields they'll need.
JSON is unversioned, so you can add and remove fields as you wish.
Sure, but if you do, you have to handle the version-management code at the application level, manually, where it's really easy to make mistakes.
And for languages where type safety is in place, the JSON libraries frequently allow you to pre-define the data structure which the JSON will attempt to parse into, giving type safety & a well define schema for very little additional overhead as well.
Sure, and if you're going to do that, you might as well use protobufs which is going to be much faster/more lightweight.
Sure, and if you're going to do that, you might as well use protobufs which is going to be much faster/more lightweight.
If you're looking for fast, you're probably not looking at an interpreted language. Plus, there are faster protocols out there than protobufs, if speed is all you care about.
It means the compiler can verify your types are correct and the runtime can verify your messages have all the fields they'll need.
Again, the OP was referring to using protobufs in Ruby. Type safety and the compiler are not high priorities when writing in Ruby.
Sure, but if you do, you have to handle the version-management code at the application level, manually, where it's really easy to make mistakes.
That depends on your application's requirements - for most cases, Python/Ruby/Javascript make it very easy to add or deprecate fields in dictionaries/hashes without having to explicitly worry about versions. Just specifying default values when requesting a key. And since you can ignore hash pairs with even less effort, deprecating portions of an API are simple.
Protobuffers definitely has its place, I'm just not convinced that place is in dynamically typed languages like Python, Ruby or Javascript.
Comments
Right, that's the point -- since in normal use you impose a set of "schema" requirements over all data interchange formats, even schemaless ones, it's a strictly good thing to have that schema explicitly written out. It means the compiler can verify your types are correct and the runtime can verify your messages have all the fields they'll need.
Sure, but if you do, you have to handle the version-management code at the application level, manually, where it's really easy to make mistakes.
Sure, and if you're going to do that, you might as well use protobufs which is going to be much faster/more lightweight.
If you're looking for fast, you're probably not looking at an interpreted language. Plus, there are faster protocols out there than protobufs, if speed is all you care about.
Again, the OP was referring to using protobufs in Ruby. Type safety and the compiler are not high priorities when writing in Ruby.
That depends on your application's requirements - for most cases, Python/Ruby/Javascript make it very easy to add or deprecate fields in dictionaries/hashes without having to explicitly worry about versions. Just specifying default values when requesting a key. And since you can ignore hash pairs with even less effort, deprecating portions of an API are simple.
Protobuffers definitely has its place, I'm just not convinced that place is in dynamically typed languages like Python, Ruby or Javascript.