https://serverless-stack.com/ logo
Join Slack
Powered by
just wanna bounce something off other devs (workin...
# help
s
just wanna bounce something off other devs (working solo on this stuff sucks, I miss water cooler days) 😄 say you have one SST project with a bunch of stacks. I’m thinking, does it make zero sense for Lambda functions to invoke other Lambda functions in the same or other stacks using 
lambda.invokeFunction
? seems like it’s a better idea to just 
import
the function and call it directly. I can’t think of any reasons off the top of my head why this is a bad idea.. 🤔 or why it’s more advantageous to use 
lambda.invokeFunction
one exception I can think of is, is if a long-running Lambda needs to be executed.. then it might make sense for one function to call another with 
InvocationType: 'Event'
to run it asynchronously.
t
I've been thinking about this as well. I think calling the function directly is probably a good place to start. That's how I'm doing it. I can see situations where people want to define boundaries more discretely across domain (especially limiting permissions) where they'd have lambdas invoking other lambdas. A lot of those situations are actually better modeled as step functions.
I'm still writing my code as "domains" that are functions that can be imported and called. My lambda functions don't really contain any business logic themselves meaning the domain functions are very portable. This might be a habit from non-serverless world but it's working well for me especially since domain functions can might be needed in tests or cli scripts
s
yeah.. hmm. I think it just depends. there are definitely things to avoid, like Lambda A calling Lambda B (long-running func), and then they’re both running for 5 mins. in those cases, it def makes sense to import the pure func & run it with 
await
. or have Lambda A invoke Lambda B with 
InvocationType: 'Event'
no, that’s a good habit to have for sure. one I need to get into. ideally the main biz logic should be separated from the handler so it can be easily unit tested.
they’re all tightly coupled w/ the handlers for now, mostly cuz I have no tests for those Lambda funcs. but I can refactor later.
Copy code
case 'videos':
      await lambda.send(
        new InvokeCommand({
          InvocationType: 'Event',
          FunctionName: process.env.TRANSCODE_VIDEO_LAMBDA,
          Payload: Buffer.from(
            JSON.stringify({
              userId,
              id,
              fileId,
              bucket,
              key,
              duration,
            })
          ),
        })
      );
this is a good example. this is within my 
uploadProcessor
Lambda which is executed directly from the front end after a file is uploaded to S3. the Lambda call here probably makes sense, because that video transcode process could take a couple minutes to analyze larger videos. I wouldn’t wanna tie up the front end waiting for that
f
I’d like to think about this from the angle of how easy it is for u to debug if something is wrong, ie. X-ray can tell u if A failed or both A and B failed, and if u r very comfortable with using X-ray, splitting it up would make it easier to debug.
Really up to what toolings you are using.
t
This is where people use EventBridge to decouple functions. The first lambda could emit an event stating that a video has been uploaded. The second function can listen for those events and do the processing and then emit another event when it's done
s
a good Sentry config can help w/ this too. I probably wouldn’t use X-Ray in production, as I’ve seen it add latency
t
Also can be done using step functions
s
@thdxr that’s a great idea (EventBridge). I wrote all of this code before it existed
ooh, 
sst.EventBus
is a thing
4 Views
Open in Slack
PreviousNext
Powered by