3 ms·

Or, y'know, just jo.put("previous", previous); Rather than jo.put("previous", previous.toJson()); Presumably the reason they didn't do this is becau

Or, y'know, just jo.put("previous", previous); Rather than jo.put("previous", previous.toJson()); Presumably the reason they didn't do this is because they couldn't handle a recursive schema?

alephaleph 4y ago
In the post they say they didn’t do this bc they’d just be trading long strings for deeply nested objects.
- lalaithion 4y ago
  Deeply nested objects grow linearly with the size of history, not exponentially.
  - NegativeLatency 4y ago
    Agreed, I'd take deeply nested objects, over deeply nested strings (of strings...) of objects.
- crdrost 4y ago
  For the record I do agree that the schema data Screen = Screen { previous :: Maybe Screen, ... } is inferior to what they eventually had, data ScreenHistory = ScreenHistory { previous10 :: [Screen], current :: Screen } -- Screen itself is nonrecursive But I do think that storing JSON as a string was a weird antipattern in the first case, smacking of a premature optimization.
btown 4y ago
This is reminiscent of some APIs I've had the great pleasure of needing to integrate with, where a SOAP API would take XML containing Username, Password, Method, Data... where Data was a string, itself containing barely-documented XML, but serialized as a string before being placed in the XML. You'd think that if they knew how to stand up a SOAP API, they'd know that XML is literally designed to be nested. Alas, such was not the case. I shudder to think about their security under the hood...
- jiggawatts 4y ago
  I remember dealing with a small ISV that was told to make an RPC API, so they used SOAP (via WCF). That would have been fine, except that every function took a single "string" parameter that was invalid XML that a normal parser couldn't read. You had to use their hand-rolled parser. And then the whole thing was "encrypted"... with a static RSA key. I don't mean they used a stream cipher based on a hard-coded key, which would bad enough. No, they used the RSA keys directly for bulk data encryption. I flat rejected their solution, then was overruled as being "too picky", and this monstrosity went into production.

Or, y'know, just jo.put("previous", previous); Rather than jo.put("previous", previous.toJson()); Presumably the reason they didn't do this is because they couldn't handle a recursive schema?

alephaleph 4y ago

In the post they say they didn’t do this bc they’d just be trading long strings for deeply nested objects.

lalaithion 4y ago
Deeply nested objects grow linearly with the size of history, not exponentially.
- NegativeLatency 4y ago
  Agreed, I'd take deeply nested objects, over deeply nested strings (of strings...) of objects.
crdrost 4y ago
For the record I do agree that the schema data Screen = Screen { previous :: Maybe Screen, ... } is inferior to what they eventually had, data ScreenHistory = ScreenHistory { previous10 :: [Screen], current :: Screen } -- Screen itself is nonrecursive But I do think that storing JSON as a string was a weird antipattern in the first case, smacking of a premature optimization.

btown 4y ago

This is reminiscent of some APIs I've had the great pleasure of needing to integrate with, where a SOAP API would take XML containing Username, Password, Method, Data... where Data was a string, itself containing barely-documented XML, but serialized as a string before being placed in the XML. You'd think that if they knew how to stand up a SOAP API, they'd know that XML is literally designed to be nested. Alas, such was not the case. I shudder to think about their security under the hood...

jiggawatts 4y ago
I remember dealing with a small ISV that was told to make an RPC API, so they used SOAP (via WCF). That would have been fine, except that every function took a single "string" parameter that was invalid XML that a normal parser couldn't read. You had to use their hand-rolled parser. And then the whole thing was "encrypted"... with a static RSA key. I don't mean they used a stream cipher based on a hard-coded key, which would bad enough. No, they used the RSA keys directly for bulk data encryption. I flat rejected their solution, then was overruled as being "too picky", and this monstrosity went into production.