3 ms·
If you are going down this path, I think the killer feature is to simply put the log in the console.log area, so there are interlaced with whatever you are logg
by quickthrower2 7y ago
If you are going down this path, I think the killer feature is to simply put the log in the console.log area, so there are interlaced with whatever you are logging on the client side, perhaps in a different colour.
Then you can see the timeline of both client and server ha penning together.
- uhoh-itsmaciek 7y agoYep. I wrote a debug logger that could send messages to the browser console from the client, the backend's web process (via websocket), and the backend's background workers (via redis pubsub relayed to websocket). It was pretty tightly coupled to the architecture of the application, so it couldn't be used more generally like this library, but it was pretty simple and very handy for debugging some types of issues. It's worth investing a bit in dev ergonomics on your project: it can pay off in spades.
- thrower123 7y agoI've always done this the other way around, and had the client send back messages to be included into my server logs. Spraying the server logs to clients would really not be something I'd be very comfortable doing. Certainly not in production, and if I'm developing in debug mode, I've already got the log output scrolling by in a console appender, so seeing it in the browser dev tools isn't really any better or worse.
- eshengsky 7y agoNow the v2.0.0 version support print server logs in Chrome Console, based on extension installed.