It's a nice attempt, but it's barely a draft IMO.
But with respect to microframeworks, Sanic is getting pretty close to feature parity with Flask, only asynchronously. I'm not sure what kind of plugin architecture you're looking for, but you can do middleware with Sanic. Also custom protocols. Also decorators (e.g., for auth). And for namespacing, there are blueprints. I'm not sure what you mean by "conf hooks".
It does help with Sanic if you're already familiar with Flask. Sanic is very close to an async version of Flask.
For a task queue, you can run async tasks with Sanic alone using `app.add_task(some_async_function)`.
It's also simple to use apscheduler if you want a more full-feature async scheduler. Example:
from apscheduler.schedulers.asyncio import AsyncIOScheduler
from sanic import Sanic
app = Sanic()
async def tick():
print('Work!')
@app.listener('before_server_start')
async def initialize_scheduler(app, loop):
scheduler = AsyncIOScheduler({'event_loop': loop})
scheduler.add_job(tick, 'interval', seconds=1)
scheduler.start()
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8000, debug=True)
To answer your question as to "why WSGI?" the point is that if you write code that targets WSGI, no matter what you can put your Python code behind any WSGI compliant server. You wont be screwed because you picked a dying framework.
I would love to see this, BUT I don't think it's needed to compete with Node.js. Async is mostly interesting for networking, and you can get that now with Django Channels (https://channels.readthedocs.io/) or Pushpin (http://pushpin.org (disclosure: I'm the author)).
Yeah they rely on separate processes which is a bit of a dodge, but IMHO the separation is good architecture.
Currently to setup a Django website you usually need a wsgi server, and a font-end server like nginx, then maybe a task queue and now your django channel server. None of them being well integrated.
It's crazy. You should have one process that pops and manage the other ones, and allow them to integrate and communicate transparently, with not even a need for nginx/apache for small to medium websites.
You should not have to setup a task queue manually, a thread/process pool and the like. You should have a way to communicate real time between the client code, the tasks in your queues, endpoints in your servers and all your workers.
You should have synchronization primitives, a common configuration system (with live settings that propagates) and a clean way to build a hierarchy of components.
The closest I get is crossbar.io serving django + celery and some custom code to hook them using the WAMP protocol. It's very, very nice, but far away from the integration we should have for those things in 2017.
I have been starting to work on something (https://github.com/Tygs) but since it's a VERY hard problem, I struggle find continuity by working on it only here and there. This is something you need a few months full time to really dig deep. Especially since with async, the HTTP part is actually the easiest part. The hard part is to make it easily usable, configurable and debugable.
Maybe there is a kickstarter to build for this.
Being async and capable of dealing with http requests are only the very beginning of the story. With what async allows, we should be able of doing more. Way, way more.
[1] https://github.com/encode/apistar [2] https://github.com/encode/apistar#asyncio
What you are doing here is just "what sync frameworks do, but async". There is no use for that. I can already do it with WSGI frameworks. It works well. It's robust, proven and productive.
If you don't use async to provide novel features that only async enables, what's the point ?
Async allows to maintain low latency permanent connections between each clients, being it a web page, a task queue, a server worker, etc. We finally can have it all connected. We can broadcast setting changes, propagate cache invalidation, push action notifications, update task completions to subscribers, allow everybody to react to stuff on the file system or the db instead of polling, all in soft real time.
The potential is amazing.
We all can do HTTP req / resp. The question now is: how good the tooling around this cycle is.
Have you looked at the options there / if there would be an easy way to bolt on a more async driven framework? Obviously, it doesn't solve the missing framework issue, but maybe there's some clever tricks you can do because uwsgi is allowing you to bend the rules.
We need a django of the async world. We need something in Python to compete with nodejs, or even meteor, with async/await as primary tool. And maybe a aWSGI support.
But WSGI ? We have everything we need. They are proven tools. They work. Have great ecosystems and documentations. They do the job perfectly for non real time oriented web site. We don't need another one.