Support AWS Lambda Deployment

[bradshjg]

While it's not too difficult to wrap the app in https://github.com/slank/awsgi or similar for Lambda deployment, first-class support could be handy...especially docs/tooling (hopefully very thin tooling) to support deployment.

The API should be GitHubApp.lambda_handler(event, context) and should probably return the same (un-jsonify-ed) response.

• Should not break backwards compatibility
• Unmodified applications should be deployable, but this is a soft requirements
• Tooling should be able to package projects for AWS Lambda that employ a requirements.txt file with only pure-Python package. Anything beyond that gets messy very quickly.

Edit: Now I'm not sure if the api should be public...it doesn't really need to be 😕 ...ohhhh and I'm also completely ignoring secrets management. I don't want to have an opinion on it...but for non-sensitive apps a GUI walkthrough using Lambda env vars should be pretty straightforward. Folks can handle it however they want outside that.

[bradshjg]

Looking back on this I'm curious if a lot of the use cases for github apps have been subsumed by github actions. With current eyes I'm less inclined to specialize this codebase for Lambda deployment and more inclined to make it more generic and separate some of the flask-iness while keeping the spirit (namely easy event/action -> function with payload context and credentialed client). I'm curious if there might be value in a framework for action development. Really should look at some prior art first though :-)

Edit: GitHub has a good breakdown of actions vs. apps

I don't see the philosophy of this project being especially useful for github actions given good support for workflow templates. My original thought was that we could leverage some central "super-action" that defines a DSL for configuration kinda in the spirit of how wolox-ci attempts to create an opinionated layer on top of Jenkins. That's a whole other project though...but maybe one worth prototyping 🤓

[bradshjg]

This prior art is pretty fascinating https://github.com/probot/actions-adapter did this a year and a half ago :-)

[bradshjg]

Working in a Ruby port for a while I'm now thinking this could benefit from a "core" library that doesn't deal with any I/O or protocol concerns.

The idea is that http/wsgi leaks too far and we could support non-wsgi much easier if we created a clean separation. An "event" and "context" object could carry largely the same semantics as a request body and headers w/o coupling themselves too tightly to the implementation.

Per the "rule of three" of sorts, to make sure it's properly generic we could implement the service provider interface for WSGI, Lambda, and Azure Functions. Though I'm also very interested in an async Python implementation (not super well versed in it though).