Hi,
I would like to know if Toki saves the workflow state under the hood.
Does it use a message broker(pub-sub) or is it pure request response?

Context

• Each action configuration should allow for an optional untyped options object to be passed through. Because we are making action plugins first class citizens and exporting the functionality of http actions to be a function of toki-method-http, the options needs to be passed with the routes and action verbs associated to that action along with even customizable templated payloads.
• Documentation needs to be specific that this optional untyped options object is not validated by toki core and the responsibility of that is on the onus of the plugin itself.

For consistency, we should use the naming standards established by toki-method-http.

Changes needed:

• clientResponse renamed to clientResponseConfiguration
• createConfiguration renamed to inputConfiguration
• (if used) assembleConfiguration renamed to outputConfiguration

Context

• The action.type attribute is not clear that this value is what we use to require in toki-method-* plugins. All of the examples have action.type names that do not align with our toki-method-* plugin signature. Do we want to consider doing something webpack does which is optionally, you can plug in a name that does not prepend with toki-method and we will try to prepend the signature if one does not match? If not, we should be clear in our examples what to expect via a naming convention.

What are you trying to achieve or the steps to reproduce ?

I would like to do something like:

"actions": [ /*list of toki actions to take. nothing different here.*/ ],
"failure": [{
    "name": "RabbitCatch",
    "type": "toki-method-rabbit",
    "createConfiguration": {
         "event": "toki.request_failed",
        /*the rest of the event mapping*/
    }
}]

What are you trying to achieve or the steps to reproduce ?

Since Toki delegates the responsibility for sending HTTP responses to action methods in all cases except for "uncaught" errors (500 Server Error), there should be an action "type" that indicates that an HTTP response needs to be sent. Methods like toki-method-proxy and toki-method-http handle the response delegation, but there are use cases (below) in which the action needed is nothing more than a simple HTTP response.

What result did you expect ?

The contrived "failure" ruleset should result in a rabbit event being emitted, then a mapped response being sent back to the client.

"failure": [
    {
        "name": "rabbit action",
        "type": "toki-method-rabbit",
        "rabbitConfiguration": { /*BunnyBus configs*/ },
        "createConfiguration": {
            "event": "toki.request-failed",
            "message": {
                "processed": false,
                "errors": "{{=it.errors}}"
            }
        }
    },
    {
        "name": "error response",
        "type": "responder",
        "clientResponse": {
            "statusCode": "{{=it.errors.designatedStatusCode}}",
            "payload": "{{=it.errors.optionalPayload}}"
        }
    }
]

What result did you observe ?

Since the built in HTTP responder does not exist, the request hangs open when the "failure" ruleset is executed.

Requirements

• An action (whether in "actions" or "failure" rulesets) with the type "responder" should utilize the build in responder method instead of trying to require('responder').
• The clientResponse should support toki-templater templated payloads.
• The clientResponse config is required and has the following Joi schema:

  const responderConfig = Joi.object().keys({
      statusCode: Joi.alternatives().try(Joi.string, Joi.number()).required(),
      payload: Joi.alternatives().try(Joi.string(), Joi.object()).optional()
  }).required();

• The HTTP response should be sent with the configured statusCode and, if present, payload.
• An error in responder should result in the default error handler sending back a 500 Server Error response.

We should allow for the use of toki methods that are not published to npm/private repositories. This will allow for business logic written on a service to be used inside of Toki route configurations.

There is some security research needed, but the initial implementation being discussed involves adding something like the below here;

        const localMethods = requiredir(path.join(process.cwd(), './methods');

        //require handler to be called as per configuration type
        let handler;

        if (localMethods[action.type]) {
            handler = localMethods[action.type];
        }
        else if (action.type === 'responder') {
            handler = require('./responder');
        }
        else {
            handler = require(action.type);
        }

Context

For the toki-method-* method contract. We are passing in a context. Lets remove it since the superset of data and utilities is binded through this anyways.

Context

Validate that all action names within a route is unique.

Context

We need additional documentation around the context object to help green to us engineers understand what is being offered exactly for the method actions to use.

• context.request
  • what is the exact contract we are offering with decorations on top of the node request object
• context.reply
  • what does this action do exactly?
• How does the actions configuration section map on the context