Description
I'd like to add in the ability to swap in a custom msgpack library to use. I'm making a proposal first before opening a PR just to see if there's support. This would somewhat mirror the existing capacity to bring your own packet parser to socket.io.
My proposal for the change would be to add a new key/value to RedisAdapterOptions of something like:
interface MsgpackInterface {
decode: (data: any) => any;
encode: (data: any) => any;
}
interface RedisAdapterOptions {
// other options
/**
* MessagePack library to use for marshaling and un-marshalling data out of Redis.
*
* @default notepack.io
*/
msgpack?: MsgpackInterface;
}
and then in the RedisAdapter constructor, have something like this.msgpack = opts.msgpack || msgpack, and then any future call to msgpack in the class would be replaced with this.msgpack. I've loosely tested this within my own application and haven't seen anything break, but I may be missing something on how this is used.
I'd make a similar change for the @socket.io/redis-emitter library as well.
For the motivation for this change, this library currently uses the notepack.io library to handle encoding/decoding messages into/out of redis. In benchmarking our application, we are finding that msgpackr library would give us a decent speed-up for the sorts of payloads we have (We also already use it in a number of other places in our stack):
Encoding (this will take a while):
+----------------------------+----------------+
| │ data |
+----------------------------+----------------+
| notepack │ 25,242 ops/sec |
+----------------------------+----------------+
| msgpack-js │ 2,192 ops/sec |
+----------------------------+----------------+
| msgpack-lite │ 17,457 ops/sec |
+----------------------------+----------------+
| @msgpack/msgpack │ 21,024 ops/sec |
+----------------------------+----------------+
| msgpackr │ 42,637 ops/sec |
+----------------------------+----------------+
| JSON.stringify (to Buffer) │ 16,157 ops/sec |
+----------------------------+----------------+
Decoding (this will take a while):
+--------------------------+----------------+
| │ data |
+--------------------------+----------------+
| notepack │ 24,175 ops/sec |
+--------------------------+----------------+
| msgpack-js │ 18,337 ops/sec |
+--------------------------+----------------+
| msgpack-lite │ 10,894 ops/sec |
+--------------------------+----------------+
| @msgpack/msgpack │ 19,320 ops/sec |
+--------------------------+----------------+
| msgparck │ 45,733 ops/sec |
+--------------------------+----------------+
| JSON.parse (from Buffer) │ 39,214 ops/sec |
+--------------------------+----------------+
As such, I'd like to have the ability to provide my own msgpack implementation to use for the adapter.