Alternately:
``` from flask import Flask app=Flask() @app.route(‘/‘) def hi(): return "Hi!” ```
$ pip install zappa
$ zappa init
$ zappa deploy
$ zappa certify
IAM, SSL, API Gateway, Lambda, all taken care of. We did the work so you don't have to.
``` from flask import Flask app=Flask() @app.route(‘/‘) def hi(): return "Hi!” ```
$ pip install zappa
$ zappa init
$ zappa deploy
$ zappa certify
IAM, SSL, API Gateway, Lambda, all taken care of. We did the work so you don't have to.
One thing I would improve with the authors article is he crammed a giant conditional statement on the http-method inside his one function. Serverless makes it easy to bundle a single function per HTTP method and even share common code between them. You can build out a whole application as a single npm package.
Bonuses include plugins for serverless that let you unit test your handlers, run a simulated APIG/Lambda/Dynamo environment locally for development, plugins that let you interact more deeply with AWS like assigning a custom domain to your APIG.
Example apps: https://github.com/serverless/examples
Are there any particular benefits to exporting and reimplementing all of that routing and organizational logic into instructions that "program" the API Gateway instead?
In this particular case, the API is solely for external consumption by a third party
[0] https://github.com/UnitedIncome/serverless-python-requiremen...
Sure Zappa, keeps the “container-function-thing” alive so you can cache it as a global variable, but this is a jacket approach that I’m not clear enough on the consequences to use.
Something like dynamo db is a better fit if it works for you, otherwise most people seem to be forced to run a few servers with pgbouncer