allows for overriding the makeId function#44
Conversation
glebec
left a comment
There was a problem hiding this comment.
I like this feature. Have some nits to pick; in rough order of priority:
- possibly fill in empty test spec
- remove unnecessary export property
- prefer init-time branching
- some small spelling typos
- unnecessary formatting diffs
| | string | uses a new debug instance with a custom namespace | | ||
| | function | uses any function, such as a pre-generated debug instance. Note that the function will be called with colorized strings. | | ||
|
|
||
| The `makId` property specifies a custom request id generation function. It MUST be a funciton that returns a string. |
There was a problem hiding this comment.
makId->makeIdfunciton->function
| * Log both upon **request** and **response**. Drawback: it is not necessarily clear which responses are for which requests. | ||
| - Log only upon **request**. Drawback: we cannot log the corresponding response, which happens later (if at all). | ||
| - Log only upon **response**, attaching the request. Drawback A: if the server never sends a response, e.g. due to a bug, the request will not be logged either. Drawback B: two temporally distinct events are conflated, misleadingly. | ||
| - Log both upon **request** and **response**. Drawback: it is not necessarily clear which responses are for which requests. |
There was a problem hiding this comment.
Unnecessary formatting diff * -> - — not a blocker, but also if it can be undone that'd be swell.
| - [morgan-debug](https://github.com/ChiperSoft/morgan-debug#readme) | ||
| - [winston](https://github.com/winstonjs/winston#readme) | ||
| - [express-winston](https://github.com/bithavoc/express-winston#readme) | ||
| - [node-bunyan](https://github.com/trentm/node-bunyan/#readme) |
There was a problem hiding this comment.
More unnecessary * -> - formatting
| const sp = ' ' | ||
|
|
||
| module.exports = Volleyball() // eslint-disable-line new-cap | ||
| module.exports.makeId = makeId |
There was a problem hiding this comment.
Why are we adding this to the volleyball instance itself? As I understand it, we only need to make makeId a property of the config passed to volleyball.custom.
| app.use(volleyball.custom({ makeId })) | ||
| }) | ||
|
|
||
| it('logs reuests and responses', test) |
There was a problem hiding this comment.
reuests->requests- Empty spec; ideally we should capture output and see if the id matches expectations, I guess
| const cycle = { | ||
| log: log, | ||
| id: makeId(), | ||
| id: config.makeId ? config.makeId() : makeId(), |
There was a problem hiding this comment.
The compiler may be able to optimize this, but on principle I'd prefer init-time branching – add the following ca. line 17 (before defining function volleyball):
const idGenerator = config.makeId || makeIdThen cycle would be defined as:
const cycle = {
log: log,
id: idGenerator(),
time: process.hrtime()
}It may be overkill, but that's how I'd do it (similar to how I instantiate the log function above).
There was a problem hiding this comment.
Follow-up, I would also prefer to add a modicum of dynamic type-checking to this config.
if ((makeId in config) && (typeof config.makeId) !== 'function') {
throw TypeError('Volleyball config option `makeId` must be a function')
}(untested)
This allows for a customized request id generator.
In particular I've been using it with
continuation-local-storageto get a "request id" that can be used by any async resource in a given express "request thread"https://www.npmjs.com/package/continuation-local-storage
A bit like this:
Assignee Tasks