jordic

Google is no longer interested in returning good search results, their priority are ads. (Good results are on ads)

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.

Perhaps we need an expert on design history. Typefaces are a complex thing with lot's of design decisions behind.

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.

This is one of the firsts principes of critical thinking: it's not only about understanding something, it's about being ready to challange it.

We do something like this, also we took some inspiration from hashura. Asyncpg it's so fast an ergonomic.

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 ;)

Also it'so easy to start making new components dependent on the store, and ending with reusability.

I'm more used to preact, it's small it's fast, and it's near the DOM. Last, with preact/htm it doesn't need any tooling :)

Cool! Thinking so many times in something like this, but sql it's not easy composable...

Our front service it's a nextjs/nodejs project. But I still prefer python :) and our API's are python based, typed async python.. but python..

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...

On one project we use Databases, with a custom opensourced "adapter" for sqlalchemy models: https://github.com/vinissimus/asyncom

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

Latest opensourced thing, it's a work queue based on plgsql, with asyncpg bindings. (https://github.com/vinissimus/jobs/).

So, we can say, we use asynpg in all possible forms.

For example: https://discuss.tryton.org/t/wsgi-server-choice/2766 https://mail.zope.org/pipermail/zodb-dev/2010-December/01389... https://docs.rhodecode.com/RhodeCode-Enterprise/admin/tuning... https://github.com/benoitc/gunicorn/issues/1045

We are also using starlette and works quite well.. in combination with asyncpg..

The thing is that you can serve a lot of requests on a single core.. (and at least us we pay per core)

In our use case, from 12 cores to 2 :) (mostly for ha)

With async Django views we can use Django with asyncpg... o_o but middlewares are still synch...

Python context managers are a great way to prevent this type of issues. Anyway feels like a bit strange to not use the current connection (from between the transaction) to query things. Perhaps the problem is between the API, because it's not explicit the borrow/leave of connections from the pool.

I would also add to the article, that when you try to alter a busy table add it a timeout (otherwise you will lock the world). SET statement_timeout = 50; Alter .... ;

Agree, at least for me, I don't discovered the sqlsuperpowers till I got inside it... I would love to see some of this pretty clever orm migrations applied on a busy potgresql server.. with a bit of concurrency... :)

May Django work with multiple tenants on different postgresql schemas? Can Django migrations handle this in an easy way (better than sql).. When projects grow old (+10years), things trend to complicate (lot of hands, lot of changed requirements.. ), and that's when the advices on the article had a lot of sense.. on the end data is there and the model is the database..

Does still django lacks a connection pooling? If I'm not wrong sometime ago I saw people using the sqlalchemy pool on Django projects.

That's a nice feature, when landed it?

Then you still need to upgrade Django.. (had seen so many sprint points spent on it.. :/)

Haha, dB = database. My android keyboard is trolling me :/