Sanic: Make sanic WSGI compliant.

[rfyiamcool]

sanic not support gunicorn /uwsgi ?

[seemethere]

Going to be hijacking this issue,

Sanic needs to WSGI compliant to work with things like gunicorn / uwsgi.

To do this we need to look at the WSGI spec located here: https://docs.python.org/3/library/wsgiref.html

I'm going to target sanic being WSGI compliant not for the next milestone but probably for the 1.0.0 milestone.

[seemethere]

For those interested I'm going to be pushing work for this here:

https://github.com/seemethere/sanic/tree/wsgi_server

[tuukkamustonen]

I might be lost here but isn't ASGI spec intended to replace WSGI for async servers? Can sanic (or any async app) run in WSGI mode?

I thought you wouldn't need gunicorn/uwsgi or alike with sanic - just app.run()? Sanic (or python, rather) seems to even have its own listen queue.

What's the benefit of running sanic with gunicorn/uwsgi? Would you also recommend nginx then (or anything that handles/buffers slow clients)?

[GMLudo]

You don't need to support WSGI to use Gunicorn in multi-worker mode, aiohttp and API-Hour has implemented custom Gunicorn handlers for that.

[seemethere]

I personally think it'd be beneficial to have WSGI compliance in both the server and the application so that if you want to use a Flask application with the sanic server you can, if you want to use gunicorn with Sanic you can.

I don't think our users should be limited just because they wanted to use sanic's API to build their web-service. We should enable users to have their choice of server. In any case, this is just experimentation for now and if there is a big performance decrease WSGI support will be abandoned.

[zaibacu]

In my personal opinion, a web framework which cannot run on Gunicorn cannot be treated seriously. Running a web server (even very performant one) is one thing, but actually maintaining is another. If you want it to be more than a hobby-test project, you should consider implementing custom worker for Gunicorn

[frnkvieira]

@zaibacu I disagree with you. A synchronous framework which is not WSGI compliant cannot be treated seriously but an async framework is a whole new story. Although I have to admit that maintaining a HTTP server is no easy task, Gunicorn itself has less attention (and a hell lot of bugs too) than this framework (just check Github). Maybe being WSGI compliant (even as it sounds strange for a framework which supports asyncio) will make both worlds happy as long as performance stays the same. The solely reason why Sanic is being picked over Flask is the async support and performance. In both cases Gunicorn has nothing to do here and it does not even remove the needs of a real battle proven HTTP server in the front line as Nginx.

[seemethere]

Created a working example for this but I found that it slowed performance by a lot. Will revisit later if there's enough support for it but the benefits that I saw earlier aren't as big.

Will reopen if we do ever decide to revisit though.