TheMadBevah
commented
4 months ago Why choose GUnicorn:
- Good for 'serial' processing.
- Data processing and 'Blogs', is standard choice for both
- Stable and tested Why not GUnicorn:
- cant handle a lot of requests at once (eg. lets say 200k+) (not relevant for our use case)
- Not compatible with FastAPI (relevant if chosen in #5 )
Why Uvicorn:
- New ASGI (Asynchronous Server Gateway Interface)
- Makes Website more responsive
- can handle multiple requests at once (not an issue we will encounter in this project)
- Good for real-time chat use case (we only click button and generate, responsiveness not an issue overall)
- Compatible with FastAPI
- The modern approach to web design Why not Uvicorn:
- not as tested
- doesnt do well with mutliple worker processes
- is a development server (still usable in production, so not an issue like with Flask)
Why Guvicorn:
- Combines the positives of above - allows FastAPI integration
- Workers are handled by Gunicorn - fast, reliable
- ASGI handled with uvicorn Why not Guvicorn:
- Two 'Frameworks'
Waitress:
- Already tried to use it once, bad experience personally, skipped here.
uWSGI:
- Obviously too expansive for our use case - need a simple website, and a button.
- using this would be beyond overkill for the task at hand and also isnt the main focus of our project
Fazit: I am leaning towards just using guvicorn. Reliable, fast, makes sure failures are handled, allows ASGI (though unsure if used), Gonna have to see what works on Windows - can cause problems. Using Guvicorn allows use of FastAPI - also a fast way to get the Website up and running
close when done
GeroVanMi
Options:
Note: uWSGI is only to be used when you know why you're using it. I most likely don't.