Zappa VS gunicorn

If people aren't familiar, there's a similar project for Python that's fantastic: https://github.com/zappa/Zappa

Chalice was a consequence, a reaction from AWS to the release of (Zappa Framework)[https://github.com/zappa/Zappa] that provide a very good alternative to migrate very quickly a Django/Flask or any WSGI compliant solution in Python.

Use Zappa https://github.com/zappa/Zappa and host as a Lambda, simple setup and deployment, Lambda only costs when processing requests, no servers to mess around with

One of my favorite options that is probably the most cost-effective is to deploy using a 'severless' model on AWS Lambda using zappa which supports deploying Python webapps to AWS in this way. Zappa also makes it super easy to deploy in just a couple commands! The README includes instructions for everything you might need, including handling sensitive information like your database passwords, running django management commands, setting up DNS, etc.

Deployment works nicely with Docker. I often use AWS AppRunner because it's really easy and just scales. Some people use AWS Lambda with Zappa but I don't recommend it unless you really want to spend less than $15 a month. You will probably need Django Storages to save uploads to an S3 bucket. At some stage you might want to put a CloudFront distribution in front of everything but the configuration of the caching behaviour might be a bit confusing when you do it the first time.

It doesn't have to be an either-or! I have several apps in production that were developed on Django or Flask, and deployed to Lambda using Zappa.

If you need a relational DB, you can use AWS Aurora or RDS and use cloud functions ('lambda' in AWS) that you can invoke with HTTP to process the document first. Zappa will do a lot of the configuration for you if you go that route.

Lambda + API gateway, this library bundles a Django application into a lambda https://github.com/zappa/Zappa . 1 million free invokes from aws, scale to zero, plugs into your RDS

I use Zappa, it just schedules a frequent execution of the lambda: https://github.com/zappa/Zappa#keeping-the-server-warm

I'm hoping so – gunicorn has a long-open pull request that would fix `--reuse-port`, which currently does nothing

https://github.com/benoitc/gunicorn/pull/2938

However, I'm curious about the best way to deploy, specifically with regard to WSGI. I've tried using the raw eventlet WSGI server (`eventlet.wsgi.server(eventlet.listen(("", 8000)), application)`). I then start it with `python manage.py runserver`. This has worked okay, but I'm unsure about how scalable it is. It seems like the standard stack is Django + Gunicorn + NGINX. Based on `python-socketio` documentation, this should be possible. I tried django + eventlet + gunicorn, but it seems like gunicorn a) [doesn't play nice with eventlet](https://github.com/benoitc/gunicorn/pull/2581) and b) only supports one worker. Gevent + Gunicorn doesn't have this bug, but still only supports one worker. Also, I'm not sure how actively maintained gevent is. So I'm not sure how scalable either Gunicorn + eventlet or Gunicorn + geventlet is as a WSGI server. So I'm not sure if Gunicorn is my best bet, or if it's too limited.

For building your API, I recommend using the Flask library. It is very beginner-friendly, and you will be able to build a simple API in a matter of minutes! Keep in mind that, for a more serious project, you should definitely use something like gunicorn to run you API as a production server.

Interesting looks like it might actually be a python bug. Somehow just changing from sys.exit(0) -> os._exit(0) apparently fixes it.

https://github.com/benoitc/gunicorn/pull/2820

The cool thing is that you can easily migrate your WSGI- application such as Flask, Django, or Gunicorn to AWS.

Yeah, that's kind of the impression I was getting. I stumbled across a github issue for gunicorn along these lines.

Taking a glimpse at gunicorn's code it looks like they pretty much all do the same: 2. seems to be creating a wsgi app using django's internals, and 3. uses 2.