gateway-js: adjust for Apollo Server de-'engine' renames #148
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 it will be possible to upgrade your server to the version of the gateway containing this change before you upgrade to the version of AS with apollographql/apollo-server#4453, actually getting this PR to build will require us to release |
27 tasks
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 11, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
34 tasks
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 11, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 11, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 14, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 15, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 18, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
glasser
added a commit
to apollographql/apollo-server
that referenced
this pull request
Sep 18, 2020
Currently, the `engine` option to `new ApolloServer` contains a mishmash of data
including the Apollo API key, the graph variant, configuration options for usage
reporting, configuration options for schema reporting, and more. Also, Engine is
no longer the name of the Apollo commercial product (the web app is now called
Studio).
This is the first PR in a series of PRs which will replace this `engine`
option. Future PRs will refactor `EngineReportingAgent` into a set of smaller
`ApolloServerPlugin`s.
This PR addresses the basic configuration: API key, graph ID, and graph
variant. It adds a new option called `apollo` to `new ApolloServer` of type
`ApolloConfigInput`, where you can specify the API key, graph ID, and graph
variant. It adds a second type `ApolloConfig`, which is similar except it also
contains the API key hash, and the graph variant here is always
defined ('current' by default). A single new internal determineApolloConfig
function is used to produce an `ApolloConfig` object at the top of the
ApolloServer constructor, consolidating a bunch of previously scattered code.
(This also consolidates some warnings. For example, we now consistently warn
when you create an ApolloServer and an API key is available but a variant is not
specified, instead of doing that in just ApolloGateway.)
It is an error to pass both `apollo` and `engine` to `new ApolloServer`. This
does mean that if you want to configure any of the other aspects of reporting,
you can not yet use the `apollo` option. I do not expect this PR to be released
until all of that configuration can be done via separate plugins as mentioned
above.
This `ApolloConfig` object is now passed to `ApolloServerPlugin`s in
`serverWillStart`, to `ApolloGateway` in `load`, and to the
`EngineReportingAgent` constructor. The former two still also receive `engine`
options for backwards compatibility. `ApolloGateway` will be updated to be able
to read both `apollo` and `engine` in
apollographql/federation#148
(Note that I've intentionally applied `prettier` to apollo-engine-reporting's
agent.ts, as that package's files have generally been kept prettier-clean. That
file will be deleted soon anyway.)
glasser
force-pushed
the
glasser/gateway-apollo-config
branch
3 times, most recently
from
b8847d6 to
f07a089
Compare
|
OK, now that the AS modules are published, this PR actually builds. Review away! |
apollographql/apollo-server#4453 removes the old product name "Engine" from the Apollo Server API. Most relevantly for the JS Gateway: - The package `apollo-engine-reporting-protobuf` (used in the gateway to build federated traces) is renamed to `apollo-reporting-protobuf`. - The `GraphQLService` interface implemented by `ApolloGateway` now passes configuration related to Apollo's hosted services in the `apollo` key instead of the `engine` key, and the values in that object change slightly too (`apiKeyHash` changes to `keyHash`, and `graphVariant` is always provided). Apollo Server continues to pass the old `engine` value as well for compatibility purposes. After this change, `ApolloGateway` can read its configuration from either key too. There is no constraint on the order in which you upgrade Apollo Server and Apollo Gateway, though it is still a good idea to upgrade them at the same time (eg, so you only are using one protobuf package). Also update a comment in federation-js, and upgrade the top-level `@types/node-fetch` dependency so that (after running `npm dedup`) there's no need for a `gateway-js/node_modules` directory.
glasser
force-pushed
the
glasser/gateway-apollo-config
branch
from
f07a089 to
2045018
Compare
abernix
approved these changes
Sep 24, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
apollographql/apollo-server#4453 removes the old product
name "Engine" from the Apollo Server API. Most relevantly for the JS Gateway:
The package
apollo-engine-reporting-protobuf(used in the gateway to buildfederated traces) is renamed to
apollo-reporting-protobuf.The
GraphQLServiceinterface implemented byApolloGatewaynow passesconfiguration related to Apollo's hosted services in the
apollokey instead ofthe
enginekey, and the values in that object change slightlytoo (
apiKeyHashchanges tokeyHash, andgraphVariantis alwaysprovided). Apollo Server continues to pass the old
enginevalue as well forcompatibility purposes. After this change,
ApolloGatewaycan read itsconfiguration from either key too.
There is no constraint on the order in which you upgrade Apollo Server and
Apollo Gateway, though it is still a good idea to upgrade them at the same
time (eg, so you only are using one protobuf package).
Also update a comment in federation-js, and upgrade the top-level
@types/node-fetchdependency so that (after runningnpm dedup) there's noneed for a
gateway-js/node_modulesdirectory.