Hacker News new | past | comments | ask | show | jobs | submit login

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.




If using NodeJS there is a very similar package to zappa called Serverless https://serverless.com/

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


Serverless Framework is also great for Python if you're not porting a WSGI application. Plug/Disclaimer: I'm the creator/maintainer of the defacto python dependency packaging plugin for serverless[0]

[0] https://github.com/UnitedIncome/serverless-python-requiremen...


+1 for serverless. Have also used it extensively for building python applications on AWS lambda.


I'm currently working on a project where -- in serverless.yml -- a single API gateway path for all HTTP methods leads to a Flask app... largely because this scheme seems much much easier and faster to test and develop locally.

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


I went for AWS SAM, but it's still lacking behind Serverless.


To me, the beautiful thing about this zappa approach is that I still follow the spec of a UWSGI-compliant app and I get the benefit of quick deployment to lambda without any form of vendor lock-in as it is also straightforward to plug the same app into, say nginx, without code change.


What is the group thought on running these containers that have access to (for example) a Postgres or Redis dB?

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.


The most obvious limitation is the scale out concurrency model of lambda (serial requests within a container). This is great for simplicity but means you can’t have a connection pool.

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


This sounds terrific, thanks for the tip!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: