https://twill.io logo
Powered by
# ❓questions
  • i
    however, as you identified, even if already computed, pulling from S3 is slow
  • f
    Thanks @User - that's a good shout with regard to checking with curl - I'll give that a try. Regarding using a cdn like coudfront, I saw in another reply you talked about needing to set up another ImageService. Is that right? Is there any chance you'd be able to spell out the steps I'd need to take to get that integrated (broad brush strokes is fine - I can research to fill in the gaps
  • i
    that's right if you only want to serve images through cloudfront, since you will need urls to be different than the ones that are generated. it can be a simple as doing a string replacement when outputting image urls rather than writing a custom ImageService though.
  • i
    but if you can, I'd recommend serving the whole site through Cloudfront
  • i
    that way you don't have to change anything as far as generated image urls
  • f
    OK, thanks for the advice! I'll be serving this site on Laravel Vapor so I'm not entirely sure how easy or otherwise it would be to use cloudfront like that. Do you have any experience running twill on vapor?
  • i
  • i
    we do have exp. with Twill on Vapor, as well as adding a custom Cloudfront distribution alongside the one Vapor creates for assets
  • i
    we developed https://github.com/area17/edge-flush for granular invalidation on Laravel model changes
  • i
    and their's a Cloudfront cache invalidation service in Twill that you can call when things change in the CMS
  • i
    that way you can have fully static html responses that are invalidated only when they need to, and in milliseconds
  • i
    basically the benefits of modern SSG without the build time drawbacks 😉
  • f
    Sorry @ifox - got pulled into a meeting! This is really handy info - thank you! I'll take a look at that edge flush package for sure. Am I right in saying that the readme for that package details the set up required to get that working on Vapor?
  • f
    (obviously it won't be vapor specific but I guess I'm asking if there are likely to be any gotchas when trying to implement it on Vapor that you might be aware of)
  • i
    I don't think there's anything specific documented for Vapor in the package, but I can get back to you on this, we did have to make a couple tweaks to Twill on top of Vapor
  • f
    Hey @ifox - if you do think of anything that would be great. Thanks very much for the help!
  • i
    @FourStacks
    Copy code
    if (!function_exists('twillAsset')) {
    function twillAsset($file): string
    {
        $asset = app(TwillAssets::class)->asset($file);

        $customAssets = filled(env('ASSET_URL')); // for Vapor

        return $customAssets ? asset($asset) : $asset;
    }
}
  • f
    Thanks @ifox - I think I remember finding this snippet on here before - appreciate the reminder!
  • i
    we also had issues with the default docker runtime on Vapor, https://hub.docker.com/r/luislavena/laravel-vapor is the alternative image we use.
  • f
    OK that's good to know - I did stand up a demo for the client on the current docker vapor build and it generally seemed OK but I'll keep an eye out.
  • f
    I do have more question relating to Cloudfront if you can spare the time. I've set up a distribution and hooked it up to the S3 bucket I'm using. The distribution works if I fire off a URL for a non-cropped (e.g. and image that's not in glide_cache) image e.g.:
  • f
    https://dmy-cdn-name.cloudfront.net/38cds4346f7a-4497-baa1-73f839b432ece/my-image.jpg
  • f
    I can see how I could cook up a blade helper function or something that would take the URL that 
    $article->image('featured_image', 'default')
    spits out and prefixes it with the CDN address per the above. However what has me stumped is how I can get a reference to the crops in the glide_cache instead?
  • i
    that's because in that case you'd need the urls to point to generated files in the glide cache instead of using query parameters, since the request doesn't go through the Laravel app anymore. the approach is rather to point the distribution to the origin so that requests to /img gets cached by CloudFront. When CloudFront doesn't have it in cache but glide did generate it, subsequent requests from CloudFront to the origin will be faster
  • i
    because you could say then you don't benefit from glide's cache, but you actually do, since with CloudFront each edge might request your origin separetely. So the first edge will generate the file and all other ones will use the cache.
  • f
    Hmm, ok I think I get what you're saying. So my distribution is pointed at my S3 bucket and I've not set up any origin path as part of it's config. It should just be pointing at the root of the bucket. What you're saying is that if I simply ensure that 
    $article->image('featured_image', 'default')
    is prefixed with the CDN url that glide will still continue to do it's thing and that the CDN will reference the crop going forward?
  • i
    hmm, not exactly. Your CloudFront distribution shouldn't point to your S3, it should point to your Laravel app
  • i
    you don't need any url rewritting in this case
  • i
    you can setup the distribution to fully bypass CloudFront for everything else than /img/* if you don't want to configure your app to be cached by cloudfront
  • f
    Ah, ok. So you're saying that this config option in AWS:
1...217218219...484Latest