Hi,
These days I've been doing some work on creating an OpenWhisk action directly
from a GitHub repo - issue link [1] ; initial implementation [2] . After
successfully deploying a "hello-world" action - [3] I thought about updating
the message with some information from an OAuth token. I've used the API
Gateway to decorate the request with a "context" object. To achieve this I had
to merge the context with the actual event payload. I've posted the snippet of
the API Gateway code at [4] in a gist. Things are working fine and here is a
sample of a response from the action; note the "context" object which was added
by the API Gateway.
{
"payload": "Hello, 1FF62BDC53C3662B from branch-1 !",
"event": {
"context": {
"identity": {
"user_id": "1FF62BDC53C3662B",
"client_id": "demo_app",
"scope": "openid,avatar"
}
}
}
}
As a result of this experience I've learned a few things out of which the most
important one that I'd like to open a discussion here on the list is: the
mechanism to pass a context to an action.
At the moment the only way is to decorate the event with extra fields and I see
a few drawbacks to this approach:
* The fact that we need to unpack the request body and change it has an
impact on performance
* If we want to send binary payloads in a special format, the API Gateway or
some other process in the middle has to know how to decode/encode that
payload/Content-Type. So we're limited to what these intermediary processes
know.
The same thing happens with default action parameters; they get merged with the
event. Basically besides the event itself there's no other way to configure the
action with extra params or pass it a context.
I'd like to get your feedback to see if we're ok to enhance the existing
mechanism.
As an example, AWS Lambda allows a similar mechanism to pass a "context" to a
function. See [5]. Clients can provide a custom "clientContext" object .
Besides this object, the AWS API Gateway also adds its own fields into the
"context" object; see [6].
If we want, we could take a similar approach. The way it works in AWS is
through headers. For instance the "clientContext" is passed as a Base64
JSON-encoded header.
In OpenWhisk actions the main method signature would allow 2 params instead of
1 (as it is today) and it could look like:
function main(event, context)
The clientContext would be accessible as:
context.clientContext
And context.identity.* would be something reserved for the OpenWhisk API
Gateway to populate and it could also be based on special headers like
"X-GW-Identity".
What I like about this approach with Headers is that no intermediary process
needs to understand the body of the request; we could also support multiple
content types easier as well.
WDYT ?
Thanks,
dragos dascalita haut | project lead, software development | adobe cloud
platform
[1] - https://github.com/openwhisk/openwhisk/issues/1537
[2] - https://github.com/ddragosd/openwhisk-github-deployer
[3] -
https://github.com/ddragosd/openwhisk-hello-package/blob/branch-1/src/greeting.js
[4] -
https://gist.github.com/ddragosd/3afd5d8678e5dbda48b943a1125aad0c#file-zcloudfront-conf-L71-L93
[5] -
http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestSyntax
[6] -
http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference
