Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for creating the entire infrastructure with Terraform. This is great for a number of reasons:
s3-resizer
easier. (i.e: reduce issues like Cyclic redirect with CloudFront #5 - if everyone has the same infra, everyone can "talk in the same language")Take a look at the new
README.md
to see how everything works.While developing this, I made two changes to how the whole flow works. These changes might warrant a new major version.
Instead of having one bucket, now there are two buckets: the source and the destionation. The source bucket may be private, while the destination bucket must be public (through CloudFront, the public can not access it direcly).
I made this change to make it easy for people to integrate
s3-resizer
with existing infrastructure. Otherwise, the current buckets would have to be imported into the terraform state, which is a bit more complicated.Furthermore, I think that this change is a nice security improvement: you can have the original, large files private, and only the resized files accessible to the public. This, in combination with the whitelist, can effectively protect the full-size files.
The current guide reccommends to host the lambda from a custom route in a custom stage in an API Gateway, but I found using the
$default
route and stage to be more simple, because it removes the need for the?path=
shenanigans. The cloudfront route is mapeed 1:1 to the lambda route.In consequence, I had to make some modifications to the
index.js
because now thepath
variable contains the leading slash.For the time being, I'll be hosting a custom instance so you can test how it works:
https://d37qm260myncmt.cloudfront.net/500xAUTO/blade-runner-2049.jpg
Thanks for reading! If you have any questions I'll be happy to help :)