openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dragos Dascalita Haut <ddas...@adobe.com>
Subject Passing a context object to actions
Date Sat, 07 Jan 2017 01:04:07 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message