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