Андрей Мелихов, остановитесь! Вы картавый обрюзгший мужчина. Неужели не понимаете, что все зло от несовершенных как вы? Займитесь искусством и спортом.
Возможно, подразумевается, что при рендеринге на бэкенде готовые компоненты должны сразу отправляться пользователю, не дожидаясь остальных, чтобы как можно раньше начать строить UI на клиенте. Но это не точно : )
Главный плюс експресса и мидлверов его прозрачности - ты видишь общий флоу данных и можешь без проблем прологгировать каждый этап. В несте все "под капотом", что больше мешает, чем чему то помогает. В итоге гораздо чаще мне приходится перехватывать какие то штуки, потому то стандартное решение не подходит, в несте уже внутри защита херова туча оверхеда.
Могу ответить за себя. Я в основном в одиночку разрабатываю различные сервисы, обслуживающие мои собственные направления бизнеса. Чтобы мне легче было разрабатывать и поддерживать решения, я хочу, чтобы они были максимально унифицированы по технологиям. В моём случае, связка NestJS + Angular хорошо подходит. Раньше я на сервере использовал php, но решил от него отказаться во вышеуказанным причинам.
Надеюсь, спустя три недели ты уже осознал бессмысленность вопроса :) Но если вдруг нет, то: если решил идти конкретно в бэк, то учить java или python и переходить на nest (который как бы javascript, typescript, node) - это трата времени. Не говоря уже о том, что java позиций много сейчас и будет много потом, а вот судьба nest/node бэка совершенно непредсказуема.
@@Huggowasright не будет много джавы в будущем , будет на спад только идти. Голанг большими темпами набирает обороты в бекенд среде. От джавы останется только легаси и банковская сфера. А на счет ноды, то она и дальше будет развиватся и шикарно себя чувствовать.
@@user-jv2hu8uz8i соглашусь, что джаву рано или поздно сменят другие языки. Но я бы не стал рисковать ставить всё на Ноду, будучи чисто бэкендером. Я, кстати, не видел позиций для node разработчиков уже года два в нашей стране. Может специфика рынка..
Кривая же инфра получилась... И, может Я чего то не понимаю, но какая у Вас сложная бизнес логика когда Nest только за SSR отвечает? Бизнес логика всегда на бэке, иначе зачем такой бэк нужен, в базу сходить? На фронте же могут быть сложные манипуляции с интерфейсом и какие то логические условия, но никак не бизнес логика. И для чего в итоге Nest тут нужен? Обвязку на фронте делают через микрофронтенды. Та же шапка или боковая меню могут быть в отдельной репке и подтягиваться отдельно. Короче сомнительно всё это, особенно для Яндекс Денег.
Вот опять (есичо я за нест). Посмотрите на этот ужасный код на экспрессе - инфраструктурная и бизнес логика намешана в одной портянке. Поддерживать невозможно. Блин, да кто вас заставляет мешать инфраструктурную и бизнес логику в одном методе? При чем тут экспресс?
Валентина, вы прям мои мысли читаете. Впрочем, видно же что докладчик уровня мидл, видимо вся команда такая была, поэтому пока этим гениям фреймворк явно рельсы не проложил они так и писали логику прямо в обработчиках запросов.
Еще не очень понятен момент с "помойкой" в req. Что такое туда нужно складывать, чтобы там образовалась помойка? Или же у вас req пробрасывается через всю логику сервиса до уровня запроса в бд, и на всех уровнях в него что то подмешивается? Тогда это опять же проблема проектирования модулей внутри сервиса, на мой взгляд
@@aroundyouaroundme Давайте сейчас рассказывать про идеальный мир, где в продакшн выходит код, написанный исключительно синьор разработчиками, а весь "плохой" код он где то в вакууме в университетах только пишется. Вы же наверное в таком живёте? Че плохого то в том что на рельсы сходу ставят?
@@romanabubekerov5851 верно. он же сказал, nest помогает писать правильно и мешает писать неправильно. Это реально так благодаря его заранее продуманной архитектуре.
Вот из за таких архитектурных гениев , страдают нормальные бекендеры , которые не пишут на node монолит , я нихрена не понимаю на сколько должен быть узким мозг до которого ни как это не доходит , пошёл смотреть доклад как там пишут монолиты на golang 😂
Наконец-то понял что такое нест и для чего он нужен
Очень качественный доклад
доклад очень качественный, человек знает о чем говорит, объясняет понятно
Андрей Мелихов, остановитесь!
Вы картавый обрюзгший мужчина.
Неужели не понимаете, что все зло от несовершенных как вы?
Займитесь искусством и спортом.
Интересно было бы послушать, что изменилось за два года
В более новом докладе он ушел пробовать лямбды и перешел на fastify
Отличный доклад! Спасибо всем причастным :)
Крутой доклад. Спасибо!!!
Хороший доклад, спасибо!
Андрюха умеет понятно разложить по полкам. Оч интересно.
Спасибо, очень интересно. Андрей профессионал топ, конечно.
Спасибо за доклад
Поздравляю господа. JavaEE ад пришел к вам в гости))
Все новое - хорошо забытое старое)
ага, то из-за чего хотелось выпилить джаву с сервера
спасибо
Thanks
Как выглядит потоковый рендер на Реакте? Зачем он? Чем плох NextJs? Можно подробнее пожалуйста
Возможно, подразумевается, что при рендеринге на бэкенде готовые компоненты должны сразу отправляться пользователю, не дожидаясь остальных, чтобы как можно раньше начать строить UI на клиенте. Но это не точно : )
когда жс-ники рассказывают про DI контейнер как про магию и новшества
Да, забавно было послушать. Похоже на презентацию эпл
На 19:03 оговорка по-видимому, имелся ввиду nest.
Нет тут оговорки не было существует инструмент под названием next для react ssr
По итогу построили?
Главный плюс експресса и мидлверов его прозрачности - ты видишь общий флоу данных и можешь без проблем прологгировать каждый этап. В несте все "под капотом", что больше мешает, чем чему то помогает. В итоге гораздо чаще мне приходится перехватывать какие то штуки, потому то стандартное решение не подходит, в несте уже внутри защита херова туча оверхеда.
Так нужно понимать для чего использовать ту или иную технологию
Я тут мимо проходил , увидел это вот "флоу", меня аж перевернуло
Спасибо за доклад! На 19:53 вы говорите что-то про автогенерацию доки. Каким инструментом это можно сделать?
Посмотрел доку, видимо речь про docs.nestjs.com/recipes/documentation
Я думаю они про Swagger
Swagger и Compodoc
Зачем пользоваться инструментами для фронта, вместо существующих решений для бекенда? go, java, например?
Могу ответить за себя. Я в основном в одиночку разрабатываю различные сервисы, обслуживающие мои собственные направления бизнеса. Чтобы мне легче было разрабатывать и поддерживать решения, я хочу, чтобы они были максимально унифицированы по технологиям. В моём случае, связка NestJS + Angular хорошо подходит. Раньше я на сервере использовал php, но решил от него отказаться во вышеуказанным причинам.
Можно ли начинать изучать бекенд сразу с nestjs или же нужно сначала выучить отдельные языки вроде java или pyton?
Начинать изучать бекенд можно на любом языке но перед изучением nest надо знать node.js
@@Northerner19 спасибо
Надеюсь, спустя три недели ты уже осознал бессмысленность вопроса :)
Но если вдруг нет, то: если решил идти конкретно в бэк, то учить java или python и переходить на nest (который как бы javascript, typescript, node) - это трата времени. Не говоря уже о том, что java позиций много сейчас и будет много потом, а вот судьба nest/node бэка совершенно непредсказуема.
@@Huggowasright не будет много джавы в будущем , будет на спад только идти. Голанг большими темпами набирает обороты в бекенд среде. От джавы останется только легаси и банковская сфера. А на счет ноды, то она и дальше будет развиватся и шикарно себя чувствовать.
@@user-jv2hu8uz8i соглашусь, что джаву рано или поздно сменят другие языки. Но я бы не стал рисковать ставить всё на Ноду, будучи чисто бэкендером.
Я, кстати, не видел позиций для node разработчиков уже года два в нашей стране. Может специфика рынка..
Почему он фейспалмит на превьюхе?
Кривая же инфра получилась...
И, может Я чего то не понимаю, но какая у Вас сложная бизнес логика когда Nest только за SSR отвечает?
Бизнес логика всегда на бэке, иначе зачем такой бэк нужен, в базу сходить?
На фронте же могут быть сложные манипуляции с интерфейсом и какие то логические условия, но никак не бизнес логика. И для чего в итоге Nest тут нужен?
Обвязку на фронте делают через микрофронтенды. Та же шапка или боковая меню могут быть в отдельной репке и подтягиваться отдельно.
Короче сомнительно всё это, особенно для Яндекс Денег.
@Кирилл Никода В самом видео автор говорит, что они Nest для ssr используют, не Next.
Вот опять (есичо я за нест). Посмотрите на этот ужасный код на экспрессе - инфраструктурная и бизнес логика намешана в одной портянке. Поддерживать невозможно. Блин, да кто вас заставляет мешать инфраструктурную и бизнес логику в одном методе? При чем тут экспресс?
Валентина, вы прям мои мысли читаете. Впрочем, видно же что докладчик уровня мидл, видимо вся команда такая была, поэтому пока этим гениям фреймворк явно рельсы не проложил они так и писали логику прямо в обработчиках запросов.
Еще не очень понятен момент с "помойкой" в req. Что такое туда нужно складывать, чтобы там образовалась помойка? Или же у вас req пробрасывается через всю логику сервиса до уровня запроса в бд, и на всех уровнях в него что то подмешивается? Тогда это опять же проблема проектирования модулей внутри сервиса, на мой взгляд
@@aroundyouaroundme Давайте сейчас рассказывать про идеальный мир, где в продакшн выходит код, написанный исключительно синьор разработчиками, а весь "плохой" код он где то в вакууме в университетах только пишется. Вы же наверное в таком живёте? Че плохого то в том что на рельсы сходу ставят?
@@romanabubekerov5851 верно. он же сказал, nest помогает писать правильно и мешает писать неправильно. Это реально так благодаря его заранее продуманной архитектуре.
Сложнааа
Простаа
просто сложно
Вот из за таких архитектурных гениев , страдают нормальные бекендеры , которые не пишут на node монолит , я нихрена не понимаю на сколько должен быть узким мозг до которого ни как это не доходит , пошёл смотреть доклад как там пишут монолиты на golang 😂
Как дети, то туда, то сюда... ССР... Ладно.