feat: GZIP

[PuruVJ]

This adds withCompression method on DbConnection with the options gzip | none. We are dropping brotli here and erroring out anywhere where we recieve a brotli message back.

For GZIP, we are using the built-in DecompressionStream('gzip') constructor which is compatible with Chrome 80 onwards and NodeJS 17+. This is a standard parser run at the system level by the browser/platform rather than the heavy userland brotli.js, saving us from any inconsistency from userland solutions.

As soon as DecompressionStream('brotli') gains minimum viable support, we will add that as an option as well. Tracking this issue whatwg/compression#34

This brings down our bundle size from 72.1KB min+br to just 7.2KB! 🎉

Main change

DecompressionStream is a stream, aka it is asynchronous. This means we need to add a bunch of async and awaits wherever the decoding is going on. Is that going to affect us?

[changeset-bot]

🦋 Changeset detected

Latest commit: 0bf82ae

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@clockworklabs/spacetimedb-sdk	Patch
@clockworklabs/test-app	Patch
client-vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/@clockworklabs/spacetimedb-sdk@109

commit: 0bf82ae

[Centril]

Minor questions but impl looks correct.

[gefjon]

DecompressionStream is a stream, aka it is asynchronous. This means we need to add a bunch of async and awaits wherever the decoding is going on. Is that going to affect us?

This is difficult for me to answer given that we don't have any fully-integrated tests or working examples.

Does the user-facing API change? No more async/await points should be exposed to users now than were before, which should be zero (but who knows if it actually was).

Is it possible that messages will be processed out-of-order if an early message takes a very long time to decompress, while a later message takes a short time to decompress?

If the answer to both of these questions is "no," then this is fine. Otherwise, something somewhere needs to change.

[gefjon]

Update: We determined that there is an out-of-order processing bug in this PR. The high-level solution will be to have a queue of handleOnMessage calls (or something like that), and zero-or-one handleOnMessage promises/futures. When one of those promises completes, grab the next call from the queue and start it. When the onMessage callback is invoked, check if a promise is already running; if it is, add the call to the queue rather than immediately spawning its promise.