Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use debug #1

Open
thebigredgeek opened this issue May 13, 2017 · 7 comments
Open

use debug #1

thebigredgeek opened this issue May 13, 2017 · 7 comments

Comments

@thebigredgeek
Copy link

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.

@larixer
Copy link
Member

larixer commented May 14, 2017

Yes, good idea. I also thought about exposing formatter and reporter options to the users, with providing default formatter and reporter in the logger.

@larixer
Copy link
Member

larixer commented May 14, 2017

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?

@larixer
Copy link
Member

larixer commented May 14, 2017

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.

@thebigredgeek
Copy link
Author

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

@larixer
Copy link
Member

larixer commented May 15, 2017

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?

@leviwheatcroft
Copy link

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 ?

@larixer
Copy link
Member

larixer commented Feb 25, 2018

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants