xogroup/toki

Add built-in response sender method

Closed this issue · 0 comments

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.