feat: add api id and amplify environment name to stash #2273
Conversation
🦋 Changeset detectedLatest commit: 8987f6e The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| * Pipeline resolver request handler | ||
| */ | ||
| export const request = (ctx) => { | ||
| ctx.stash.apiId = '${amplifyApi.apiId}'; |
There was a problem hiding this comment.
I'd normally recommend we namespace all amplify variables, as in:
amplifyAppsyncApiIdamplifyEnvironmentNameamplifyFooBar...
However! Since we already have an output name for API ID, I wonder if we should use that:
awsAppsyncApiId
For parallelism, that makes the other variable something like:
awsAmplifyEnvironmentName
Co-authored-by: Tim Schmelter <[email protected]>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Please make checks happy. |
| @@ -71,12 +78,15 @@ export const convertJsResolverDefinition = ( | |||
|
|
|||
| const resolverName = `Resolver_${resolver.typeName}_${resolver.fieldName}`; | |||
|
|
|||
| const amplifyEnvironmentName = | |||
| scope.node.tryGetContext('amplifyEnvironmentName') ?? 'NONE'; | |||
There was a problem hiding this comment.
This context var amplifyEnvironmentName looks like is set by data construct exclusively? Is this the branchName for CI/CD deployments and NONE for sandbox?
There was a problem hiding this comment.
Yes, this is this the branchName for CI/CD deployments and NONE for sandbox.
There was a problem hiding this comment.
than we are using the wrong naming here. amplifyEnvironmentName suggests amplify wide name for the environment which is not the case here. May I suggest amplifyApiEnvironmentName?
There was a problem hiding this comment.
The value is already used in the data construct. To use the new name without a breaking change we would need to set both variables, then it might be confusing why there are two variables with the same value. I think it is a better option to continue using the existing one.
There was a problem hiding this comment.
I'm not asking to change in the data construct but rather the new variables created in the backend-data to which this value is assigned. As well as the new variable set in the convert_js_resolvers.ts. It's not a branch name since it's applicable for sandboxes as well.
There was a problem hiding this comment.
Oh sorry, you mean const amplifyEnvironmentName not what is in context?
There was a problem hiding this comment.
yes, I understand context vars are harder to change, but we should not create more vars with this naming (such as amplifyBranchName)
| const amplifyApiEnvironmentName = | ||
| scope.node.tryGetContext('amplifyApiEnvironmentName') ?? 'NONE'; |
There was a problem hiding this comment.
I thought we didn't want to change the context parameter, is this intended?
There was a problem hiding this comment.
Oops, hasty find and replace.
Problem
Customers are not able to use DDB batch operations in custom JS resolvers. The customer needs the DDB table name to perform batch operations. The customer can construct the table name from the GraphQL API ID and the Amplify environment name (
<model-name>-<graphql-api-id>-<environment-name>).Issue number, if available: aws-amplify/amplify-category-api#408 (comment)
Changes
Add GraphQL API ID and the Amplify environment name to resolver context stash.
Corresponding docs PR, if applicable: aws-amplify/docs#8145
Validation
Checklist
run-e2elabel set.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.