Работу с БД лучше проводить на беке, после сформированные данные отправлять клиенту

Я имею в виду я могу расчёты проводить непосредственно на стороне БД, а могу именно в питоне

Вопрос. К тем, кто пользовался channels. У меня приложение на Джанго рест и я хочу добавить одну точку входа через веб-сокет. Если я правильно понял channels под капотом оборачивает всю работу сервера. Как в этом случае с производительностью, не проседает на синхронной части?

Почему когда захожу под логином и паролем суперюзерв в админку на сайте мне выдаёт вот это?
Тип права на чтение только

Смотря какие расчеты. Но в целом обычно вычислять в базе быстрее

проверь БД, есть ли там доступ на write или она только для чтения

Каким образом проверить ?
На локалке все ок было

база sqlite ?

Да

Быстрее, но вопрос наверно ещё к сложности разработки, дебага, расширяемости. В общем, вероятнее всего это всё от случая зависит

проверь чтобы пользователь под которым работает веб сервер имел доступ на чтение к файлу

Дебажить не сложно если знаешь SQL и ориентируешься в orm. Зависит от случая все и всегда. Но если на базу легко переложить что-то, лучше переложить.

Оке, спасибо! Пожалуй так и сделаю

Хм , как можно это сделать?

ls -l

в папке с файлом

добрый. подскажите, редактор wagtail позволяет html код вставлять?

@valroi123 будет жить. Поприветствуем!

Привет. Всё зависит от архитектуры, которую вы будете использовать. Django (и DRF тоже) используют wsgi - интерфейс для синхронных приложений request-response. Django-channels в свою очередь использует asgi - интерфейс для асинхронных приложений, написанный специально для channels и также способный запускать синхронный код написанный под wsgi (т.е. в нашем случае Django).
Из-за этого появляются две возможные конфигурации: uwsgi-сервер + asgi-сервер, где первый будет обрабатывать все синхронные запросы (http), а второй все асинхронные запросы (ws). Или можно использовать только asgi-сервер, который будет обрабатывать и http и ws.

Первая конфигурация имеет преимущество в скорости работы, т.к. использует для wsgi-приложений их нативный обработчик, оптимизированный в процессе долгой жизни wsgi. Но для такой имплементации требуется запуск как минимум двух экземпляров приложения и разделение запросов на более низком уровнее (например в nginx).

Вторая конфигурация имеет только один плюс - унификация всех запросов, которая позволяет не иметь ниже стоящих laod balancer'ов / proxy. Из-за того, что asgi появился относительно недавно, большинство серверов еще сырые, имеют слабую конфигурацию и кастомизируемость. Поэтому скорость работы может заметно снизится.

Лично я использую uwsgi (wsgi-сервер) + daphne (asgi-сервер) упакованные в docker. Все ws запросы на /api/ws/,  http запросы на /api/ (routing настроен в nginx). Скорость заметно выше, чем при использовании чистого daphne, плюс uwsgi имеет намного больше возможностей. Также хочу попробовать gunicorn (wsgi) + uvicorn (asgi). Uvicorn позволяет запускать своих воркеров нативно в gunicorn'е.

Анжелика Ковтанова будет жить. Поприветствуем!

Спасибо, как раз хотел в процессе чтения, задать вопрос про uvicorn, но ответ уже был вконце. Благодарю