экспрес и тайпскрипт..
- прекрати, они же еще дети

У меня никак не получается органично классифицировать подходы в голове: Грасп, Солид, и т.д. Они выглядят, как искусственная попытка научить людей не быть тупыми. В контексте:  разделять иерархически построенные понятия по элементарной логике и думать на два шага вперёд. "Не плоди сущностей сверх необходимого", "сила цепи зависит от самого слабого звена", "если что-то может в дальнейшем изменится - подстели соломку" и т.д. Попытки эти подходы искусственно разделить по именам создателей, недостаточно убедительные, на мой взгляд. Впрочем, я теоретик не настоящий, я каску на стройке нашёл. Вы не поделитесь своими соображениями на этот счёт?

Та не спорю)

Да, в теории у нас сейчас все не очень стройно, это далеко не математика, но лучшей теории пока нет, пойду на пенсию - буду разрабатывать

Это все имхо, про управление сложностью. когда работаешь один и проект не серьезный то гамнякай как хоч. А в команде надо уметь управлять сложностью отсюда имхо и родились солиды граспы паттерны и так далее

Что-то не понятно, экспресс дал дуба или уже всё на отлично сделали, что и обновлять не нужно?

Спасибо. Не идите на пенсию.
Вы на встрече затронули тему швейцарского ножа для реляционных баз данных, тут у меня друг делает нечто подобное, только в обратную сторону, возможно, вам будет интересно:  
https://t.me/nosingularity
Позволю себе его процитировать, не сочтите рекламой:

1, но его все ещё юзают

"Как можно использовать компилятор parsers.dev прямо сейчас?
parsers.dev прямо сейчас?
1) По DDL + DML сгенерировать типы, модели и вообще все что угодно для своего языка программирования.
PostgreSQL поддерживается неплохо, и скорее всего подойдет для абсолютного большинства проектов."

Это классический БД-центрический подход конца 90х годов.

Разница очевидна

т.е. парсер дело хорошее, но брать структуру БД за центр системы - это путь в никуда

его всё еще пытаются продавать

"опишите магией структуру БД и мы сгенерируем вам счастье"

https://www.prisma.io/ как пример

Тут есть свой синтаксис для можеди, а там выше описали когда SQL скрипт заменяет модель

10 строк понятной sql или 100 непонятной конфигурации, что же выбрать для того, чтобы один раз сгенерировать таблички:)

Я позволил себе пригласить Антона для обсуждения, поскольку тема крайне интересна, актуальная, и, надеюсь, полезная.

Привет. Я по приглашению @lp0404 :)

У меня история немного про другое. Это не генератор crud по схемам. Таких инструментов уже достаточно, не было смысла делать еще один.

Немного другой подход. Он для тех, кто пишет сложные запросы и не пользуется ORM. Стояла задача сгенерировать типы результатов (а в идеале и параметров) для произвольного запроса. Схема в данном случае нужна, чтобы ее скомпилировать в промежуточный объект и понять какие типы у используемых полей.
Существует проект, который компилирует запросы в prepared statements и извлекает типы результата прям из базы. Надежно, но не очень универсально.

Кроме типов мне не хватало еще двух вещей - nullability, и класса количества строк (none, one, one or none, many, many or none), для проверки в рантайме.


А когда я научился делать компиляцию в промежуточные объекты, появилась возможность сделать статический анализатор - holistic.dev

А когда есть типы - из них уже можно что хочешь собрать. Хочешь  модели, хочешь json-schema, хочешь весь микросервис целиком, если он только то и делает, что в базу ходит