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.