Recognized string types, things C++ can read and understand as strings. "String" does not have to mean "text", it can also be "binary".
Ironically, JavaScript strings are the least performant of all options, to pass or receive to/from C++. This because we expect UTF-8, which is packed in 8-byte chars. JavaScript strings are UTF-16 internally meaning extra copies and reinterpretation are required.
That's why all events pass data by ArrayBuffer and not JavaScript strings, as they allow zero-copy data passing.
You can always do Buffer.from(arrayBuffer).toString(), but keeping things binary and as ArrayBuffer is preferred.
Sliding dedicated compress window, requires 128KB of memory per socket
Sliding dedicated compress window, requires 16KB of memory per socket
Sliding dedicated compress window, requires 256KB of memory per socket
Sliding dedicated compress window, requires 32KB of memory per socket
Sliding dedicated compress window, requires 3KB of memory per socket
Sliding dedicated compress window, requires 4KB of memory per socket
Sliding dedicated compress window, requires 64KB of memory per socket
Sliding dedicated compress window, requires 8KB of memory per socket
No compression (always a good idea if you operate using an efficient binary protocol)
Zero memory overhead compression (recommended for pub/sub where same message is sent to many receivers)
Constructs a non-SSL app. An app is your starting point where you attach behavior to URL routes. This is also where you listen and run your app, set any SSL options (in case of SSLApp) and the like.
Constructs an SSL app. See App.
Takes a POSTed body and contentType, and returns an array of parts if the request is a multipart request
Closes a uSockets listen socket.
Generated using TypeDoc
WebSocket compression options