search

graphile / logger

An extremely lightweight log abstraction for libraries that can be used in place of `console.log`/etc, allowing users to optionally log through other log providers (`winston`, `bunyan`, etc)
MIT License
8 stars 1 forks source link

Best strategy for existing logger? #4

Open julien51 opened 1 year ago

julien51 commented 1 year ago

Summary

We are considering using Graphile and we have deployed multiple tests. So far, so good (and thank you!). However we have issues with logging inside the Tasks. I read the section on logging and it looks like the Tasks must use their own logging from the helpers logger facility. Unfortunately that does not look like a great option for us because we share a lot of the code in the Tasks with our web app and there are many places in this web app where we call logger.info(...) (logger is a winston logger). It is current imported in all the files where there is logging using import logger from '....'

We would really love to avoid passing down/around the "logger" object as it could be different based on whether it is the "web app logger" (winston) or the Graphile logger.

Any trick on how to make things work without rewriting all of our files? (i.e we would love to keep our import logger from '...'?

benjie commented 1 year ago

You can call any arbitrary logic from your tasks, so you should be able to use whatever logging you want; BUT worker still does it’s own logging. The point of @graphile/logger is to provide an abstraction so that you can feed in whatever logging framework you’re using - e.g. you can use a Winston adaptor and then every log that Worker outputs will go through Winston.