https://serverless-stack.com/ logo
#help
Title
# help
d

Dan Van Brunt

01/06/2022, 9:39 PM
@Frank Can I open this back up for discussion? https://serverless-stack.slack.com/archives/C01JG3B20RY/p1638399778443400?thread_ts=1638399496.442900&cid=C01JG3B20RY I’m now blocked by my own usage of
resolve
inside one of my own custom constructs. *MY CONSTRUCT (extends StaticSite)* inside, I am trying to add more origins and an origin group OUTSIDE MY CONSTRUCT (where I’m using the construct) outside, I’m trying to
addBehavior
but since its already resolved it does not get added.
Here is what I’m doing inside my construct to add an origin….
There must be a more extensible way to do this without using resolve?
I think I need to put this code AFTER the
super
in my construct, since I need the
this.deployId
in order to create the origin
otherwise I could just pass all the origin config into
sst.StaticSite
I imagine
I have another use case for this need, beyond just adding a custom header. We also need to modify the existing s3origin… to point to an origin group when we setup cross region replica buckets….
perhaps there is a feature that can be added to
sst.StaticSite
for being able to affect origins/origin-group
Trying to think of even what I PR might look like to add this feature to sst.StaticSite … Again, I need the
this.deployId
in order to setup the origins properly. I may just have to for Static site? 🤷‍♂️ So that ours handles cross-site replica buckets and custom headers for deployId
hmmm… forking seems messy too since sst’s
BaseSite
and,
Construct
are not exported. ☹️
Any chance you can export those? @thdxr @Frank
f

Frank

01/06/2022, 10:20 PM
@Dan Van Brunt Yeah I think I understand what you are looking for. My local environment is a mess now (in the middle of upgrading to CDK v2). I will take a look at this after the upgrade. I think exposing the origin is definitely possible.
d

Dan Van Brunt

01/06/2022, 10:22 PM
Great! GL with the upgrade. Any reason to keep Basesite and Construct unexported as well?
f

Frank

01/07/2022, 7:39 AM
Thought about this more.. I think exposing the origin probably won’t work, you will still get an unresolved value.
But I have 2 solutions in mind. Let me talk to @thdxr tmr and share some more details.
d

Dan Van Brunt

01/07/2022, 2:17 PM
Ya I was thinking the same. I didn’t know about any method to “update” existing origins on a CDK distro construct.
@Frank @thdxr Likely you already know about this…. but it looks like CDK added support for s3 origin custom headers… https://github.com/aws/aws-cdk/pull/16161/files As far as the other desire to add ablitly for us to add cross-region buckets. …. Would you be open to a PR and for me to add our CustomResource that does this inside
sst.StaticSite
?
then users of StaticSite would be able to ….
Copy code
new StaticSite(this, "Site", {
  path: "path/to/src",
  replicaRegions: ['us-west-1', 'af-south-1', 'ap-south-1] 
});
@thdxr @Frank Is this something worth me working on officially? Otherwise we’ll have to fork. Need to solve this for our sites.
@Frank Any thoughts yet on this ☝️
f

Frank

01/24/2022, 10:38 PM
Hey @Dan Van Brunt sorry to get back to this late. We had a change to talk about it and we will likely add out of the box support for replica regions when more ppl ask for this.
For for now, let me implement a callback where you can customize the default behavior and origin before they are created.
That should allow you to add s3 origin custom headers and create origin group.
d

Dan Van Brunt

01/24/2022, 10:39 PM
while still using the sst.StaticSite’s bucket that it creates for you?
which is one of the origins in question
sounds a bit like a circular situation maybe?
f

Frank

01/24/2022, 10:42 PM
something like:
Copy code
new StaticSite(this, "Site", {
  path: "path/to/src",
  callback: {
    beforeCloudFrontDistributionCreated: ({ props: cloudfront.DistributionProps, deployId, s3Bucket }) => {
      // make changes to props

      // return the updated props used to create the distribution
    },
  },
});
d

Dan Van Brunt

01/24/2022, 10:55 PM
honestly I think I’d have to just try it… not 100% clear how this will work. StaticSite internally creates a bucket and I need that bucket inside that callback. Is that what your code is showcasing it could do? I think that is what you are saying that you would give out the DistributionProps, deployId and s3bucket ?
I think that would work then.
Surprised not more people asking for it. We already got burnt once last time s3 had hiccups only on us-east-1 which netted out to our site cashing 404 for all routes. Cross-Region buckets would have seen us threw that with no issues. https://serverless-stack.slack.com/archives/C01JG3B20RY/p1643063910079400?thread_ts=1641505143.041700&cid=C01JG3B20RY