https://serverless-stack.com/ logo
Join Slack
Powered by
<@U01JVDKASAC> Can I open this back up for discuss...
# help
d
@Frank Can I open this back up for discussion? https://serverless-stack.slack.com/archives/C01JG3B20RY/p1638399778443400?thread_ts=1638399496.442900&amp;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
@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
Great! GL with the upgrade. Any reason to keep Basesite and Construct unexported as well?
f
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
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
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
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
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
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&amp;cid=C01JG3B20RY
Open in Slack
PreviousNext
Powered by