sysgears
use debug
I think using debug would be ideal for output. it allows the user to filter based on namespaces with an environment variable (or REPL, via telnet for example). we could add namespaces for subscription, mutation, query, etc.
Yes, good idea. I also thought about exposing formatter and reporter options to the users, with providing default formatter and reporter in the logger.
But I'm also concerned about minimum number of steps to start logging. With using debug it will be 2 steps. Maybe we could provide reporters for using console and debug, with console used by default?
Configuring output would be nice for sure, but I'm not sure whether it is really useful to
add namespaces for subscription, mutation, query, etc.
Why anyone would want to output only queries and not mutations or subscriptions? I think we should evaluate possible use cases first and then add implementation to cover them.
Well, the usual reason is telneting into your server to figure out what is going on via REPL. A lot of people that I know use debug at runtime in this way
Yes, the reason to support debug is perfectly valid. The question is:
add namespaces for subscription, mutation, query, etc.
Why anyone would want to output only queries and not mutations or subscriptions?
I can't think of a use case for namespacing subscription, mutations, and queries. But certainly we need the ability to namespace arbitrary graphql endpoints.
Not sure about exposing reporter & formatter. Currently there's debug and formatRequest fns, are these what you suggested exposing?
Would it be easier to be able to pass an array whitelisting operationNames to addApolloLogging ?
@leviwheatcroft Yes, I suggest exposing report and format as an options that you can pass to new LoggingLink({report: msg => console.log('endpoint X', msg), format: req => ... }) and to addApolloLogging(pubSub, {report: msg => console.log('endpoint X', msg), format: req => ... })
This should fulfill most customization needs