Event payloads

[andrhamm]

The event argument received by my function when using the proxy plugin is not very similar to true Lambda/APIG events. It seems that currently this plugin is only useful for purely JSON API requests. It would be great if the event payload could more closely simulate a true event. It would also be handy if the logging was more specific about what "Payload" is (request vs response... and it is really only referring to the body for requests).

Examples:

Example func:

module.exports.test = function(event, context, callback) {
  console.log("event:");
  console.log(event);

  callback(null, {
    statusCode: 203,
    body: event,
    headers:{}
  });  
}

Logs for a proxy event:

INFO  2017-10-13T14:40:01.960Z RequestReceived: POST /?hostname=www.example.com&node-id=XXXX ID: 1507905587080
VERB  2017-10-13T14:40:01.960Z Payload:

INFO  2017-10-13T14:40:01.960Z Forwarding localhost:10000
event:
null
INFO  2017-10-13T14:40:01.963Z ResponseReceived ID: 1507905587080
VERB  2017-10-13T14:40:01.963Z Payload:
{
  "statusCode": 203,
  "body": null,
  "headers": {
    "Access-Control-Allow-Credentials": false,
    "Access-Control-Allow-Headers": "Content-Type"
  }
}

Real event (first arg of lambda func):

{ resource: '/',
  path: '/',
  httpMethod: 'POST',
  headers:
   { Accept: 'application/json',
     'CloudFront-Forwarded-Proto': 'https',
     'CloudFront-Is-Desktop-Viewer': 'true',
     'CloudFront-Is-Mobile-Viewer': 'false',
     'CloudFront-Is-SmartTV-Viewer': 'false',
     'CloudFront-Is-Tablet-Viewer': 'false',
     'CloudFront-Viewer-Country': 'US',
     Host: 'XXXXXXXXXX.execute-api.us-east-1.amazonaws.com',
     'User-Agent': 'Paw/3.1.4 (Macintosh; OS X/10.12.6) GCDHTTPRequest',
     Via: '1.1 YYYYYYYYYY.cloudfront.net (CloudFront)',
     'X-Amz-Cf-Id': 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==',
     'X-Amzn-Trace-Id': 'Root=1-XXXXXXXXXX-YYYYYYYYYYYYYYYYY',
     'X-Forwarded-For': 'XX.XXX.XXX.XXX, YY.YYY.YYY.YY',
     'X-Forwarded-Port': '443',
     'X-Forwarded-Proto': 'https' },
  queryStringParameters: { hostname: 'www.example.com' },
  pathParameters: null,
  stageVariables: null,
  requestContext:
   { path: '/dev/',
     accountId: 'WWWWWWWWWWWWWWW',
     resourceId: 'asdfgasdf',
     stage: 'dev',
     requestId: '39de4035-b023-11e7-8ca8-b1a11c3f0fb9',
     identity:
      { cognitoIdentityPoolId: null,
        accountId: null,
        cognitoIdentityId: null,
        caller: null,
        apiKey: '',
        sourceIp: 'XX.XXX.XXX.XXX',
        accessKey: null,
        cognitoAuthenticationType: null,
        cognitoAuthenticationProvider: null,
        userArn: null,
        userAgent: 'Paw/3.1.4 (Macintosh; OS X/10.12.6) GCDHTTPRequest',
        user: null },
     resourcePath: '/',
     httpMethod: 'POST',
     apiId: 'ZZZZZZZZZZZZZ' },
  body: null,
  isBase64Encoded: false }

[tommedema]

@andrhamm I think you're looking for something like https://github.com/localstack/localstack

[breathe]

Localstack looks interesting but extremely heavyweight to me.

I’ve been meaning to add a “deploy passthru lambda” capability to serverless-plugin-bespoken which might help with your use case. The idea being to deploy a “passthru” lambda that simply invokes the bespoken proxy with the same arguments as the aws lambda received. I think it will work for a variety of use cases pretty well. My motivation is faster development cycles and the ability to use a debugger ...

[breathe]

Hey @andrhamm

This pull request might be useful for you?

https://github.com/bespoken/serverless-plugin-bespoken/pull/8

It adds an option to the serverless deploy command that replaces the lambdas that would be deployed by your serverless config with passthru's that invoke the bespoken proxy. It works in conjunction with the serverless proxy command.

So you would run: serverless deploy --stage someStage --inject-passthru

To deploy the passthrus and then

serverless proxy --stage someStage to fire up a local server for handling the proxied requests on your machine. Means the 'event' arguments you receive aren't simulated but rather coming directly from whatever event source caused your lambda to be invoked on aws side.