hapijs / good

hapi process monitoring
Other
525 stars 160 forks source link

good stream recipes??? #483

Closed jmjf closed 8 years ago

jmjf commented 8 years ago

One of the goals of good 7 is to reduce the need for dedicated good reporters and allow developers to use any stream module that suits a particular need (from several closed issues).

It may be useful to assemble recipes for common problem solutions. That could be on the wiki or in the repo, similar to gulp's recipes. Entries could range from whole reporter specs to details on how to use a specific stream to achieve a desired result.

For example, when sending SafeJson to a file stream, args: [ {}, { separator: ',' } ] makes it much easier to convert the file into a parseable JSON array. (Wrap it in [] and remove the last ,.) Same trick can get you ,\n or \n if you like to eyeball the file.

(I'm not a JS expert, so figuring that out required crawling through monitor.js to understand how args made it to good-squeeze plus some trial and error.)

arb commented 8 years ago

I'm not sure what kind of recipes you would put in there... what did you have in mind?

Also the thing with args is documented in API.md

[args] - an array of arguments to pass to the constructor when this stream object is created via new.

If you do not find that clear, I'm always open to documentation PRs.

jmjf commented 8 years ago

FWIW, this more a suggestion than a request, but whatever labels work for you.

I'm not sure what kind of recipes you would put in there... what did you have in mind?

Recent closed issues, #474, #476 and #479, all include some form of "How do I write to X?" as part of the issue. My read of your responses is that reporters are the new good-xxxx modules and users are encouraged to move away from dedicated reporter modules to reporters based on off-the-shelf transform and write stream modules.

Defining a place for people to share reporter definitions and inviting PRs could produce useful example reporters. Examples would help/encourage users to adopt good 7.x. and move away from writing custom reporters that can reasonably be built in a stream. Good examples would also encourage reusing existing functionality and discourage duplicating transform stream functionality in custom write streams.

(Assumption: transform streams (examples: Squeeze, SafeJson, good-console) perform filtering and formatting; endpoint streams (examples: good-file, stdout) deliver their input to the endpoint.)

If you do not find that clear...

I saw the the docs on [args]. After a lot of trial and error failed, I read the code and made the connection between the arguments object in a function and the [args] array in the options. (:+1: for lightbulbs.) That may be my JS skills as much as the documentation. I'll think about what might be clearer to me and submit a PR for consideration if I come up with something.

Thanks.

tom2strobl commented 8 years ago

+1 imho it would be very practical to have something like a recipe collection somewhere inside the good repo so people don't have to search which modules are currently on vogue. like https://github.com/hapijs/good-file/issues/82

arb commented 8 years ago

I'd be open to this idea. Not a wiki though; nothing else in the org uses wikis so it would have to live elsewhere in the repo. Under examples or a separate markdown file.

jmjf commented 8 years ago

I'll work on a PR with a few starters that include what you have in the readme using a directory in the repo.

arb commented 8 years ago

Maybe add the one from good-file for using the rotation stream one. Also add one using white-out to strip potentially sensitive data since that was a removed feature.

jmjf commented 8 years ago

See PR #484. Let me know if this looks reasonable/works for you.

arb commented 8 years ago

Closed via 0023f1c4c70b25e4f3152ee50b6444d5f8e2d0d0

lock[bot] commented 4 years ago

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.