I use acme as a personal wiki where I can store useful playbooks (executables from there). From sqls to kubectl commands. Just a big wiki with the unix at the mouse.
At my past job we have something like for newsletters and 250k/tasks per day was fine. The only design problem we have had is that if you keep past tasks on the queue table, when it grows it traches a lot cache due to index writes, so moving already finished jobs from the hot table had solved the issue.
Think on it like a middleware that wraps a transaction. It's fine, till you start consuming other Io based services (elastic/solar/...) And you find that this blocks one connection per request..
Synthetic event system + render decoupling. Preact uses the event system of the platform (browser) and only renders to it (there's no react native support).
Anyway we are using it at prod and allowed us to reduce our bundle sizes ;)
Someone should take care of it, but doesn't seem like a trivial problem.. btw, I also will be so happy to be able to reuse part of twisted core on asyncio services :)
I must say that python3.8 does a better job detecting not awaited awaitables.
Anyway,asyncio it's not new to python, the stdlib still has asyncore in it. There are still awesome web servers around (threaded) but using "asyncio" on the main thread. ZServer, medusa (look at what powers supervisor for example).
The file io thing it's still a pain, but same happens on node side.. but seems there is in the way something that will fix it.
Mostly agree around reusing existing libs, and being and split point on the community, but I also can't understand why so many detractors. It's a tool and does it's job quit well. Anyway, in my test I prefer explicit and don't like monkey patching :)
Nice one, but.. I prefer sqls that you can debug without rendering.. (it's not so manageable when you deal with ctes, window functions, joins different schemas, custom functions...
Our cms, is based on Guillotina (https://github.com/plone/guillotina) that uses a Datastore more or less equivalent to the Zodb, and plone, but internally uses postgresql and asyncpg. We are active contributors on it, and since latest version it works around asgi (uvicorn). We also have some plans to make it a bit more psqlidiomatic (get rid of pickles, ....)
On other internal services, we use the raw asyncpg.pool, mostly because part of our bussiness logic it's inside prostgresql, and this doesn't feet super well with an ORM. Think on a 15 year old sql schema, that had evolved through different hands, and right now it's multitenant xD