Hacker News Reader

Comment by crdrost | Hacker News Reader

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?

View on HN

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

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.

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

Deeply nested objects grow linearly with the size of history, not exponentially.

Agreed, I'd take deeply nested objects, over deeply nested strings (of strings...) of objects.

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.

Reply on news.ycombinator.com