Hey, should I be using `cdk.Fn.import_value` for s...
# sst
b
Hey, should I be using
cdk.Fn.import_value
for sharing values across sst projects? for context, I have a SNS Topic setup in project “EventsCore”, and I want “ReaderApi” to subscribe.
this.addOutputs(..)
from EventsCore and import value in ReaderAPI? Or any cleverness/best-practices I could be considering?
I’m actually not a huge fan of using outputs, as it tends to hard-couple to stacks, which over time makes it really annoying to manage/iterate when EVERYONE depends on your stacks output.
(although I do remember reading somewhere that listed the various ways of sharing data between stacks, apps, projects etc - or maybe I am remembering wrong)
a
What I do is define
readonly
attributes on the stacks.
And then read them from other stack parameters.
b
hrrm.. these are different repos
ideally different teams
a
Oooh.
In that case not much can be done more than outputs.
I think.
b
well, you can stash in ssm, secretsmanager, and I’ve even had terraform write a json file to a s3 bucket.
a
Yeah I’m using SSM for that too.
To store info about the sql connection for example.
And reading them from other stacks.
Due sql is created on other repo.
So you can use ssm or cf-outputs.
b
you should actually use secretsmanager for db configurations - integrates into RDS very nicely.
a
Yeah, currently using SSM Secure.
b
so you can auto-cycle passwords and credentials at app and db at “same” time (depending how you’re passing the connection string into your lambdas)
a
But going to move to SM soon.
b
ssm is secure
a
Yeah!
b
I really do enjoy SM tbh
a
Yeah it’s in my roadmap, haha.
b
using it even for less secure things, it’s just really nice to have a whole json blob in there
a
You have the connection string into SM?
Like.. password, host, user, port?
b
my advice, don’t bake SM into environments - I highly reccomend https://docs.serverless-stack.com/environment-variables#3-use-the-aws-ssm-construct
a
Or just passqord?
I’m pulling credentials in runtime.
b
yeah, all of the connection details, RDS will actually produce this for you via cloudformation (or CDK in our case)
a
Is what worked best of my requirements.
b
having to re-deploy your lambdas to get updated environment vars.. can really suck.
a
Yeah, but you have to put stuff into SM once RDS is created?
Yeah that sucks.
But well, could be that the lambda is warm, and the password changes.
b
yeah no, the SM can talk to RDS directly
a
Nothing is ideal.
I’m using Middy for SSM and SM.
Do you?
b
technically, as far as cloudformation goes 1. you create secret 2. tell SM to generate a complex password 3. create RDS using that secret 4. RDS reads from secret 5. applications read from secret
I.. actually tried to get my team to use middy
a
Interesting.
b
but they opted to write their own, it was some deal with how middy is typed
so we have.. a lot of home brewed middleware (I’m not a big fan)
it’s basically the same tho
a
Yeah middy is not perfect but solved my ssm/sm implementation quick.
Yeah.
I think is somehow cleaner.
I’m putting stuff in the middy-context.
And then the lambda is really simple.
I mean, the function.
The actual final lambda it’s a bunch of middlewares.
b
yeah
a
But the implemented lambda it’s simple, and then I can re-use all the middlewares from a
common
package.
b
I worked with express for years, so I’m a big fan of middleware pattern
a
Oh yeah I see.
b
not to mention, I am more of a functional developer - so it’s nice to keep it encapsulated
a
Yeah.
I’m more like a OOP dev, but well.
b
lol, good luck with that
⚔️
lol
a
Hahahaha.
b
I really like seeing all of the logic I need to in one place
but s’bigger conversation
a
Yeah, well I’m more used to oop frameworks, and I’m using a DI framework with lambda too.
So can’t go away from OOP 😂
I love it, coming from java, then TS is my favorite.
b
hey, it’s all just ones and zeros in the end
computers don’t care how we structure our code
a
Hahahaha true.
b
“Programs should be written for people to read, and only incidentally for machines to execute.”
a
Agreed!
b
it’s from — Structure and Interpretation of Computer Programs by Abelson and Sussman
(a dense but interesting read I’ve been sharing around the office)