-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
add context variables and stage variables to API NG context #11111
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
Conversation
8ee5867
to
1216a74
Compare
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 22m 58s ⏱️ - 1h 14m 50s Results for commit 6a1308d. ± Comparison against base commit adc580c. This pull request removes 2517 tests.
♻️ This comment has been updated with latest results. |
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! I can see so much extra code and repeated functionality we will be able to remove by having the context variables built and maintained together like that!
The split in integration request already makes it very clear as to what is meant to happen and this clear display of the logic's order will help maintaining the service 🚀
Nice additions to the tests too 😉
class IntegrationRequest(TypedDict, total=False): | ||
http_method: Optional[HTTPMethod] | ||
"""HTTP Method of the incoming request""" | ||
uri: Optional[str] | ||
"""URI of the integration""" | ||
query_string_parameters: Optional[dict[str, str]] | ||
"""Query string parameters of the request""" | ||
headers: Optional[dict[str, str]] | ||
"""Headers of the request""" | ||
multi_value_query_string_parameters: Optional[dict[str, list[str]]] | ||
"""Multi value query string parameters of the request""" | ||
multi_value_headers: Optional[dict[str, list[str]]] | ||
"""Multi value headers of the request""" | ||
body: Optional[bytes] | ||
"""Body content of the request""" |
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.
Having that clear separation from the invocation request will be key in maintaining transparency over the requests.
requestTimeEpoch=int(now.timestamp() * 1000), | ||
stage=context.stage, | ||
) | ||
return context_variables |
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.
Should we log this dict immediately?
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.
Done! Good catch! We can revisit the overall logging later on when we have a clear picture, to make it a consistent experience, but for now simply logging it is really good. I believe we will also realize later on some values needs default values, maybe $context.identity
for example?
def update_context_variables_with_resource( | ||
context_variables: ContextVariables, resource: Resource | ||
): | ||
# TODO: log updating the context_variables? |
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 is fine to leave as a TODO, but I think it would really useful to log them in debug mode.
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.
Done 👍
# this is merged with the Context returned by the Authorizer, which can attach any property to this dict in string | ||
# format |
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 catch!
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 a lot for the review! 🙏 good comments about the logging, I've looked into #11114 and took the same format as you, it was very good 😄
requestTimeEpoch=int(now.timestamp() * 1000), | ||
stage=context.stage, | ||
) | ||
return context_variables |
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.
Done! Good catch! We can revisit the overall logging later on when we have a clear picture, to make it a consistent experience, but for now simply logging it is really good. I believe we will also realize later on some values needs default values, maybe $context.identity
for example?
def update_context_variables_with_resource( | ||
context_variables: ContextVariables, resource: Resource | ||
): | ||
# TODO: log updating the context_variables? |
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.
Done 👍
Motivation
We need a separate context, representing the
$context
variables used to render VTL templates, and which is also passed in the payload toAWS_PROXY
integrations.More informations about
$context
here.https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference
It is a bit of duplicated information from the original
RestApiInvocationContext
object and theInvocationRequest
, but they serve different purposes.If we need to update different contexts at the same time, then maybe we could simplify. But we learned that creating those context when needed, collecting informations from different sources, can be pretty hard.
The
InvocationRequest
goal is simply to represent the incoming request "as is", with no transformation.The idea would be to go from
InvocationRequest
, get theResource
. Use the originalInvocationRequest
, theResource
,theContextVariables
andStageVariables
to construct theIntegrationRequest
and send it down.The
InvocationRequest
will not be mutated. TheContextVariables
will be mutated and populated along the way of the different handlers.Changes
ContextVariables
and populate itLoggingContextVariables
which can add more data to the loggingIntegrationRequest
for future work in integration request handlerTODO
What's left to do: