Logging?

[glennblock]

First, thanks for this great project. I have been playing with it the past few days and using the OData handler to talk to Microsoft Graph. Being able to use graphiql to issue queries against Graph is magical.

One of the things I ran into while doing this exploration is that some queries were failing. What I want to be able to do is see the requests that are being sent to Microsoft Graph so I can see what is causing the failure.

This gets me to the topic at hand, LOGGING.

I have noticed there appears to be no logging throughout Mesh. For diagnosing issues in production, dev etc, logging is essential, and there are lots of available solutions to leverage, they just need a design and to be plugged in.

Has any consideration been given to adding a logger to Mesh? It would be nice to have some default like Winston or Bunyan, even better would be to let me override the logger with my own. Once the logger is there, it would be some effort to figure out how to abstract and surface the logger throughout the code base and to make it avail to plugins. I'd argue the cost outweighs the benefits. I'd also argue against pure console logging, as using a logger gives you the ability to set verbosity levels which can easily be turned up or down through environment vars when needed, and they also support different outputs, formatting etc.

Thoughts?

[dotansimha]

Hi @glennblock !
@ardatan started to do some work on that here: #785 , and I'll continue.

I think in general we need 2 types of logging here:

• General logging on the mesh level (to log entries of resolvers execution, their input values and their return values):

meshLogging: debug
sources:
  - ...

• Per-handler logging - to print details regarding the execution of the handlers.

sources:
  - name: Microsoft Graph
    handler:
      odata:
        baseUrl: https://graph.microsoft.com/${GRAPH_VERSION}
        batch: json
        logLevel: debug
        operationHeaders:
          Authorization: Bearer {context.accessToken}

And to be more specific, we need even granular control over what's being logged, so the signature of logLevel could be either a general logging level, like debug or info, but also maybe an object/array to define the specific items you wish to log:

meshLogging:
  default: info
  Query.test: debug
  Query.test2: debug

[rufman]

I'm going to piggy back off this question: I see winston is being used for console logging. I'm looking into adding logging for the GRPC handler and adding basic file logging is straightforward. However I'd want to be able to load a custom transport (e.g. Sentry), which leads me to my question: How would this be handled best? Is adding a meshrc attribute that is an array of filenames that point to transports an acceptable solution? These files would then be loaded when the server starts.