Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allows for overriding the makeId function #44

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

allows for overriding the makeId function #44

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 13 additions & 9 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,9 +22,9 @@ Volleyball is a minimal Connect-style middleware function which logs incoming re

Logging HTTP cycles can be approached in several ways, each with its own drawbacks:

* 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.
- 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.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary formatting diff * -> - — not a blocker, but also if it can be undone that'd be swell.


Volleyball takes the last approach, and assigns randomly-generated ids to label request-response pairs. It is designed for student project development, teaching beginning programmers how HTTP servers and asynchronicity work. It may also be useful as a low-configuration debug tool.

Expand Down Expand Up @@ -54,13 +54,17 @@ The `debug` property logs using the [`debug`](https://github.com/visionmedia/deb
| 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.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • makId -> makeId
  • funciton -> function


See `src/id.js` for the default `makeId` implementation.

## Related and Alternatives

For more powerful, configurable, and compatible logging needs, check out:

* [debug](https://github.com/visionmedia/debug#readme)
* [morgan](https://github.com/expressjs/morgan#readme)
* [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)
- [debug](https://github.com/visionmedia/debug#readme)
- [morgan](https://github.com/expressjs/morgan#readme)
- [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)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More unnecessary * -> - formatting

4 changes: 3 additions & 1 deletion lib/volleyball.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,8 @@ var makeId = require('./id');
var sp = ' ';
module.exports = Volleyball(); // eslint-disable-line new-cap

module.exports.makeId = makeId;

function Volleyball() {
var config = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : {};
// items shared across multiple req-res cycles, for a given volleyball
Expand All @@ -22,7 +24,7 @@ function Volleyball() {
// items shared between the request and response of just one cycle
var cycle = {
log: log,
id: makeId(),
id: config.makeId ? config.makeId() : makeId(),
time: process.hrtime()
};
logReq(req, cycle);
Expand Down
3 changes: 2 additions & 1 deletion src/volleyball.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ const makeId = require('./id')
const sp = ' '

module.exports = Volleyball() // eslint-disable-line new-cap
module.exports.makeId = makeId
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


function Volleyball(config = {}) {
// items shared across multiple req-res cycles, for a given volleyball
Expand All @@ -18,7 +19,7 @@ function Volleyball(config = {}) {
// items shared between the request and response of just one cycle
const cycle = {
log: log,
id: makeId(),
id: config.makeId ? config.makeId() : makeId(),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 || makeId

Then 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).

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

time: process.hrtime(),
}

Expand Down
12 changes: 12 additions & 0 deletions test/test.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,18 @@ describe('An Express app', function() {
it('logs requests and responses', test)
})

describe('using volleyball with custom makeId', () => {
function makeId() {
return 'IDID'
}

beforeEach(function() {
app.use(volleyball.custom({ makeId }))
})

it('logs reuests and responses', test)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • reuests -> requests
  • Empty spec; ideally we should capture output and see if the id matches expectations, I guess

})

describe('using volleyball with debug true', function() {
beforeEach(function() {
app.use(volleyball.custom({ debug: true }))
Expand Down