-
Notifications
You must be signed in to change notification settings - Fork 4k
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
feat(appsync): import existing graphql api #9254
Conversation
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.
a great first attempt! thanks for getting this ball rolling.
I think we need to tighten up some of the APIs and their signatures.
would love to also see what @MrArnoldPalmer thinks
@@ -315,6 +372,8 @@ export class GraphQLApi extends Construct { | |||
public readonly arn: string; | |||
/** | |||
* the URL of the endpoint created by AppSync | |||
* | |||
* @attribute | |||
*/ | |||
public readonly graphQlUrl: string; |
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.
curious about the casing here (and everywhere really)... how does this translate to Python where we do snake casing?
does GraphQL
get broken down into graph_q_l
?
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.
yeah i think in this case would be best to change all of them to graphqlUrl for props
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 would be a breaking change tho so not sure if thats the best move for something so small..
@MrArnoldPalmer thoughts?
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'm not sure it needs to happen in this PR, but fixing the casing sounds like something we need to do regardless if it requires code that is not idiomatic for Python developers
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.
yeah i think a chore might be better
construct.addDependsOn(this.schema); | ||
return true; |
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.
do we need this method? it seems like it's substituting one API call (addDependsOn
) with another (addSchemaDependency
). any reason users can't just do it directly?
does it require validation? what's valid as a construct to add
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.
there needs to be a dependency add for resolvers and the schema, but i was not comfortable passing schema's around in imports so essentially i needed a way to allow for adding a dependency only if the api wasn't imported.
this basically was my workaround.. if anything i can make this function protected
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.
can we make it internal?
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.
actually, I've thought about this a little more and I think that it might be good to offer a public api to add a dependency.. if the graphql api is in another stack, it will be deployed before the imported stack so the dependency doesn't matter too much?
but in the case that it does we should have a public api to allow for adding dependencies? if not i dont see why a public api is a net bad
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 it enables use cases that users cannot achieve, then I agree.
this method calls construct.addDependsOn(schema)
and returns true. can users just make that api call instead?
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.
@shivlaks its just really annoying for users to have to do after creating each resolver.
The only reason its public as of right now is that I need IGraphQLApi
to have some capability to reference a schema, I can't make it protected or the function will be inaccessible to the Resolver class.
* @param description The description of the data source | ||
* @param table The DynamoDB table backing this data source [disable-awslint:ref-via-interface] | ||
*/ | ||
addDynamoDbDataSource( name: string, description: string, table: ITable ): DynamoDbDataSource; |
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.
it's consistent with the rest of the construct library and also compliant with design guidelines
Wow this PR got fat real quick :( To make reviewing easier, I will summarize and highlight important files: FILES ADDRESSED BY BREAKING CHANGES (not that important):
INTEG TESTS:
[NEW] UNIT TEST FILES (mostly the same test but across different data sources):
LOGIC (most important):
We are still discussing the topic of adding a dependency for resolvers to schema.
|
/** | ||
* The name of the data source | ||
* | ||
* @default - '<DataSourceType>CDKDefault' |
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.
perhaps rephrase toAutomatically generated name
and include an example.
I'm not super fond of the default part but I agree CDK should be in the default.
can multiple data sources be added with the same "friendly name" or will that complain? Can I just add 2 data sources of the same type with the defaults?
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.
No, i created a unit test to make sure of this. But essentially each resolver is a construct and a construct must have a unique name.
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.
change documentation to reflect breaking change
graphqlApiId: api.apiId, | ||
graphqlArn: api.arn, | ||
}); | ||
importedApi.addDynamoDbDataSource('TableDataSource', 'Table', table); |
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.
importedApi.addDynamoDbDataSource('TableDataSource', 'Table', table); | |
importedApi.addDynamoDbDataSource(table, 'tableId'); |
and change everywhere else
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.
great job working through all the feedback on this one!
I left a few other minor comments and added a do-not-merge
please ensure that @MrArnoldPalmer also gives his blessing before dropping the label.
/** | ||
* the ARN of the API | ||
*/ | ||
public abstract readonly arn: string; |
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.
did we want to give this a specific prefix before the arn
- since we're introducing this, let's make sure it aligns with how we define arn elsewhere
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 change this here i feel like we need to change it for every where else.. including the GraphQLAPI.. i think this breaking change should happen in another pr
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
[ISSUE]
Appsync missing
fromXxx
functionality, making multiple stack appsync interaction impossible.[Approach]
Created a base class for
GraphQLApi
and aIGraphQLApi
interface for imports. AddedfromXxxAttributes
functions to code base that can add dataSources.[Notes]
Only accessible props from
IGraphQLApi
areapiId
andarn
. Only accessible functions fromIGraphQLApi
are theaddXxxDataSource
functions.Added
props-physical-name:@aws-cdk/aws-appsync.GraphQLApiProps
as linter exception because the breaking change isn't worth the return of making the physical name (name exists already).Added
from-method:@aws-cdk/aws-appsync.GraphQLApi
as linter exception because afromGraphQLApiAttributes
function will turn intofrom_graph_q_l_api_attributes
in python.Fixes #6959
BREAKING CHANGE: appsync.addXxxDataSource
name
anddescription
props are now optional and in anDataSourceOptions
interface.name
anddescription
inaddXxxDataSource
have been moved into new propsoptions
of typeDataSourceOptions
DataSourceOptions.name
defaults to idDataSourceOptions.description
defaults to undefinedBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license