4 ms·

After half a decade of "better than JSON" mentality, fiddling with thrift, protobufs, custom serialization methods, I came to realize JSON/HTTP is usually the r

by lxe 6y ago

After half a decade of "better than JSON" mentality, fiddling with thrift, protobufs, custom serialization methods, I came to realize JSON/HTTP is usually the right tool for 90% of jobs.

DJBunnies 6y ago
Agree. Handful of cases where thrift or grpc helps with an interface or streaming, but they seem to be the edge cases.
secondcoming 6y ago
Maybe, if you're not paying for data transmission costs. Binary formats win for the following cases: - payload size - serialisation/deserialisation speed - simplicity of client / server code (e.g. replacing a full blown HTTP server with a simple ZeroMQ one) Sure, having payloads that are human readable is great for initial debugging/verification, but once things are put live it's just an unnecessary expense.
- t-writescode 6y ago
  Definitely not for simplicity of server/client code. Using a Json serialization library basically means implementing a POJO at this point.
  - secondcoming 6y ago
    I was more referring to the overkill nature of needing a HTTP server rather than the ease of integration of JSON parsing code.
    - t-writescode 6y ago
      I remain confused. Many libraries support generic data contracts that enable both xml and json objects from the same objects.
- lxe 6y ago
  This is true. There usually are a few cases an org would have where latency costs, de-serialization and deserialization costs outweigh the simplicity of http/json, and it usually happens in a business critical part of the company. This leads to a standardization policy where ALL projects now use grpc/thrift/etc... as an RPC standard, even if when it doesn't make sense.
  - cbsmith 6y ago
    "simplicity of http/json" always elicits snickering from me. HTTP, by itself, is one of the more complex layer-7 protocols known to man. UTF-8 is not simple. Converting a decimal string representation of a floating point value into IEEE 754 is not simple (particularly compared to... memcpy). In a bizarre example of the tail wagging the dog, the ARM ISA has added an instruction specifically for parsing JSON... There's really not a lot of value in having different serialization formats, so the "even if it doesn't make sense" requires a specific context for determining what makes sense.
    - fanf2 6y ago
      I guess the ARM instruction you are thinking of is FJCVTZS, which implements the special ToInt32 operation required by JavaScript. https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... It is nothing to do with JSON.
      - cbsmith 6y ago
        You think an instruction with Javascript in the name, that converts JavaScript floating-point to signed fixed-point, rounding towards zero, isn't used when parsing JSON?
        SAI_Peregrinus 6y ago
        It is, but oddly enough Javascript numbers and JSON numbers are different and mutually incompatible. JS allows ±INF and the NANs, since it uses IEEE754 double-precision floating point. JSON doesn't, and technically allows arbitrary precision floating point (though implementations are allowed to define truncation behavior to a format at least as large as an IEEE754 double).
- cbsmith 6y ago
  With compression, payload size differences aren't that significant, and don't necessarily favour other formats (e.g. almost none of the formats have particularly compact representations of strings, and single decimal digit integer values are common enough that integer fields are not that wasteful in JSON). I totally hear you on serialization/deserialization speed, though it is amazing how inefficient some of the "machine readible" implementations can be, and how efficient people have been able to get JSON parsing, its horrible design disadvantage in this area is lethal. The simplicity argument is an amusing one to me. I think a lot of people build simple client/server code for JSON, but these "simple" implementations have all kinds of rough edges that prove problematic long term. Once you start doing things right, JSON proves to be far more complex.
  - secondcoming 6y ago
    Are you including the size of the typically useless HTTP headers when you talk about 'payload size', or just the actual payload in the HTTP request itself? I really mean 'typically useless' in the scenario where the communication is being done internally, not when you're actually communicating over the public internet. There can be quite a bit of wastage in this scenario. I really don't care about the 'Date' header or the 'Server' header, but the HTTP spec does, so they're there.
    - cbsmith 6y ago
      Thanks to all that complexity in HTTP (particularly HTTP2), there is no need to pay that headers size cost in most cases, particularly ones where bandwidth tends to be a concern. Yes, naive and "simple" implementations totally waste a TON of space in headers, and even if you exploit all that complexity HTTP is still inefficient in terms of network bandwidth consumption, much as even compressed JSON is still inefficient with its use of bytes. All I'm saying is that while JSON is horribly inefficient for some payloads, the reality is that most serialization formats tend to be efficient for specific kinds of payloads, but still have plenty of common cases they don't attempt to be efficient with. For example, machine readable formats like protobuf, thrift, avro, etc. employ some variation on varint encoding to keep small integers compactly represented, they encode strings relatively inefficiently; They encode field type & number, followed by a varint for length, followed by uncompressed UTF-8 encoded payload... and I've found that if anything it seems once you go through the compression ringer it often isn't much different in terms of space consumption vs. JSON... and sometimes it can be less efficient. Given how often fields end up being encoded as strings (even though they should be enums, ints, etc.), this has resulted in a lot of surprising cases for teams who have tried switching away from JSON to reduce payload sizes. If you cared about efficiency, you'd probably have a special encoding mechanism for short strings, and then a reasonably compact (but fast to parse) representation for longer strings, probably using something like SCSU encoding instead of UTF-8.
cbsmith 6y ago
...and I've reached the exact opposite conclusion. You aren't unusual, but I've never been able to understand how people get there any more than they understand how I have come to my conclusion.
rwmj 6y ago
Provided you never need to use integers > 53 bits, dates, binary data, comments or validate what you're sending or receiving it's totally fine.
- fanf2 6y ago
  I-JSON specifies how to represent dates and binary data in strings. https://tools.ietf.org/html/rfc7493 https://tools.ietf.org/html/rfc7493 JSON Schema http://json-schema.org/ http://json-schema.org/ is widely used for things like Swagger / OpenAPI.
  - xellisx 6y ago
    I like JSON Schema and I wish Typescript did something more like it with it type definitions.

by lxe 6y ago

After half a decade of "better than JSON" mentality, fiddling with thrift, protobufs, custom serialization methods, I came to realize JSON/HTTP is usually the right tool for 90% of jobs.

DJBunnies 6y ago

Agree. Handful of cases where thrift or grpc helps with an interface or streaming, but they seem to be the edge cases.

secondcoming 6y ago

Maybe, if you're not paying for data transmission costs. Binary formats win for the following cases: - payload size - serialisation/deserialisation speed - simplicity of client / server code (e.g. replacing a full blown HTTP server with a simple ZeroMQ one) Sure, having payloads that are human readable is great for initial debugging/verification, but once things are put live it's just an unnecessary expense.

t-writescode 6y ago
Definitely not for simplicity of server/client code. Using a Json serialization library basically means implementing a POJO at this point.
- secondcoming 6y ago
  I was more referring to the overkill nature of needing a HTTP server rather than the ease of integration of JSON parsing code.
  - t-writescode 6y ago
    I remain confused. Many libraries support generic data contracts that enable both xml and json objects from the same objects.
lxe 6y ago
This is true. There usually are a few cases an org would have where latency costs, de-serialization and deserialization costs outweigh the simplicity of http/json, and it usually happens in a business critical part of the company. This leads to a standardization policy where ALL projects now use grpc/thrift/etc... as an RPC standard, even if when it doesn't make sense.
- cbsmith 6y ago
  "simplicity of http/json" always elicits snickering from me. HTTP, by itself, is one of the more complex layer-7 protocols known to man. UTF-8 is not simple. Converting a decimal string representation of a floating point value into IEEE 754 is not simple (particularly compared to... memcpy). In a bizarre example of the tail wagging the dog, the ARM ISA has added an instruction specifically for parsing JSON... There's really not a lot of value in having different serialization formats, so the "even if it doesn't make sense" requires a specific context for determining what makes sense.
  - fanf2 6y ago
    I guess the ARM instruction you are thinking of is FJCVTZS, which implements the special ToInt32 operation required by JavaScript. https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-instruction-with-javascript-in-the-name-fjcvtzs https://stackoverflow.com/questions/50966676/why-do-arm-chip... It is nothing to do with JSON.
    - cbsmith 6y ago
      You think an instruction with Javascript in the name, that converts JavaScript floating-point to signed fixed-point, rounding towards zero, isn't used when parsing JSON?
      - SAI_Peregrinus 6y ago
        It is, but oddly enough Javascript numbers and JSON numbers are different and mutually incompatible. JS allows ±INF and the NANs, since it uses IEEE754 double-precision floating point. JSON doesn't, and technically allows arbitrary precision floating point (though implementations are allowed to define truncation behavior to a format at least as large as an IEEE754 double).
cbsmith 6y ago
With compression, payload size differences aren't that significant, and don't necessarily favour other formats (e.g. almost none of the formats have particularly compact representations of strings, and single decimal digit integer values are common enough that integer fields are not that wasteful in JSON). I totally hear you on serialization/deserialization speed, though it is amazing how inefficient some of the "machine readible" implementations can be, and how efficient people have been able to get JSON parsing, its horrible design disadvantage in this area is lethal. The simplicity argument is an amusing one to me. I think a lot of people build simple client/server code for JSON, but these "simple" implementations have all kinds of rough edges that prove problematic long term. Once you start doing things right, JSON proves to be far more complex.
- secondcoming 6y ago
  Are you including the size of the typically useless HTTP headers when you talk about 'payload size', or just the actual payload in the HTTP request itself? I really mean 'typically useless' in the scenario where the communication is being done internally, not when you're actually communicating over the public internet. There can be quite a bit of wastage in this scenario. I really don't care about the 'Date' header or the 'Server' header, but the HTTP spec does, so they're there.
  - cbsmith 6y ago
    Thanks to all that complexity in HTTP (particularly HTTP2), there is no need to pay that headers size cost in most cases, particularly ones where bandwidth tends to be a concern. Yes, naive and "simple" implementations totally waste a TON of space in headers, and even if you exploit all that complexity HTTP is still inefficient in terms of network bandwidth consumption, much as even compressed JSON is still inefficient with its use of bytes. All I'm saying is that while JSON is horribly inefficient for some payloads, the reality is that most serialization formats tend to be efficient for specific kinds of payloads, but still have plenty of common cases they don't attempt to be efficient with. For example, machine readable formats like protobuf, thrift, avro, etc. employ some variation on varint encoding to keep small integers compactly represented, they encode strings relatively inefficiently; They encode field type & number, followed by a varint for length, followed by uncompressed UTF-8 encoded payload... and I've found that if anything it seems once you go through the compression ringer it often isn't much different in terms of space consumption vs. JSON... and sometimes it can be less efficient. Given how often fields end up being encoded as strings (even though they should be enums, ints, etc.), this has resulted in a lot of surprising cases for teams who have tried switching away from JSON to reduce payload sizes. If you cared about efficiency, you'd probably have a special encoding mechanism for short strings, and then a reasonably compact (but fast to parse) representation for longer strings, probably using something like SCSU encoding instead of UTF-8.

cbsmith 6y ago

...and I've reached the exact opposite conclusion. You aren't unusual, but I've never been able to understand how people get there any more than they understand how I have come to my conclusion.

rwmj 6y ago

Provided you never need to use integers > 53 bits, dates, binary data, comments or validate what you're sending or receiving it's totally fine.

fanf2 6y ago
I-JSON specifies how to represent dates and binary data in strings. https://tools.ietf.org/html/rfc7493 https://tools.ietf.org/html/rfc7493 JSON Schema http://json-schema.org/ http://json-schema.org/ is widely used for things like Swagger / OpenAPI.
- xellisx 6y ago
  I like JSON Schema and I wish Typescript did something more like it with it type definitions.