kissarat
@kissarat
Node.js

Чем плох мой подход к архитектуре web-приложения?

В дизайне и программировании я руковожусь двома принципами: читабельностью и простотой и считаю, что чем меньше кода тем лучше. Я стараюсь реализовать логику приложения, главным образом, в PostgreSQL (с помощью вюшек и, в крайнем случае, функций), и я хочу генерировать правила проверки на сервере Node.js и клиенте (на React.js) на основе ограничений (constraints) в моей PostgreSQL базе данных. Т.е. генерировать код во время запуска сервера там, где это возможно. Хоть и многие проверки все же приходится императивно описывать на серевере Node.js, хотя бы пока.

Собственно к генерации валидаторов руки еще не дошли, это вопрос времени, как и двухсторонее настраиваимое свьязывания именений в UI и таблиц БД. Но схема, на основе которой это будет генерироватся уже есть, как и API доступа к таблицам базы, с пагинацией и сортированиям.

Выбор Node.js не случайный так как теоретически на нем можно писать код который будет работать как на клиенте так и на сервере. Меня удивлило то, что до сих пор нету годного фреймворка, который бы использовал одни и те же модели (одни и те же файлы) как на клиенте, так и на сервере. После того, как я представлю как же все-таки можна сделать прив язку UI к серверу полностью конфигурируемой и зависимой в две стороны от БД задача сделать общие модели будет уж не столь сложной, но жизненно важно. Правда прийдется переписывать почти весь код, чтобы он работал с методами моделей, а не с конструктором запросов или оберткой вокруг API.
Если прив язка UI к данным в базе займет месяць или максимум два, то переписывания на использования моделей несколько недель.
  • Вопрос задан
  • 619 просмотров
Пригласить эксперта
Ответы на вопрос 2
rSedoy
@rSedoy
Python/Django

Я стараюсь реализовать логику приложения, главным образом, в PostgreSQL (с помощью вюшек и, в крайнем случае, функций)

Как по мне, вот тут минимум 2 проблемы: читабельность и возможности тестирования кода.
PS: А слона и не заметил, а с масштабируемостью как в таком случае?
Ответ написан
@Finsh
В том, что Ваш подход не знает слов гибкость, сопровождение, да и много других он тоже не знает. За последние пару лет работал на 3-х проектах, ни один проект не имел только одной бд. Данные хранились в 2-3х бд, тянулись по апи из сторонних сервисов, в общем бд никогда не ставилась во главу стола. Представьте себе ситуацию, вот вы пилите 2-3 года проект, и тут вам заказчик сообщает, что ему кровь из носу надо переехать на другую бд или надо дополнительно тянуть данные и обрабатывать из иного хранилища, поставить поисковый движок. Вы будите дублировать всю логику? Да и потом, в больших проектах, обычно бд является первым узким местом, наваливая на бд ещё и логику Вы делаете это место ещё более узким. Сейчас более интересен подход не данные ферст и уж тем более никак не бд. Лучше посмотрите на DDD подход, Эрик Эванс вам в этом в помощь.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы