Skip to content
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

[GM-833] Update Apollo Graph Manager API Key environment variable #3923

Merged
merged 19 commits into from
Apr 23, 2020

Conversation

michael-watson
Copy link
Contributor

Since changing to Apollo Graph Manager, it is confusing to new users the reference to ENGINE_API_KEY. This PR is to change to the reference to APOLLO_KEY and add a deprecation warning for the old value

- Change ENGINE_API_KEY reference to APOLLO_KEY and add a deprecation message.
- Export keys to be referenced through out packages
@michael-watson
Copy link
Contributor Author

@abernix I wasn't sure how to add a test for checking the environment variables, so that might be something for us to add to this.

@zionts zionts changed the title Update Apollo Graph Manage API Key reference [GM-833] Update Apollo Graph Manager API Key reference Mar 28, 2020
@zionts zionts changed the title [GM-833] Update Apollo Graph Manager API Key reference [GM-833] Update Apollo Graph Manager API Key environment variable Mar 28, 2020
Copy link
Contributor

@zionts zionts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not to bike-shed toooooo much, but it does strike me as a bit odd that whether this is "turned on" or not is triggered by whether the API key is in the environment, and we are just trusting the caller to not use the API key in the environment to put it into the constructor options so that they will see the deprecation message & error handling will happen. In this case, it's actually fine, but we handle options?.engine?.apikey || process.env.APOLLO_KEY || process.env.ENGINE_API_KEY several times in this repo because of it.

Copy link
Member

@trevor-scheer trevor-scheer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to echo myself from @zionts PR: a couple simple tests that validate the new logs and throw errors would be great. Happy to pair on that with you!

PS: this needs a changelog entry

packages/apollo-engine-reporting/src/agent.ts Outdated Show resolved Hide resolved
packages/apollo-engine-reporting/src/agent.ts Outdated Show resolved Hide resolved
@@ -29,7 +30,7 @@ export class ApolloServer extends ApolloServerBase {
// another place, since the documentation becomes much more complicated when
// the constructor is not longer shared between all integration
constructor(options: Config) {
if (process.env.ENGINE_API_KEY || options.engine) {
if (process.env[keyEnvVar] || process.env[legacyKeyEnvVar] || options.engine) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zionts pointed out that we're doing this in a number of places. I have a suggestion. Let's export a function from apollo-server-env, something like getApiKeyFromEnv().

This fn can be responsible for:

  • Throwing when both exist
  • Notifying (once) that the user is depending on deprecated functionality
  • Caching values requested from process.env and returning them. Accessing these values isn't free, and we only need to do it once in a process's lifetime.
  • Returning a single apiKey, cleaning up much of the || logic we're seeing everywhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, so I followed a similar pattern to what I did here for engine.graphVariant, which is to throw it in an exported function from agent.ts in apollo-engine-reporting, which gateway relies upon. The challenge here is that it's important to have EngineReportingAgent be a class that can run on its own and perform its own validation, which means that we don't want to just calculate the "right" thing up above and pass it through. Additionally, the gateway and aer actually have different objects that they use in their construction, so there needs to be some calculation and conversion in order to satisfy the gateway.

All to say, I think having this be an exported function from aer so that aer can continue to remain a standalone package has benefits, and we can still export it and rely on it from other places, including in constructing the gateway object. That's what I've done here in response to this comment. Now we do call it twice in the case of a gateway, which would, theoretically, be a fairly simple fix, but I didn't prioritize doing so because of the added complexity that it causes and the unclear impact of the benefit (one deprecation message in your console instead of two and one more read of an environment variable at boot-up time)

Adam Zionts added 3 commits March 31, 2020 01:47
These do not need to sendReportsImmediately because the reporting agent
has support for handling shutdown signals to send off its final reports.
@zionts
Copy link
Contributor

zionts commented Mar 31, 2020

FYI @michael-watson I added some commits to your PR if you'd like to take a look :)

abernix
abernix previously requested changes Apr 2, 2020
Copy link
Member

@abernix abernix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for moving this work forward! I've left a number of comments throughout. Some are likely duplicative of [my review](https://github.com/apollographql/apollo-server/pull/3924#pullrequestreview-385965077] on #3924 since I reviewed them several hours apart but they have overlapping concern. 😉

packages/apollo-server-azure-functions/src/ApolloServer.ts Outdated Show resolved Hide resolved
packages/apollo-server-cloud-functions/src/ApolloServer.ts Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
packages/apollo-engine-reporting/src/agent.ts Outdated Show resolved Hide resolved
packages/apollo-server-cloud-functions/package.json Outdated Show resolved Hide resolved
packages/apollo-gateway/CHANGELOG.md Outdated Show resolved Hide resolved
@@ -45,6 +45,22 @@ export type GenerateClientInfo<TContext> = (
requestContext: GraphQLRequestContext<TContext>,
) => ClientInfo;

export function getEngineApiKey({engine, shouldWarnOnDeprecatedUsage = true}: { engine: EngineReportingOptions<any> | boolean | undefined, shouldWarnOnDeprecatedUsage?: boolean }) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reasoning behind not using a module-level variable as a toggle to determine whether the deprecation warning was already shown, rather than passing it in as an option? Seems we'd only want this warning applied exactly once across... anything that uses it?

My hunch might be that it's because of the need to use the correct logger, but that's unstated.

Copy link
Contributor

@zionts zionts Apr 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using a module-level var works here actually — I just generally abhor mutability, though I suppose in this case it cleans things up in quite the happy way. It does not work, actually, since some calls use the module function directly and some create a new instance of the class, which recreates module-level vars

packages/apollo-engine-reporting/src/agent.ts Outdated Show resolved Hide resolved
Adam Zionts and others added 7 commits April 13, 2020 09:55
Co-Authored-By: Jesse Rosenberger <git@jro.cc>
If both APOLLO_KEY and ENGINE_API_KEY are set, this will now warn and
prefer APOLLO_KEY, in accordance with changes to apollo-tooling. Imp
personally not very opinionated on this front, so happy to take
direction from the reviewer.
@abernix abernix self-assigned this Apr 20, 2020
@abernix abernix added this to the Release 2.13.0 milestone Apr 23, 2020
@abernix abernix merged commit fa42e36 into master Apr 23, 2020
@abernix abernix deleted the aw/2020-3/update-api-key branch April 23, 2020 15:03
abernix added a commit that referenced this pull request May 4, 2020
Also some word-smithing to align these similar concepts.

Follows-up: #3923
Follows-up: #3924
@glasser
Copy link
Member

glasser commented Sep 3, 2020

FYI, this PR (presumably accidentally) changed the semantics of setting engine: false but also setting one of the API key env vars: before this PR, that would disable usage reporting, but after this PR the engine: false is ignored.

(My work in #4453 removes engine: false and replaces it with more explicit things like ApolloServerPluginUsageReportingDisiabled() anyway.)

abernix pushed a commit to apollographql/federation that referenced this pull request Sep 4, 2020
…apollo-server#3923)

Co-authored-by: Adam Zionts <adam@meteor.com>
Co-authored-by: Adam Zionts <adam@apollographql.com>
Apollo-Orig-Commit-AS: apollographql/apollo-server@fa42e36
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants