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.

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

Merged
merged 22 commits into from Aug 15, 2020

Conversation

BryanPan342
Copy link
Contributor

@BryanPan342 BryanPan342 commented Jul 25, 2020

[ISSUE]
Appsync missing fromXxx functionality, making multiple stack appsync interaction impossible.

[Approach]
Created a base class for  GraphQLApi and a IGraphQLApi interface for imports. Added fromXxxAttributes functions to code base that can add dataSources.

[Notes]
Only accessible props from IGraphQLApi are apiId and arn. Only accessible functions from IGraphQLApi are the addXxxDataSource 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 a fromGraphQLApiAttributes function will turn into from_graph_q_l_api_attributes in python.

Fixes #6959

BREAKING CHANGE: appsync.addXxxDataSource name and description props are now optional and in an DataSourceOptions interface.

  • appsync: the props name and description in addXxxDataSource have been moved into new props options of type DataSourceOptions
  • appsync: DataSourceOptions.name defaults to id
  • appsync: DataSourceOptions.description defaults to undefined

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@BryanPan342 BryanPan342 added pr/do-not-merge This PR should not be merged at this time. @aws-cdk/aws-appsync Related to AWS AppSync labels Jul 25, 2020
@BryanPan342 BryanPan342 self-assigned this Jul 25, 2020
Copy link
Contributor

@shivlaks shivlaks left a 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

packages/@aws-cdk/aws-appsync/lib/graphqlapi-base.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-appsync/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-appsync/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-appsync/README.md Outdated Show resolved Hide resolved
@@ -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;
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor Author

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

packages/@aws-cdk/aws-appsync/lib/graphqlapi.ts Outdated Show resolved Hide resolved
Comment on lines +598 to +599
construct.addDependsOn(this.schema);
return true;
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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.

packages/@aws-cdk/aws-appsync/package.json Outdated Show resolved Hide resolved
@mergify mergify bot dismissed shivlaks’s stale review July 29, 2020 19:43

Pull request has been modified.

packages/@aws-cdk/aws-appsync/lib/graphqlapi-base.ts Outdated Show resolved Hide resolved
* @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;
Copy link
Contributor

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

@mergify mergify bot dismissed shivlaks’s stale review July 30, 2020 19:33

Pull request has been modified.

@BryanPan342 BryanPan342 added pr/breaking-change This PR is a breaking change. It needs to be modified to be allowed in the current major version. and removed pr/do-not-merge This PR should not be merged at this time. labels Jul 31, 2020
@BryanPan342
Copy link
Contributor Author

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.graphl-iam.expected.json
  • integ.graphl-iam.ts
  • integ.graphl.expected.json
  • integ.graphl.ts

INTEG TESTS:

  • integ.api-import.expected.json
  • integ.api-import.ts

[NEW] UNIT TEST FILES (mostly the same test but across different data sources):

  • appsync-dynamodb.test.ts
  • appsync-none.test.ts
  • appsync-http.test.ts
  • appsync-lambda.test.ts

LOGIC (most important):

  • [NEW] graphqlapi-base.ts: added an interface DataSourceOptions and changed implementation in base class to create defaults
  • graphqlapi.ts: unchanged
  • datasource.ts: unchanged
  • resolver.ts : unchanged

We are still discussing the topic of adding a dependency for resolvers to schema.

addSchemaDependency(construct: CfnResource): boolean;

@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Jul 31, 2020
@BryanPan342 BryanPan342 removed the contribution/core This is a PR that came from AWS. label Jul 31, 2020
packages/@aws-cdk/aws-appsync/lib/graphqlapi-base.ts Outdated Show resolved Hide resolved
/**
* The name of the data source
*
* @default - '<DataSourceType>CDKDefault'
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@mergify mergify bot dismissed shivlaks’s stale review August 3, 2020 16:38

Pull request has been modified.

Copy link
Contributor Author

@BryanPan342 BryanPan342 left a 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);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Suggested change
importedApi.addDynamoDbDataSource('TableDataSource', 'Table', table);
importedApi.addDynamoDbDataSource(table, 'tableId');

and change everywhere else

@shivlaks shivlaks added the pr/do-not-merge This PR should not be merged at this time. label Aug 5, 2020
shivlaks
shivlaks previously approved these changes Aug 5, 2020
Copy link
Contributor

@shivlaks shivlaks left a 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.

packages/@aws-cdk/aws-appsync/lib/graphqlapi-base.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-appsync/lib/graphqlapi-base.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/aws-appsync/lib/graphqlapi-base.ts Outdated Show resolved Hide resolved
/**
* the ARN of the API
*/
public abstract readonly arn: string;
Copy link
Contributor

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

Copy link
Contributor Author

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

@mergify mergify bot dismissed shivlaks’s stale review August 6, 2020 17:38

Pull request has been modified.

@BryanPan342 BryanPan342 changed the title feat(appsync): fromXxx functionality added to appsync feat(appsync): import existing graphql api Aug 14, 2020
@BryanPan342 BryanPan342 removed the pr/do-not-merge This PR should not be merged at this time. label Aug 14, 2020
@mergify
Copy link
Contributor

mergify bot commented Aug 14, 2020

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-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
  • Commit ID: 5a15cf0
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Aug 15, 2020

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).

@mergify mergify bot merged commit 5732b8e into aws:master Aug 15, 2020
@BryanPan342 BryanPan342 deleted the appsync-imports branch September 8, 2020 18:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-appsync Related to AWS AppSync pr/breaking-change This PR is a breaking change. It needs to be modified to be allowed in the current major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Access GraphQLApi from AppSync through ARN
3 participants