v1 upgrade: • Is the lack of support for

events.CronOptions

intentional for

sst.Cron.schedule

? Seems like a huge loss for the only composable way to create a schedule to be gone.

I believe you can find it under the cdk field

Just shared some thoughts here https://serverless-stack.slack.com/archives/C01JVDJQU2C/p1651710403186499?thread_ts=1651619130.512549&cid=C01JVDJQU2C

Works for me, thanks fellers. Just as a note, I am a few hours in on one repo’s migration, and I am finding I am using the

cdk

prop about 75% more than before. Not sure if that was the intent, but figured you guys were looking for feedback.

hmm.. that’s not ideal. The intention was that for ppl without prior CDK knowledge, they didn’t can just learn SST, and progressively dive into the

cdk

prop as they need to customize the underlying resources.

well, that is perhaps what you are shooting for then. I know the underlying CDK resources about as well as SST, and with the changed/more limited SST props, I am partially going with what I know.

can you share an example?

Its a rather large monorepo, and after a few hours I have all of the authorizer changes figured out, which were quite extensive, especially since we use an actual CDK authorizer (which used to work as a prop). Cron was another major stickler, we have about 40 of em in this repo and there are a lot of changes needed to each. The rest seems relatively painless so far.

(cc @thdxr on API generics)

for that example can you return api without specifying the generic? It should infer the right value

it sorta does, so long as I dont need to use it anywhere else in the class:

Ah that's one of the reasons I went with functional stacks, you don't need to define the types as they can be inferred through. You technically can do that here with some tricks though

private readonly api: ReturnType<MyStack["createApi"]>

I could also do some kind of

typeof

on a the method, but I prefer to be explicit, that way if it changes, it throws

yeah that doc looks off

i think I see how…

btw the delineation of what's in cdk vs what's not is where our current line is but not absolute. If there's particularly common things that people find useful to be lifted out we'll definitely do that

thats the new implementation I can get to work

curious why you don't skip the entire resource if local - is it because you still invoke it manually?

correct.

I think with 1.0 the line is more explicit so we’re hoping people give us arguments for what should be moved up

Yeah, I believe Derek’s code is getting lengthier only momentarily, and over time it should look more compact as we lift things out of

cdk

just to be clear, I have no issue with the stuff I am bringing up, I just know we are a fairly unique (and extensive) use case for you guys, and letting you know the effects. I think my only real interface that really threw me is the labeling, and then using, of the magic string authorizer name on

Api

. I’m assuming this is about supporting more than one authorizer per type, so I kind of understand, but it is causing me much grief.

ah got it

deploying 10 apps now, all types are passing

Nice thread!