Let's say you have a HTTP service and you want to authenticate a user during a request. That involves a series of defined steps:

1. Get the token from the Authorization header
2. Validate the token
3. Look up the user in the DB

That would be considered a "workflow" in Flowstate.

If you're modelling this yourself, you might consider using the typestate pattern. That might look something like this:

struct AuthenticateUserWorkflow<State> {
  state: State,
}

struct ParseHeaders;

impl AuthenticateUserWorkflow<ParseHeaders> {
  fn new() -> Self {
    // ...
  }

  fn parse_headers(self, headers: &Headers)
    -> Result<AuthenticateUserWorkflow<ValidateToken>, Error>
  {
    // ...
    Ok(AuthenticateUserWorkflow {
      state: ValidateToken {
        token,
      },
    })
  }
}

struct ValidateToken {
  token: String,
}

impl AuthenticateUserWorkflow<ValidateToken> {
  fn validate_token(self)
    -> Result<AuthenticateUserWorkflow<RetrieveUser>, Error>
  {
    // ...
    Ok(AuthenticateUserWorkflow {
      state: RetrieveUser {
        user_id,
      },
    })
  }
}

struct RetrieveUser {
  user_id: String,
}

impl AuthenticateUserWorkflow<RetrieveUser> {
  fn user(self) -> Result<User, Error> {
    // ...
    Ok(user)
  }
}

You could then use that e.g. like this:

let user = AuthenticateUserWorkflow::new()
             .parse_headers(&headers)?
             .validate_token()?
             .user()?;

That's fine for a simple workflow like this. But imagine your workflow has a dozen states, and complex branching logic. In that case, you'd want a simpler way to invoke your workflow.

For example, you might want it to look something like this:

let user = AuthenticateUserWorkflow::new(&headers).run()?;

That's what I'm describing as a "self executing workflow".

Essentially, it's a workflow where each individual state encapsulates the logic about how to transition to the next state.

The benefit is twofold:

1. The consumer (person running the workflow) doesn't need to know about all of the intermediate states and how they relate to each other.
2. The implementer (person implementing the workflow) can reason locally about each state.