simplifies the caller's work. currently the return value of dispatch always needs to be inspected for if the content contains a promise or not, and then the promise needs to be resolved/rejected before continuing. the fact of the matter is the implementation always returns a Promise, so there's very limited benefit of a synchronous response. current callers whose work would be simplified include the express middleware and the tests. in the future if any other server interfaces were supported, those would also be simplified.
con:
~delays the signal back to the server interface that a request was indeed matched to a callback, which can potentially delay any further processing by "next" middleware~ we could return a Promise right away, the resolution/rejection would come later.
~currently the response status is available synchronously, which could be used without having the whole body.~ the timing of the response is all currently controlled by the adapter, and there's no possibility of a streaming response, so it seems a little futile to send a status code before the rest of the response.
we want to sort this out before any additional server interfaces are created (in addition to adapter.expressMiddleware().
a proposed interface using typescript syntax for illustration:
interface JSONObject {}; // what you might expect
interface DispatchResult {
status: number;
content?: string | JSONObject;
};
// if this function returns undefined, then there was no matching callback and the server should proceed to another handler
adapter.dispatch(payload: JSONObject): Promise<DispatchResult>?;
Requirements
[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
Description
pro:
con:
we want to sort this out before any additional server interfaces are created (in addition to
adapter.expressMiddleware()
.a proposed interface using typescript syntax for illustration:
Requirements