-
Notifications
You must be signed in to change notification settings - Fork 77
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
refactor: allow JS resolvers with S3 assets #2890
Conversation
3a00ab9
to
1799b63
Compare
@@ -431,11 +477,19 @@ export class TransformerResolver implements TransformerResolverProvider { | |||
` | |||
: '$util.toJson($ctx.prev.result)'; | |||
|
|||
const initResolverMappingTemplate: FunctionRuntimeTemplate = isJsResolverFnRuntime(this.runtime) |
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.
This function implementation could benefit from splitting things out in a cleaner way. A part of me feels bad for tacking on more runtime specific conditional checks here. But a bigger part wanted to keep the scope of this (already large) PR to a minimum.
throw new Error('Runtime provided with codeMappingTemplate is not a JavaScript runtime'); | ||
} | ||
const codeTemplateLocation = codeMappingTemplate.bind(scope, api.assetProvider); | ||
return codeMappingTemplate.type === MappingTemplateType.INLINE |
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.
As far as I can tell, the instanceof InlineTemplate
check conducted for VTL resolvers below isn't a valid conditional for determining if a mapping template is inline or not. I'm not comfortable changing the behavior for VTL resolvers because I assume downstream things are depending on this behavior. But JS resolvers are a new concept here, so this is doing the "correct" check. Hence the discrepancy in conditionals between JS and VTL mapping templates.
dataSourceName?: string, | ||
pipelineConfig?: string[], | ||
scope?: Construct, | ||
runtime?: CfnFunctionConfiguration.AppSyncRuntimeProperty, |
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.
If we're disambiguating the runtime by introducing new runtime specific methods, do we still need this argument?
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.
Good call, thanks. I removed them from the TransformHostProvider
functions already, but missed them here. Addressed in 27f4ea1
@@ -187,6 +230,28 @@ export class DefaultTransformHost implements TransformHostProvider { | |||
pipelineConfig?: string[], | |||
scope?: Construct, | |||
runtime?: CfnFunctionConfiguration.AppSyncRuntimeProperty, |
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.
same here: should we let this method handle the runtime setting internally?
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.
Addressed in 27f4ea1
); | ||
}; | ||
|
||
public addResolver = ( |
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.
Should this be public, or would we prefer access to come in via one of the JS/VTL specific methods? (Future PR is fine if you agree there needs to be a change)
Important
No snapshots were harmed in the making of this PR.
No behavioral changes are included in this PR. This is prerequisite work to allow S3 asset JS resolver functions.
This is followup work to #2812.
Description of changes
Removes
addToSlot
from exportedTransformerResolverProvider
interface in favor ofaddVtlFunctionToSlot
andaddJsFunctionToSlot
(reference)Adds
S3MappingJSResolverFunctionCode
class for JS runtime specificS3MappingTemplateProvider
(reference)Adds
MappingTemplate.s3MappingFunctionCodeFromString
function to allow creation of (S3) asset based JS runtime resolver functions. (reference)Updates
TransformerResolver
constructor and internal functions to accept newFunctionRuntimeTemplate
type.Updates callsites in various transformers to new
addVtlFunctionToSlot
,addJsFunctionToSlot
functions See commits for individual changes made to each transformer.Updates conversation and generation transformers to use
JSRuntimeTemplate
.Note
I recommend conducting a very surface level review of the conversation and generation changes. This PR is a prerequisite to two follow up PRs (for conversation and generation respectively) that migrate to using S3 asset based resolver functions. The majority of the conversation and generation transformer specific changes in this PR are again changed in these subsequent PRs. This was done to isolate the changes in the PR as much as possible, while not breaking the conversation and generation transformers.
CDK / CloudFormation Parameters Changed
N/A
Issue #, if available
N/A
Description of how you validated changes
Checklist
yarn test
passesRelevant documentation is changed or added (and PR referenced)New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policiesAny CDK or CloudFormation parameter changes are called out explicitlyBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.