Visualises requests when in development. #104

rickharrison · 2016-10-09T06:51:51Z

I took a stab at visualising requests from #33. The one thing that is a little messy is parsing and displaying the json. I ended up keeping a reference to it on the request since you can only call getRawBody once per request.

Let me know your thoughts!

timneutkens · 2016-10-09T09:39:59Z

lib/index.js

@@ -37,6 +55,12 @@ async function run(req, res, fn, onError) {

 async function json(req, {limit = '1mb'} = {}) {
  try {
+    if (DEV && req.parsedJson) {
+      return req.parsedJson
+    } else if (DEV && req.jsonError) {


Shouldn't we first check if there is an error? 🤔

In theory, there can only be one or the other, but I can switch the order if you like.

timneutkens

Looks fine 👍, maybe add in a way to pass a custom parse function later on, so you can also log out other stuff. urlencoded forms for example.
For now this will do fine 😄

rauchg · 2016-12-09T20:31:04Z

This is really beautiful @rickharrison. I think we should have --log=dev|prod|none as well that ignores env sniffing.

The prod mode of this would be a compressed version that excludes the body.

rauchg · 2016-12-09T20:31:20Z

(basically something similar to the default express logger)

rickharrison · 2016-12-13T19:11:30Z

Sounds good! I will work on this over my holiday break :)

luisrudge · 2016-12-25T23:24:45Z

This is amazing

rickharrison · 2016-12-27T01:41:18Z

Here is what --log=prod looks like:

timneutkens

Looks good :)

timneutkens · 2017-01-06T12:39:55Z

@rauchg final check?

rauchg · 2017-01-06T22:04:47Z

I'll take a look!

rauchg · 2017-01-06T22:05:29Z

bin/micro

+  -H    Host to listen on   [0.0.0.0]
+  -p    Port to listen on      [3000]
+  -h    Show this help message
+  --log dev|prod|none`);


off would be better than none IMO

we also need long forms for all of this, in addition to the short form

-H, --host -p, --port -h, --help -L, --log

I'll add your second comment to my readme PR @rauchg

@rauchg PR'ed #122

https://github.com/rickharrison/micro/pull/1

rauchg · 2017-01-06T22:06:56Z

lib/index.js

@@ -5,8 +5,22 @@ const server = require('http').Server
 const getRawBody = require('raw-body')
 const typer = require('media-typer')
 const isStream = require('isstream')
+const chalk = require('chalk')
+const jsome = require('jsome')

 const DEV = 'development' === process.env.NODE_ENV


It'd be cool to document in the README that we do the nicer logging upon explicit NODE_ENV = development setting

rauchg · 2017-01-06T22:07:20Z

lib/index.js

@@ -41,6 +63,14 @@ async function run(req, res, fn, onError) {

 async function json(req, {limit = '1mb'} = {}) {
  try {
+    if (req.jsonError) {


I'd like to avoid polluting req if at all possible

timneutkens · 2017-01-07T21:29:28Z

README.md

@@ -250,6 +250,14 @@ function handleErrors (fn) {
 }
 ```

+### Logging
+
+Micro provides some built-in logging to help visualise requests. When `NODE_ENV` is set to `development`, micro will display the request along with any json body like this:


Remove some

timneutkens · 2017-01-07T21:31:22Z

bin/micro

@@ -28,7 +29,8 @@ const help = () => {
  console.log(`Usage: micro [opts] <file>
  -H, --host  Host to listen on   [0.0.0.0]
  -p, --port  Port to listen on      [3000]
-  -h, --help  Show this help message`);
+  -h, --help  Show this help message
+  -L, --log dev|prod|off`);


Turned this around in my merge commit. First the logging then help, also added [off] as default indicator

timneutkens · 2017-01-07T21:46:33Z

@rauchg 🚀

rauchg · 2017-01-08T02:58:30Z

@rickharrison @timneutkens I think a few additions would make sense:

Response time (+ delta). EG: 10:30:00 PM (+30ms). Kinda like how debug gives you deltas
Also visualize response objects?
Not 100% sure, but I believe we can anchor the time to the right hand side with an ANSI escape code? (that'd be neat if possible!)

rickharrison · 2017-01-08T03:21:56Z

Sounds good! I'll take a look at this later tonight.

rickharrison · 2017-01-08T08:31:54Z

@rauchg So I have it logging response objects as well now, but I did it by adding a property to res 🙁

The problem is I'm not sure how to get the response body in the res.on('finish') event. Is it possible to see the data chunks from a http.ServerResponse? An alternative would be to use the callback parameter in the res.end() call. However, I do not know what the current log level is in that method. Do you think it would be better to store the log level in a global variable like DEV is from the initial serve call? Then instead of attaching to res, we could output the response body in the res.end()

As another caveat, if send or a return value is not used, then the logger won't be able to pick up on the response body at all unless I am missing something and getting the data from the ServerResponse is possible.

I was unable to find a way to align the time text to the right side. If anyone else has an idea of how to do that with ANSI, please let me know.

Happy to chat more on the zeit slack about this as well!

EDIT: Updated screenshot

rauchg · 2017-01-08T19:09:18Z

that looks really amazing! One way we could capture the response I assume is by patching the internal write method of the response object? The one that both res.end and res.write call

rickharrison · 2017-01-08T19:10:23Z

Yea, we definitely could do that. I can take a stab and patching those methods inside of the logRequest method.

rauchg · 2017-01-08T19:14:18Z

Also, I have a slightly different take on this now:

{
  "dependencies": {
     "micro": "latest"
  },
  "devDependencies": {
     "micro-dev": "latest"
  }
}

micro-dev would have micro in peerDependencies, rather than include it.
It works with the exact same signature as micro, but…
We can add more options related to logging, for example whether to include headers, if you want to log only requests or only responses, etc.
We get rid of NODE_ENV sniffing. If you run micro-dev, it logs.
Works really nicely for package.json. start can run micro, dev can run micro-dev

This way, micro remains lean both in download time, LOC/maintainability & performance!

rauchg · 2017-01-08T19:15:32Z

https://github.com/zeit/micro-dev

onbjerg · 2017-01-20T14:35:13Z

@rauchg The repository is empty -- forgot to push or do you need a PR? 😊

timneutkens · 2017-01-20T14:38:04Z

I'm working on it @onbjerg 😄

onbjerg · 2017-01-22T11:14:59Z

@timneutkens I couldn't wait so I implemented it as a simple wrapper function instead of a CLI tool: https://github.com/onbjerg/micro-visualize

timneutkens · 2017-01-22T11:17:02Z

@onbjerg micro-dev is most likely coming today :)

onbjerg · 2017-01-22T11:19:16Z

@timneutkens 😨

iamstarkov · 2017-03-17T11:04:26Z

@timneutkens https://github.com/zeit/micro-dev is 404

onbjerg · 2017-03-17T13:33:50Z

https://github.com/onbjerg/micro-visualize is still an option

timneutkens reviewed Oct 9, 2016

View reviewed changes

timneutkens approved these changes Oct 9, 2016

View reviewed changes

timneutkens approved these changes Dec 27, 2016

View reviewed changes

This was referenced Jan 3, 2017

Any suggestions on good logging practice? #119

Closed

Visualising requests #33

Closed

rauchg reviewed Jan 6, 2017

View reviewed changes

timneutkens reviewed Jan 7, 2017

View reviewed changes

Rick Harrison and others added 8 commits January 8, 2017 00:24

Visualises requests when in development.

e114c2b

Adds --log cli var with values dev, prod, none

c9ab17b

Alias -L to --log, rename none to off

23cc89c

Remove side effect from json method

4ec29af

Add raw body to request

448cb12

Adds note to README about logging.

fc35d16

Adds test for double body parsing.

470a854

Adds response logging for json objects.

8db58c2

rauchg closed this Jan 8, 2017

Visualises requests when in development. #104

Visualises requests when in development. #104

Conversation

rickharrison commented Oct 9, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timneutkens left a comment

Choose a reason for hiding this comment

rauchg commented Dec 9, 2016

rauchg commented Dec 9, 2016

rickharrison commented Dec 13, 2016

luisrudge commented Dec 25, 2016

rickharrison commented Dec 27, 2016

timneutkens left a comment

Choose a reason for hiding this comment

timneutkens commented Jan 6, 2017

rauchg commented Jan 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timneutkens commented Jan 7, 2017

rauchg commented Jan 8, 2017 • edited Loading

rickharrison commented Jan 8, 2017

rickharrison commented Jan 8, 2017 • edited Loading

rauchg commented Jan 8, 2017

rickharrison commented Jan 8, 2017

rauchg commented Jan 8, 2017

rauchg commented Jan 8, 2017

onbjerg commented Jan 20, 2017

timneutkens commented Jan 20, 2017

onbjerg commented Jan 22, 2017

timneutkens commented Jan 22, 2017

onbjerg commented Jan 22, 2017

iamstarkov commented Mar 17, 2017

onbjerg commented Mar 17, 2017

rauchg commented Jan 8, 2017 •

edited

Loading

rickharrison commented Jan 8, 2017 •

edited

Loading