Serverless Step Functions: no more leaky abstractions

Yan Cui

I help clients go faster for less using serverless technologies.

This article is brought to you by

Don’t reinvent the patterns. Catalyst gives you consistent APIs for messaging, data, and workflow with key microservice patterns like circuit-breakers and retries for free.

Try the Catalyst beta

I have some exciting news to share with you about the Serverless Step Functions plugin.

One of the main pain points of using the plugin was that you needed to use fully-formed ARNs. We addressed this in v1.18.0 by supporting CloudFormation intrinsic functions Fn:GetAtt and Ref. This makes it possible for you to reference a local function instead.

functions:
  hello-world:
    handler: hello-world.handler

stepFunctions:
  stateMachines:
    myStateMachine:
      definition:
        StartAt: HelloWorld
        States:
          HelloWorld:
            Type: Task
            Resource:
              Fn::GetAtt: [HelloDashworldLambdaFunction, Arn]
            End: true

But this is still a leaky abstraction – you have to know how the Serverless framework converts local function names into CloudFormation logical IDs.

Newcomers would often get confused here.

“How did you get the logical ID HelloDashworldLambdaFunction from hello-world?”

I can hardly blame them for not knowing. This is an implementation detail in the Serverless framework, one that you shouldn’t have to care about!

Which is why I’m really happy to tell you that, as of v2.2.0 you can reference local functions using their local names in the state machine definition.

functions:
  hello-world:
    handler: hello-world.handler

stepFunctions:
  stateMachines:
    myStateMachine:
      definition:
        StartAt: firstTask
        States:
          firstTask:
            Type: Task
            Resource:
              Fn::GetAtt: [hello-world, Arn]
            Next: secondTask
          secondTask:
            Type: Task
            Resource: arn:aws:states:::lambda:invoke
            Parameters:
              FunctionName:
                # you can use Ref to get the function name
                Ref: hello-world
              Payload:
                answer: 42
            Next: thirdTask
          thirdTask:
            Type: Task
            Resource: arn:aws:states:::lambda:invoke.waitForTaskToken
            Parameters:
              FunctionName:
                # you can also use Fn::GetAtt to get the ARN
                Fn::GetAtt: [hello-world, Arn]
              Payload:
                token.$: $$.Task.Token
            End: true

In the above example, when we reference the local function hello-world we no longer need to use its CloudFormation logical ID HelloDashworldLambdaFunction.

As you can see from the example, it applies when you use either Ref or Fn::GetAtt functions in a Task state. And it applies to all 3 ways of invoking a Lambda function from a Task state.

Whenever you’re ready, here are 3 ways I can help you:

  1. Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop for quickly levelling up your serverless skills.
  2. I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
  3. Join my community on Discord, ask questions, and join the discussion on all things AWS and Serverless.