Ошибка в конечном теге шаблона?

Дмитрий, попробуй вместо {% endblock aside_news_sections%} просто {% endblock %}

Flask or Django & React\Redux - хорошая практика?

sim3x,

Я скорее скажу, что из-за такого оверинжиниринга и замедление написания кода проект прикроют сегодня, потому как вчера не было написано и строчки кода для решения бизнесс-задач

Следуя такой логике, можно и тесты не писать, потому что это отнимает время и не решает бизнес-задачи. Тесты - это технический долг, как и продуманная архитектура. Использование шаблонов проектирования не является никаким образом оверинжинирингом и не является какой-либо преждевременной оптимизацией или чем-то в том духе. Следуя Вашей логике, введение уровней абстракции придумали для дураков, которые занимаются разработкой ради разработки. В данном случае использование слоя сервисов решает вполне конкретную задачу: избавиться от толстых моделей.

Потом в отдельный файл с функциями

Тот же уровень абстракции, о котором я и говорю. Что файл с функциями, что сервисы - в данном случае суть примерно та же.

мускул не используется никогда. Редис не используется для перманентного хранения чего-либо

Я ж это написал в качестве примера, что специально подчеркнул. Можно заменить "Редис" в этом высказывании на любое хранилище любого вида.

Flask or Django & React\Redux - хорошая практика?

sim3x,

Когда начинают добавлять паттерны поверх MVT

я не предлагал это (entity - repository - service - controller) делать поверх джанговского шаблона проектирования. В случае с Django я предложил лишь добавить слой сервисов, чтобы избежать в проектах на ней разрастания моделей, в которых хранить бизнес-логику, на мой взгляд не логично. От "толстых моделей" во многих проектах стремятся уходить - и возникает логичный вопрос, куда в таком случае переносить бизнес-логику. Потому что со временем модели меньше не становятся - и копаться в файлах с тысячами строк занятие не из приятных. Одно дело, когда какие-то геттеры типа __str__ в модель пихают - еще понятно, но бизнес-логику, которая может взаимодействовать с другими моделями, выполнять обращения к сторонним сервисам, работать с кешем и т.п. - это странно. Потому что в таком случае "простота" сомнительна. Тем более, что в случае с тестированием сервисов мокать придется явно меньше, чем в случае со здоровенными методами модели (где в одном методе нередко и sql-запросы, и http-отстуки куда-либо намешаны). Да, можно и модели большие методы дробить на более мелкие и тестить их отдельно, но так ли уж имеет смысл их тогда в модели держать?

А зачем нам отвязываться от ОРМ, если неизбежно произойдет построение параллельного апи к ОРМ, которое будет дублировать ОРМ

Я так понял, речь о репозиториях? Если да, то это шаблон проектирования, нужный для того, чтобы скрыть источник получения данных. Нужно, чтобы была возможность легко при необходимости переключиться на другой источник данных (не только база данных SQL, а совершенно любой). Сегодня у тебя mysql используется для хранения списка товаров интернет магаза, а завтра приперло redis для этих же целей использовать (ну, чисто для примера). В случае, когда у тебя есть репозитории, достаточно запилить новый класс, реализующий те же методы, что и старый репозиторий, покрыть тестами - и все. В случае без репозиториев потребуются гораздо более серьезные правки. Завтра скажут - а давай обратно на MySQL, грубо говоря - и ты легко переключился на прошлый репозиторий. Если без репозиториев, то будет тяжело. Да и просто наличие репозиториев тебе позволяет поменять одну ORM-ку на другую. Хотя конкретно в случае с Django это вообще не имеет смысла, потому что ORM-ка там вколочена намертво.

Flask or Django & React\Redux - хорошая практика?

sim3x, KISS - так а где ненужная сложность? Точнее, где лежит граница между нормальной архитектурой и излишней сложностью? Кто-то сайты вообще в одном файле лепит на пхп, смешивая php, html, запросы к базе и верстку и утверждает, что главное - простота.

"а зачем?" - чтобы проект можно было поддерживать, развивать, покрывать тестами и чтобы из глаз не текла кровь))

Flask or Django & React\Redux - хорошая практика?

Антон Спирин, и какие это дает преимущества?

P.s. "при наличии опыта пишется за несколько часов" - с тестами, без?)

Flask or Django & React\Redux - хорошая практика?

sim3x, ну, я (чисто мое мнение) хорошую архитектуру вижу как-то так: entity - repository - service - controller. Entity - просто модель данных (например, представление таблицы из БД). repository - операции типа выборок, вставок и т.п., реализующие общий интерфейс. Нужно, чтобы абстрагироваться от типа хранилища. Service - собственно бизнес-логика. Ну а controllers - тут все ясно. Контроллеры, которые дергают методы сервисов. Всякие хелперы/валидаторы и т.п. я тут умышленно не озвучил.

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

"потому как так проще." - но ведь бизнес-логика может затрагивать сразу несколько моделей. В какой из моделей тогда этот метод реализовывать?

"Упростит ли ето что-то?" - даст возможность абстрагировать бизнес-логику от конкретного фреймворка, его ОРМок и т.п.. Да, я понимаю, что конкретно эта либа все равно идет вразрез с этим высказыванием из-за ее привязки к Джанго, но вообще в идеале сервисный слой должен быть независимым.

Flask or Django & React\Redux - хорошая практика?

sim3x, ну это да, согласен с тем, что "Микрофреймворки на продакшене доступны на уровнях выше мидла
Джун без строгой структуры сваливается в говнокод сразу же".
А почему так уверенно: Fat models? Смешивается по сути entity с бизнес-логикой проекта. Сами файлы моделей зачастую очень сильно разрастаются. Какое архитектурное преимущество у такого подхода перед вынесением бизнес-логики в сервисы?

Flask or Django & React\Redux - хорошая практика?

sim3x, то есть разработка на микрофреймворках - это обязательно велосипедостроение разве? Что конкретно из Django будет юзаться в Rest API? Думаю, что ORMка да роутинг. Может быть, что-то еще по мелочи. Первое решается прикручиванием к проекту любой ормки в виде сторонней библиотеки (алхимия - для питона, горм - для го), второе есть и так в любом микрофреймворке из коробки. Какие батарейки из джанго-комбайна делают его удобным для создания рест апи? Возможность разрабатывать быстро разве что. И то порог вхождения для новичка в любой микрофреймворк явно ниже, чем в джангу. Поэтому это тоже спорный вопрос.

Да и так ли уж в Django не будет велосипедов? Тот же насущный вопрос "где в Django хранить бизнес-логику" уже приводит к спорам и разногласиям. Кто-то во view хреначит, кто-то пилит толстые модели, а кто-то делает свой слой сервисов. Чем не велосипедостроение?

Flask or Django & React\Redux - хорошая практика?

Gimir, можно. Я использую как раз Next.JS - мне норм. Как раз лучше использовать готовое решение для рендеринга, чем пилить свою балалайку для аналогичной задачи. У тебя SSR с питоном вообще никак не связан, поэтому апи пили вообще на чем угодно. Единственное, не советую Django, потому что юзать ее для обычного REST api избыточно. Я взял вообще gin/gonic (go).