add context variables and stage variables to API NG context #11111
Conversation
8ee5867
to
1216a74
Compare
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 23m 3s ⏱️ - 1h 14m 45s Results for commit f96581c. ± 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.
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.
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.
Should we log this dict immediately?
| def update_context_variables_with_resource( | ||
| context_variables: ContextVariables, resource: Resource | ||
| ): | ||
| # TODO: log updating the context_variables? |
There was a problem hiding this comment.
It is fine to leave as a TODO, but I think it would really useful to log them in debug mode.
| # this is merged with the Context returned by the Authorizer, which can attach any property to this dict in string | ||
| # format |
Motivation
We need a separate context, representing the
$contextvariables used to render VTL templates, and which is also passed in the payload toAWS_PROXYintegrations.More informations about
$contexthere.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
RestApiInvocationContextobject 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
InvocationRequestgoal 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,theContextVariablesandStageVariablesto construct theIntegrationRequestand send it down.The
InvocationRequestwill not be mutated. TheContextVariableswill be mutated and populated along the way of the different handlers.Changes
ContextVariablesand populate itLoggingContextVariableswhich can add more data to the loggingIntegrationRequestfor future work in integration request handlerTODO
What's left to do: