I have two stacks and as far as I can tell the sec...
# help
o
I have two stacks and as far as I can tell the second stack should wait for the AssetsStack to deploy before it then deploys itself (I need the url for one of the routes in the api). But the value it ends up with is
https://${Token[TOKEN.186]}
which then results in the following error
error Cannot find a handler file for "https://${Token[TOKEN.186]}"
. I'm sure I've missed something obvious but I've now been starring at this problem to long to see it! lib/index.js
Copy code
import MyStack from "./MyStack";
import AssetsStack from "./AssetsStack";

export default function main(app) {
  // Set default runtime for all functions
  app.setDefaultFunctionProps({
    runtime: "nodejs14.x"
  });

  const assets = new AssetsStack(app, "assets-stack");

  new MyStack(app, "my-stack", { asset_url: assets.url });

}
lib/AssetsStack.js
Copy code
import  { Stack, StaticSite } from "@serverless-stack/resources";

export default class AssetsStack extends Stack {
    url
    constructor(scope, id, props) {
        super(scope, id, props);
        
        // Create a Sattic Site
        const assets = new StaticSite(this, "Assets", {
            path: 'src/build/assets/'
        })

        this.url = assets.url

        // Show the endpoint in the output
        this.addOutputs({
            "CloudFrontEndpoint": assets.url 
        });
    }    
}
lib/MyStack.js
Copy code
import { Stack, Api } from "@serverless-stack/resources";

export default class MyStack extends Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    const { asset_url } = props

    // Create a HTTP API
    const api = new Api(this, "Api", {
      routes: {
        "GET /_app": asset_url,
        "$default": "src/lambda.handler",
      },
    });

    // Show the endpoint in the output
    this.addOutputs({
      "ApiEndpoint": api.url
    });
  }
}
t
The way cloudformation works is 100% of your code executes locally and then ships the output to AWS. This means your code has no idea what the values from AWS are when executing, which is why you're seeing a tokenized version
are you trying to proxy
/_app
to the static site? If so you should be defining the route like this I believe
Copy code
"GET /_app": { url: asset_url}
But curious what you're trying to achieve by serving the static site through the api. You lose a lot of the benefits of using StaticSite
o
Yeah that's total what I'm after. A bit more background I'm playing around trying to get svelte-kit to SSR render on lambda...
Also this is the first time playing with SST so I just picked StaticSite as an easy start point... Also I have experience with REST APIs on aws but haven't played with HTTP APIs. Ahh the fun of learning new stuff 😄
Copy code
"GET /_app": { url: asset_url}
This solved it, it now works as I was expecting it! Did I miss this in the SST Api docs?
t
It is a confusing interface haha it's referenced here: https://docs.serverless-stack.com/constructs/Api#configuring-http-proxy-routes
Doesn't svelte SSR need a live node thing running? StaticSite ships static files to s3 and puts a cloudfront distribution in front of it
o
So /_app/ is all of the static files that SvelteKit generates when it is built for production. Everything else then runs through a node "server" which is the default route to a lambda function that maps the APIGW event to the node "server" and then spits back the html... well that's how I think it'll work!
I'm going for a quick hacky POC and then refine from there if I can get the thing to work. SST is doing a nice job of turning the ES Module output from SvelteKit into something lambda will run. I've had it out put the SSR html already so pretty certain that part works ok! Just deploying SST now so I'll report back on the static files side of things 🤣
t
ah gotcha that makes sense. Looks cool! If it works well we should support it directly with a SvelteSite construct
o
Yeah I suspect that would make a lot of people give sst a try
I just wish the cloud formation deployment process was quicker... (am aware that's not an sst thing)
t
You'll hear me complaining about that at least once a week 😄
o
Oh ok so
sst start
clears the s3 bucket after a deploy 🥲
t
I think this is because we don't deploy the real site during sst start - in most sst start situations people are running their frontend locally. So we only really do the deployment during
sst deploy
. I did just make this ticket to disable it https://github.com/serverless-stack/serverless-stack/issues/817
o
That makes sense, no point uploading if you don't need to.
Is it possible to make my own construct?
🎉 Looks like it's worked on the most part!
t
nice!
o
Hurrah so far so good, I'll have a think about what needs to change for a production environment and I can help you put a construct together for it? Thanks for all the help!
t
cool I'll make an issue for it and see where it lands on our roadmap