Remove loglevel-debug and DEBUG=apollo-gateway:* support.
#3896
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While this package provided some simple functionality at one point or another, it was neither actively maintained, properly typed, and as of # fully-featured as of #3894, no longer really necessary. Also, since it re-uses the same logger based on repeat requests to `getLogger("name")` in a global context, it was responsible for recursively wrapping our log function in tests with the same `methodFactory` and causing our log messages to get longer and longer for each test which used `ApolloGateway`. This only affected tests, but was hard to track down the cause! The new `logger` functionality in the above PR should provide much more flexibility here and `debug: true` on the `ApolloGateway` constructor can replicate the same behavior. Anyone who misses this behavior can utilize the new pluggable logger to provide [`loglevel-debug`] themselves! [`loglevel-debug`]: https://npm.im/loglevel-debug
abernix
changed the title
loglevel-debug and DEBUG=apollo-gateway:* support.loglevel-debug and DEBUG=apollo-gateway:* support.
This merely replicates the pattern and behavior here: https://github.com/apollographql/apollo-server/blob/fea6f15f/packages/apollo-server-core/src/ApolloServer.ts#L204-L209
This was only used for display purposes in a way that turned out to be to resolve a problem that `loglevel-debug` had necessitated by the way it provides its own `methodFactory` that prepends the date, etc.
abernix
changed the title
loglevel-debug and DEBUG=apollo-gateway:* support.loglevel-debug and DEBUG=apollo-gateway:* support.
abernix
force-pushed
the
abernix/remove-gateway-loglevel-debug
branch
from
90cb1df to
a9f1a1f
Compare
abernix
added a commit
that referenced
this pull request
Jun 29, 2020
Removed in the same spirit as was done in the `@apollo/gateway` package (see footer for PR reference) due to general deficiencies and bugs in that chosen implementation and also just because it's widely unutilized (if used at all). Much in the same way as the PR below suggests, this behavior could be opted into if necessary by providing a custom `logger` to the plugin options. While that option doesn't yet exist, a PR would be very much welcome (though it does require juggling some of the conditions around how the "dry-run" mode works and does its logging in a well-defined way. [Ref]: #3896.
abernix
added a commit
that referenced
this pull request
Jun 29, 2020
Removed in the same spirit as was done in the `@apollo/gateway` package (see footer for PR reference) due to general deficiencies and bugs in that chosen implementation and also just because it's widely unutilized (if used at all). Much in the same way as the PR below suggests, this behavior could be opted into if necessary by providing a custom `logger` to the plugin options. While that option doesn't yet exist, a PR would be very much welcome (though it does require juggling some of the conditions around how the "dry-run" mode works and does its logging in a well-defined way. [Ref]: #3896.
abernix
added a commit
that referenced
this pull request
Jun 29, 2020
BREAKING CHANGE: Drop the use of uncommonly used `loglevel-debug`. Removed in the same spirit as was done in the `@apollo/gateway` package (see footer for PR reference) due to general deficiencies and bugs in that chosen implementation and also just because it's widely unutilized (if used at all). Much in the same way as the PR below suggests, this behavior could be opted into if necessary by providing a custom `logger` to the plugin options. While that option doesn't yet exist, a PR would be very much welcome (though it does require juggling some of the conditions around how the "dry-run" mode works and does its logging in a well-defined way. [Ref]: #3896.
abernix
added a commit
that referenced
this pull request
Aug 7, 2020
BREAKING CHANGE: Drop the use of uncommonly used `loglevel-debug`. Removed in the same spirit as was done in the `@apollo/gateway` package (see footer for PR reference) due to general deficiencies and bugs in that chosen implementation and also just because it's widely unutilized (if used at all). Much in the same way as the PR below suggests, this behavior could be opted into if necessary by providing a custom `logger` to the plugin options. While that option doesn't yet exist, a PR would be very much welcome (though it does require juggling some of the conditions around how the "dry-run" mode works and does its logging in a well-defined way. [Ref]: #3896.
abernix
added a commit
to apollographql/federation
that referenced
this pull request
Sep 4, 2020
…graphql/apollo-server#3896) While this package provided some simple functionality at one point or another, it was neither actively maintained, properly typed, and as of # fully-featured as of apollographql/apollo-server#3894, no longer really necessary. Also, since it re-uses the same logger based on repeat requests to `getLogger("name")` in a global context, it was responsible for recursively wrapping our log function in tests with the same `methodFactory` and causing our log messages to get longer and longer for each test which used `ApolloGateway`. This only affected tests, but was hard to track down the cause! The new `logger` functionality in the above PR should provide much more flexibility here and `debug: true` on the `ApolloGateway` constructor can replicate the same behavior. Anyone who misses this behavior can utilize the new pluggable logger to provide [`loglevel-debug`] themselves! Apollo-Orig-Commit-AS: apollographql/apollo-server@0ca43f8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While this package provided some simple functionality at one point or another, it was neither actively maintained, properly typed, and as of # fully-featured as of #3894, no longer really necessary. Also, since it re-uses the same logger based on repeat requests to
getLogger("name")in a global context, it was responsible for recursively wrapping our log function in tests with the samemethodFactoryand causing our log messages to get longer and longer for each test which usedApolloGateway. This only affected tests, but was hard to track down the cause!It also was responsible for prepending the log lines with dates and times which were often undesirable since a more fully functional logger (as in, most cloud-based loggers) would already have baked in such metadata, rather than needing it inlined in the message itself.
The new
loggerfunctionality in the above PR should provide much more flexibility here anddebug: trueon theApolloGatewayconstructor can replicate the same behavior.Anyone who misses this behavior can utilize the new pluggable logger to provide
loglevel-debugthemselves.