Я поделил бы это на несколько сервисов и сделал бы такой стек.
1. Backend API - отвечает за основную CRUD логику находится позади всех. За одно является хранилищем сообщений.
2. Live chat service - отвечает за "живой" чат по websocket-у или ещё каким нибудь протоколам.
3. Client frontend

Когда пользователь заходит на сайт клиент подключает его к чат сервису. В ответ на что сервис возвращает ему последние N сообщений. На начальном этапе сервис может брать историю напрямую из API. Но в будущем конечно лучше прикрутить какое нибудь inmemory кэш хранилище.

Когда пользователь отправляет сообщение, сервис делает запрос в API для сохранения его в базе. После чего пересылает сообщение дальше подключённым пользователям. (запрос в API и пересылка сообщения пользователям может быть ассинхронной).

Ну и конечно из-за того что это отдельные сервисы не будет какой-то жесткой привязке к какому нибудь языку или фреймворку. Так как твой backend api абстрагирован от чата, тебе не придется ничего в нем менять.

Никто случаем не натыкался на неплохие статьи об отличиях await от yield from? Псевдо имплементация с подробным описанием или похожее. По yield from материала много, а вот по await нашёл <<

Неизвестные особенности модуля operator Python

Модуль operator включает в себя арифметические и бинарные операции, которые на первый взгляд не представляют ничего интересного. Но при правильном их использовании, вы можете удивиться возможностям этого модуля.

Подробнее:

https://tprg.ru/W1dL

await это новый yield from, предназначенный для asyncio.

Я очень часто натыкаюсь что отличие «это дополнительная проверка бла бла бла» - хочу узнать в псевдореализации, не залезая на гитхаб исходников питона и шерстя их. Вопрос не стоит что такое await

А если на то пошло, могли бы уж и yeild from использовать для asyncio, но не стали же🤷🏼‍♂️(это придирка - не воспринимайте серьезно)

https://www.python.org/dev/peps/pep-0492/ может это

PEP380 и PEP492 читал, в PEP492 больше вырезками и о применении, в PEP380 затрагивается реализация yield from как раз псевдо кодом (и неплохо так описана), для 492 таковой не нашел

в разделе Rationale and Goals как раз рассказывается зачем сделали переход

Неплохой и понятный докладик. Если скорость на 1.5 поставить вообще красота

https://www.youtube.com/watch?v=39XNklRQJI4

@sv_roman
разница в том, что в первом случае дополнительно вызывается  GET_AWAITABLE

Implements TOS = get_awaitable(TOS), where get_awaitable(o) returns o if o is a coroutine object or a generator object with the CO_ITERABLE_COROUTINE flag, or resolves o.await.

Даже докладчики Питона - медленные 😁

Язык выбирают под характер)

да. Мы просто никуда не спешим (или успокаиваем себя таким образом)

​Чистый код в Python

Чистый код в Python — это не просто написанный с использованием сниппетов, пробелов и PEP8. Это множество нюансов, понимание которых приходит с опытом. Или с полезной статьёй, которая по полочкам раскладывает и объясняет все эти нюансы:

https://tprg.ru/PupL

7. Use solution domain names - весьма спорно

5. Keep your arguments at a minimum пример тоже приведён так себе ))) вместо функции засунули аргументы в конструктор и довольные :)
NamedTuple, dataclasses - видимо до их появления писали статью.

Удобно когда нужно Вимом поправить код. 💁🏻‍♂️