step

An Amazon State Language based state machine.

It is probably worth pointing out that this design probably isn't terribly practical in reality. There are many ways to solve this problem but the current structure was chosen for ease of development, to better understand the problem space, and to get a feel for the Amazon State Language spec itself. One could imagine many different approaches, including:

• Separate the validation and execution steps: Validation and deployment of a specification versus the runtime invocation are distinctly different as it pertains to the overall lifecycle of the state machine. One approach could be to validate both structure and data integrity, then place the valid specification in a data store. At runtime the state machine could reference that specification by name, retrieve it, and run the machine to completion.
• Generate the state machine implementation: Perhaps a more efficient solution would be to generate and deploy the complete implementation (a FaaS Function) based on the provided spec. The platform could either change the implementation of how it would fulfill remote Tasks based on the FaaS provider, or the implementation could be provided by the author. (I like this one, personally.)

See additional notes below.

Basic API

const json = {
    "StartAt": "Demo",
    "States": {
        "Demo": {
            "Type": "Pass",
            "Result": {
                "pass": {
                    "a": "b"
                }
            },
            "Next": "Done"
        },
        "Done": {
            "Type": "Succeed"
        }
    }
};

const input = {
    foo: {
        bar: true,
    },
};

const machine = Machine.create(json);
const result = await machine.run(input);
console.log(result);

Testing

$ npm test

Notes

• The Node runtime version (in .npmrc) was explicitly chosen for OpenWhisk compatibility. The associated stability that comes with selecting one runtime is preferred for now (in the early stages of development) over flexbility across providers.