-
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
[GM-833] Update Apollo Graph Manager API Key environment variable #3923
Conversation
- Change ENGINE_API_KEY reference to APOLLO_KEY and add a deprecation message. - Export keys to be referenced through out packages
@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. |
There was a problem hiding this 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.
There was a problem hiding this 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
@@ -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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
These do not need to sendReportsImmediately because the reporting agent has support for handling shutdown signals to send off its final reports.
FYI @michael-watson I added some commits to your PR if you'd like to take a look :) |
There was a problem hiding this 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-core/src/__tests__/ApolloServerBase.test.ts
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 }) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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-server-core/src/__tests__/ApolloServerBase.test.ts
Outdated
Show resolved
Hide resolved
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.
FYI, this PR (presumably accidentally) changed the semantics of setting (My work in #4453 removes |
…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
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 toAPOLLO_KEY
and add a deprecation warning for the old value