plugins: Declare types rather than use in-line types for life-cycle hooks.#3902
Merged
Merged
Conversation
…ooks. This makes it easier to reason about the types and to keep things DRY, in addition to preserving a more real stacking of types as the stages of server life-cycles progress. E.g., `validationDidStart` will have a super-set of `Required` properties which were present in the `parsingDidStart` phase. Now, rather than actually repeating them verbosely, they will be intersected. These new explicit types will live in `apollo-server-types` where they can also be relied upon by `@apollo/gateway` and other packages, but they'll also be exported directly from the `apollo-server-plugin-base` package. Reason being: The overall concept of `apollo-server-types` and this `apollo-server-plugin-base` package is that they should NOT depend directly on "core", in order to avoid close coupling of plugin support and specific server versions. In other words, someone should be able to install a version of a plugin that depends on `apollo-server-plugin-base` in their application which uses a semver compatible plugin API but NOT the same semver range of `apollo-server-core`, though they are currently similar. They are duplicated concepts right now where one package is intended to be for public plugin exposure (`-plugin-base`), while the other (`-types`) is meant to be used internally. In the future, `apollo-server-types` and `apollo-server-plugin-base` will probably roll into the same "types" package, but that is not today!
They are defined at the same time, as noted in the referenced link. Ref: https://github.com/apollographql/apollo-server/blob/eadcc6b4/packages/apollo-server-core/src/requestPipeline.ts#L196-L197
trevor-scheer
approved these changes
Mar 20, 2020
abernix
added a commit
to apollographql/federation
that referenced
this pull request
Sep 4, 2020
…llographql/apollo-server#3902) * plugins: Declare types rather than use in-line types for life-cycle hooks. This makes it easier to reason about the types and to keep things DRY, in addition to preserving a more real stacking of types as the stages of server life-cycles progress. E.g., `validationDidStart` will have a super-set of `Required` properties which were present in the `parsingDidStart` phase. Now, rather than actually repeating them verbosely, they will be intersected. These new explicit types will live in `apollo-server-types` where they can also be relied upon by `@apollo/gateway` and other packages, but they'll also be exported directly from the `apollo-server-plugin-base` package. Reason being: The overall concept of `apollo-server-types` and this `apollo-server-plugin-base` package is that they should NOT depend directly on "core", in order to avoid close coupling of plugin support and specific server versions. In other words, someone should be able to install a version of a plugin that depends on `apollo-server-plugin-base` in their application which uses a semver compatible plugin API but NOT the same semver range of `apollo-server-core`, though they are currently similar. They are duplicated concepts right now where one package is intended to be for public plugin exposure (`-plugin-base`), while the other (`-types`) is meant to be used internally. In the future, `apollo-server-types` and `apollo-server-plugin-base` will probably roll into the same "types" package, but that is not today! * plugins: Same as `source`, `queryHash` is required at `parsingDidStart`. They are defined at the same time, as noted in the referenced link. Ref: https://github.com/apollographql/apollo-server/blob/eadcc6b4/packages/apollo-server-core/src/requestPipeline.ts#L196-L197 * Remove unnecessary casting. Per: https://github.com/apollographql/apollo-server/pull/3902/files#r395767682 Thanks to: d1b7a82 Apollo-Orig-Commit-AS: apollographql/apollo-server@7e09cf2
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
This makes it easier to reason about the types and to keep things DRY, in addition to preserving a more real stacking of types as the stages of server life-cycles progress. E.g.,
validationDidStartwill have a super-set ofRequiredproperties which were present in theparsingDidStartphase. Now, rather than actually repeating them verbosely, they will be intersected.These new explicit types will live in
apollo-server-typeswhere they can also be relied upon by@apollo/gatewayand other packages, but they'll also be exported directly from theapollo-server-plugin-basepackage. Reason being: The overall concept ofapollo-server-typesand thisapollo-server-plugin-basepackage is that they should NOT depend directly on "core", in order to avoid close coupling of plugin support and specificserver versions. In other words, someone should be able to install a version of a plugin that depends on
apollo-server-plugin-basein their application which uses a semver compatible plugin API but NOT the same semver range ofapollo-server-core, though they are currently similar.They are duplicated concepts right now where one package is intended to be for public plugin exposure (
-plugin-base), while the other (-types) is meant to be used internally. In the future,apollo-server-typesandapollo-server-plugin-basewill probably roll into the same "types" package, but that is not today!