A high performance javascript redis parser built for [node_redis](https://github.com/NodeRedis/node_redis) and [ioredis](https://github.com/luin/ioredis). Parses all [RESP](http://redis.io/topics/protocol) data.
Library.prototype.returnReply = function (reply) { ... }
Library.prototype.returnError = function (err) { ... }
Library.prototype.returnFatalError = function (err) { ... }
var lib = new Library();
var parser = new Parser({
returnReply: function(reply) {
lib.returnReply(reply);
},
returnError: function(err) {
lib.returnError(err);
},
returnFatalError: function (err) {
lib.returnFatalError(err);
}
});
Library.prototype.streamHandler = function () {
this.stream.on('data', function (buffer) {
// Here the data (e.g. `new Buffer('$5\r\nHello\r\n'`)) is passed to the parser and the result is passed to either function depending on the provided data.
parser.execute(buffer);
});
};
```
You do not have to use the returnFatalError function. Fatal errors will be returned in the normal error function in that case.
And if you want to return buffers instead of strings, you can do this by adding the `returnBuffers` option.
If you handle with big numbers that are to large for JS (Number.MAX_SAFE_INTEGER === 2^53 - 16) please use the `stringNumbers` option. That way all numbers are going to be returned as String and you can handle them safely.
```js
// Same functions as in the first example
var parser = new Parser({
returnReply: function(reply) {
lib.returnReply(reply);
},
returnError: function(err) {
lib.returnError(err);
},
returnBuffers: true, // All strings are returned as Buffer e.g. <Buffer48656c6c6f>
stringNumbers: true // All numbers are returned as String
});
// The streamHandler as above
```
## Protocol errors
To handle protocol errors (this is very unlikely to happen) gracefully you should add the returnFatalError option, reject any still running command (they might have been processed properly but the reply is just wrong), destroy the socket and reconnect. Note that while doing this no new command may be added, so all new commands have to be buffered in the meantime, otherwise a chunk might still contain partial data of a following command that was already processed properly but answered in the same chunk as the command that resulted in the protocol error.
## Contribute
The parser is highly optimized but there may still be further optimizations possible.
npm install
npm test
npm run benchmark
Currently the benchmark compares the performance against the hiredis parser:
