Conversation
rix0rrr
left a comment
There was a problem hiding this comment.
Thanks, I love it!
I have one lingering concern on naming, but I'm also having a hard time coming up with something 😅
| authorizationConfig: {}, | ||
| name: 'myApi', | ||
| schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'myApi.graphql')), | ||
| apiSource: appsync.ApiSource.fromFile(path.join(__dirname, 'myApi.graphql')), |
There was a problem hiding this comment.
I know I came up with apiSource myself, but I'm not a 100% happy with it 😅 . Have you given any thought to alternatives? Is there a term that AppSync itself uses for that might apply here?
There was a problem hiding this comment.
Probably schema should be part of the name. Both GraphQL APIs and Merged APIs have a schema configuration in the AWS console:
- GraphQL API: Design your schema using GraphQL SDL, attach resolvers, and quickly deploy AWS resources.
- Merged API: Your Merged API’s schema is created from the schemas of your included Source APIs, and is read only. Changes to the schema must be initiated in your source APIs.
How about schemaSource or schemaDefinition?
@elthrasher @Lock128 After using the Merged API in our hackathon project: Do you have any feedback or ideas for a new name? We are looking for a better name than apiSource (see examples in the pull request).
There was a problem hiding this comment.
I like "definition". How about just definition?: Definition or apiDefinition?: ApiDefinition ?
There was a problem hiding this comment.
Let's call it definition. Other attributes like name don't use api as a prefix, so I'm fine with definition.
| /** | ||
| * Merging option used to associate the source API to the Merged API | ||
| * | ||
| * @default - Manual merge, requires the user to trigger schema merges manually. |
There was a problem hiding this comment.
Ooo, what does that mean?
Doesn't automatic sound like a better default?
There was a problem hiding this comment.
Developers must manually press the Merge Now button in the AWS console to merge changes from source APIs into the Merged API. This is the default behaviour in CloudFormation (see documentation) and when you manually create a Merged API in the AWS console.
However, I used the AUTO_MERGE merge type in my project. So it's fine for me if we change it default to AUTO_MERGE in CDK. Please let me know which default value we should use.
There was a problem hiding this comment.
Whatever default we choose should be friendly to CI/CD. If a merge cannot be triggered from CloudFormation, then I think automatic should be the default.
I'm impressed this service team actually built this feature! Let's use it!
There was a problem hiding this comment.
Okay, I changed the default to AUTO_MERGE.
| * @param filePath the file path of the schema file | ||
| * @returns API Source with schema from file | ||
| */ | ||
| public static fromFile(filePath: string): ApiSource { |
| this.validateAuthorizationProps(modes); | ||
|
|
||
| if ((props.schema !== undefined) === (props.apiSource !== undefined)) { | ||
| throw new Error('You cannot specify both properties schema and apiSource.'); |
There was a problem hiding this comment.
And you must do at least one (so, exactly one).
(props.schema !== undefined) === (props.apiSource !== undefined) will also be true if both are undefined.
There was a problem hiding this comment.
Done, another if-statement checks if schema or definition is set.
| * API source (schema file or source APIs) for this GraphQL Api | ||
| */ | ||
| public readonly schema: ISchema; | ||
| public readonly apiSource: ApiSource; |
There was a problem hiding this comment.
Let's make it easy on ourselves and make this private. I don't want to expose things on the public API unless absolutely necessary.
There was a problem hiding this comment.
Wouldn't that be a breaking change? Currently, I can access the schema of the construct, but later I cannot?
There was a problem hiding this comment.
schema will still be there, it just got moved.
(But it will throw if the API was not created from a schema)
There was a problem hiding this comment.
Should schema be deprecated? I deprecated it in this PR. That means, it will be removed in CDK v3.
The schema will then be inaccessible, which could be considered a breaking change (information is no longer available). However, I am not sure how this property is used by other developers.
There was a problem hiding this comment.
Thanks for letting me know, I had missed that.
Let's leave .schema as it is for now without deprecating. I'm also not quite sure what people would use it for; I'm inclined to think it's not necessary, but I also don't want to make too many assumptions.
|
Thank you for contributing! Your pull request will be updated from main 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 main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
@rix0rrr Thank you also for your help with this PR. 👍 |
| this.mergedApiExecutionRole = sourceApiOptions.mergedApiExecutionRole; | ||
| } else { | ||
| const sourceApiArns = sourceApiOptions.sourceApis?.map(sourceApiOption => { | ||
| return sourceApiOption.sourceApi.arn; |
There was a problem hiding this comment.
We also need this role to be able to access all top level fields like:
There was a problem hiding this comment.
Thanks for pointing this out. I will fix it next week. I'm on holiday at the moment.
There was a problem hiding this comment.
Hey, I am actually going to be in this code for an enhancement here so I can go ahead and submit these changes if you want?
|
I don't mean to necro this, but the deprecation comment when using What's next? I can't see myself having the time to make a PR for this change any time soon...an issue for documentation? Can someone else make a PR faster than me (probably)? |
|
Add support for AppSync Merged API feature.
At the moment, a GraphQL schema can be passed using the
schemaproperty. I deprecated this property because it is not used for merged APIs.Depecreated syntax:
Instead, I introduced a new property
apiSourcethat can be used to create a AppSync GraphQL API or Merged API.GraphQL API:
Merged API:
Closes #25960.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license