Доброго времени суток!
Раньше немного программировал на Python на микрофреймворке Flask и очень понравилось все это (и язык и фреймворк) ввиду простоты и понятности сервера написанного на нем, к сожалению не могу сказать то же самое об express.js на котором я пытался писать api. В интернете есть мало информации об express (относительно), я имею ввиду официальной документации, уж слишком она бедна на подробности, а у Flask и Django есть...
Вопрос - хорошая ли практика использовать с React'ом Pytnon'овский фреймворк при условии что будет ssr? Есть ли какие-то существенные минусы? Не лучше ли дальше учить express.js?
Gimir, тут все зависит от того какие инструменты будут использованы для реализации. Если использовать next, то придется использовать их причудливый серверный роутинг с масками на клиенте. Если писать SSR собственными силами, то можно ограничиться react-router.
Gimir, можно. Я использую как раз Next.JS - мне норм. Как раз лучше использовать готовое решение для рендеринга, чем пилить свою балалайку для аналогичной задачи. У тебя SSR с питоном вообще никак не связан, поэтому апи пили вообще на чем угодно. Единственное, не советую Django, потому что юзать ее для обычного REST api избыточно. Я взял вообще gin/gonic (go).
sim3x, то есть разработка на микрофреймворках - это обязательно велосипедостроение разве? Что конкретно из Django будет юзаться в Rest API? Думаю, что ORMка да роутинг. Может быть, что-то еще по мелочи. Первое решается прикручиванием к проекту любой ормки в виде сторонней библиотеки (алхимия - для питона, горм - для го), второе есть и так в любом микрофреймворке из коробки. Какие батарейки из джанго-комбайна делают его удобным для создания рест апи? Возможность разрабатывать быстро разве что. И то порог вхождения для новичка в любой микрофреймворк явно ниже, чем в джангу. Поэтому это тоже спорный вопрос.
Да и так ли уж в Django не будет велосипедов? Тот же насущный вопрос "где в Django хранить бизнес-логику" уже приводит к спорам и разногласиям. Кто-то во view хреначит, кто-то пилит толстые модели, а кто-то делает свой слой сервисов. Чем не велосипедостроение?
sim3x, ну это да, согласен с тем, что "Микрофреймворки на продакшене доступны на уровнях выше мидла
Джун без строгой структуры сваливается в говнокод сразу же".
А почему так уверенно: Fat models? Смешивается по сути entity с бизнес-логикой проекта. Сами файлы моделей зачастую очень сильно разрастаются. Какое архитектурное преимущество у такого подхода перед вынесением бизнес-логики в сервисы?
sim3x, ну, я (чисто мое мнение) хорошую архитектуру вижу как-то так: entity - repository - service - controller. Entity - просто модель данных (например, представление таблицы из БД). repository - операции типа выборок, вставок и т.п., реализующие общий интерфейс. Нужно, чтобы абстрагироваться от типа хранилища. Service - собственно бизнес-логика. Ну а controllers - тут все ясно. Контроллеры, которые дергают методы сервисов. Всякие хелперы/валидаторы и т.п. я тут умышленно не озвучил.
"Скомпоновали вью и формы и назвали сервисами" - там еще это все в транзакции завернуто (опционально). На самом деле, удобная штука, потому что service layer должен выполнять проверку данных, которые в него передаются - и тут это реализовано прямо на джанговских формах. То есть не важно, из вьюхи дернул или из консольной команды или еще как-то - валидация уже есть.
"потому как так проще." - но ведь бизнес-логика может затрагивать сразу несколько моделей. В какой из моделей тогда этот метод реализовывать?
"Упростит ли ето что-то?" - даст возможность абстрагировать бизнес-логику от конкретного фреймворка, его ОРМок и т.п.. Да, я понимаю, что конкретно эта либа все равно идет вразрез с этим высказыванием из-за ее привязки к Джанго, но вообще в идеале сервисный слой должен быть независимым.
Дмитрий Свиридов, заметьте, я не имею ничего против next.js и ничего не говорил о преимуществах или недостатках, того или иного решения. Я лишь указал на то, что ваше утверждение не состоятельно, так как вы выдаете свое оценочное суждение за факт. Единственным аргументом, насколько я понял, было слово "пилить", но пилить там на самом деле особо нечего: один middleware для express, серверная точка входа, HOC, Provider и вспомогательная функция для асинхронного ожидания выполнения запросов на стороне сервера.
sim3x, KISS - так а где ненужная сложность? Точнее, где лежит граница между нормальной архитектурой и излишней сложностью? Кто-то сайты вообще в одном файле лепит на пхп, смешивая php, html, запросы к базе и верстку и утверждает, что главное - простота.
"а зачем?" - чтобы проект можно было поддерживать, развивать, покрывать тестами и чтобы из глаз не текла кровь))
точнее, где лежит граница между нормальной архитектурой и излишней сложностью?
вот тут
entity - repository - service - controller
Когда начинают добавлять паттерны поверх MVT
"а зачем?" - чтобы проект можно было поддерживать, развивать, покрывать тестами и чтобы из глаз не текла кровь))
Я не вижу, как абстрагирование от орм (и неизбежный оверкодинг) упростят юнит-тестирование и функциональное тестирование
А ведь придется еще и абстрактную орм мокать
И я видимо неправильно задал вопрос
Он звучал так
А зачем нам отвязываться от ОРМ, если неизбежно произойдет построение параллельного апи к ОРМ, которое будет дублировать ОРМ?
Хотите использовать raw-запросы к постгрес - ок
Хотите алхимию - ок
Хотите джанго - ок
Хотите все вместе - чта?
я не предлагал это (entity - repository - service - controller) делать поверх джанговского шаблона проектирования. В случае с Django я предложил лишь добавить слой сервисов, чтобы избежать в проектах на ней разрастания моделей, в которых хранить бизнес-логику, на мой взгляд не логично. От "толстых моделей" во многих проектах стремятся уходить - и возникает логичный вопрос, куда в таком случае переносить бизнес-логику. Потому что со временем модели меньше не становятся - и копаться в файлах с тысячами строк занятие не из приятных. Одно дело, когда какие-то геттеры типа __str__ в модель пихают - еще понятно, но бизнес-логику, которая может взаимодействовать с другими моделями, выполнять обращения к сторонним сервисам, работать с кешем и т.п. - это странно. Потому что в таком случае "простота" сомнительна. Тем более, что в случае с тестированием сервисов мокать придется явно меньше, чем в случае со здоровенными методами модели (где в одном методе нередко и sql-запросы, и http-отстуки куда-либо намешаны). Да, можно и модели большие методы дробить на более мелкие и тестить их отдельно, но так ли уж имеет смысл их тогда в модели держать?
А зачем нам отвязываться от ОРМ, если неизбежно произойдет построение параллельного апи к ОРМ, которое будет дублировать ОРМ
Я так понял, речь о репозиториях? Если да, то это шаблон проектирования, нужный для того, чтобы скрыть источник получения данных. Нужно, чтобы была возможность легко при необходимости переключиться на другой источник данных (не только база данных SQL, а совершенно любой). Сегодня у тебя mysql используется для хранения списка товаров интернет магаза, а завтра приперло redis для этих же целей использовать (ну, чисто для примера). В случае, когда у тебя есть репозитории, достаточно запилить новый класс, реализующий те же методы, что и старый репозиторий, покрыть тестами - и все. В случае без репозиториев потребуются гораздо более серьезные правки. Завтра скажут - а давай обратно на MySQL, грубо говоря - и ты легко переключился на прошлый репозиторий. Если без репозиториев, то будет тяжело. Да и просто наличие репозиториев тебе позволяет поменять одну ORM-ку на другую. Хотя конкретно в случае с Django это вообще не имеет смысла, потому что ORM-ка там вколочена намертво.
бизнес-логику, которая может взаимодействовать с другими моделями, выполнять обращения к сторонним сервисам, работать с кешем и т.п. - это странно
Сначала в Manager
Потом в отдельный файл с функциями
В тяжелых случаях - делаем свой класс и добавляем в цепочку наследования
Потому что в таком случае "простота" сомнительна
просто нет
У нас есть мантра питона и там все описано
Тем более, что в случае с тестированием сервисов мокать придется явно меньше
нет же. Те части сервисов, которые сильно завязаны на орм просто тестируем, как модель вместе с данными
Тестирование кода, который писал человек не знающий про функциональный подход - всегда мучение
Но ето не повод продолжать писать грязные функции
Я так понял, речь о репозиториях?
нет, речь про
"Упростит ли ето что-то?" - даст возможность абстрагировать бизнес-логику от конкретного фреймворка, его ОРМок и т.п.
Сегодня у тебя mysql используется для хранения списка товаров интернет магаза, а завтра приперло redis для этих же целей использовать (ну, чисто для примера)
нет. Просто нет
мускул не используется никогда
Редис не используется для перманентного хранения чего-либо
Завтра скажут
нет. Всегда постгрес. В запущенных случаях оракл
И кроме того, оверинжинирить из-за того что может произойти завтра - безумие чистой воды
Я скорее скажу, что из-за такого оверинжиниринга и замедление написания кода проект прикроют сегодня, потому как вчера не было написано и строчки кода для решения бизнесс-задач
Я скорее скажу, что из-за такого оверинжиниринга и замедление написания кода проект прикроют сегодня, потому как вчера не было написано и строчки кода для решения бизнесс-задач
Следуя такой логике, можно и тесты не писать, потому что это отнимает время и не решает бизнес-задачи. Тесты - это технический долг, как и продуманная архитектура. Использование шаблонов проектирования не является никаким образом оверинжинирингом и не является какой-либо преждевременной оптимизацией или чем-то в том духе. Следуя Вашей логике, введение уровней абстракции придумали для дураков, которые занимаются разработкой ради разработки. В данном случае использование слоя сервисов решает вполне конкретную задачу: избавиться от толстых моделей.
Потом в отдельный файл с функциями
Тот же уровень абстракции, о котором я и говорю. Что файл с функциями, что сервисы - в данном случае суть примерно та же.
мускул не используется никогда. Редис не используется для перманентного хранения чего-либо
Я ж это написал в качестве примера, что специально подчеркнул. Можно заменить "Редис" в этом высказывании на любое хранилище любого вида.
нет
Тесты убирают страх внесения изменений в большой проект
Оверинжиниринг добавляет страхов, что завтра тз перевернется с ног на голову
Использование шаблонов проектирования не является никаким образом оверинжинирингом и не является какой-либо преждевременной оптимизацией или чем-то в том духе
в том виде, что вы описали - является и оверинжинирингом и преждевременной оптимизацией
Нужно, чтобы была возможность легко при необходимости переключиться на другой источник данных
Следуя Вашей логике, введение уровней абстракции придумали для дураков
моя логика - если уровни абстракции усложняют мою работу - они не нужны
В данном случае использование слоя сервисов решает вполне конкретную задачу: избавиться от толстых моделей.
Еще раз, в приведенном примере толстая модель заменяется на толстое вью
Никакого упрощения не происходит
Тот же уровень абстракции, о котором я и говорю. Что файл с функциями, что сервисы - в данном случае суть примерно та же.
Когда я делаю декомпозицию и выноу чистые функции, которые легко юнит-тестировать, я не делаю никаких сервисов, репозиториев и тп вещей
Я упрощаю код
Когда мне вместо чистых функций приводят иерархию классов - у меня сразу начинается аллергическая реакция
Я ж это написал в качестве примера, что специально подчеркнул. Можно заменить "Редис" в этом высказывании на любое хранилище любого вида.
я видимо неясно выразился - все храним в постгресе, кеши - где удобнее
Никаких смен орм
Никаких "я вот почитал книжку про паттерны и давайте внедрим у себя парочку"
Разраб - сразу в сад
Заказчику - поясняем сколько лет он будет платить деньги без решения его текущих задач
Средний
