This is cool, but the high cost of using step functions ($0.025 per 1,000 state transitions) makes me pretty wary of using it for anything that doesn't really need the orchestration functionality (i.e. long term wait / retry logic)
my principal argument against using step functions is that it couples what it is ultimately business logic (your state machine) to a non-programming language that has no test framework other than E2E integration testing.
I'm legitimately interested in being talked out of this objection, since I think the visualization component is where programming is headed in the long term. Any takers?
Sure; this isn't directed at step functions, but in general, if you have your business logic (state machine) in a declarative format, albeit non-programming language (e.g., JSON), then that can potentially make it even more testable than a hand-written, informally-specified state machine in code.
Since all of the states/transitions are consistently and declaratively specified, you can iterate through them, build up a directed graph in code, and unit/integration/E2E test them however you'd like. Without that strict declarative "DSL", you would need to figure that out otherwise (requires much more effort), and you're bound to miss coverage on states/transitions, especially if the logic changes.
in my case, I do still have much better tooling for dealing with state-machines-as-code. but it's a helpful reminder that the tooling for step functions, if I had the time to build it, could potentially be significantly simpler since it would be dealing with a smaller set of possibilities.
4 comments
[ 2.7 ms ] story [ 20.7 ms ] threadI'm legitimately interested in being talked out of this objection, since I think the visualization component is where programming is headed in the long term. Any takers?
Since all of the states/transitions are consistently and declaratively specified, you can iterate through them, build up a directed graph in code, and unit/integration/E2E test them however you'd like. Without that strict declarative "DSL", you would need to figure that out otherwise (requires much more effort), and you're bound to miss coverage on states/transitions, especially if the logic changes.
in my case, I do still have much better tooling for dealing with state-machines-as-code. but it's a helpful reminder that the tooling for step functions, if I had the time to build it, could potentially be significantly simpler since it would be dealing with a smaller set of possibilities.