does the team plan on integrating step functions i...
# sst
k
does the team plan on integrating step functions in any way within SST? such as a SST-based higher-level construct versus importing a raw CDK step function... i'd like to hear what the team has to say on the choreography vs orchestration aspect of micro services. also interested in seeing how the SST library might package together their higher-level constructs with step functions here's an article that i think is excellent. https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/
s
Can't speak on what is on the teams roadmap, but I am using SST with Step Functions. I use the CDK to define the Step Functions, which I find is a pretty good interface. SST has been helpful when using Lambdas in my Step Functions. I simply use the SST Function construct when defining the workflow. I've never tried using other constructs (SQS, Table, etc), but assume they'd work similarly
k
and you're doing something similar to
Api>Lambda>StepFunction
? where the center lambda is "proxying" the event/payload to your step function, using the SDK within the lambda
s
In my case, I'm trigger the Step Function via an Event Bridge rule. Event Bridge->Step Function
k
i think that proxying flow is necessary because there isnt a direct integration between ApiGW/SQS/etc with Step functions... which kinda makes sense based on apiGw/SQS potentially expecting a response back
ok and are directly invoking the Step Function with the EventBridge rule?
rule > target > step function
s
correct
well, the target is the Step Function
To be clear, I'm not directly invoking anything. The Event Bridge rule invokes the Step Function.
k
correct. iTargetable interfaced StepFunction (very similar to lambda)
s
and you could use Step Functions to go between ApiGW and SQS (or any number of AWS services) without Lambda in-between by doing input/output transformations as needed
for me, that part has taken the most time to learn
k
right. and those input/output steps are great places to actually do a lot of "error handling" during the orchestration
keeping the lambda application code really light
the execution-replay-ability of step functions is very very powerful. and you dont get this when you do SQS>lambda directly
i much prefer step function workflows over sqs>lambda>dlq stuff
i could see a step function type of construct more of an application's implementation details, and maybe thats outside the scope of what the SST framework is aiming to solve.
s
Yeah, I agree with those takes. I'm not sure what SST could do to improve the Step Function developer experience outside of the live Lambda development environment.
the Step Function tooling is pretty amazing, especially the workflow editor
f
with
sst.Api
ur code is a lot more concise than u were to write CDK code
Copy code
new Api(stack, "Api", {
  routes: {
    "GET  /notes": "src/list.main",
    "POST /notes": "src/create.main",
    "$default"   : "src/default.main",
  },
});
With step functions, what do u want the SST construct to simply on top of CDK’s construct @Kevin Wright ?
k
@Kevin Wright perhaps Event bridge rules + filters combined with event archives could also give you a replay setup even without using step functions