Тут мало кто декомпозирует сильно, в основном монолиты пилят, и если смотреть как на монолит, то да может нест и не нужен, так как все его абстракции можно сделать с нуля за неделю, просто Камиль это уже сделал и почему бы не юзать его, чем городить в каждой конторе свой нест, проще взять готовое и людей проще обучать и искать, когда есть архитектура уже можно тратить время на декомпозипование и тестирование, двигаться в сторону лаконичного и надёжного кода, а твой самописный нест ты всю жизнь будешь улучшать, с нестом мы просто снимаем этот головняк со своих плеч

Нет, только спринг

Чувак, который работал со спрингом не должен задавать таких вопросов по определению, имхо

Если в jwt хранится id из таблицы сбросов пароля и jwt имеет время протухания и не смущает что гет запрос будет длинным то наверно жить можно

так и есть, спасибо

Похоже, что нет. Нест как раз и выбирают из-за схожей идеологией (как в спрингах или дотнете) , вы разберитесь сначала для себя, что такое dependency injection и чем он отличается от dependency inversion.

Тут мало кто декомпозирует сильно, в основном монолиты пилят, и если смотреть как на монолит, то да может нест и не нужен, так как все его абстракции можно сделать с нуля за неделю, просто Камиль это уже сделал и почему бы не юзать его, чем городить в каждой конторе свой нест, проще взять готовое и людей проще обучать и искать, когда есть архитектура уже можно тратить время на декомпозипование и тестирование, двигаться в сторону лаконичного и надёжного кода, а твой самописный нест ты всю жизнь будешь улучшать, с нестом мы просто снимаем этот головняк со своих плеч

Только не сам id пользователя, а именно id из таблицы сбросов паролей или указывать тип токена в самом токене или подписывать другим secret_key. Просто из предыдущего вашего сообщения вы хотите просто хранить id пользователя в at и тут же хотите в токене сброса пароля id пользователя хранить. Получается что по разным токенам можно и пароль сбрасывать и в тоже время получить доступ к закрытым ресурсам

Годится вроде бы. Только не понял один момент, вы говорите что нест подходит для  микросервисов больше чем для монолитов?

Например в своём несте ответ почему не работает моя фича новичку займёт 3 часа попути нужно объяснить как самописный нест работает, в несте ответ: ты модуль такой-то забыл, и все минута блин) не три часа, дальше новичек импортнет модуль и все заведётся и если ему будет интерестно то пойдёт и САМ изучит как он устроен, время тратит только свое, а не всей команды

Какой то грязный прием. Ничего из того что я написал не давало повода считать что я путаю, di и dependency inversion. Такое чувство что вы за неимением ответов/аргументов пытаетесь дискредитировать меня в глазах участников чата которые не станут разбираться. Давай вы не будете так делать.

Да нет разницы куда больше он годится, это готовая платформа которую можно заточить как пол мс так и под монолит. Тебе правильно ответили, нест - это уже готовый велосипед от Камиля, который достаточно хорош , а городить свое конечно можно, но порог входа в это может быть очень высоким

Ну может быть да, а может быть это какой то лишний уровень абстракции, который тоже надо учить, а если какие то люди предпочитают учить его потому что не осилили самый низкий уровень абстракции ноды, то это очень грустно. Лично мне проще прочитать код проекта что бы понять его, чем учить нест. Особенно если я сам начинаю писать проект. Кроме того есть ограничения которые накладывает на меня нест, использую нативную ноду илт экспресс ограничений нет и я могу воротить что хочу

Я не говорил, что вы их путаете, я намекал, что вы их не понимаете и + не понимаете разницу, между ними, я это у видел из ваших доводов на примере express

Мне кажется что порог входа в лапшу из декораторов сильно выше чем в проект написанный на экспрессе, да и бенефитов никаких нет от этих декораторов

У нас внутри компании планируется митап, я к нему продемонстрирую , как эволюционировал проект от самописаного экспресс до нест , какие ошибки были и от чего ушли

Запись будет?

Да