Add handler for lambda integration

[jvarho]

This fixes #137

Probably still requires some documentation at least. I'm also somewhat confused about the seemingly random use of u"strings", I just copied the other event mapping code so I have no idea if they are necessary or correct. I no longer have a working python 2 environment to test in.

This leaves all response mapping to the user. For example:

      response:
        headers:
          Content-Type: "'application/json'"
        template: '$input.path("$.body")'
        statusCodes:
          200:
            pattern: ''
          400:
            pattern: '.*"statusCode": ?400.*'
          500:
            pattern: '.*"statusCode":.*'

An alternative would be to do the simple thing by default, returning the body on 200 and raising RuntimeException("[code] body") otherwise. That would set the status codes automatically, but would not allow more advanced mapping per status code.

Anyway, either works for me. I've been using a version of this without response handling for async: true.

[codecov]

Codecov Report

Merging #167 (4441b91) into master (f8d5a92) will increase coverage by 0.03%.
The diff coverage is 100.00%.

❗ Current head 4441b91 differs from pull request most recent head ad1093f. Consider uploading reports for the commit ad1093f to get more accurate results

@@            Coverage Diff             @@
##           master     #167      +/-   ##
==========================================
+ Coverage   99.09%   99.13%   +0.03%     
==========================================
  Files           5        5              
  Lines         553      575      +22     
  Branches       69       69              
==========================================
+ Hits          548      570      +22     
  Misses          5        5              

Impacted Files	Coverage Δ
serverless_wsgi.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f8d5a92...ad1093f. Read the comment docs.

[a-nadig]

Hi @jvarho,
I cloned the code in your PR and ran the plugin locally by adding it to the .serverless_plugins directory as I really wanted to use this. I have a very straightforward async endpoint with a single path parameter, something like:

  foofunction:
    handler: wsgi_handler.handler
    timeout: 900
    maximumRetryAttempts: 1
    events:
      - http:
          method: any
          path: /foo/{id}/bar
          integration: aws
          async: true
          authorizer: aws_iam
          cors: true
          request:
            passThrough: WHEN_NO_MATCH
            parameters:
              paths:
                id: true

Now, when I deploy this, I get a 500 error from APIGW with the error "Execution failed due to configuration error: Unable to transform request". I'm just using the default request templates serverless provides and the header Content-Type: 'application/json'. Haven't really configured any responses of my own and using the default that got set up for now.

I know this is not related to your code since it's not even reaching the handler you've added but I was wondering if you've faced such an issue or similar because I just can't seem to figure it out. Any suggestions appreciated. Thanks!

Serverless Framework version: 2.34.0 (latest right now)

[jvarho]

@a-nadig I think the issue is passThrough + cors. If you are using json you can just leave passThrough undefined.But I'm not sure about cors, since OPTIONS and POST probably have different Content-Type.

However, there's actually a bug with my patch regarding path parameters. They are not passed through, instead only the parameter name is. I'll see if I can fix it.

[jvarho]

Fixing paths was quite easy. I also committed my test case, which I really should have shared initially: https://github.com/jvarho/wsgi-lambda-integration

[logandk]

I'll merge this for now, even though some docs would be nice. I don't have time to add it at the moment, but if anyone else does, please submit at PR and I'll merge it.

Regarding the u"" strings, it's a relic from when Lambda was on 2.7. Those days are long passed and we can get rid of Python 2.x support entirely.