19 ms·
I see two great things about this tool, and not exactly for what it was designed: 1) Fix bandwidth problems caused by API designer laziness. 2) Detect API des
by codehero 12y ago
I see two great things about this tool, and not exactly for what it was designed:
1) Fix bandwidth problems caused by API designer laziness.
2) Detect API designer laziness and programmer laziness.
The API designer laziness merits description. Essentially, if you as an API host server are sending back tons of redundant data, you are doing a disservice to your user by not passing references to this data in the first place. The results in your API should either include an entities section or links to retrieve more data. (Note the scale of repeated data I am talking about here are subtrees, not just key/value)
The programmer laziness is when an he just sends back JSON.stringify(someVeryLargeObject), instead of making sure only a minimal object is sent back.
So we can detect this laziness by running this tool and looking for 4x compression gains!
- Ixiaus 12y agoBandwidth issues can be solved well with msgpack too.
- Guillaume86 12y agoIt's not always lazyness, several small connections can be considered worse than one bigger payload in some scenarii. There's no universal truth about API design, every case is different.
- AYBABTME 12y agoSending too much data is often better than having to do many RPC calls. It's the same problem than normalizing/denormalizing DB schemas, except that DB engines are smart (denormalizing can hurt perf) while RPC clients aren't.