Continuing examination of Grav and its feasibility for a small university website, we are trying to find ways to deploy Grav in a format that is compatible with AWS autoscalers to maintain best performance and high availability. Right now, this is as simple as storing the site as a git repo and using Chef to pull from the repo every fifteen minutes to keep the site updated on all nodes.
One issue we are trying to figure out is hosting the media. We want to keep images out of the git repo. One potential solution involved using AWS Elastic File System and mounting an images directory automatically when a node is provisioned. This option allows us to continue utilizing Grav’s image caching as well as AWS Cloudfront as a CDN. From our understanding, this would pull unaltered images directly from the EFS mount and altered images from the image cache, and CloudFront would be able to cache them both. This would sacrifice some performance for uncached requests, but would allow us to keep a DRY image architecture without the repo ballooning in size.
The problem is that there’ s no easy way to directly upload to EFS in a manner that we can pass off to our student interns. There isn’t a browser-based way to upload like there is with S3. We considered using S3 and modifying Grav to route image requests directly to the public S3 endpoint, but I believe that would bypass Grav’s image cache and prohibit us from changing the images with commands like ?cropResize=300,300.
So, we have two questions:
- Would routing all media requests to an external S3 endpoint bypass Grav image caching?
- Would routing all media requests to an external S3 endpoint prohibit the use of operations like
?cropResize?