The middleware works a lot like compression, a standard Express middleware which transparently compresses any text-based response body that emits from something in the middleware chain.
hastily works as an add-on to an Express server or middleware that is already serving images.
;;const app = ;app;app;
You now have an app which can serve any image from
/www/images, and optimize it with URL parameters from the Fastly Image Optimization API.
Hastily is meant to be registered as a middleware within an app that may be handling non-image requests as well as image requests. By default, it will only attempt to transform responses that appear to be uncompressed images. Hastily verifies this in several steps.
By URL: The default
filterfunction for the imageopto middleware is
hastily.hasSupportedExtension(req: Request)It. checks a request's URL path for an extension that indicates a Sharp-supported file type. It reads the supported extensions from Sharp itself. If a file does not have an image-file extension, it will do nothing.
Supply an alternative function as the
filterproperty of imageopto options to override this behavior.;// Don't require an extension. Require a certain base directory and query param.;// Require an extension, OR an 'imageServer' path.hastily;
By method and status: Hastily will not transform any response unless the request was a
GETand the response code is in the
By Cache-control: If the response has a
no-transform, Hastily will respect that.
By dedupe: Both Hastily and Fastly (which Hastily emulates) set telltale headers on responses after processing them. If a
fastly-io-infoheader is present, OR an
X-Optimized: hastilyheader is present, Hastily will assume a transform has already occurred and won't attempt another. This behavior can be overridden by
options.force, but you shouldn't do that.
By content type: Hastily will try to get the
Content-Typeheader of the response. If it cannot detect a content type, OR if Sharp does not support the content type, Hastily will not attempt to transform.
By content encoding: Hastily will not attempt to decompress gzipped responses. Images shouldn't be gzipped (or deflated, or brotli'd, or what have you) and it's a mistake to configure a server to do so by default. The available gzip algorithms are designed for text data, and they don't compress binary data hardly at all. If your server is gzipping images before Hastily handles them, fix this configuration for the highest speeds.
The Hastily middleware logs debugs, warnings and errors to standard error, which is what web server stacks expect. When
production, only warnings will be logged, as parseable JSON lines.
NODE_ENV is not
production, Hastily respects the Node convention of path syntax in the
DEBUG environment variable to determine log level.
DEBUG=hastily:* will show all debug data in a pretty format. You can limit logging to subject areas by using paths like
- implement resize and crop mappers
- throw on unsupported
- implement enable and disable for upscaling in resize
- implement format, auto=webp, and quality params in post-manip phase
- add unit tests
- add image-diff automated testing
- implement sharpen, mapping [amt, radius, threshold] to libvips sharpen params
- implement brightness, contrast, saturation by figuring out percentage to multiplier mapping
- use image.metadata() to implement relative and context-based methods
- add header-based methods