-
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
Misleading error if you set APOLLO_KEY
to something that is not a service token
#4640
Comments
glasser
added a commit
that referenced
this issue
May 26, 2021
Apollo Server shouldn't need to have deep knowledge of Apollo Studio's data model. "ID and variant" are overly precise. This PR moves us towards a world where Apollo Server only needs to be aware of the "graph ref", a string like `id@variant` (but which might end up with other spellings later). We intend to remove the API key parser in Apollo Server 3 and stop providing `graphId`/`graphVariant` to plugins and the gateway, but these remain for now. This PR: - Allows you to specify the graph ref via `APOLLO_GRAPH_REF` or `apollo: {graphRef}`. It is an error to also specify ID or variant if you specify the ref. - Makes `graphRef` available to plugins and the gateway alongside `graphId` and `graphRef`. - If you specify an API key but it does not start with `service:` and you do not specify graph ref or graph ID, it throws an error. This fixes #4640. Note that while there are other legal Apollo key formats, Apollo Server only currently works with `service:*` keys. - Switches usage reporting and schema reporting to use new protocols that specify the graph ref instead of the variant, and to print Studio URLs that use the graph ref instead of the ID and variant separately. (The old protocols didn't specify the ID because it was implied by the API key.) - The schema reporter previously used Apollo Codegen without any documentation of how it worked. Set up graphql-code-generator instead and add an npm script to regenerate the types. Part of #5157.
glasser
added a commit
that referenced
this issue
May 26, 2021
Apollo Server shouldn't need to have deep knowledge of Apollo Studio's data model. "ID and variant" are overly precise. This PR moves us towards a world where Apollo Server only needs to be aware of the "graph ref", a string like `id@variant` (but which might end up with other spellings later). We intend to remove the API key parser in Apollo Server 3 and stop providing `graphId`/`graphVariant` to plugins and the gateway, but these remain for now. This PR: - Allows you to specify the graph ref via `APOLLO_GRAPH_REF` or `apollo: {graphRef}`. It is an error to also specify ID or variant if you specify the ref. - Makes `graphRef` available to plugins and the gateway alongside `graphId` and `graphRef`. - If you specify an API key but it does not start with `service:` and you do not specify graph ref or graph ID, it throws an error. This fixes #4640. Note that while there are other legal Apollo key formats, Apollo Server only currently works with `service:*` keys. - If you specify an API key but don't specify a graph ref or ID, prints a deprecation warning telling you to set a graph ref. - Switches usage reporting and schema reporting to use new protocols that specify the graph ref instead of the variant, and to print Studio URLs that use the graph ref instead of the ID and variant separately. (The old protocols didn't specify the ID because it was implied by the API key.) - The schema reporter previously used Apollo Codegen without any documentation of how it worked. Set up graphql-code-generator instead and add an npm script to regenerate the types. Part of #5157.
glasser
added a commit
that referenced
this issue
May 26, 2021
Apollo Server shouldn't need to have deep knowledge of Apollo Studio's data model. "ID and variant" are overly precise. This PR moves us towards a world where Apollo Server only needs to be aware of the "graph ref", a string like `id@variant` (but which might end up with other spellings later). We intend to remove the API key parser in Apollo Server 3 and stop providing `graphId`/`graphVariant` to plugins and the gateway, but these remain for now. This PR: - Allows you to specify the graph ref via `APOLLO_GRAPH_REF` or `apollo: {graphRef}`. It is an error to also specify ID or variant if you specify the ref. - Makes `graphRef` available to plugins and the gateway alongside `graphId` and `graphRef`. - If you specify an API key but it does not start with `service:` and you do not specify graph ref or graph ID, it throws an error. This fixes #4640. Note that while there are other legal Apollo key formats, Apollo Server only currently works with `service:*` keys. - If you specify an API key but don't specify a graph ref or ID, prints a deprecation warning telling you to set a graph ref. - Switches usage reporting and schema reporting to use new protocols that specify the graph ref instead of the variant, and to print Studio URLs that use the graph ref instead of the ID and variant separately. (The old protocols didn't specify the ID because it was implied by the API key.) - The schema reporter previously used Apollo Codegen without any documentation of how it worked. Set up graphql-code-generator instead and add an npm script to regenerate the types. Part of #5157.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
If you set
APOLLO_KEY
to something that does not start withservice:
(and don't explicitly setAPOLLO_GRAPH_ID
orapollo: {graphId}
), then the usage reporting plugin will be installed by default, but it will fail with the misleading errorThe fix is twofold:
That said, usage reporting doesn't actually work for anything other than graph (service) tokens (ie, user tokens are not supported for usage reporting, though they are for schema reporting), so if you're not setting a service token it's not going to work.
The text was updated successfully, but these errors were encountered: