-
Notifications
You must be signed in to change notification settings - Fork 2k
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
ApolloServer.logger should probably be public readonly in AS4 #6082
Comments
Our plan for Apollo Server 4 (see https://github.com/apollographql/apollo-server/blob/main/ROADMAP.md and https://github.com/apollographql/apollo-server/milestone/60) is to change ApolloServer from having a subclass-based API to having a more well-defined public API that you extend by writing separate "createHandler" functions that take the single ApolloServer as an argument. So changing In the meantime, I don't see any reason we would get rid of |
Probably |
…gins This change does two things, which we originally thought were kind of connected but maybe aren't. First, we switch the implementation of contravariance from a hacky `__forceTContextToBeContravariant` field to the new TS 4.7 variance annotations. But in fact, instead of making it contravariant, we make it invariant: `ApolloServer<X>` can only be assigned to `ApolloServer<Y>` when X and Y are the same. This is because: - An `ApolloServer<{foo: number}>` is not a `ApolloServer<{}>`, because you can invoke `executeOperation` on the latter with an empty context object, which would confuse the former (this is the contravariance we already had). - An `ApolloServer<{}>` is not a `ApolloServer<{foo: number}>`, because you can invoke `addPlugin` on the latter with a plugin whose methods expect to be called with a `contextValue` with `{foo: number}` on it, which isn't the case for the former. Considering the second condition is why this is now invariant (`in out`). We're not quite sure why TS couldn't figure this out for us, but it can't. Second, we add `server: ApolloServer` to various plugin hook arguments (`GraphQLRequestContext` and `GraphQLServerContext`). This makes `logger` and `cache` on `GraphQLRequestContext` somewhat redundant, so we make those fields into public readonly fields on `ApolloServer` and remove them from the plugin hook arguments. (We thought this was related to the other part because adding `server` appeared to require invariance instead of contravariance, but it turns out that we needed invariance anyway due to `addPlugin`.) Note that this means that anyone consuming our `.d.ts` files must be on TS4.7. Before v4.0.0 we'll probably fix that; see #6423. Fixes #6264. Fixes #6082.
…gins This change does two things, which we originally thought were kind of connected but maybe aren't. First, we switch the implementation of contravariance from a hacky `__forceTContextToBeContravariant` field to the new TS 4.7 variance annotations. But in fact, instead of making it contravariant, we make it invariant: `ApolloServer<X>` can only be assigned to `ApolloServer<Y>` when X and Y are the same. This is because: - An `ApolloServer<{foo: number}>` is not a `ApolloServer<{}>`, because you can invoke `executeOperation` on the latter with an empty context object, which would confuse the former (this is the contravariance we already had). - An `ApolloServer<{}>` is not a `ApolloServer<{foo: number}>`, because you can invoke `addPlugin` on the latter with a plugin whose methods expect to be called with a `contextValue` with `{foo: number}` on it, which isn't the case for the former. Considering the second condition is why this is now invariant (`in out`). We're not quite sure why TS couldn't figure this out for us, but it can't. Second, we add `server: ApolloServer` to various plugin hook arguments (`GraphQLRequestContext` and `GraphQLServerContext`). This makes `logger` and `cache` on `GraphQLRequestContext` somewhat redundant, so we make those fields into public readonly fields on `ApolloServer` and remove them from the plugin hook arguments. (We thought this was related to the other part because adding `server` appeared to require invariance instead of contravariance, but it turns out that we needed invariance anyway due to `addPlugin`.) Note that this means that anyone consuming our `.d.ts` files must be on TS4.7. Before v4.0.0 we'll probably fix that; see #6423. Fixes #6264. Fixes #6082.
…gins (#6668) This change does two things, which we originally thought were kind of connected but maybe aren't. First, we switch the implementation of contravariance from a hacky `__forceTContextToBeContravariant` field to the new TS 4.7 variance annotations. But in fact, instead of making it contravariant, we make it invariant: `ApolloServer<X>` can only be assigned to `ApolloServer<Y>` when X and Y are the same. This is because: - An `ApolloServer<{foo: number}>` is not a `ApolloServer<{}>`, because you can invoke `executeOperation` on the latter with an empty context object, which would confuse the former (this is the contravariance we already had). - An `ApolloServer<{}>` is not a `ApolloServer<{foo: number}>`, because you can invoke `addPlugin` on the latter with a plugin whose methods expect to be called with a `contextValue` with `{foo: number}` on it, which isn't the case for the former. Considering the second condition is why this is now invariant (`in out`). We're not quite sure why TS couldn't figure this out for us, but it can't. Second, we add `server: ApolloServer` to various plugin hook arguments (`GraphQLRequestContext` and `GraphQLServerContext`). This makes `logger` and `cache` on `GraphQLRequestContext` somewhat redundant, so we make those fields into public readonly fields on `ApolloServer` and remove them from the plugin hook arguments. (We thought this was related to the other part because adding `server` appeared to require invariance instead of contravariance, but it turns out that we needed invariance anyway due to `addPlugin`.) Note that this means that anyone consuming our `.d.ts` files must be on TS4.7. Before v4.0.0 we'll probably fix that; see #6423. Fixes #6264. Fixes #6082.
Fixed in |
Proposal
We would like to propose exposing the
logger
property ofApolloServerBase
class that is currentlyprivate
to any class that extends it by updating it to aprotected
property.apollo-server/packages/apollo-server-core/src/ApolloServer.ts
Lines 127 to 131 in fca56e7
Use case
We have extend the
ApolloServerBase
class using the serverless approach by implementing a custom handler. We would like to add logging in our handler method but do not want to useconsole
or some global logger. We would like to access thethis.logger
property configured on initialization of the base class. We do not override constructor function and would prefer not for this a hack around the logger initialization.The text was updated successfully, but these errors were encountered: