I’m a latecomer to this conversation by 3 months, but I would have voted to not include Brotli and zstd by default. We have an nginx proxy in front of our services that can handle compression/decompression if required, and the extra filesize is a real bummer. We’re going to be looking at using GraalVM soon, I’m hopeful that the Brotli and zstd JARs don’t end up compiled into the native-image binary https://clojurians.slack.com/archives/C0G922PCH/p1702723929287379
You are not the only one with that pain point, see the discussion from https://github.com/clj-commons/aleph/pull/705#issuecomment-1985055876 onward
Also has some context on why not including them by default is apparently not so easy 😕
@danielcompton Fair warning, there have been attempts to package aleph for graal over the years, but iirc, there were obstacles in aleph and manifold that made that difficult. Not sure where things stand currently. Also, it's not ideal for your case, but you should be able to strip out the compression libs for the architectures you don't care about, to save some space.
Took another stab at making zstd and brotli optional again: https://github.com/clj-commons/aleph/pull/723
Does anyone have any experience with sending/receiving binary data over an aleph websocket when :compression? is enabled? I'm seeing something that is almost certainly either a bug in the browser or in aleph, and I suspect it's aleph, but it's not very easy to just jump into the guts of the netty websocket compression code.
The config and/or a minimal test case would help.