Batch mode for NRS HTTP API
Issue #7
new
The way the NRS API is written produces a lot of traffic and latency between clients and nodes. Batch API calls (e.g. to get a batch of account transactions with one API call) would be better.
Comments (3)
-
reporter
-
reporter
"Compression has the trade off of higher cpu load on the nodes, but might make sense anyway. I was more refering to latency and number of round-trips, which is very easy (=cheap) to fix. Currently when a client wants to fetch all or all recent transactions for an account, e.g. the last 100, it needs to do 101 requests to NRS. A simple batch API call for getPeers, getTransactions and probably for the AE stuff, where you ask for all e.g. transactions between timestamp X and Y and get all transactions details in one HTTP response would fix this. I think this would be a good initial bounty project. It would need rather simple extensions in the NRS core in non-critical areas. So people would actually touch the source, Jean-Luc would need to review the changes and bring it into his branch."
-
reporter
ferment: The nodes generally aren't under any CPU load. Reducing bandwidth will reduce hosting costs with EC2 and others that meter bandwidth. Given the refactoring of the JAVA code, I'm sure there's plenty of ways to wrap the code to do binary/compression like with BSON (binary json) or MessagePack in addition to setting up compression options in the HTTP server. We could also spec a high leval API to reduce the chattiness of the current API and batch things.
- Log in to comment
chan3r: "EDIT: Yep batch would be good and compression on this would yield even more benefits... esp remember people will be using mobiles and data hungry apps get a very bad press - I know..
I agree - perhaps some of this would be improved perhaps by just using RLE on some of the larger text data as a start... moving the API to binary would be significant work and probably not necessary initially - maybe one of the initial 'smaller' projects is one on client/node protocol compression.
"