3 ms·
That makes sense. There are also good reasons to just HTTP: one less technology to understand/troubleshoot, reuse existing tools and middleware.
by tlrobinson 12y ago
That makes sense. There are also good reasons to just HTTP: one less technology to understand/troubleshoot, reuse existing tools and middleware.
- rubiquity 12y agoYup, I agree with that and in a team environment that may be very valuable. HTTP is definitely the "JavaScript of protocols." However, I don't think learning other protocols is a ton of overhead, and learning is always a good thing ;)
- Xorlev 12y agoWe've had a similar argument internally. In load testing, we're not bounded by the speed of our JSON parsing, and if we were we'd probably just swap that endpoint to use a different message body provider before moving to a totally binary RPC model. Especially in the Java world, where Jackson + Afterburner is fast enough for most cases. Protobufs/Thrift will smoke it in most performance tests, true enough, but when you're waiting on a database or algorithm to run, what's JSON serialization? There's certainly benefits at extreme scale, but not enough to justify the loss of tooling that comes with it until necessary.