-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
fix(appsync): strongly type expires
prop in apiKeyConfig
#9122
Conversation
Title does not follow the guidelines of Conventional Commits. Please adjust title before merge. |
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.
@eladb @MrArnoldPalmer This mainly involves your are ownerships, have a look as well?
@BryanPan342 Note that breaking changes should be specified with a |
} | ||
|
||
type Query { | ||
getTests: [ test! ] |
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.
How is this related to this change?
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.
just for the integrity test to see if the API Key works for query/mutation
typeName: 'Query', | ||
fieldName: 'getTests', | ||
requestMappingTemplate: MappingTemplate.dynamoDbScanTable(), | ||
responseMappingTemplate: MappingTemplate.dynamoDbResultList(), |
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.
How is this related to this change?
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 as the comment above
just for the integrity test to see if the API Key works for query/mutation
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.
@eladb o i see.. i just need to check if the apikey exist is that right?
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 think its important to test the connection else i can just remove the integ test all together
I was suggested to move the equivalent of If we add those functions to
wdyt? |
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.
Still feels like this PR includes two different changes: one is the introduction of the Expiration
class in core and using it in various places and the second is the change to the appsync library and the apikey tests.
/** | ||
* Expiration value as a string | ||
*/ | ||
public readonly value: 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.
Why is this needed? Seems like this the UTC representation of the date, which can be obtained from x.date.toUTCString()
, no?
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.
s3-deployments uses the value
property, I added the date
property myself, but I wouldn't mind just removing the date
property entirely.
* | ||
* @param s the string that represents date to expire at | ||
*/ | ||
public static fromString(s: string) { return new Expiration(s, new Date(s)); } |
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.
Why is this needed? Expiration.atDate(new Date(s))
is short enough, no?
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 existed in the s3-deployment version and I don't have the domain knowledge to know if this is something that should keep maybe @iliapolo knows more about this
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.
From a user's mental model, I think .date
makes much more sense then .value
. We can change s3-deployment
to use .date.toUTCString()
or whatever it needs.
@eladb would it be better if I separated this PR? |
Yes, I think it makes sense to separate. |
moved core and s3 changes to #10192
Move `Expires` class from s3-deployments to core. Rename to `Expiration` **BREAKING CHANGE**: s3-deployments property `expires` takes `cdk.Expiration` instead of `Expires` - **s3-deployments**: `BucketDeploymentProps.expires` now takes in type `cdk.Expiration` **Note**: PR separated from #9122 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@MrArnoldPalmer @shivlaks got #10192 approved! Would love it you guys could take a pass at this today. I dont think there is anything too controversial here. Maybe the integ test is unnecessary? |
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). |
fix(appsync): strongly type `expires` prop in apiKeyConfig (aws#9122)
[ISSUE]
apiKeyConfig
has propexpires
that has unclear documentation/not strongly typed and is prone to user errors.[APPROACH]
Force
expires
to takeExpiration
class fromcore
and will be able to output api key configurations easily throughExpiration
static functions:after(...)
,fromString(...)
,atDate(...)
,atTimeStamp(...)
.Fixes #8698
BREAKING CHANGE: force
apiKeyConfig
require a Expiration class instead of stringapiKeyConfig
takesExpiration
class instead ofstring
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license