ModaOperandi / agora

Engineering standards
3 stars 1 forks source link

Rework Image Resizing Lambda #60

Closed jackfarzan closed 2 years ago

jackfarzan commented 3 years ago

Current mojo cdn contains a Lambda that resizes all of our full sized production images on the fly to be served to the client. This puts all the computation on the lambda at edge, which has a very short maximum runtime, and this process can be done ahead of time once we know what images will be used on the site.

Can we have some process resize images before they're uploaded to discovery's asset bucket?

bjmiller commented 3 years ago

A clarification: The current resizer lambda first checks if the resized version of this image is the S3 bucket (already converted) before attempting to convert. If the lambda times out, or the response is larger then 1 million bytes, the user is served the original image.

We don't know which images will be used on site until late in the process, when products are created in Pink. So, we chose to resize what is asked for on the site, rather than trying to predict in advance which images will need to be resized vs. not resized.

jackfarzan commented 3 years ago

@bjmiller @upperbounds @barryoneill pls add image resizing reqs so we can figure out if/how we can develop an image resizer service

ruxy commented 3 years ago

@ppatt can you help with email images as well pls?

ruxy commented 3 years ago

https://github.com/ModaOperandi/cdn/tree/master/lambdas/img-resizing

barryoneill commented 3 years ago

Still gathering requirements on the PLG integration, but it's safe to assume the 3pl integration team will need an endpoint from which to fetch images for any given sku that will have the detail needed for the receiving team at the warehouse to verify that the item is what was ordered - as @upperbounds suggests, likely the same image from the PO.

This may or may not need to be a public API, depending on whether we decide to upload images to PLG or want them to fetch them from us.

upperbounds commented 3 years ago

Sizes produced by Mojo from full-size retouched studio images: Look image sizes: main => 348x558 medium_low => 256x410 thumb => 64x64

Product image sizes large => 1600x2550 medium_large => 750x1200 medium => 320x512 medium_low => 256x410 low => 150x240 small => 90x144 thumb => 64x64

Buy image sizes full => 220x352 small => 160x256 thumb => 64x64

Editorial images ???

ruxy commented 3 years ago

Customer-facing requirements:

In today's customer facing environment and considering we offer a product which shows a lot of images, we need to be able to get the right size images while maintaining aspect ratio in order to keep performance of the site and apps fast while providing a beautiful experience to our users.

Since our site is responsive and there are many different device screen sizes available both for app and site, we need an easy way to be able to get a particular image with parameters of height, width, and quality at the very least. We wouldn't want to pull the same size image for a mobile device as we do for desktop site, especially as performance is at a premium for mobile. For height and width, we want a generated image given those requirements while making sure there is auto-cropping available if needed and aspect ratio can be maintained even if the parameters given are not an exact match for the aspect ratio (this can also be a parameter). For quality requested this is because we may not always need the full resolution of an image, this is usually a balance between the way an image looks to the user and the performance metrics.

ruxy commented 3 years ago

Also need cache-busting in case there is an update to an image.

ruxy commented 3 years ago

We need to also resize animated gifs and pngs - right now Sharp does not offer that.