@ji-constructs/cdk-image-resize-behavior
v0.6.3
Published
This construct library is adapted from [https://github.com/nlopezm/aws-cdk-image-resize](https://github.com/nlopezm/aws-cdk-image-resize) which was inspired by [this blog](https://aws.amazon.com/blogs/networking-and-content-delivery/resizing-images-with-a
Downloads
26
Readme
AWS Image Resizer Construct Library
This construct library is adapted from https://github.com/nlopezm/aws-cdk-image-resize which was inspired by this blog from the AWS official website and this one from web.dev, and provides a way to easily setup the required arquitecture to start serving performant images.
Optimization
If the client is requesting an image and if the client supports avif or webp, this construct will take care of returning an optimized image (which is usually 80% lighter than the conventional jpg/png images).
Resizing
You might want to serve multiple image versions. Why would your mobile users pay the cost of loading the same big files desktop users need?
Just pass width
and/or height
(in px) as query params and you will get original image cropped to the requested sizes.
This is how the client's code would look like:
<img
srcset="https://cloudfront-url/path-to-your-image/image.ext?width=150 150w,
https://cloudfront-url/path-to-your-image/image.ext?width=500 500w,
https://cloudfront-url/path-to-your-image/image.ext?width=800 800w"
src="https://cloudfront-url/path-to-your-image/image.ext"
>
Refer here for more information on this!
Image generation workflow
Source: AWS blog
- Two Lambda@Edge triggers namely Viewer-Request and Origin-Response which are associated to a CloudFront distribution.
- Amazon Simple Storage Service (Amazon S3) as origin.
Let’s understand what happens in these various steps 1 to 5
Step 1: The requested image URI is manipulated in the viewer-facing Lambda@Edge function to serve appropriate dimension and format. This happens before the request hits the cache. The URI should be the path to the original resource (e.g. /image.jpg). The manipulated URI will look something like this:
/image.png
, if no optimization or resize is possible/image.png;;.webp
, if webp supported by the client/image.png;width=${width}&height=${height};.webp
, in case width and/or height are supplied as query params
Step 2: CloudFront fetches the object from S3.
Step 3: If the required image is already present in the bucket, S3 returns the object to CloudFront. Otherwise it returns a 404 Not Found response.
Step 4: CloudFront returns the resulting image to the viewer.
Step 5: If the image is not present in the bucket, the original image is fetched, the resize and optimizations are applied and the resulting file is put into the bucket so subsequent requests return this image that is now already present in the bucket. If the original image could not be fetched, the 404 is passed onto the viewer.
Note: Step 2, 3 and 5 are executed only when the object is stale or does not exist in CloudFront cache. Static resources like images should have a long Time to Live (TTL) as possible to improve cache-hit ratios.
This step by step is also taken from AWS blog with some minor tweaks.
How to use
Default
import * as cdk from 'aws-cdk-lib/core';
import { ImageResize } from 'aws-cdk-image-resize';
export class MyStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const imageResize = new ImageResizeBehavior(this, 'ImageResize');
}
}
BYOB (bring your own bucket... and cloudfront distribution)
import * as cdk from 'aws-cdk-lib/core';
import { ImageResize } from 'aws-cdk-image-resize';
export class MyStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const bucket = new Bucket(this, 'Bucket');
const imageResize = new ImageResizeBehavior(this, 'ImageResize', {
createDistribution: false,
s3BucketOrProps: bucket,
});
const cloudfront = new Distribution(this, 'Distribution', {
defaultBehavior: imageResize.behaviorOptions,
});
}
}
The construct is 100% customizable:
- s3BucketProps: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-s3-readme.html
- originResponseLambdaProps: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-lambda-readme.html
- viewerRequestLambdaProps: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-lambda-readme.html
- cloudfrontDistributionProps: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-cloudfront-readme.html
Resources created
This Construct will create
- 1 Lambda@Edge function for the Viewer Request
- 1 Lambda@Edge function for the Origin Response with permissions to write and read the S3 bucket. This lambda uses sharp library under the hood.
- 1 Cloudfront Distribution (optional)
- 1 S3 bucket (optional)
Roadmap
- Add a way to keep the derrived images in a separate bucket and/or separate key prefix from the source images, apply Tags to the derrived images, and apply lifecycle policy to the derrived images so they will automatically be cleaned up and don't hang around forever.