Roman K

1. PHP актуален, седьмая версия лишний раз его "воскресила"
2. Где он будет через 5 лет — не важно. Ровно так же не важно, где будет любой язык X через Y лет. Если ты делаешь всё правильно, то ты изучаешь не язык, не фреймворк, а программирование. Если это так — тебе не составит труда перейти на любой другой язык с той же парадигмой, если вдруг твой язык умрёт (как, например, стало с Perl)
3. Хочешь быстрый результат — бери Python. Хочешь самый правильный результат — бери Java. Хочешь что-то посередине — бери TypeScript или PHP. TS более правильный, но молодой

У тебя какие-то неочевидные связи. Язык почему-то должен влиять на фронт, IDE должно влиять не препроцессоры. Попахивает дилетантством.

Лучшее, что ты можешь сейчас сделать — это разделить фронт и бэк. Фронт писать на React'е. Нужен SSR — настроить SSR. Хочешь SASS — легко. Минификацию там сделает за тебя webpack или parcel. ES6 в ES5 переведёт babel.

А пихать в джангу какие-то фронтовые кишки — ну это прям фу.

Django шаблонизатор — это самый обычный текстовый шаблонизатор, который не зависит от того, к чему ты ты его пытаешься применить — HTML, py-код, CSS, не важно.

Другое дело, что CSS принято передавать отдельным файлом и кэшировать на стороне браузера. Если ты каждый запрос будешь ворошить многокилобайтный файл, то это будет не только долго на стороне сервера, но и глупо на стороне клиента, ведь в CSS файле не будет никакого смысла, если он будет меняться каждый запрос.

Несколько лет назад я (видимо, как и ты) уверовал в logging. Ведь не зря же там такие дикие и глубокие настройки: и форматтеры есть, и хэндлеры есть, да и фильтры какие-то. И подумал я: крутые программисты всё это используют, а я на задворках рынка побираюсь.

И начал с тех пор настраивать все мыслимые и немыслимые настройки logging. Все ошибки у меня были в соответствующих файлах для ошибок. Также, был лог с дебаговой инфой. Всё это группировалось по файлам. Дебаг форматировался одним форматтером, ошибочный лог — другим форматтером, более подробным. И всё это росло, цвело и пахло.

Реальность оказалась жестокой. Все эти форматтеры оказались абузой — грепать логи стало сложней. Отдельные файлы с дебагом и ошибками оказались абузой — ведь проще грепнуть по уровню лога ( | grep ERROR). В куче файлов логов — чёрт ногу сломит. Да и вообще, логи почти всегда оказывались ненужными — ошибки летят в Sentry, а статистика собирается другими механизмами (prometheus). А ротацию и архивирование логов сделали девопсы.

А вот хорошие практики, которые я вынес:
1. Возьми loguru, которому буквально не нужны настройки:

from loguru import logger
...
# Где-то настроил sink-файл (либо будет только stdout)
...
logger.debug("hello")

2. Иногда удобно логи вести в JSON-формате. Отпадает необходимость придумывать хитрые grep'ы, всё отлично фильтруется с помощью jq

3. Ошибки надо не логировать, а слать в Sentry. Желательно, если Sentry настроен на веб-хуки в какой-нибудь slack/discord, чтобы ты видел ошибку в ту же секунду, как она произошла. В Sentry должен быть порядок.

4. Статистику по логам не стоит строить. Для этого есть куда более удобные и быстрые инструменты от обычных баз данных до prometheus + grafana

5. Куча файлов логов — в топку. Один файл

6. Ротация логов желательно должна быть извне

7. Используй ELK

8. Используй тесты и дебаггер

Если резюмировать: на логи возлагают слишком большие надежды и ожидания. Логи — это побочный продукт, который ОЧЕНЬ РЕДКО помогает расследовать неожиданное поведение, причём, очень неудобным способом. Чаще всего, логами обкладывается недостаточно нужной информации и много ненужной информации. И в момент аварии логов не хватает, на то ведь она и авария — её нельзя предусмотреть. Вместо логгирования в большинстве случаев удобнее использовать другие инструменты. Также, советую ознакомиться с этим https://sobolevn.me/2020/03/do-not-log

Серьёзные проекты всегда пользуются, сверху опционально добавляя mypy. С аннотациями типов жить становится сильно проще. Это радикально облегчает понимание кода в дальнейшем, его поддержку и, особенно, работу в команде. Также, аннотации заставляют лучше проектировать архитектуру проекта, использовать интерфейсы вместо конкретных реализаций (в питоне, правда, это ABC) и вовсю использовать полиморфизм.

А с появлением чудо-pydantic'а жить стало ещё лучше. Ну и fastapi, построенном поверх него и starlette.

Те, кто аннотации не используют, ни разу не разрабатывали ничего сложнее интернет-магазинчика в одно лицо и не поддерживали проект по 2+ лет.

Конечно, у докера есть оверхэд. В реальности ты его не заметишь.

Проектировать приложение нужно так, чтобы оно могло масштабироваться горизонтально. Не стоит думать, что разница между приложением, запущенным прямо на VPS и приложением, запущенным в докере на этом же VPS — это "вот как раз то, чего не хватало". Если CPU/Networking упирается в 100%, то это повод разворачивать ещё несколько идентичных серверов и размазывать нагрузку. А это в сто раз легче сделать, если у тебя контейнеры.

Более детальный анализ: https://stackoverflow.com/questions/21889053/what-...

Поставь минус перед len, будет в обратном порядке по длине

Если данные в БД изменяются только через Django-приложение, то проще всего повесить хендлер на сигнал на сохранение/удаление модели и вычищать кэш.

https://docs.djangoproject.com/en/3.1/topics/signals/

[bytes([x]) for x in range(1, 4)]

https://www.pyimagesearch.com/2018/05/21/an-opencv...

Мне нужно получить из подключенной в settings.py базы данных MYSQl заранее созданную ( не в моем коде) модель

Тык

которая может измениться, и эти изменения должны быть также и у меня

Никак, кроме как по тому, что в какой-то момент твоё приложение начнёт падать, если какие-то столбцы из таблицы удалят или изменят

fruits = set()
fruits.add("Apple")
fruits.add("Apple")  # Ничего не произойдёт
fruits.add("Pineapple")

assert "Apple" in fruits
assert "Watermelon" not in fruits

print(fruits)

fruits.remove("Apple")
assert "Apple" not in fruits