https://serverless-stack.com/ logo
Join Slack
Powered by
Would it be feasible and reasonable to generalize ...
# help
j
Would it be feasible and reasonable to generalize the StaticSite handling of env vars, so they could be accessed in any kind of local script (not just site)? Let's say I would like to have a devel script that creates few test users in cognito pool. It needs to know the pool id, so I would run the script with 
sst-evn
Or is it already possible?
t
yes this is something we've needed
but right now you can't, you'd have to specify the outputs file flag and parse the json yourself
j
specify the outputs file flag
what does it mean
like I would create "fake" StaticSite resource?
I am probably missing something, I am not sure where I should look for this flag
t
sorry I was forgetting the cli flag: https://docs.serverless-stack.com/packages/cli#options
j
ah thank you
t
that said for your specific use case, this is why I tend to load everything in SSM, that way there's no env vars to pass around to all the contexts you need them in
j
I am no sure I follow. Do you mean the script would read the pool id from parameter store? Sorry I am quite new to these things ...
Or perhaps I can reference it by a (resource) name?
t
yeah it's a bit tricky and we really need to provide a native way in SST to make this easier, have a prototype but haven't shipped it. Basically yeah, in your cdk code you'd save stuff like USER_POOL_ID to SSM under a path like 
/app/stage/USER_POOL_ID
Then your script can just fetch those when it starts. I typically have a Config domain that manages all those both for my lambdas and my scripts
j
and you set the ID to SSM inside Stack definition?
after resource creation...?
t
yep exactly
your approach of using outputs is fine and can go through the outputs file like I mentioned but I've personally found putting everything in SSM to be useful
My tests use it as well
Copy code
import { StringParameter } from "aws-cdk-lib/aws-ssm"
      new StringParameter(this, name, {
        parameterName: `/${app.name}/${app.stage}/${name}`,
        stringValue: value,
      })
j
Make sense, thank you.
Wonder, isn't there some SDK api to lookup resource by name?
cos it seems the parameter would represent basically the same thing...
t
well not all resources have simple names, it's usually generated
so you shouldn't hardcode those names anywhere, esp if you have multiple stages
j
well the stage is part of the name as well, same as with param...
dunno about the generated ones... shouldn't I be able to provide them "reasonable" name? I still have to retrieve them, give them the alias and store the alias to SSM...
t
SSM you can load wildcards so you can do /app/stage/* and load everything into a config object
j
oh, ok didn't know that
or I quess the script could be a lambda function and I could just 
aws lambda invoke
f
Just to chime in, currently 
sst-env
only works with the 
StaticSite
construct b/c 
StaticSite
has the 
environment
concept, ie.
Copy code
new StaticSite(this, "site", {
  environment: {
    POOL_ID: ...
  },
});
And 
sst-env
basically sets the 
POOL_ID
environment variable. @Jan Plaček how did you imagine 
sst-env
work when using it to run a script, ie.
Copy code
sst-env -- my-node-script.js
are you looking to reference stack outputs in ur script? ie. 
process.env["auth.user_pool_id"]
where 
auth
is the name of the stack, and 
user_pool_id
is an output in the 
auth
stack?
t
script being a lambda function and invoking from console is a great pattern 👍🏽
j
@Frank I don't have an exact picture, but I would imagine it would basically work the same way, eg 
this.addEnvironmentOutputs(id, { API_URL }
and it would add new entry to `static-site-environment-output-values.jso`;
speaking of which ... i am not actually sure if I use it correctly, I set the 
path
to where I run the "web-start" command, which is at root (
''
), due to 
nx
project structure, not in the actual angular app project directory
so if I will have 3 different sites they will all have 
path: ''
... is that OK?
f
r u referring to the 
path
props for 
StaticSite
or 
--path
for 
sst-env
command?
j
path props for StaticSite
f
do u also run the build command for the angular app from the root?
j
yes
f
I haven’t tried this setup. 
path: ''
sounds right
is the build command different for the 3 different sites?
j
My worry is, that 
sst-env
identifies the env vars by matching CWD with 
path
in -values.json
but CWD will be the same for all sites
since I run it from root
f
hmm yeah.. i think we can make 
sst-env
take a 
--name
option to point to a specific StaticSite
j
and at that point it doesn't matter if "name" is SiteName or whatever arbitrary identifier
f
by arbitrary identifier, u mean 
id
in this context?
Copy code
this.addEnvironmentOutputs(id, { API_URL });
j
yes
btw that json already have an 
id
prop, dunno if its actually used for anything atm
f
I see. let me take a look.
Btw, is this a blocker for you? (just trying to prioritize this)
j
Atm we have only one site, dunno if or when we plan to add others (can let you know tomorrow). So no it's not a blocker. Actually I didn't even realize there could be such problem till this discussion.
Could be cool if 
sst-env
would eventually get the envs from SSM using the approach mentioned by @thdxr
f
Yeah i just drew down some of the things we mentioned here as a reference https://github.com/serverless-stack/serverless-stack/issues/1495
We definitely want to bake SSM into SST, going to give it some more thoughts.
Atm we have only one site, dunno if or when we plan to add others (can let you know tomorrow). So no it’s not a blocker. Actually I didn’t even realize there could be such problem till this discussion.
Let me know when this becomes a blocker. Putting in the id check should be super quick.
j
ok, much appreciated
Open in Slack
PreviousNext
Powered by