According to ASGI Documentation there are 3 ASGI Servers: Daphne, Hypercorn and Uvicorn.
From FastAPI's documentation to Deploy FastAPI without Docker we could use Uvicorn or Hypercorn.
But which ASGI Server works best with FastAPI in terms of performance and scalability? A comparison chart or pros and cons between the available ASGI Servers would be helpful!
Also for Serverless Deployment what else should I consider?
As per documentation, FastAPI is built on top of Starlette which itself is built on top of Uvicorn.
The performance difference between the ASGI servers is small and arguably is not important in the grand scheme of things (aka going from flask to fast).
So the suggestion would be to use Uvicorn since it is used by FastAPI under the hood.
@ArcLightSlavik My application needs to be deployed as FaaS on AWS Lambda. Previously I used Zappa for deploying flask application. I've found something similar for this purpose named Mangum and Serverless.
When my application is built with any of the mentioned framework above, the total size gets about ~500 MB! This raises an _error_ uploading to AWS Lambda (as AWS Lambda limits zip sizes to 50 MB). To solve this problem I used a property named slim_handler on Zappa. Setting this to true would just upload a small handler to Lambda and load actual project from S3 at runtime.
I couldn't find anything like this to do with Mangum or Serverless. Do you have any clue how to solve this problem?
@ShaonDey
I have no experience with lambda/running application this way so this will be pure speculation.
Zappa says including, but not limited to, WSGI web apps which means gunicorn should be supported. So you can continue using Zappa but change gunicorn to use the uvicorn worker. This is the recommended behaviour for uvicorn.
Will it work? probably but ¯\_(ツ)_/¯
@ShaonDey FYI https://github.com/Miserlou/Zappa/issues/2159
@ShaonDey you might find https://www.serverless.com/plugins/serverless-python-requirements helpful for dealing with the size limitations in AWS Lambda when deploying using Serverless.
This might solve the problem I was facing. Thank you for suggesting Serverless! @jordaneremieff
You should probably use Gunicorn for production. It's one of the mature Python application servers and offers a plethora of configuration options. Plus uvicorn provides a worker class for Gunicorn which can be used as follows:
gunicorn -k uvicorn.workers.UvicornWorker
@MwinyiMoha Currently I am running my FastAPI application with uvicorn as a worker under gunicorn. But this has a downside on the development.
Gunicorn 'Green Unicorn' is a Python WSGI HTTP Server for UNIX.
For this, either all developers are forced to work on a UNIX based environment (obviously which can not be imposed), or a custom logic has to be written in the codebase to run differently (with uvicorn only on non UNIX or gunicorn-uvicorn) depending on the environment. And guess what I had to go with the second option.
But there should be a rock-solid ASGI Server solving the standard deployment issues.
@ShaonDey, it is pretty understandable IMHO, it does not force you, because Windows is not designed that way, it has limitations and I think they do not think it is worth for their efforts.
For example, in Windows, you can use only 64 sockets in the asyncio's event loop. It is a limitation of the underlying select API call.
That means, since you can not use Gunicorn, also you won't be able to get the same performance in Windows with pure ASGI servers(Uvicorn, Hypercorn, etc.) when you compare it to the Unix environments.
You should probably use Gunicorn for production. It's one of the mature Python application servers and offers a plethora of configuration options. Plus uvicorn provides a worker class for Gunicorn which can be used as follows:
gunicorn -k uvicorn.workers.UvicornWorker
I Think his choice is to deploy with a async web server.
Most helpful comment
@ShaonDey, it is pretty understandable IMHO, it does not force you, because Windows is not designed that way, it has limitations and I think they do not think it is worth for their efforts.
For example, in Windows, you can use only 64 sockets in the asyncio's event loop. It is a limitation of the underlying select API call.
That means, since you can not use Gunicorn, also you won't be able to get the same performance in Windows with pure ASGI servers(Uvicorn, Hypercorn, etc.) when you compare it to the Unix environments.