https://serverless-stack.com/ logo
Join Slack
Powered by
Hi folks, SST beginner here! I’m working on a stac...
# help
n
Hi folks, SST beginner here! I’m working on a stack with 2 cron jobs in it, one for an api keep-warm lambda and the other for a timing test lambda. I’d like these to run in dev, but not in local. I can handle this in the lambdas by checking for 
process.env.IS_LOCAL
and returning to abort the lambdas, but it’d be even nicer to have the crons not run at all. Is there a way to add a rule to the cron job definition not to run if 
process.env.IS_LOCAL
is set?
a
you could check 
app.stage
in index.js and if it has a certain value, not deploy the cron stacks at all
or in the respective stack wrap the 
new Cron
in such an 
api.stage
check
or I guess instead of that check you could also stick with your local check
the trick is that your infrastructure setup is now programmable, so you can do it there already
r
We do it like this:
Copy code
new sst.Cron(this, 'some-id', {
      job: someFunc,
      schedule: process.env.CRON_SCHEDULE,
      cdk: {
        rule: {
          enabled: !scope.local, // Need to run via SST console if running locally
        },
      },
    });
a
ah, that's even cleaner, nice
would this be 
app.local
in the new functional constructs?
r
yeah, so it’d be
Copy code
ctx.app.local
Where ctx is the StackContext
a
I like this way, because you don't have to do empty checks in places that are trying to work with the cron
n
Cheers for the replies Adrian, Ross! Ross’ solution looks ideal here. We’ve got a few devs who spin up local versions of the stack using own names as temporary stage names for development. so keeping it generic with the check for IS_LOCAL or app.local might be best for us. Looks like that 
cdk.rule.enabled
might be the piece I’m missing. Thanks so much! 🙂
r
No worries 😄
a
my way creates less cruft in cloud formation template, though 🙂
but I think I'm also switching to Ross' way, because it makes the rest of the stack code cleaner
t
btw lambda warmers actually don't do much
they only keep 1 instance of your function alive so if you have 2 requests that overlap the 2nd one will experience a cold start
best to focus on keeping bundle sizes low to keep coldstarts fast
a
aren't lambda functions mostly there to please ignorant customers with a "fast load time"?
and for that, they mostly work
t
yeah I'm saying you'll still have people that experience slow load times because there's no way for your warmer to keep multiple lambda instances warm
a
sure
t
you should use provisioned concurrency if you want to keep a pool always up
Provisioned concurrency – Provisioned concurrency initializes a requested number of execution environments so that they are prepared to respond immediately to your function's invocations. Note that configuring provisioned concurrency incurs charges to your AWS account.
a
I guess people who use lambda warmers aren't keen on that last sentence 🙂
my remarks were relating to a customer we once had who manually timed the load times of their website at different times of the day and then complained to us when it was not as expected
aggressive local caching can also help to avoid having to hit a lambda at all
t
ah customer as in if you're building something for someone else, gotcha
I do wish coldstarts were faster. I'm excited for 
bun
which is a new js runtime that is way way better at starting up
hopefully that'll become well integrated with everything
a
interesting, never heard of it
t
also jealous of the cloudflare worker model which has basically 0 cold start
f
@Neil Hynes @Adrian Schweizer @Ross Coundon in 
v1.2.0
, we lifted 
enabled
out of 
.cdk
for convenience, you can do this now:
Copy code
new sst.Cron(this, 'cron', {
  job,
  schedule,
  enabled: app.local,
});
3 Views
Open in Slack
PreviousNext
Powered by