There are a few SAS offerings out there that do something similar (https://www.imgix.com/ is another one). The advantage is that they take care of supporting all of the new image types that come out (HEIC/HEIF, etc.) and you can focus on your core business logic. All depends what kind of ‘transformations’ you are doing and if you need the Exif data maintained/updated in the images after modification (I think Imagizer strips the Exif out by default). If you can live with the limitations of these SAS offerings, you may not even need the second app since they’d be doing the hard work…it would essentially just become an asset server.

Another benefit of Cloudfront is that the cache gets copies stored geographically close to the end users, so it improves their page load times, even if your api has only one availability zone.

Without knowing your entire use model, not sure if Broadway, GenStage or even Flow would actually solve your bandwidth problem or not. If the end users expect the image to be served right away, back-pressure on the asset delivery isn’t the greatest solution and you’ll need to build a queuing or retry system in the consuming app to deal with that back-pressure/delay that the Elixir server would be applying. If this is the case, and you actually have a throughput problem, you might look at ways to alleviate the bottleneck before adding a lot of overhead in managing the back-pressure on both sides.

So I’ve really been kicking this idea around for sometime.

I know this maybe not the ideal solution for you, but I’m activity working to learn rust so I can make a web assembly app that will scale the images client side and then I will have my client side app directly upload them via signed urls to s3. I think cost alone will make this a much more effective solution long term.

Photon: A WebAssembly Image Processing Library looks promising

Yes I’ve used this before and it performed quite well. If the files are really large, you may need to scale them down and then apply the transforms to the resized image if it is taking too long. If you find you need more than one instance, you just set up a load-balancer with multiple EC2’s behind it and auto-scale them. There’s an AMI for Imagizer in the AWS marketplace and you spin up an EC2 instance using it, then just pass query string params for the transforms. I believe Imagizer’s documentation explains all of the setup…been a while since I looked at it last (and I wasn’t involved in the initial set up either).

We actually used it without any middle app to do transforms right from the JS front-end of the app. In that case, the main api app only managed the pre-signed URLs for upload and the access keys for reading and Imagizer did the rest of the hard work.

Cloudfronting what is a common request eliminates much of the load from the main app freeing up the resources for the rest of the business logic. This also means you don’t have to store the same image in multiple sizes…the other sizes are just transforms and just pull from the cache, falling back to a new request only if they’ve expired, which just causes them to be re-cached. It’s pretty efficient.

Cloudfront is both super cheap, and super performant for the end user because it keeps copies geographically close to them, so time to glass is kept to a minimum (way faster than trying to do this on the fly, even with parallel transforms going on).

Technically, you could even use infrequent access instead of standard S3 with the CF caching and save on your storage costs too.

Again, it all depends on your application and performance needs. For our use case, it worked extremely well and was nearly maintenance free. The only time we had to touch the mechanism was when a new version of the AMI came out…otherwise, it just worked. Depending upon your request volumes (and keep in mind that CF helps keep that minimal after initial caching) you could also use their SAS offering and not have to deal with setting up the EC2 instances. With our volumes, EC2 was a cheaper solution, but you will need to evaluate that for yourself.

Hope this was helpful.