Object-Relational Mapping (ORM) — технология, призванная «поженить» реляционную природу SQL-баз (PostgreSQL, MySQL, SQLite и т.п.) с объектной моделью языков программирования. Она настолько популярна, что её пытаются реализовать даже в необъектных языках — например, в Go или Erlang.

Если в Java без ORM действительно неудобно, то в экосистеме Node.js (и TypeScript в частности) ситуация принципиально иная. И ORM здесь — зачастую избыточная абстракция. В большинстве случаев рациональнее обойтись компактным SQL-билдером который сильно упрощает построение запросов, оставляя над ними полный контроль, и который совсем не занимается управлением объектами. Почему в Node.js ORM почти не даёт преимуществ...

За годы работы с TypeScript, Java, Kotlin и Go я не раз сталкивался с одним и тем же паттерном: команда внедряет «правильное» архитектурное решение — и получает не гибкость, а технический долг.

Причина проста: оверинжиниринг маскируется под профессионализм. Мы выбираем сложные инструменты не потому, что они нужны, а потому, что «так делают в серьёзных проектах».

В результате принцип KISS — «Keep It Simple, Stupid» — работает не хуже, чем в 1930-х, когда его впервые сформулировали в среде авиационных инженеров. В этой статье — мой личный список подходов, которые в 90% случаев (особенно в REST-серверах) приносят больше вреда, чем пользы.

Не кажется ли вам, что ИИ снизил ценность операционных знаний, типа «как сделать ту или иную вещь на том или ином языке программирования», но повысил ценность архитектурного мышления и умения правильно декомпозировать код, то есть делить его на модули. Принципы этого деления никак  не изменились с 70-х годов. Но теперь им нужно следовать куда как более тщательно, иначе ИИ создаст настолько плохо структурированный код, что распутать человеческими мозгами будет невозможно.

Под катом принципы декомпозиции (с обобщёнными примерами) и история этих принципов

Создатель Node.js Райан Даль в одном из своих интервью заявил, что для написания серверов предпочёл бы Go. Это интервью состоялось в 2017 году, с тех пор Райан переходил на Rust, даже написал на нём еще одну среду для выполнения серверного JS – Denо. Но джин уже выпущен из бутылки. Стали даже появляться заявления о скорой кончине Node.js. Фразу продолжают вспоминать в спорах по сей день, и сейчас можно увидеть статьи о переходе с Ноды на Голанг.

Мне же представляется, что вопрос о переходе между этими двумя технологиями едва ли стоит – эти решения для разных ниш. Прикладные API-сервера, для которых чаще всего используют Ноду устроены таким образом, что получить выигрыш производительности переходом на Go довольно трудно, а вот замедлить разработку очень легко.

Если, когда вы смотрите на NEST.js вас гнетёт необъяснимая тоска. Если вы не можете понять воодушевления и радости от использования декораторов. Если рассмотрение очередного NEST-инструмента вызывает лёгкое недоумение — не стесняйтесь, вы не одиноки.

NEST.js – это фреймворк для написания REST серверов под Node.js на языке TypeScript, который потом транспилируется в JavaScript. Он написан поверх библиотеки Express (или Fastify – можно выбрать) и привносит модные концепции – Inversion of Control, Dependency Injection и т. п. в мир JavaScript. Нередко описание этого инструмента сопровождается восторженным настроением. Как мне кажется, эта восторженность несколько преувеличена, сложность излишняя, а чудо-сила отсутствует. Некоторые неудобства вынудили нас отказаться от его использования после нескольких лет разработки.