Yan Cui’s Post

I use Workflow Studio to develop my state machine, then save the underlying ASL as a statemachine.asl.json file. I then use CDK's sfn.DefinitionBody.fromFile('statemachine.asl.json') directive to load the ASL into my CDK state machine definition. I never directly write CDK constructs for each of the ASL states. This way I can reload the ASL back into Workflow Studio and make changes.

This problem is why I built a new state-machine construct. It's almost identical to the existing L2 shipped with the CDK but provides a clean way to import an ASL definition AND override properties in the ASL to values driven by your other CDK code. https://constructs.dev/packages/@matthewbonig/state-machine/v/0.0.33?lang=typescript

I code it directly in the CDK. It is a little odd because you feel like you are coding upside down. You soon get used to it. It is a little like building a relational schema where you are coding the leaf nodes of the DAG and building up to the top. I use the Workflow Studio as a means to visualise the output. I don't use CloudFormation because i don't want to code in JSON/YAML and the same applies to ASL. I am trying to lower cognitive load not increase it :)

Console. Then copy-paste and set it as a string. We need the console to produce CDK. Not just the ASL.

Depends on the SF complexity. But usually the initial design on the console. The design is easier to look as a whole and also maybe share the initial design in a design document or initial refinement session. And then move to code in CDK (use the initial ASL as support for the CDK code). I’ve seen some projects where people use the console, export the ASL final json and import it in the CDK code. I need to learn both in my case but it pays off, because helps to spot mistakes, bugs and also helps to manage the complexity produced on the CDK code. Honestly not the best development experience though.

I use the Workflow Studio to visualize, then CDK constructs. The approach mentioned above with ASL sounds interesting, but I believe developing SF in CDK requires serious development skills and design patterns because it forces you to define dependencies steps within your workload. Also, in majority of my SFs I use waitTaskToken that probably is modified in another SF. Therefore, all your business logic will be defined in your infra code. So writing one Typescript file will be very complex and using design patterns will be the way to go

I typically start in CDK right away, only looking at the console to check after a milestone whether everything looks fine. I never really look at ASL. With major branches of a complex workflow possible to be handled separately in code and easily connected in CDK when done, I find this quite manageable and productive with a bit of experience.

Really depends on what I'm doing. If it's a standard flow i just grab some existing CDK code and copy/modify it. If it's new and or complex, I'll use the web portal to design first, then use the generated template as a starting point. Sometimes the CDK settings needed for a step aren't the clearest, so doing it in the web console first reveals the property combinations needed.

First I design the state machine in the workflow studio, and then I replace some concrete references (lambda arns etc.) in the .asl with placeholders. And finally I pass the replacement values through definitionSubstitutions. After then if I need to make some major change on an existing state machine I do the same thing as above, otherwise if the change is trivial, then I directly edit the .asl file.

I do both yes. Typically if I'm not yet 100% sure how my SFN will look like I'll do it in the designer. After that I'll translate it to the chain syntax in CDK. I also used the ASL gave it to ChatGPT and let it convert to CDK which worked surprisingly good :D So in general: Designer to get started -> CDK L2 from that point on