3 ms·
What I wrote is based on a) best practice, b) the understanding that the vast majority of APIs are, in production, consumed by applications, not humans, and c)
by 7Figures2Commas 13y ago
What I wrote is based on a) best practice, b) the understanding that the vast majority of APIs are, in production, consumed by applications, not humans, and c) the knowledge that, in high-volume production environments, small inefficiencies can add up to larger inefficiencies.
Finally, I don't know where you came up with your 1% figure but I just ran a test on an API I use and the uncompressed pretty printed response was 24% larger than the uncompressed non-pretty printed response because of all the whitespace. I'd challenge you to find a scenario under which a pretty printed response of reasonable size is only 1% larger than its non-pretty printed counterpart.
- callahad 13y agoTo add more data to this discussion, I've been playing with the GitHub Issues API recently, which pretty-prints by default. I grabbed the last hundred open issues from the Mozilla Persona repo, and found == Uncompressed == Pretty Printed: 312,556 bytes Minified: 272,604 bytes ------------- Delta: 39,952 bytes (+14.66%) Not as bad as a 24% hit, but that's all moot because gfodor very explicitly discussed using gzip when pretty-printing. Let's see what happens there: == Gzipped == Pretty Printed: 41,748 bytes Minified: 40,648 bytes ------------- Delta: 1,100 bytes (+2.71%) Not as good as the original claim of <1%, but still pretty darn negligible. Data derived from this API endpoint: https://api.github.com/repos/mozilla/browserid/issues?per_page=100 https://api.github.com/repos/mozilla/browserid/issues?per_pa...
- gfodor 13y agoThanks. My <1% claim was ill-founded, I was assuming the use of tabs and trailing braces to minimize single-character lines so a little arithmetic in my head pointed to a small relative cost. But out of the box pretty printing does not try to minimize whitespace characters like this. Seems like it could be a worthy hack.