https://serverless-stack.com/ logo
Join Slack
Powered by
I've been thinking about this `StaticSite` constru...
# seed
r
I've been thinking about this 
StaticSite
construct. It's a great and welcome additional, but it seems like there are quite a few adjacent problems that need solving that could be nicely wrapped up in it. (Only solutions I've come up with feel really hacky and are cumbersome) More control over the deployment to the s3 bucket • Setting metadata on files • Not deleting old files, but rather setting an expiry on them to be removed after a period (eg. so users that are running the existing frontend don't suddenly get 404's. Frontend frameworks usually used content hashed file named to handle versioning and caching) Setting environment variables for the frontend • Ideally done at deployment time as to not require a frontend rebuild • Also, would be great to be able to include Cloudformation outputs, which would also need to happen after it's been built • Something generic, like a find/replace with a file glob would be great and flexible. This it could happen in a json file, in compiled code, in index.html, etc. That's about it for my wish list 🙂 Thinking this would require a whole new custom resource right?
f
Thanks @Ryan, yes this requires a new custom resource. And we are working on some of the things on the list already!
One thing I heard conflicting feedback is:
Not deleting old files, but rather setting an expiry on them to be removed after a period
Your point on users getting 404s makes sense. But what about the scenario where I renamed 
about.html
to 
aboutus.html
, and we don’t want users to hit the 
about.html
page. (cc @Dan Van Brunt)
With Netlify, deployments are immutable, meaning every deploy creates a new site. So the old files are not around after a new deploy. @Jay you are familiar with Netlify, can you confirm this?
r
I can see the conflict. It doesn't make sense in all scenarios and it adds extra complexity. Service workers can handle a lot of cases in the frontend so it would only end up providing benefit in some obscure scenarios. It could probably be handled (and might be better handled now I think of it) by blue green deployments.
Ok, can take that off the wish list. It's just often not a problem considered with frontend deployments. They are usually assumed to be consumed as a single asset and when a deployment happens it's assumed people are suddenly on the latest version.. But in reality people have their browser open for hours and can continually stream other resources required for the current version of the app they are on. I think we are 95% of the way there though with at least invalidating the cloudfront cache on index.html, services workers, etc. :)
j
Yeah Netlify does immutable deployments AFAIK. So each git push is a new site.
f
Hey @Ryan, just released v0.29.1 with some improvements to `StaticSite`:
Setting metadata on files
You can configure different 
cacheControl
settings to different files. For example, don’t cache 
*.html
and cache 
*.css *.js
forever. Example here - https://docs.serverless-stack.com/constructs/StaticSite#configure-caching
Not deleting old files, but rather setting an expiry on them to be removed after a period
StaticSite
now does atomic deploys. Each deployment gets deployed to a new folder in S3 bucket.
Setting environment variables for the frontend
You can specify a list of glob patterns, with the search and replace terms for each. Example here - https://docs.serverless-stack.com/constructs/StaticSite#replace-deployed-values
Let me know if there’s anything else you’d like see!
r
🤩🤩🤩😍😍😍😍 Amazing!!! That's unreal. Thanks :) I'll give it a whirl and test it out :)
@Frank I just updated the existing static site and added in 
replaceValues
But I'm getting an error
Copy code
Error: Received response status [FAILED] from custom resource. Message returned: An error occurred (AccessDenied) when calling the ListObjects operation: Access Denied
I tried removing and creating the entire stack again, but still the same Error. I can investigate more a bit later. Entire config is:
Copy code
const frontend = new sst.StaticSite(this, "StaticSite", {
      path: '../../frontend',
      buildCommand: 'npm run build:prod',
      buildOutput: 'dist/',
      customDomain: {
        hostedZone: process.env.HOSTED_ZONE,
        domainName: process.env.DOMAIN
      },
      replaceValues: [
        {
          files: '*.json',
          search: '${API_URL}',
          replace: api.customDomainUrl
        }
      ]
    });
f
hmm.. it seems the custom resource doesn’t have the s3:ListObjects permission
Let me take a look.
@Ryan fixed this in v0.29.2
r
That did the trick. Thank you!
Is there any reason why it builds the frontend on 
sst remove
?
f
hmm lemme take a look. It shouldn’t run the build command on 
sst remove
.
r
Copy code
> npx sst remove frontend
Preparing your SST app
Detected tsconfig.json
Transpiling source
Linting source
Running type checker
Removing dev-project-frontend
Building Lambda function src/lambda.handler

> project@0.0.0 build:prod
> ng build --configuration=production

- Generating browser application bundles...
f
Yup.. I’m able to reproduce it as well. Working on a fix!
It will make into the next release.
r
Great!! Thanks :)
Open in Slack
PreviousNext
Powered by