Комментарии 12
А можно сделать так, чтобы вся логика была в БД? (простите за некоторую наивность)
Прям всю-всю нельзя положить в бд.
Но можно боложить большие куски логики в хранимки.
Правда это жёсткий антипаттерн. Ибо база не должна знать про бизнес логику приложений,
а приложение не должно быть завязано на какую-то конкретную бд.
Почему? Мы же привыкли традиционно определять свойства полей и ограничения целостности. Что мешает ещё и логику прописывать? Что должно происходить, например, при создании объекта. В этом случае, клиент загружает метаданные и настраивает свою работу.
Потому что данные и логику смешивать вредно.
- В случае когда бизнес-логика выносится из сервисного слоя приложения, то начинается её многократное дублирование.
- Так-же такую логику тяжелее поддерживать и расширять.
- В разныех БД по разному пишутся хранимки и по разному оптимизируются. Это значит, что в случае миграции с PostgreSQL ну например на Oracle будет большая боль в процессе переноса этой логики. В случае когда вся логика находится внутри приложения, то придётся просто переключить драйвер и может поправить миграции, которые идут в обход ORM.
- В рамках одной БД от версии к версии может поменяться фнкциональный набор для написания хранимок. Например что-то что было deprecated - уберут. И такое изменение не позволит осуществить переезд.
- Одним из существенных минусов использования хранимых процедур - это значительные трудности поддержания версий кода.
- Масштабирование приложений со сложной логикой - проще и дешевле чем масштабирование бд
- Логика в приложении гораждо проще поддаётся качественному тестированию
На самом деле - это очень холиварная тема.
Если вы знаете что делаете и для чего, то возможно хранимки вам подойдут. С другой стороны, хорошей архитектуры у приложения добиться скорее всего будет очень сложно, а зависимось от базы будет очень жёсткой.
Вот есть пост тут от 2014 года где активно холиварят.
Вот пост тут от 2020 статья в более пессимистичном духе к хранимкам
Посмотрите, почитайте, а там ужа сами решайте, нужно вам это или нет
PostgREST даст вам возможность не только логику в БД положить, но и выставить наружу API! Вот только стоит ли так делать?
Берёте любой серверный фрэймворк и не изобретаете велосипед, тот же Vaadin например.
А такой подход не создаст излишней связности между беком и фронтом?
Наоборот, появляется возможность менять фронт-ы как перчатки или (как в нашем случае) стереть разницу между веб-фронтом и мобильным приложением так как форма целиком, включая алгоритм её работы, формируется бэк-ом.
Чтобы сменить один фронт на другой(например angular на чистый javascript) достаточно один раз воссоздать на новом фронт-е механизм обработки приходящих с бэк-а инструкций. При этом количество уже используемых в проекте форм не важно так как все они обрабатываются одним и тем же механизмом однообразно.
Спасибо за статью!
А такой подход как долго у вас практикуется на проде? Большая ли команда и проект? Ресурс публичный или внутрикорпоративный? Какая нагрузка?
В свое время я активно работал с компонентными фреймворками (Wicket, Zk), и статья выглядит как переоткрытие этого подхода. По моему опыту он подходит разве что для админок или прототипов. Огромный мемори футпринт на каждого пользователя из-за хранения состояния виджетов/страниц на бэке, боль из-за попыток реализовать богатое поведение веба, огромное количество коллбеков с фронта, спаггети код из-за смешения фронтовой и бэковской логики (наверное этого можно избежать, но неизбежно кодовая база разрастается нещадно из-за того, что все теперь хранится только на бэке). Имхо в статье server-side подход представлен очень однобоко, негативные моменты, как мне кажется, не были должным образом освещены. Сходу выглядит, как серебряная пуля:) Но статья интересная, еще раз спасибо за ваш труд)
У Альфа банка есть статья про Server Driven UI, по сути то же самое, что описывали вы, но опробованное на проде и с описанием того, почему жёсткие привязки вида "если в поле а введено значение, то показываем б" не очень хорошо)
Server side Form. Управление веб-формами на стороне сервера