Does anyone have examples of storing `env` variabl...
# help
c
Does anyone have examples of storing
env
variables in SSM? How are these initially loaded? Do you put all SSM params in one stack or is this integrated into your other stacks? Do you load them from env var file and then set them or set them in the UI?
t
For values known at synth time (eg a dynamodb table name) I just create the parameter in my stacks code
I scatter them through my stacks depending on what they're related to
For secrets I create + set them in the UI
fwiw we're planning on making this a first class concept in SST so this is all simplified
c
Ok so you create a source component and then set ssm straight after. Then if it needs to be consumed in another stack, you query ssm and pass the results to the consumer component?
t
I load the SSM values inside the function
I'll send you some examples later for how I do things
I wrote my own little framework but a better version of it should be integrated into sst directly
c
Awesome, thank you @thdxr!
c
I'd love to see it. at my cur job they built a cool framework where they create the releases and put the values to the lambda during the CI process, but with SST I don't know if it'd be a good practice
a
I've also been looking for examples of this as stack exports/inputs via Cloudformation is getting unwieldy/brittle for us in certain cases
t
There's a
Parameter
concept, you can create parameters that have values like a dynamodb table name or secrets
then you can "use" them in functions - which basically grants the function permission to read it. Inside the function you can use
import { Config } from "@serverless-stack/node/config"
and Config will have it autoloaded
There's also some codegen in there for getting proper typing
This is really rough - if it was more usable it would be in SST core already. But it demonstrates my approach
What's nice about this i sin my unit tests I can run them with SSM_VALUES=* and it'll just load them all so my tests will just have access to everything they need
a
Thanks for sharing this, @thdxr!