This portion of the workshop is focused on shrinking the size of data you send over to your client, aka the compression chapter. A lot of the times, you'll have your nginx doing the work for you, but on some occassions you might want to do this on a fly. So let's do some HTTP compression.
You want to be cmprssng & streamn on the fly as the reqsts comein . To
tackle this exercise, put together a simple
html file you want to be serving
up to your client.
Modern browsers accept one (or all) three types of compression algorithms:
brotli. You can see which ones are accepted under the
Node has a zlib implementation, which
allows you to compress both in
gzip. For brotli, you might want
to look this node's implementation
- create a server with
- as a
reqcomes in send back a
deflateversion of the file using
- curl your server and see what you're getting back. If it looks like gibberish, you're good.
Next try sorting out which of the compression algorithms the browser is accepting.
- check the
- send back the correctly compressed version. You might have to do a bit of matching.
To checkout the compression sizes you're getting back, pipe in something like
word count to your
$ curl -i -H "accept-encoding:gzip" localhost:8080 | wc
To 🍄 level up 🍄 , implent enbrotli compression as well!
You might want to create a read stream to send back the html file. Once you're
streaming, we suggest you use pump instead
of the usual
.pipe to handle your stream gracefully. We suggest to also
implement the optional callback to handle and the log the error, which is quite
important in production purposes.
Don't forget to set the correct
Content-Encoding when you send back the