undefined | Better HN

0 pointssimplotek3y ago0 comments

> And the problem here wasn't JSON in the first place anyway

Yes it was. They stored state in a huge JSON dump which ended up working like a zip bomb by the way they had to escape a string. This alone resulted in an exponential increase in memory that quickly became a problem.

Think about it for a second: would they experience this issue if they stored an in-memory stack per user? They wouldn't.

Heck, it seems that they could live with their JSON choice if they replaced '/' with any other inescapable character and converted it back to '/' when reading.

0 comments

4 comments · 1 top-level

xigoi3y ago· 3 in thread

XML would also have a problem with this: you'd replace < with <, then with &lt;, then with &amp;lt;, … It's not exponential, but still inefficient.

simplotekOP3y ago

Inefficient is not the same as problematic. They turned what otherwise would be a linear increase in memory usage into an exponential increase, which expectedly resulted in memory exhaustion problems.

There are plenty of problems to go around this approach and overall system design, but the weakest link is undoubtedly how JSON was used.

jmull3y ago

Can you imagine arguing in a tech meeting that a reason not to use JSON is that it doesn't support unbounded recursive levels of escaping very well?

ilyt3y ago

That is just entirely wrong; not serializing JSON into JSON would turn it back into linear.

j / k navigate · click thread line to collapse