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.

Sign up for GitHub

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

Jump to bottom

Improved pipeline handling #296

Merged
merged 7 commits into from
Jan 13, 2020
Merged

Improved pipeline handling #296

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
30c100f
Update index.js to better handle pipelines
markvp Jan 10, 2020
971454d
Update README.md
markvp Jan 10, 2020
ba7b048
Fix typos and linting
markvp Jan 10, 2020
17e59b3
Fix kind: pipeline
markvp Jan 10, 2020
84a5a65
Update readme again
markvp Jan 12, 2020
ff57092
Update readme again
markvp Jan 12, 2020
1c76301
Revert before/after vtl name change
markvp Jan 12, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,10 +123,12 @@ custom:
mappingTemplatesLocation: # defaults to mapping-templates
mappingTemplates:
- dataSource: # data source name
type: # type name in schema (e.g. Query, Mutation, Subscription)
type: # type name in schema (e.g. Query, Mutation, Subscription, PIPELINE)
Copy link
Collaborator

Choose a reason for hiding this comment

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

@markvp type does not take PIPELINE as a value, it's under kind.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oops. fixed.

field: getUserInfo
request: # request mapping template name
response: # response mapping template name
functions: # array of functions if type === 'PIPELINE'
- # function name
request: # request mapping template name | defaults to {field}.{type}.{pipeline ? before : request}.vtl
response: # response mapping template name | defaults to {field}.{type}.{pipeline ? after : response}.vtl
# When caching is enaled with `PER_RESOLVER_CACHING`,
# the caching options of the resolver.
# Disabled by default.
Expand All @@ -143,6 +145,11 @@ custom:
ttl: 1000 # override the ttl for this resolver. (default comes from global config)

- ${file({fileLocation}.yml)} # link to a file with arrays of mapping templates
functionConfigurations:
- name: # function name
dataSource: # data source name
request: # request mapping template name | defaults to {name}.request.vtl
response: # reponse mapping template name | defaults to {name}.response.vtl
dataSources:
- type: AMAZON_DYNAMODB
name: # data source name
Expand Down
10 changes: 6 additions & 4 deletions src/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -825,11 +825,11 @@ class ServerlessAppsyncPlugin {
return flattenedFunctionConfigurationResources.reduce((acc, tpl) => {
const reqTemplPath = path.join(
functionConfigLocation,
tpl.request || `${tpl.type}.${tpl.field}.request.vtl`,
tpl.request || `${tpl.name}.request.vtl`,
);
const respTemplPath = path.join(
functionConfigLocation,
tpl.response || `${tpl.type}.${tpl.field}.response.vtl`,
tpl.response || `${tpl.name}.response.vtl`,
Copy link
Collaborator

Choose a reason for hiding this comment

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

@markvp I understand you point.
Thinking about this now, I guess that the previous implementation did not really make sense
However, this should still be considered a breaking change.
Can we add backward compatibility?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Given that functions don't have a type or a field, I'm not sure how anyone could have used this functionality in the past? I certainly couldn't get it to work.
Given that, I don't really see this is a breaking change as much as it is a fix of unusable code (no offence!)

Copy link
Collaborator

Choose a reason for hiding this comment

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

@markvp After giving it a second thought and having a deeper analysis on this, I think you are right.
I got that those fields are indeed not present in pipeline definitions, but I thought that someone might have used them anyway (as a hack) in order to auto-generate the filename. But I realize that it would make no sense, since you could just place the filename directly instead.

I'll accept this change 👍

);
const requestTemplate = fs.readFileSync(reqTemplPath, 'utf8');
const responseTemplate = fs.readFileSync(respTemplPath, 'utf8');
Expand Down Expand Up @@ -872,8 +872,10 @@ class ServerlessAppsyncPlugin {
const flattenedMappingTemplates = config.mappingTemplates
.reduce((accumulator, currentValue) => accumulator.concat(currentValue), []);
return flattenedMappingTemplates.reduce((acc, tpl) => {
const reqTemplPath = path.join(config.mappingTemplatesLocation, tpl.request || `${tpl.type}.${tpl.field}.request.vtl`);
const respTemplPath = path.join(config.mappingTemplatesLocation, tpl.response || `${tpl.type}.${tpl.field}.response.vtl`);
const reqSuffix = tpl.kind === 'PIPELINE' ? 'before' : 'request';
const respSuffix = tpl.kind === 'PIPELINE' ? 'after' : 'response';
const reqTemplPath = path.join(config.mappingTemplatesLocation, tpl.request || `${tpl.type}.${tpl.field}.${reqSuffix}.vtl`);
const respTemplPath = path.join(config.mappingTemplatesLocation, tpl.response || `${tpl.type}.${tpl.field}.${respSuffix}.vtl`);
Copy link
Collaborator

Choose a reason for hiding this comment

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

@markvp This however is a breaking change.
People probably already rely on the fact that their before/after mapping templates are called request/response.

I see no problem in adding support for .before/.after suffixes but we must keep backward compatibility with request/response.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm. I understand the desire for backwards compatibility. Not sure the best way to implement that. Perhaps checking for file existence first?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@markvp 🤔 Well, in CloudFormations (and in this plugin), even if in the doc they refer to it as before and after, the fields that hold these template paths are still called request and response.
So I think the right thing to do is to avoid complexity (and confusion) and stick to that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok. removed before/after update for now

const requestTemplate = fs.readFileSync(reqTemplPath, 'utf8');
const responseTemplate = fs.readFileSync(respTemplPath, 'utf8');

Expand Down