Я про это. Возможно, это просто утрированный пример и можно сделать элегантнее
Это специальная демонстрация функции reaction, не более. Что с помощью нее можно трекать изменения конкретных свойств и реагировать на них. В данном примере она не несет никакой пользы, просто в консоль пишет, что локальный title или глобальный title были изменены) Опять же, чисто для демонстрации принципа)
о, что mobx позволяет так делать - это плюс, конечно, это выглядит красиво и удобно
Это ещё цветочки, по сути там целый простор для всяких шикарных штук. Можете сделать мега удобные классы для работы с формами, валидаторы, роутер, да и вообще все что угодно, ограничений то нет) Только фантазия) У меня уже давно 100500 решений написано и вспомогательных штук на все(99%) случаи жизни) Для меня разработка проходит вообще играючи, никаких проблем, ни с чем не надо бороться, ничто не мешает и не вставляет палки в колеса.
Но вот глядя на пример приведённый - ну как-то многовато кода писать приходится, не находите?
Нет) Многовато это что? Слово observer и makeAutoObservable?) Потому что кроме этих 2х ребят всё остальное по сути просто тупо нативный JS код.
Каждый компонент со стейтом в observer запихивать
И что?) Зато оптимизация производительности из коробки и никаких лишних перерендеров. Можно написать плагин для vite/webpack чтобы автоматом компоненты в observer заворачивались, я так и сделал несколько лет назад)
хуки использовать и тот же useEffect...
Поясните что вы имеете ввиду
А ещё у mobx огромный бандл в 60 Кб
Это вы про 17.5kb gzip?) Ну в масштабах самого реакта и вообще real world проектах, это копейки и они тонут в общем размере проекта) Так что как обычно по поводу размера, аргумент не аргумент https://bundlephobia.com/package/mobx@6.13.7
И у Zustand простое и лаконичное API, которого в целом хватает
Простое, да. Но не лаконичное, ибо там всё в ручную надо делать. И писать много бойлерплейта и лишнего кода. А в mobx автоматические подписки/отписки.
Вот например лишний код, и это минималистичный и безобидный пример:
А если избавиться от лишнего мусора в виде useAppStore, то будут лишние перерендеры всей подноготной со вложенными компонентами почем зря, прям как в реакт или редакс.
Так что трезво взвесив всё, из популярных решений по сей день нет ничего лучше MobX'a для реакта. Более того, когда используешь MobX, по сути нет разницы какая версия реакта, 16, 17, 18 вообще пофиг.
Какой смысл альтернативы, если под него ничего не написано
Какой смысл был создавать React, когда был backbone и jQuery? Какой смысл был создавать Vue, когда был React? Какой смысл был создавать Node.js, когда был PHP? Ну и так далее, список можно до бесконечности продолжать... С таким подходом мы бы дальше Assembler'a не продвинулись и дальше гужевых повозок, ведь зачем что делать, если уже есть Х и Y.
если под него ничего не написано
А что, теперь самому что-то написать это проблема? Если нет библиотеки/ui кита и т.п., то всё, приплыли?
Так всё эти проблемы решены много лет назад, ещё с 2017 года или даже раньше. Всё просто, React + MobX. React для рендера, MobX для управления состоянием, как глобальным, так и локальным. И никаких тебе ререндеров лишних да и никакой боли в целом. Тупо наслаждаешься всеми благами JSX'a и компонентного подхода, а так же человеческим стейт менеджментом и минимальным кол-вом кода.
Мазохисту не очевидно что иглы себе под ногти засовывать это не хорошо.
Я понимаю, промысловикам вообще начхать на чем писать и какой говнокод, с какой скоростью он будет работать и т.п. Их интересует только один вопрос, чтобы ЗП платили.
Для меня более чем очевидно что nest это максимально уродливый говнокод, с кучей лишнего бойлерплейта, все самый простые вещи доведены до абсурда и превращены в сложные и монструозные, связывает руки, навязывает свою ущербную архитектуру, и как вишенка на торте он самый медленный из всех решений какие только есть. А если ещё ORM ему в пару дать, так это вообще пиши пропало. Таких людей я тоже не понимаю, в чем проблема написать SELECT запрос руками? А для insert/update для пущего удобства 1 раз в жизни написал просто query builder или если не умеешь, взял уже кем-то написанный и вуаля.
Итого перформанс на дне(это не фронт, на бэке это намного важнее), качество и красота кода на дне, скорость разработки на дне, удобство разработки на дне, утопаем в бесконечных @@@@@
@Module({
imports: [],
controllers: [AppController],
providers: [AppService],
})
@Injectable()
@Controller()
@Get()
и ещё бесконечное кол-во @@@@@@ над каждым полем повсюду.
Зачем мне платить эту цену за дно по всем фронтам? Я выбираю максимальный перформанс(fastify или своё решение, аля express, только работающее со скоростью http.createServer), минимальное кол-во кода и максимальная простота кода.
И ещё, представим ситуацию, что вдруг на nest код будет приятный и т.п., но как инженер я себя никогда не буду уважать если возьму его, уже только из-за того, что он максимально медленный. Т.е. он не работает на пределах возможности Node.js с минимальным оверхедом, а он просто позорит node.js и ставит его производительность на колени.
Ну естественно routes в отдельной папке, hanlders в отдельной, middlewares в отдельной) Всё разбито на уровне логики и здравого смысла. Тут дело в том, что самого кода надо минимум, т.е. вообще без лишнего мусора. И писать сам этот код легко, ты по сути только делаешь то, что нужно, а не пытаешь угодишь nest'у.
И всё, у нас зарегистрирован роут, он закрыт авторизацией и назначена функция handler которая его обработает. Всё в что касается эндпоинта сразу видно, всё супер очевидно, просто и ноль мусора.
Вообще это очень странное сравнение, ведь express и fastify это скорее библиотеки, а nest полноценный фреймворк
express/fastify/nest/koa/hapi и т.п. решают абсолютно одну и ту же задачу. Так что сравнение не странное. Нет ничего, что может nest и чего не может тот же express или fastify. То, что на nest навешали сверху всяких кривых "решений" из коробки, не делает его лучше. Ибо вы если адекватный разработчик, у вас уже много лет есть все эти решения, которые работаю так же, а скорее всего лучше и быстрее, только с express или fastify. У меня например ещё в 2017 году уже было вообще все для express, и валидатор и квери билдер для постгреса, и враппер для более удобной работы с rabbitmq и вообще всё что только хочешь, ибо эти вещи базовые и элементарные. И разработка всегда шла как по маслу, минимум кода, максимум скорости и удобства. На любой запрос, если вдруг у меня не было решения, я его просто писал и всё, это изи. Это и есть разработка. А позиция брать под каждый чих библиотеку и фреймворк, это кто угодно, но не разработчик.
Просто до свидания. И это только hello world, в реальной жизни кол-во "кода" на nest стабильно раза в 3-4 больше чем на Express. И уровень уродливости кода с nest удивит даже самых отпетых мазохистов)
Конечно можно и на Express все грамотно сделать, но это явно сложнее и дольше.
Ага, обязательно) Безумно сложно и супер долго))
Разрабатывал и на Express и на Fastify
Уверены?) Я как бы тоже, в том числе и на php и на go, и после них всех NestJS это прям фу, причем конкретное фу. Это как всю жизнь бегать в спортивных кроссовках, мягких, удобных, лёгких, сам решал куда бежать и бежать ли вообще, может хочется идти, а тут тебе нацепили валенки залитые свинцом килограмм по 6 и сказали, вот кайфуй. Мы тоже так ходим в таких. значит это нормально, а то, что ты считаешь что кроссовки лучше, это просто ты такой дурачок, а вот мы умные.
Очень удобно работать с DI
Да уж) Прям безумно удобно))) Не то, что это ваши import { someThing } from 'some/thing'; Это же ппц как не удобно, громоздко, да и вообще черт ногу сломит))) Толи дело через 10 файлов и через 10 колен я буду пробрасывать себе всякий мусор, вот это по кайфу.
А что насчет Python? Он же тоже вроде как популярен на бэкенде?
Он очень медленный, а по сравнению с node.js даёт ноль преимуществ в скорости и удобстве разработки, поэтому нет смысла за просто так получать низкую производительность. Но это не отменяет того факта, что люди плюют на производительность и берут его всё равно, это да.
Какие-нибудь Ларавелы, Симфони никуда не исчезли, а наоборот получают новые версии и проекты
Это вообще даже близко не говорит о том, что это не гуано. У нас как бы до сих пор продают ниву которая со времен 80ых. И что теперь, это значит что она лучше крузака?)
Во вторых, какое это имеет отношение к той ерунде сказанной о DI с которой все началось?
Код без DI чище и приятнее, это как минимум.
Только вот для этого уже быть разработаны модули, корректность работы которых проверена.
Ну да, я и разрабатываю модули сразу чтобы они корректно работали, в противном случае это просто промежуточная дев версия в стадии разработки.
Все зависит от разработчика.
Вот это самое главное, в прямых руках nest и ему подобное тупо мешает и вставляет палки в колеса.
Не нужно подменять понятия. Модульный тест тестирует конкретную функциональность и он должен дать уверенность в корректной работе этой функциональности. Поэтому причем тут приложение целиком?
Ну вот я делаю запрос POST /api/v1/goods с разными параметрами, позитивными и негативными, это не unit тесты. А таких методов допустим 50 и вот для каждого метода написанные такие тесты, вот они и покрывают всё приложение целиком.
Гарантии чего? Назначение модульного теста фичи и e2e теста различное. Они используются на разных этапах разработки ПО.
Гарантии того, что условный метод POST /api/v1/car будет работать исправно. А не так, что функции по отдельности которые участвуют в работе этого метода работают исправно, но при реальном запросе что-то идёт не так. И я одним тестом по сути закрываю сразу условно 10 тестов, 10 тестами этого мета, закрываю условно 100 unit тестов для этого метода)
Очень может быть. Вы это все к тому, что у всех остальных разработчиков ровно те же самые задачи, что и у вас? Вот сомневаюсь я.
Нет конечно, но чисто статистически в 99.9% они у всех разработчиков бэкенда REST API плюс минус схожи. И для них вообще не нежно никакое DI. Вот в чем цимус.
Беря на себя функции тестировщиков как вы с ними делите обязанности?
Не, в идеале это просто делает автотестер, но мы говорим про абстракную ситуацию где разработчик тестирует, вот я говорю как я тестирую АПИ.
Если мы начинаем касаться изменения бизнес логики, то это уже точно про архитектуру. А это означает, что какие-то изменения должны быть предвидены, а значит и ПО написанное по контракту не будет требовать переписывания целых подсистем и тестов.
А это смотря как изменяется бизнес логика, она может незначительно меняться, а может конкретно, так что тут воля случая.
Так я у вас и спрашиваю, кто и что у вас живет и умирает? Если у вас коннект, живет всегда, то что мешает сервису? Или что? Я вообще не понимаю, что вы хотите сказать.
То, что для вас context и dependency это одно и то же, а это разные вещи.
Если их подавляющее большинство дайте тогда какое-нибудь исследование на эту тему. А то на деле все как то наоборот. Мощные вреймворки не то что не умирают, а наоборот набирают популярность с новой силой.
Хоть 1 задача в которой будет божественен NestJS, и обосрется Express?
Но если бы сервисы которые пришлось переписывать были написаны адекватными специалистами, то их и не пришлось бы переписывать.
Это, в точку. Жаль только имеем то, что имеем(
У меня больше притензии бывают не к самому языку, а к тулингу вокруг него.
Ну вот да, допустим зачем nestjs в ноде, если есть express и fastify? Он приносит ноль пользы, добавляет кучу проблем и говнокода, ставит на колени производительность. И вот как бы заем использовать этот шлак? Я вот хоть убей не понимаю.
Rust меня подкупает тем что да, он очень быстрый все дела, и без рантайма, но вот синтаксис у него специфический и например для разработки rest api вот вообще никак я не могу его использовать.
В Go вообще на раз два можно убить производительность просто тупо одним не верным решением, и получается ты заплатил большой многословностью, но в итоге не выиграл в перформансе, или если выиграл, то гроши не принципиальные по сравнению с тем, что заплатил, а это обида) Элементарно я поднял на 20% производительность просто тупо за счет того, что написал свой драйвер для работы с pg, если победить в Go json encode/decode, эти операции можно легко в разы ускорить, Rust тому подтверждению, да даже PHP в разы быстрее JSON encode/decode делает. В общем, так то если Go ещё довести до ума чтобы он не обсирался на абсурдных вещах, и reflect сделать нормальным, чтобы на этапе компиляции инфа о типе, полях и т.п. зашивалась в объект, а не уничтожала производительность в рантайме, то будет уже прорыв. А если ещё ошибки будут сами по умолчание на верх улетать, и не нужно будет писать бесконечные if err != nuil после каждой строчке, то будет прорыв для языка в квадрате)
Если для вас 100500 зависимостей и сайд эффектов причина по которой вы не можете написать выразительные тесты для тестирования корректного поведения модуля
Это причина, по которой unit тестами, тестируя отдельные функции, а не приложение целиком невозможно добиться того, чтобы тесты реально могли отражать тот факт, что приложение работает. Поэтому верхнеуровневые e2e тесты и ручное тестирование это единственное что может дать гарантии в реальном мире. Ибо мы говорим не про библиотеку.
очевидно, перед вами такие задачи уже стояли, но вы не смогли дать удобное и понятное решение
Почему же? У меня все прекрасно работало и работает, просто я тестирую приложение верхнеуровнево и эти тесты сразу же охватывают всё. Я экономлю кучу времени, я занимаюсь разработкой, а не работаю тестировщиком вместо этого) Решение по мне очень удобное и понятное. Ты проверяешь конкретно работу АПИ, а не фантики в которые подсовываются фейковые данные, фейковые модули т.п.
Видимо поэтому, вы решили от этих задач отказаться, или нет?
Нет, зачем от них отказываться, просто для меня они не являются проблемой, ибо я следую KISS и YAGNI и у меня сложность не умножается в 10раз, а равна по сути сложности бизнес логики, т.е. мой коэффициент сложности приложения около 1, т.е. всё всегда максимально просто, насколько это возможно для данной бизнес логики приложения. А вот если бы я использовал nest, orm и ещё 100500 лишних переусложненный и абстракций, то коэффициент сложности уже был бы 10 и выше.
Вы понимаете, просто для примера, что ручное тестирование всего и вся только потому, что вы не смогли победить сложность 100500 зависимостей и сайдэффектов и спроектировать систему, которую можно модульно протестировать на корректность - это характеристика вашей системы?
Никто не говорит что ручное тестирование на каждый чих, мы говорим о комплексном тестировании, где мы реально может гарантировать корректную работу. А это совокупность e2e + ручное, опять же под ручным я имею ввиду не в ручную АПИ тыкать, а смотреть сразу связку клиент сервер. Ну опять же, я то 100500 зависимостей побеждаю, потому что e2e, а вот unit'ами их просто невозможно победить, ну либо вся ваша работа будет в написании бесконечных тестов) И потом при изменении бизнес логики лавинообразное падении тысячи unit тестов, вместо падения от силы десятка e2e) Посчитайте насколько проще и быстрее e2e подправить и на сколько тысячи упавших юнитов)
Вы правильно заметили, что для "узкоспециализированных" библиотек нужны юнит тесты, только вот именно ваши прямые руки и голова помешают вам ваше приложение так же спроектировать, что бы оно состояло из узкоспециализированных частей, которые можно и все таки нужно тестировать на корректность не запуская долгий процесс e2e или ручного тестирования.
Если отбросить реальность и жить в розовом мире, где бизнес логика приложения простая как 2х2, и максимум сложности там это просто CRUD, то да, вообще легко. Но блин, реальность просто не дает такой возможности.
А для чего вы все это написали? По вашей логике, вот нужен вам коннект к БД и вы импортируете что-то из какого то модуля, да? А потом, типа это убирается? Потом идет снова запрос и снова убирается?
Нет, наоборот, коннект живёт всегда, и не привязан к жизненному циклу запроса. Этим dependency и отличается от context.
Т.е. в вашем случае коннект создается 1000 раз, а в альтернативном один раз? И что в этом плохого?
Да нет же, он именно 1 раз создается и живёт всегда. Потому что это зависимость. А контекст создается и умирает вместе с каждым запросом.
Вот это тоже context по сути, эти объекты живут, пока живёт запрос
Для чего? Я когда писал, просто размышлял о задачах, которым это может потребоваться. Вы хотите сказать, что никогда ни для кого не было и не будет задач, которым это может потребоваться? Если да, то сильное заявление. В противном случае, вы держите в голове какие-то свои задачи, которым ваш подход действительно дает ощутимую пользу. Т.е. без описания задачи это просто один из подходов. Можно или не нужно так делать, очевидный/наглядный/простой - это уже все будет зависеть только от задачи.
Я не беру в расчет 0.01% от всех задач, которые мы решаем в 99.99% случаев, в них моего подхода более чем достаточно и он с головой себя оправдывает. Но да, может однажды в карьере появиться задача в которой, в которой DI действительно будет лучше, но шанс что такая задача встанет, крайне мал, поэтому и существует принцип YAGNI.
Ваше решение имеет место быть. Полно задач, которым оно хорошо подходит. Но на этих задачах мир клином не сошелся.
Согласен, просто таких задач подавляющее большинство. Но не абсолютные 100%, да. Я исхожу чисто из разряда статистической реальности, только и всего.
Я со своей стороны так же не утверждаю, что прям обязательно любое приложение должно использовать определенный набор технологий вот они
Логично, только если будет реально в этом потребность, в противном случае это будет во вред. Просто многие люди даже не пытаются думать, они сразу бездумно берут некий набор и на нем фигачат всё что угодно) Увидели что в каких-то вакансиях написано NestJS, значит только по этой причине они будут его брать. Увы и ах, люди такие люди)
Не можете справится с модульным тестированием? Считаете что оно не дает вам уверенности? Хотите все делать максимально просто, а потом перекладывать все на монструозное e2e? Так тоже можно.
Когда я пишу библиотеки, то легко справляюсь unit'ами и они там идеально подходят и вообще must have, но в приложениях для бизнеса я не могу им довериться сильнее чем e2e, плюс e2e дает мне гораздо больше свободы в плане того как я могу писать код. Код мне важнее тестов и скорости тестов) Пусть моё приложение будет быстрым, а тесты не самыми быстрыми, чем наоборот, приложение будет медленным, а тесты быстрыми)
Вообще не всегда, и при адекватных подходах и там и там, вопрос на сколько? Ответ я знаю) В среднем на 25-30% будет быстрее Go, но это из-за того что в ноде драйвер pg так себе по скорости, прям очень слабоват. А теперь другой вопрос, насколько быстрее и удобнее разработка на ноде?) Насколько система типов в Typescript круче чем в Go?) А ещё, если в Go не использовать самые быстрее подходы и инструменты, то он уже будет проигрывать ноде. Так что да, Go может быть быстрее ноды, но при определенных условиях и там и там, а может быть и наоборот и медленнее.
Ну вообще то, если говорить про адекватов, то очень даже быстрое и способное легко держать тысячи RPS, особенно если запускать через Bun, это бесплатно +20% производительности. И опять же можно далеко не простое, а очень больше и сложное, тоже изи. А вот если говорить про nestjs + orm, то да, там вообще производительность на коленях. Это скажем так позор языка.
Был на NodeJS - вместо 2Gb стал есть 50Mb. Запросов почти в 10 раз стал больше обрабатывать.
Это смотря что использовать на ноде, если NestJS и ORM, то да. там производительность нулевая. Если человеческие инструменты использовать, то всё очень даже хорошо, не предел совершенства, но очень даже ничего. То же самое относится к Go, очень сильно зависит от того какие инструменты там используются.
Вот я сравнил GO и Node.js(его честь защищает Bun), на ситации из реальной жизни, жизненный цикл запроса: - 3 запроса в базу данных - сериализация в JSON - десериализация JSON
Код того, чем занимает хэндлер на Go (драйвер для постгреса pgxpool(иначе было бы все печально по перформансу))
Скрытый текст
rows, err := database.Query(context.Background(), "SELECT * FROM users LIMIT 100")
if err != nil {
log.Fatal("Query failed", err)
}
users := make([]User, 0, 100)
for rows.Next() {
u := User{}
err := rows.Scan(&u.Id, &u.Name, &u.Email, &u.Age, &u.Text, &u.Ser, &u.CreatedAt)
if err != nil {
log.Fatal(err)
}
users = append(users, u)
}
rows, err = database.Query(context.Background(), "SELECT * FROM users LIMIT 99")
if err != nil {
log.Fatal("Query failed", err)
}
for rows.Next() {
u := User{}
err := rows.Scan(&u.Id, &u.Name, &u.Email, &u.Age, &u.Text, &u.Ser, &u.CreatedAt)
if err != nil {
log.Fatal(err)
}
}
rows, err = database.Query(context.Background(), "SELECT * FROM users LIMIT 98")
if err != nil {
log.Fatal("Query failed", err)
}
for rows.Next() {
u := User{}
err := rows.Scan(&u.Id, &u.Name, &u.Email, &u.Age, &u.Text, &u.Ser, &u.CreatedAt)
if err != nil {
log.Fatal(err)
}
}
jsonStringify, err := json.Marshal(users)
if err != nil {
log.Fatal(err)
}
err = json.Unmarshal(jsonStringify, &users)
if err != nil {
log.Fatal(err)
}
w.Header().Set("Content-Type", "application/json")
w.Write(jsonStringify)
Код того, чем занимает хэндлер на Node.js (драйвер для постгреса pg)
const query1 = {
// give the query a unique name
name: 'fetch-user1',
text: 'SELECT * FROM users LIMIT 100',
values: [],
}
const query2 = {
// give the query a unique name
name: 'fetch-user2',
text: 'SELECT * FROM users LIMIT 99',
values: [],
}
const query3 = {
// give the query a unique name
name: 'fetch-user3',
text: 'SELECT * FROM users LIMIT 98',
values: [],
}
Т.к. pgxpool в Go делает все запросы по умолчанию prepared statements, а pg в ноде нет, то чтобы сравнение было честным в ноде я тоже сделал чтобы они были prepared statements.
Результаты для Go:
Результаты для Node.js (в лице Bun)
Получается 9к RPS против 7k RPS, выходит что в среднем при условии что проект там и там пишет адекват, Go быстрее чем Node в среднем на 23%. А значит исходя из вашей математики, если Rust быстрее go на 20%, то Rust быстрее Node именно в задачах rest api, в среднем на 36%.
Но с точки зрения потребления памяти да, нода жрет конечно больше, не так что прям критично и в современных реалиях это не проблема.
Но справедливости ради: - Львиную долю в проигрыше Node занимает драйвер pg, как бы можно куда быстрее сделать реализацию. И это я молчу про то, что в ноду можно портировать из C++ или rust драйвер для постреса и вот тогда совсем другой колин кор будет) - В Go тоже pgx это не предел, я написал свой драйвер для постгреса и RPS в среднем на 20-25% больше если pgx заменить на мой.
А вообще, уже давно заметил что middle разработчику, который считает себя super senior, доказывать что-то это очень не благодарная работа. Они знают абсолютно все на свете с опытом работы в 3-5 лет и 1-2 проектов в 1-2 компаниях.
Я с 2012 года в коммерческой разработке и за плечами больше 20ти проектов, и больше 8ми компаний
Если вам интересно, я могу поделиться своим опытом и наблюдениями. Мне кажется это будет полезно для расширения кругозора.
Разумеется интересно, у меня кругозор без границ, я не мыслю узколобо.
доказывать что-то это очень не благодарная работа
Ну вы даже не пытались конечно) У вас у увидел лишь "аргументы" из разряда, Java и .NET подходят лучше просто потому что. Якобы nodejs чем-то обелен и якобы на Java и .NET можно сделать то, чего нельзя на ноде. Плюс опять же якобы для больших проектов лучше angular или nest, они что, позволяют сделать то, что нельзя сделать с помощью react или express? Конечно нет, даже наоборот nest и angular накладывают ограничения. связывают руки, вставляют палки в колеса, про то, что на код при их использовании без слез и бутылки водки не взглянешь это я вообще молчу, просто месиво реальное в котором полезного кода 20% всё остальное это борьба с самими angular или nest. И вот только не надо выдавать это за плюс, потому что плюсом такие вещи могут считать кто-то угодно, но явно даже не близко талантливые разработчики. Это всё равно что считать за плюс когда ты без разрешения не можешь выйти из дома и пойти туда, куда сам хочешь. Я с самого начала когда ещё писал на PHP уже презирал Symfony т.к. она сверх медленная, накладывает неудобства и ограничения, а если ее ещё с Doctrine ORM ее использовать, то это вообще труба, ну реально без шуток там 0 производительности, они в десятки раз медленнее чем код здорового человека. Разумеется я сразу написала своё решение которое потом годами со мной из проекта в проект ходило, было максимально быстрым и удобным в использовании. И ладно бы если бы за ущемление производительности я получал удобство, скорость и кайф в написании кода, как например в сделке Assembler vs Node.js) Но нет же, я по сути используя nest получаю только минусы, и "бонусом" производительность ниже плинтуса, а этой ой как "приятно" для настоящего разработчика, а не промысловика, которому пофигу на всё, который мериться со всем и терпит всё, лишь бы просто ЗП платили.
Если вы какой-то не ведомой причине решили писать очень крупный проект на Node.js, тогда, наверное Nest покажется логичным выбором
Эммм, с чего это? С того что он максимально медленный на сколько это вообще возможно? С того что код который он хочет чтобы писали используя его максимально неприятный и чрезмерно перегруженный? По каким таким мифическим причинам очень крупный проект на Express или Fastify хоть на грамм может уступить nest? Я вижу только сплошные плюсы по всем фронтам у Express и Fastify и сплошные минусы у nest. Тем более камон, быть бэкенд разработчиком и вообще ставить производительность на последнее место, ну это как бы вообще странно, это разве инженерный подход? Я вот себя бы вообще не уважал когда преднамеренно убиваю производительность если бы взял nest и ещё не приведи душу ORM какую нибудь, это будет вообще комбо.
Как и выбор Angular для написания Энтерпрайз фронтенда.
Что?)) Вы из тех кто эту чушь где-то прочитали в 2015 году и поверили в нее?)) Я думал уже таких не осталось) Яндекс, Vk, Mail.rum Ozon, WB и т.д. и тп это вообще не энтерпрайз, это так, лэндинг, не более. Опять же, с чего это вдруг React или Vue могут быть хуже? Вообще причин 0, только в кривых руках, но в кривых руках всё будет отвратное, и уж тем более Angular, даже при прямых руках на его код без слез не взглянешь.
Только в отличие от фронтенда, на бекенде есть .Net и Java со Spring Boot, которые куда больше подходят для этих целей.
А вот и нет. У TS например очень развита система типов, чем далеко не все могут похвастаться. В плане производительности он легко обойдет Java и .Net, опять же если делать всё по человечески, а не брать nest и orm. Если смотреть на баланс удобства/скорости разработки/производительности, то по сути Node.js это золотая середина, а если вместо node запускать код используя Bun, то ещё за бесплатно примерно +20% производительности капает(проверял лично) в реальных условиях, REST API с запросами в БД и т.п., RPS в среднем на 20% увеличивается.
Вот и получается что гвозди пытаются забивать лопатой. Не верно выбирают инструмент.
Nest да, это крайне плохой и неудачный инструмент. Fastify или Express - прекрасный (баланс удобства, скорости разработки, производительности, минимальном кол-ве лишнего говнокода и т.п.).
Увы, розовых очков не ношу, я реалист и знаю как всё устроено.
Но если для вам появляются такие сущности как сервисы, которые должны создаваться по требованию, иметь разные поведения в зависимости разных условий, зависеть от других таких же сервисов, то одних модулей вам не хватит.
Мне нет) И никогда) Я не усложняю простые вещи ради усложнения ни при каких условиях. Я порицаю такой подход. KISS и YAGNI наше все. У меня все всегда предельно очевидно и просто.
DI и есть, контекст выполнения
Dependency - это зависимость. Допустим для хэндлера GET /me мне нужен коннект к базе данных, это и есть зависимость(dependency). Контекст это некая сущность, например объект, который рождается в момент получения того же запроса GET /something и проходит через всю цепочку промежуточных функций, например в этом объекте есть информация о том, авторизован ли пользователь, какая у него и т.п. А когда запрос завершается и мы отправляет ответ, то этот контекст умирает. А вот наша зависимость, например коннект к базе данных не умирает, он живёт всегда пока наше приложение поднято и не является чем-то уникальным для каждого конкретного запроса.
Ваш вариант, это кодинг на уровне реализации. Вы четко зашиваете в коде какую реализацию сервиса вы используете.
Разумеется, ибо это максимально очевидный, наглядный и простой подход. Никаких загадок, всё строго и понятно, всем всегда и сразу. Мы же не говорим про библиотечные методы и их разработку, где условно интерфейс Stream у сети и файловой системы может совпадать. Мы говорим о разработке конкретных приложений с бизнес логикой.
Не, они создавались для себя, а не для всех)
Это специальная демонстрация функции
reaction, не более. Что с помощью нее можно трекать изменения конкретных свойств и реагировать на них. В данном примере она не несет никакой пользы, просто в консоль пишет, что локальный title или глобальный title были изменены) Опять же, чисто для демонстрации принципа)Это ещё цветочки, по сути там целый простор для всяких шикарных штук. Можете сделать мега удобные классы для работы с формами, валидаторы, роутер, да и вообще все что угодно, ограничений то нет) Только фантазия) У меня уже давно 100500 решений написано и вспомогательных штук на все(99%) случаи жизни) Для меня разработка проходит вообще играючи, никаких проблем, ни с чем не надо бороться, ничто не мешает и не вставляет палки в колеса.
Нет) Многовато это что? Слово
observerиmakeAutoObservable?) Потому что кроме этих 2х ребят всё остальное по сути просто тупо нативный JS код.И что?) Зато оптимизация производительности из коробки и никаких лишних перерендеров. Можно написать плагин для vite/webpack чтобы автоматом компоненты в observer заворачивались, я так и сделал несколько лет назад)
Поясните что вы имеете ввиду
Это вы про 17.5kb gzip?) Ну в масштабах самого реакта и вообще real world проектах, это копейки и они тонут в общем размере проекта) Так что как обычно по поводу размера, аргумент не аргумент
https://bundlephobia.com/package/mobx@6.13.7
Простое, да. Но не лаконичное, ибо там всё в ручную надо делать. И писать много бойлерплейта и лишнего кода. А в mobx автоматические подписки/отписки.
Вот например лишний код, и это минималистичный и безобидный пример:
А если избавиться от лишнего мусора в виде useAppStore, то будут лишние перерендеры всей подноготной со вложенными компонентами почем зря, прям как в реакт или редакс.
Вот ссылка:
https://stackblitz.com/edit/stackblitz-starters-ab7az7ym?file=src%2FApp.tsx
Так что трезво взвесив всё, из популярных решений по сей день нет ничего лучше MobX'a для реакта. Более того, когда используешь MobX, по сути нет разницы какая версия реакта, 16, 17, 18 вообще пофиг.
Какой смысл был создавать React, когда был backbone и jQuery?
Какой смысл был создавать Vue, когда был React?
Какой смысл был создавать Node.js, когда был PHP?
Ну и так далее, список можно до бесконечности продолжать...
С таким подходом мы бы дальше Assembler'a не продвинулись и дальше гужевых повозок, ведь зачем что делать, если уже есть Х и Y.
А что, теперь самому что-то написать это проблема? Если нет библиотеки/ui кита и т.п., то всё, приплыли?
Так всё эти проблемы решены много лет назад, ещё с 2017 года или даже раньше.
Всё просто, React + MobX.
React для рендера, MobX для управления состоянием, как глобальным, так и локальным. И никаких тебе ререндеров лишних да и никакой боли в целом. Тупо наслаждаешься всеми благами JSX'a и компонентного подхода, а так же человеческим стейт менеджментом и минимальным кол-вом кода.
https://stackblitz.com/edit/vitejs-vite-dspjoj?file=src%2FApp.tsx&terminal=dev
Мазохисту не очевидно что иглы себе под ногти засовывать это не хорошо.
Я понимаю, промысловикам вообще начхать на чем писать и какой говнокод, с какой скоростью он будет работать и т.п. Их интересует только один вопрос, чтобы ЗП платили.
Для меня более чем очевидно что nest это максимально уродливый говнокод, с кучей лишнего бойлерплейта, все самый простые вещи доведены до абсурда и превращены в сложные и монструозные, связывает руки, навязывает свою ущербную архитектуру, и как вишенка на торте он самый медленный из всех решений какие только есть. А если ещё ORM ему в пару дать, так это вообще пиши пропало. Таких людей я тоже не понимаю, в чем проблема написать SELECT запрос руками? А для insert/update для пущего удобства 1 раз в жизни написал просто query builder или если не умеешь, взял уже кем-то написанный и вуаля.
Итого перформанс на дне(это не фронт, на бэке это намного важнее), качество и красота кода на дне, скорость разработки на дне, удобство разработки на дне, утопаем в бесконечных @@@@@
Зачем мне платить эту цену за дно по всем фронтам?
Я выбираю максимальный перформанс(fastify или своё решение, аля express, только работающее со скоростью http.createServer), минимальное кол-во кода и максимальная простота кода.
И ещё, представим ситуацию, что вдруг на nest код будет приятный и т.п., но как инженер я себя никогда не буду уважать если возьму его, уже только из-за того, что он максимально медленный. Т.е. он не работает на пределах возможности Node.js с минимальным оверхедом, а он просто позорит node.js и ставит его производительность на колени.
Ну естественно routes в отдельной папке, hanlders в отдельной, middlewares в отдельной) Всё разбито на уровне логики и здравого смысла. Тут дело в том, что самого кода надо минимум, т.е. вообще без лишнего мусора. И писать сам этот код легко, ты по сути только делаешь то, что нужно, а не пытаешь угодишь nest'у.
app.get(`/api/v1/me`, authOnlyMiddleware, UserMehandler);И всё, у нас зарегистрирован роут, он закрыт авторизацией и назначена функция handler которая его обработает. Всё в что касается эндпоинта сразу видно, всё супер очевидно, просто и ноль мусора.
Не думайте об этом, оно вам не надо.
Ещё бы)
Как же иначе)
express/fastify/nest/koa/hapi и т.п. решают абсолютно одну и ту же задачу. Так что сравнение не странное. Нет ничего, что может nest и чего не может тот же express или fastify.
То, что на nest навешали сверху всяких кривых "решений" из коробки, не делает его лучше. Ибо вы если адекватный разработчик, у вас уже много лет есть все эти решения, которые работаю так же, а скорее всего лучше и быстрее, только с express или fastify.
У меня например ещё в 2017 году уже было вообще все для express, и валидатор и квери билдер для постгреса, и враппер для более удобной работы с rabbitmq и вообще всё что только хочешь, ибо эти вещи базовые и элементарные. И разработка всегда шла как по маслу, минимум кода, максимум скорости и удобства. На любой запрос, если вдруг у меня не было решения, я его просто писал и всё, это изи. Это и есть разработка. А позиция брать под каждый чих библиотеку и фреймворк, это кто угодно, но не разработчик.
Раз
Два
Три
Четыре
Против
Просто до свидания. И это только hello world, в реальной жизни кол-во "кода" на nest стабильно раза в 3-4 больше чем на Express. И уровень уродливости кода с nest удивит даже самых отпетых мазохистов)
Ага, обязательно) Безумно сложно и супер долго))
Уверены?) Я как бы тоже, в том числе и на php и на go, и после них всех NestJS это прям фу, причем конкретное фу. Это как всю жизнь бегать в спортивных кроссовках, мягких, удобных, лёгких, сам решал куда бежать и бежать ли вообще, может хочется идти, а тут тебе нацепили валенки залитые свинцом килограмм по 6 и сказали, вот кайфуй. Мы тоже так ходим в таких. значит это нормально, а то, что ты считаешь что кроссовки лучше, это просто ты такой дурачок, а вот мы умные.
Да уж) Прям безумно удобно))) Не то, что это ваши
import { someThing } from 'some/thing';Это же ппц как не удобно, громоздко, да и вообще черт ногу сломит))) Толи дело через 10 файлов и через 10 колен я буду пробрасывать себе всякий мусор, вот это по кайфу.
Он очень медленный, а по сравнению с node.js даёт ноль преимуществ в скорости и удобстве разработки, поэтому нет смысла за просто так получать низкую производительность. Но это не отменяет того факта, что люди плюют на производительность и берут его всё равно, это да.
Это вообще даже близко не говорит о том, что это не гуано. У нас как бы до сих пор продают ниву которая со времен 80ых. И что теперь, это значит что она лучше крузака?)
Код без DI чище и приятнее, это как минимум.
Ну да, я и разрабатываю модули сразу чтобы они корректно работали, в противном случае это просто промежуточная дев версия в стадии разработки.
Вот это самое главное, в прямых руках nest и ему подобное тупо мешает и вставляет палки в колеса.
Ну вот я делаю запрос
POST /api/v1/goodsс разными параметрами, позитивными и негативными, это не unit тесты. А таких методов допустим 50 и вот для каждого метода написанные такие тесты, вот они и покрывают всё приложение целиком.Гарантии того, что условный метод
POST /api/v1/carбудет работать исправно. А не так, что функции по отдельности которые участвуют в работе этого метода работают исправно, но при реальном запросе что-то идёт не так. И я одним тестом по сути закрываю сразу условно 10 тестов, 10 тестами этого мета, закрываю условно 100 unit тестов для этого метода)Нет конечно, но чисто статистически в 99.9% они у всех разработчиков бэкенда REST API плюс минус схожи. И для них вообще не нежно никакое DI. Вот в чем цимус.
Не, в идеале это просто делает автотестер, но мы говорим про абстракную ситуацию где разработчик тестирует, вот я говорю как я тестирую АПИ.
А это смотря как изменяется бизнес логика, она может незначительно меняться, а может конкретно, так что тут воля случая.
То, что для вас context и dependency это одно и то же, а это разные вещи.
Хоть 1 задача в которой будет божественен NestJS, и обосрется Express?
Это, в точку. Жаль только имеем то, что имеем(
Ну вот да, допустим зачем nestjs в ноде, если есть express и fastify? Он приносит ноль пользы, добавляет кучу проблем и говнокода, ставит на колени производительность. И вот как бы заем использовать этот шлак? Я вот хоть убей не понимаю.
Rust меня подкупает тем что да, он очень быстрый все дела, и без рантайма, но вот синтаксис у него специфический и например для разработки rest api вот вообще никак я не могу его использовать.
В Go вообще на раз два можно убить производительность просто тупо одним не верным решением, и получается ты заплатил большой многословностью, но в итоге не выиграл в перформансе, или если выиграл, то гроши не принципиальные по сравнению с тем, что заплатил, а это обида) Элементарно я поднял на 20% производительность просто тупо за счет того, что написал свой драйвер для работы с pg, если победить в Go json encode/decode, эти операции можно легко в разы ускорить, Rust тому подтверждению, да даже PHP в разы быстрее JSON encode/decode делает. В общем, так то если Go ещё довести до ума чтобы он не обсирался на абсурдных вещах, и
reflectсделать нормальным, чтобы на этапе компиляции инфа о типе, полях и т.п. зашивалась в объект, а не уничтожала производительность в рантайме, то будет уже прорыв. А если ещё ошибки будут сами по умолчание на верх улетать, и не нужно будет писать бесконечныеif err != nuilпосле каждой строчке, то будет прорыв для языка в квадрате)Это причина, по которой unit тестами, тестируя отдельные функции, а не приложение целиком невозможно добиться того, чтобы тесты реально могли отражать тот факт, что приложение работает. Поэтому верхнеуровневые e2e тесты и ручное тестирование это единственное что может дать гарантии в реальном мире. Ибо мы говорим не про библиотеку.
Почему же? У меня все прекрасно работало и работает, просто я тестирую приложение верхнеуровнево и эти тесты сразу же охватывают всё. Я экономлю кучу времени, я занимаюсь разработкой, а не работаю тестировщиком вместо этого) Решение по мне очень удобное и понятное. Ты проверяешь конкретно работу АПИ, а не фантики в которые подсовываются фейковые данные, фейковые модули т.п.
Нет, зачем от них отказываться, просто для меня они не являются проблемой, ибо я следую KISS и YAGNI и у меня сложность не умножается в 10раз, а равна по сути сложности бизнес логики, т.е. мой коэффициент сложности приложения около 1, т.е. всё всегда максимально просто, насколько это возможно для данной бизнес логики приложения. А вот если бы я использовал nest, orm и ещё 100500 лишних переусложненный и абстракций, то коэффициент сложности уже был бы 10 и выше.
Никто не говорит что ручное тестирование на каждый чих, мы говорим о комплексном тестировании, где мы реально может гарантировать корректную работу. А это совокупность e2e + ручное, опять же под ручным я имею ввиду не в ручную АПИ тыкать, а смотреть сразу связку клиент сервер. Ну опять же, я то 100500 зависимостей побеждаю, потому что e2e, а вот unit'ами их просто невозможно победить, ну либо вся ваша работа будет в написании бесконечных тестов) И потом при изменении бизнес логики лавинообразное падении тысячи unit тестов, вместо падения от силы десятка e2e) Посчитайте насколько проще и быстрее e2e подправить и на сколько тысячи упавших юнитов)
Если отбросить реальность и жить в розовом мире, где бизнес логика приложения простая как 2х2, и максимум сложности там это просто CRUD, то да, вообще легко. Но блин, реальность просто не дает такой возможности.
Нет, наоборот, коннект живёт всегда, и не привязан к жизненному циклу запроса. Этим dependency и отличается от context.
Да нет же, он именно 1 раз создается и живёт всегда. Потому что это зависимость. А контекст создается и умирает вместе с каждым запросом.
Я не беру в расчет 0.01% от всех задач, которые мы решаем в 99.99% случаев, в них моего подхода более чем достаточно и он с головой себя оправдывает. Но да, может однажды в карьере появиться задача в которой, в которой DI действительно будет лучше, но шанс что такая задача встанет, крайне мал, поэтому и существует принцип YAGNI.
Согласен, просто таких задач подавляющее большинство. Но не абсолютные 100%, да. Я исхожу чисто из разряда статистической реальности, только и всего.
Логично, только если будет реально в этом потребность, в противном случае это будет во вред. Просто многие люди даже не пытаются думать, они сразу бездумно берут некий набор и на нем фигачат всё что угодно) Увидели что в каких-то вакансиях написано NestJS, значит только по этой причине они будут его брать. Увы и ах, люди такие люди)
Когда я пишу библиотеки, то легко справляюсь unit'ами и они там идеально подходят и вообще must have, но в приложениях для бизнеса я не могу им довериться сильнее чем e2e, плюс e2e дает мне гораздо больше свободы в плане того как я могу писать код. Код мне важнее тестов и скорости тестов) Пусть моё приложение будет быстрым, а тесты не самыми быстрыми, чем наоборот, приложение будет медленным, а тесты быстрыми)
Вообще не всегда, и при адекватных подходах и там и там, вопрос на сколько? Ответ я знаю) В среднем на 25-30% будет быстрее Go, но это из-за того что в ноде драйвер pg так себе по скорости, прям очень слабоват. А теперь другой вопрос, насколько быстрее и удобнее разработка на ноде?) Насколько система типов в Typescript круче чем в Go?) А ещё, если в Go не использовать самые быстрее подходы и инструменты, то он уже будет проигрывать ноде. Так что да, Go может быть быстрее ноды, но при определенных условиях и там и там, а может быть и наоборот и медленнее.
Посмотрите https://habr.com/ru/articles/890882/#comment_28042698
Ну вообще то, если говорить про адекватов, то очень даже быстрое и способное легко держать тысячи RPS, особенно если запускать через Bun, это бесплатно +20% производительности. И опять же можно далеко не простое, а очень больше и сложное, тоже изи. А вот если говорить про nestjs + orm, то да, там вообще производительность на коленях. Это скажем так позор языка.
Это смотря что использовать на ноде, если NestJS и ORM, то да. там производительность нулевая. Если человеческие инструменты использовать, то всё очень даже хорошо, не предел совершенства, но очень даже ничего.
То же самое относится к Go, очень сильно зависит от того какие инструменты там используются.
Вот я сравнил GO и Node.js(его честь защищает Bun), на ситации из реальной жизни, жизненный цикл запроса:
- 3 запроса в базу данных
- сериализация в JSON
- десериализация JSON
Код того, чем занимает хэндлер на Go (драйвер для постгреса
pgxpool(иначе было бы все печально по перформансу))Скрытый текст
Код того, чем занимает хэндлер на Node.js (драйвер для постгреса
pg)Скрытый текст
Где query1,query2,query3 это
Скрытый текст
Т.к. pgxpool в Go делает все запросы по умолчанию prepared statements, а pg в ноде нет, то чтобы сравнение было честным в ноде я тоже сделал чтобы они были prepared statements.
Результаты для Go:
Результаты для Node.js (в лице Bun)
Получается 9к RPS против 7k RPS, выходит что в среднем при условии что проект там и там пишет адекват, Go быстрее чем Node в среднем на 23%. А значит исходя из вашей математики, если Rust быстрее go на 20%, то Rust быстрее Node именно в задачах rest api, в среднем на 36%.
Но с точки зрения потребления памяти да, нода жрет конечно больше, не так что прям критично и в современных реалиях это не проблема.
Но справедливости ради:
- Львиную долю в проигрыше Node занимает драйвер pg, как бы можно куда быстрее сделать реализацию. И это я молчу про то, что в ноду можно портировать из C++ или rust драйвер для постреса и вот тогда совсем другой колин кор будет)
- В Go тоже pgx это не предел, я написал свой драйвер для постгреса и RPS в среднем на 20-25% больше если pgx заменить на мой.
Я с 2012 года в коммерческой разработке и за плечами больше 20ти проектов, и больше 8ми компаний
Разумеется интересно, у меня кругозор без границ, я не мыслю узколобо.
Ну вы даже не пытались конечно) У вас у увидел лишь "аргументы" из разряда, Java и .NET подходят лучше просто потому что. Якобы nodejs чем-то обелен и якобы на Java и .NET можно сделать то, чего нельзя на ноде. Плюс опять же якобы для больших проектов лучше angular или nest, они что, позволяют сделать то, что нельзя сделать с помощью react или express? Конечно нет, даже наоборот nest и angular накладывают ограничения. связывают руки, вставляют палки в колеса, про то, что на код при их использовании без слез и бутылки водки не взглянешь это я вообще молчу, просто месиво реальное в котором полезного кода 20% всё остальное это борьба с самими angular или nest.
И вот только не надо выдавать это за плюс, потому что плюсом такие вещи могут считать кто-то угодно, но явно даже не близко талантливые разработчики. Это всё равно что считать за плюс когда ты без разрешения не можешь выйти из дома и пойти туда, куда сам хочешь. Я с самого начала когда ещё писал на PHP уже презирал Symfony т.к. она сверх медленная, накладывает неудобства и ограничения, а если ее ещё с Doctrine ORM ее использовать, то это вообще труба, ну реально без шуток там 0 производительности, они в десятки раз медленнее чем код здорового человека. Разумеется я сразу написала своё решение которое потом годами со мной из проекта в проект ходило, было максимально быстрым и удобным в использовании. И ладно бы если бы за ущемление производительности я получал удобство, скорость и кайф в написании кода, как например в сделке Assembler vs Node.js) Но нет же, я по сути используя nest получаю только минусы, и "бонусом" производительность ниже плинтуса, а этой ой как "приятно" для настоящего разработчика, а не промысловика, которому пофигу на всё, который мериться со всем и терпит всё, лишь бы просто ЗП платили.
Эммм, с чего это? С того что он максимально медленный на сколько это вообще возможно? С того что код который он хочет чтобы писали используя его максимально неприятный и чрезмерно перегруженный? По каким таким мифическим причинам очень крупный проект на Express или Fastify хоть на грамм может уступить nest? Я вижу только сплошные плюсы по всем фронтам у Express и Fastify и сплошные минусы у nest. Тем более камон, быть бэкенд разработчиком и вообще ставить производительность на последнее место, ну это как бы вообще странно, это разве инженерный подход? Я вот себя бы вообще не уважал когда преднамеренно убиваю производительность если бы взял nest и ещё не приведи душу ORM какую нибудь, это будет вообще комбо.
Что?)) Вы из тех кто эту чушь где-то прочитали в 2015 году и поверили в нее?)) Я думал уже таких не осталось) Яндекс, Vk, Mail.rum Ozon, WB и т.д. и тп это вообще не энтерпрайз, это так, лэндинг, не более. Опять же, с чего это вдруг React или Vue могут быть хуже? Вообще причин 0, только в кривых руках, но в кривых руках всё будет отвратное, и уж тем более Angular, даже при прямых руках на его код без слез не взглянешь.
А вот и нет. У TS например очень развита система типов, чем далеко не все могут похвастаться. В плане производительности он легко обойдет Java и .Net, опять же если делать всё по человечески, а не брать nest и orm. Если смотреть на баланс удобства/скорости разработки/производительности, то по сути Node.js это золотая середина, а если вместо node запускать код используя Bun, то ещё за бесплатно примерно +20% производительности капает(проверял лично) в реальных условиях, REST API с запросами в БД и т.п., RPS в среднем на 20% увеличивается.
Nest да, это крайне плохой и неудачный инструмент. Fastify или Express - прекрасный (баланс удобства, скорости разработки, производительности, минимальном кол-ве лишнего говнокода и т.п.).
Увы, розовых очков не ношу, я реалист и знаю как всё устроено.
Мне нет) И никогда) Я не усложняю простые вещи ради усложнения ни при каких условиях. Я порицаю такой подход. KISS и YAGNI наше все. У меня все всегда предельно очевидно и просто.
Dependency - это зависимость. Допустим для хэндлера
GET /meмне нужен коннект к базе данных, это и есть зависимость(dependency).Контекст это некая сущность, например объект, который рождается в момент получения того же запроса
GET /somethingи проходит через всю цепочку промежуточных функций, например в этом объекте есть информация о том, авторизован ли пользователь, какая у него и т.п. А когда запрос завершается и мы отправляет ответ, то этот контекст умирает. А вот наша зависимость, например коннект к базе данных не умирает, он живёт всегда пока наше приложение поднято и не является чем-то уникальным для каждого конкретного запроса.Разумеется, ибо это максимально очевидный, наглядный и простой подход. Никаких загадок, всё строго и понятно, всем всегда и сразу.
Мы же не говорим про библиотечные методы и их разработку, где условно интерфейс Stream у сети и файловой системы может совпадать. Мы говорим о разработке конкретных приложений с бизнес логикой.