-
-
Notifications
You must be signed in to change notification settings - Fork 211
feat!: Updates to support websocket API Gateway #54
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!: Updates to support websocket API Gateway #54
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.
Looks pretty good, just minor comments to be consistent in examples.
Not sure if this affects #46 at all. That PR had a working example of a websockets API. I can update if needed. |
@lllama Thanks for the WebSocket example in #46! I think it will be great if @bryantbiggs merges your example into this PR and update it to follow the rest of the examples we have. |
…way-v2 into chore/updates-for-websocket-support
Co-authored-by: Anton Babenko <[email protected]>
cacb480
to
402fa78
Compare
402fa78
to
0b888d9
Compare
f3bb532
to
a57c321
Compare
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.
Looks almost perfect. Could you also describe breaking changes and upgrade path in UPGRADE.md as we do in other modules already?
…ws-apigateway-v2 into chore/updates-for-websocket-support
…way-v2 into chore/updates-for-websocket-support
Can We merge this pull request? |
Its being worked on, its currently in draft mode |
b35afe7
to
781949b
Compare
781949b
to
1690b9c
Compare
@antonbabenko Can you please review the pull request? |
Yes, as soon as I can. Probably, tomorrow. |
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.
Looks good, a few comments here and there. I didn't run examples though.
Co-authored-by: Anton Babenko <[email protected]>
Co-authored-by: Anton Babenko <[email protected]>
182d16c
to
d6e694c
Compare
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 ran it on my real project and found a few minor things here and there. LGTM after that :)
examples/complete-http/outputs.tf
Outdated
value = module.lambda_function.lambda_function_arn | ||
output "test_curl_command" { | ||
description = "Curl command to test API endpoint using mTLS" | ||
value = "curl --key ./my-key.key --cert ./my-cert.pem https://customer1.${replace(var.domain_name, "*.", "")} | jq" |
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.
Maybe this can be used instead of external curl - https://registry.terraform.io/providers/hashicorp/http/latest/docs/data-sources/http ?
This data source supports ca_cert_pem
, but not key
. It may be enough for this case.
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 was unable to get that data source to work without the key. This isn't required to run the example, but rather a helpful reminder of the syntax to call the API using the cert/key - and curl
/jq
are usually quite common on machines these days
examples/complete-http/variables.tf
Outdated
variable "domain_name" { | ||
description = "Custom domain name to use on API Gateway endpoint" | ||
type = string | ||
default = "*.terraform-aws-modules.modules.tf" |
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.
default = "*.terraform-aws-modules.modules.tf" | |
default = "terraform-aws-modules.modules.tf" |
Can we have it without a wildcard in the default_name
? The description does not match the value :)
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.
Reverted in 6154fc6
I also added a small section that demonstrates the use of wildcard custom domains and mapping subdomains to that wildcard domain in the readme
value = try(aws_apigatewayv2_stage.default[0].invoke_url, "") | ||
} | ||
|
||
output "default_apigatewayv2_stage_domain_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.
Please revert this output. Such a striped domain name is needed for Cloudfront.
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.
re-added in 6154fc6
variables.tf
Outdated
data_trace_enabled = optional(bool, false) | ||
detailed_metrics_enabled = optional(bool, false) | ||
logging_level = optional(string) | ||
throttling_burst_limit = optional(number, 500) |
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.
These throttling_burst_limit
and throttling_rate_limit
defaults are being used instead of the one specified in stage_default_route_settings
.
I think we should not have these defaults here and just use the settings in stage_default_route_settings
. 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.
yes, I would normally agree and normally not like to have to set arbitrary numbers either as a default value. However, when testing I kept getting errors only to discover that things were set to 0, and there are various upstream issues both in Terraform and other projects:
- [Bug]: Empty aws_apigatewayv2_stage.default_route_settings.throttling_burst_limit results in 0, not "not configured" hashicorp/terraform-provider-aws#27674
- [Bug]: Removal of the Default route throttling for an API GatewayV2 sets the limits to 0 hashicorp/terraform-provider-aws#30373
so its really a matter of - do we set nothing, and its up to users to set something if they get 429s due to a limit of 0, or do we set something so it works out of the box, but there is a cap that again would require users to set a value that suits their use case? I am ok either way, I don't know what the right way is - either set something (across the board) or set nothing (null
- again, across the board)
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.
Thanks for pointing out the issues. I've encountered this problem in the past, but I didn't realize the reason.
Can we not have a default number here (null
) but then use coalesce()
in the code to get the provided value (if specified) or the value from stage_default_route_settings
? This way, it will be closer to the expected behavior.
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.
good point - updated to coalesce these with the stage default route settings and removed defaults from the route section of the variable in 6154fc6
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.
Awesome! Thank you for taking into account all my comments. I am active user of this module myself :)
This PR is included in version 5.0.0 🎉 |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Description
Additional changes
v5.37.0
to support recent bug fixes in the providerapi_key_selection_expression
,route_selection_expression
variables set tonull
(still matches prior value v4.x version but is set asnull
now)routes
(wasintegrations
) has been updated and now uses optional inputsAdded
Modified
stage_access_log_settings
variablethrottling_burst_limit
andthrottling_rate_limit
respectively to ensure users do not face errors when deploying APIs for the first time and not configuring these"/aws/apigateway/${var.name}/${var.stage_name}"
) and retention period (30
) have been provided for the stage access logs log groupRemoved
See UPGRADE-5.0.md for full list of changes and notes on upgrade path
Motivation and Context
Closes #7
Closes #8
Closes #42
Closes #46
Closes #61
Breaking Changes
How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request