First off, thanks for the great framework core tea...
# help
First off, thanks for the great framework core team! Anyone know of a way to add
settings to files uploaded by StaticSite? The issue is when those cache control settings are very specific, like with gatsbyjs. I can only seem to get it to work on FIRST upload if I use.. 1. 3x deployments 2. order the deployments with deps 3. prune only on first deploy However, on preceeding deploys, if you change a file name (or delete file) that impacts only say the 2nd deployment package, then you will have the old file as an orphan. Would LOVE some ideas on how to resolve this limitation. Other things I’ve half-baked-considered: • running aws
s3 cp bucket bucket
to retroactively update cache control settings. ◦ many challenges here… ◦ time consuming looping throw assets twice ◦ can’t be built into a Construct (unless rewriting the deploy construct) since it would need to have the target bucket already deployed/created. • using programmatic CDK deploy and using
to upload the assets AFTER CDK deploys. Special Note: It appears that
aws cli's s3 sync
--delete option takes into account the whole directory of files and NOT just the ones the command is filtering on. However, `s3deploy.BucketDeployment`’s prune option ONLY takes into account the filtered files. This is the crux of the issue. That and there seems to be no way to have 1x single deployment that handles multiple sources “and their associated cache control settings”. Anyone with experience with this stuff with some ideas, please share. Cheers!
Hey @Dan Van Brunt! Welcome!
Just read the gatsbyjs doc and the gist you shared. I haven’t grasped the entire picture, but lemme kick start the conversation by asking some dumb questions 🙂
uses CloudFront. With CloudFront, you can have multiple behaviors, and each behavior can have their own cache policy.
Does something like this work:
Copy code
const site = new StaticSite(this, "MyGatsbySite", { ... });

  new origins.S3Origin(site.s3Bucket),
    cachePolicy: new cloudfront.CachePolicy(...),
So additional behaviors points to the same S3 bucket, but have different cache policy.
@Frank! Thanks! If this is as simple as “CF does this so setting cache-control to bucket is not needed” then I will 😭 We indeed have our site buckets always behind a CF distro. We’ve always been setting the cache-control meta on the objects via S3 though. However, upon reading about AWS::CloudFront::CachePolicy it appears this is a very different function than s3's
settings. Let me try and explain what I think the difference is: CachePolicy: affects how the SERVER/DISTRO deals with caching S3 cache-control: How the BROWSER caches the files. No?
It is highly recommended to set cache-control on all files. This can significantly reduce the assets needing to even be downloaded from the server/distro. For any files that could be long-cached in the browser, its not at all impacted on whether they are cached at the distro or not.
Right right! Of course!
And does configuring Lambda@Edge to modify the response headers help in this case?
I could be wrong of course. But I’m surely at the end of my rope on trying to get this working in CDK
I bet it would (Lambda@Edge) but its specific to the site-type. Eg. Gatsby vs Vue etc.
You mean SST won’t be able to offer an out of the box experience, users have to tweak the Lambda@Edge config based on the site type, right?
Ideally, I was hoping there was just a way to replicate what we now do with
aws s3 sync /local bucket --delete
over on the CDK BucketDeployments
would LOVE for all this complexity to be baked into a single Construct
Can you elaborate what the
s3 sync
command help with?
There’s something here for sure.. we are planning to move away from using the s3-deployment construct due to its potential limitations
So I’m up for an implementation that solves this caching issue.
If you prefer to talk about this over zoom, i’m up for that too. Whatever works better for u.
sure…. I have a Bug on CDK about this…… it fully explains the issue and options around it.
Zoom would be great. But give that bug a read and let me know if it clears anything up at all. It’s related to the same issue
yup yup
Lemme know if it would help to Zoom. I’d love to chat. We’ve been on the lookout for something that makes working with CDK even easier. (in the middle of trying to make the switch from SLS)
@Frank that make any sense? Can you still jump on a zoom?
Yup.. reading ur post over and over again lol.. I think I’ve gotten the gist of it
Lemme send u a zoom link
Opened an issue to track the progress on this
Hey @Dan Van Brunt, just released v0.29.1 with some improvements to `StaticSite`: • You can configure different 
 settings to different files. For example, don’t cache 
 and cache 
*.css *.js
 forever. Example here -
 now does atomic deploys. Each deployment gets deployed to a new folder in S3 bucket. So no orphan files. • You can specify a list of glob patterns, with the search and replace terms for each. Example here -
Let me know if this solves the issues we talked about on Friday.
Sweet! Ya, saw that. Going to take a peak first thing when I get a moment. Thanks for doing that.
@Frank Just interested as a learner; any reason you seem to write your CDK constructs as Typescript and your lambda functions as Python? Specifically this one. Is it something to do with the
? Does that layer work in TS as well? If so, thats amazing. I thought my only options were to use the AWS “SDK” but just inspecting your code it appears that the layer allows for “CLI” usage from within lambda.
Hey @Dan Van Brunt, yeah I took the python lambda from CDK’s code
And modified it to support multiple cache control and variable replacement.
And you are right… I remember reading in their doc that the reason they wrote it in python was to make use of that layer.
but that AWS CLI layer could work in TS as well?! Thats sweet.
Ah I see. Yeah, at some point I do want to rewrite it in TS, and add some unit tests for it.