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). 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. There are a few SAS offerings out there that do something similar ( is another one). Imagizer lets you use either their SAS platform, or run it on your own EC2 instances. If the resize/transformation requests vary, then the above won’t help you much, but there are addons in AWS, such as Imagizer, which are tailor-made for this (why reinvent the wheel). This might alleviate the need for any throttling/backpressure in your Elixir app. The fallback URL for Cloudfront would hit your Elixir app to do the initial resize or transformation and the result would then be cached for subsequent requests. The advantages are much less load on your api (only needs called when the asset doesn’t exist) and you reduce your S3 egress costs because Cloudfront will cache it for a year (or whatever lifetime you set). Are the transformations constantly changing, or will the Ruby app be requesting relatively consistent sizes and transformations? If they don’t change much, consider putting Cloudfront in front of the requests to cache the assets after the first request with the specific size/transformation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |