What would you guys think of an entirely functional api to create stacks:

export async function TableStack(props) {
  const table = new sst.Table(props.stack, ...);

  return { table };
}

export async function StackB(props) {
  const { table } = use(TableStack);
  new sst.Function(props.stack, { environment:  { MYTABLE: table } })
}

It would be totally typesafe + support async functions

this probably comes down to personal preference/coding style, yeah? I know some people are big fans of functional programming. I’m more in the OOP camp.. classes just feel more natural to me

A little bit of style but it's also nice to return exports simply with type inference. The above is pretty verbose in sst today because you have to be explicit about all the types. Functional approach infers everything, zero types you have to write

class TableStack extends sst.Stack {
  public readonly table: sst.Table
  constructor(...) { 
    super(..)
    this.table = new sst.Table(...)
  }
}

class StackB extends sst.Stack {
  constructor(app, props: { table: sst.Table }) {
    super(...)
  
  }
}

const tableStack = new TableStack(app)
new StackB(app, { table: tableStack.table })

I mean, if it adds more functionality to SST, then I’m all for it 🙂

we'd probably add this as an experimental syntax

This would be amazing

This is not a game changer for me. However, I would probably switch. Since I no longer use classes on the frontend and consistency is good for my brain.

Nice

So async in that

TableStack

gets deployed before

StackB

begins to synth? If not that, then what? CDK is synchronous by design.

No they all get synthed first and then deployed. Because CDK is constructor based you can't have async functions, but this is an arbitrary constraint. It's annoying for us in a few places since we can't call esbuild.build() since it returns a promise and I imagine others have other issues like that as well

I got around that with

execSync

, though if somebody said that's a hack, I wouldn't really disagree. I'd just be wary of anything that might make it non-deterministic. Having the whole thing be synchronous was a design goal of the CDK.

@thdxr would be into this for sure as I tend to work this way in general. Having async stack construction would be nicer then needing to do all async in index and passing values around.

I'm a fan of classes, even if not OOP it helps organize related functions. The fact that stacks (and constructs) have to do all their work in the constructor makes them essentially just functions though, so I like this simplification.

@Matt Morgan yeah I don't really know why you'd need async work I just have that one esbuild example where we have to wrap it in execSync. So it's a secondary concern, my primary thing is to make it less verbose for passing things around and get proper typing through inference instead of writing it out

async has been needed for SSM for me.

Yeah true storing everything in SSM means you don't need to put stuff in your CI environment which is great

yeah, thats the route we are going here, we went with SSM injected into the CF instead of calling it at runtime

No you can't

@Ross Gerbasi what kinds of things are you injecting into the stack from SSM?

Figured, but i am still not sure how it works in

index.ts

How is it that you can have callbacks and promises in your default index handler?? how does it know to wait haha i am very curious

The limitation is coming from JS technically. Constructors in JS have to be synchronous, it's not an overall limitation in CDK. So we just spawn a normal node process to execute

main

and wait for all async work to finish before exiting

interesting. I’ve been fetching those in the Lambda code at runtime. I figured if I injected them into the stack, changing keys would require a redeploy

hm ross I don't think that pattern is actually good because your secrets leak in a few places

e understand that

@Sam Hulick you are doing it the best way I believe

We're working on making secret management first class in SST so you can just define them and they'll be auto injected into your function (with typing!) and letting you manage them in console

however calling them at runtime adds another delay to the pipeline. Everytime we wanna use that key we need to lookup from SSM first

I wrote a

getSsmParameter

function that also memoizes the values it fetches. just cache it so it’s there for any warm starts

we would rather secure our CI and be cautious with our CF security VS have every customer pay extra per request

the delay is microscopic

yeah caching for warm start is an always regardlkess

I do wish AWS would make a managed way to do this

I agree, Another option is to use cloud formations dynamic SMM references.

Might help my use case? I have an sst.Script (custom resource) just to upload resulting files with endpoints and OpenAPI for clients to access. Would be nice if each API stack could directly upload these files.

@thdxr I wonder if SST could help with this. injecting

{{resolve}}

into ENVS so we are never passing alot plaintext secrets

That's sort of what the solution we're working on does.

That would likely be ideal, no runtime cost + secure secrets all the way down.

those are readable in a lot of places

I am not sure I am as worried about ENV variables though. They are encrypted at rest anyway

Yeah I'm not opinionated on this, depending on your setup you might choose to be more practical. We can probably make your setup more built in

That would be great 🙂 Obviously my workflow doesnt work for folks that are rotating keys. There is likely a mix here folks could use. some "static" keys and some dynamic ones.

that’d be great - specially because I’ve been ignoring linter errors when creating stacks with classes that wouldn’t happen if we had this funcional approach

Just ran across this @Ross Gerbasi Useful?

@Adam Fanello very interesting, i will try this out. Might be a bit rough with JSON in a secret, but i guess we could just parse it in the Fn.... gonna try this for sure. thanks!