У меня желание в стиле: "хачу пырфоманс"
Везде восхваляют Express, хоть Koa и посовременнее, да быстрее, но все-таки хочется что-то менее мейнстримное, например: Total, Adonis и пр.
Но противоречащая сама себе информация в тырнете несколько сбивает с толку (нп: Total или Express быстрее друг друга)
Собственно, как уже сказал, мне нужен наиболее производительный фреймворк в целом, но так же и не скудный по функциональности
P.S. Надеялся услышать мнения реально разбирающихся во фреймворках node.js людей, с краткими описаниями предложенного ими фреймворком и преимуществами над аналогами и указания на ошибки в моем понимании чего-либо, а не токсичных "ыкспертов", пылающих, прямо или косвенно, от некорректной (по их уровню знаний) формулировки вопроса
В проектах в подавляющем большинстве случаев используют Express и Koa.
"Менее мейнстримовое" для вас с вашими вопросами будет отличным способом хлебнуть граблей.
Никакой "пырформанс" не спасет от ограничений вашего кода, который будет выполняться на всех фреймворках с одинаковой скоростью и плевать как быстро ваша шарманка открывает соединения. Лучше научитесь работать с Nginx.
Изучайте Express или Koa. Это решения, где мало что есть "из коробки", но они легко обвешиваются любыми модулями и middleware.
С Total будете не у дел и все равно придется в последствии изучать Express или Koa.
Джавараст Скриптович, Хотите total - берите total, кто ж вам запретит.
Если для вас эта картинка убедительна и вы ориентируетесь на нее в первую очередь - зачем вы спрашиваете?
"продакшен" не равно "самый быстрый". Самым быстрым будет какой-нибудь код собранный на коленке на ванильном JS под ограниченный кейс.
Из коробки mongoose, mysql, redis, socket, logger validation, graphql. К тому же он производительный. Ts и очень похож на angular. Этот фреймворк придется поучить если не знакомы с ts и ангуляром. Можете мельком посмотреть все в документации.
Джавараст Скриптович, для меня, как старого PHP-шника он очень похож на современный symfony (ну или явовский Spring):
0) Принцип структурирования кода в модули
1) Если использовать в связке с TypeORM - то это знакомые и привычные сервисы-репозитории-энтити
2) Dependency Injection
3) Аннотации
Есть такое понятие как бэкенд и фронтенд.
1) Бэкенд там где крутится бизнес логика, на java, php, go, etc..
2) Фронтенд то что обрабатывает запрос от клиента и уже отправляет на обработку, например nginx чаще всего, далее node.js тоже может быть им, но чаще можно встретить связку nginx->node.js->api(backend). nginx уже используется как балансировщик нагрузки меж нодами.
Суть моего посыла в том, чтобы не юзать на ноде фреймворк, он только обрабатывает SSR (для vue or react) и мелочевку в виде socket.io и бла бла бла.
Александр Дроздов, а я-то, дурак, думал, что фронтент - это само представление веб-сервиса(сайт), а не серверная часть, которая занимается серверным рендерингом)))
Ну и забавит возведение PHP над Node, будто она хуже справляется с подобными задачами)
Асинхронность - вот возьмем простой пример добавления статьи на сайт, используя ОРМ или чистым для mysql или mongo на node.js.
С клиента приходит ajax запрос на добавление с данными, добавление данных предположим добавляется долго ну секунды 3, это блокирующая операция.
Есть два варианта решения :
а) как ты хочешь с помощью промисов, тогда клиенту надо отдать сразу ответ, и обрабатывать не блокируя, тогда когда клиент поймет что данные добавились в БД? Опрос аяксом? сокетами?
Получается оверхед по коду и логике, так не делают чаще всего.
б) Дождаться ответа от сервера и отобразить клиенту что-то. Тогда операция блокирующая, и все запросы на ноду будут стопаться, пока не отработает основной скрипт.
Отсюда вывод, чтобы ничего не блокировать лучше юзать то, что лучше подходит для этого пыха там и т.п.
ради моего интереса, можно примеры?
Да тот же DI в симфони или ларавеле, нормальное ООП, нормальные ОРМ которые очень мощные, и куча библиотек (ну на ноде тоже есть, на пыхе больше) или другом языке, java, python)
Какая-то синтетика у вас...
Это не секундный пользователь(разок на сайт зашел, поглядеть) не надо за него переживать вроде: "а вдруг убежит?". Это контент-мейкер, для него оправдано ждать хоть день, скажи ему только, что "модерацию твоя статья проходит, жди, епт". После этих самых 3-х секунд, с сервака наш ценный пользователь получает ответ (200(все ок)/400(ошибка фронтендера)/500(ошибка бэкэндера))
Каким чудом "БД" и "аяксом" стоят вместе? Если речь шла о трехзвенной архитектуре, то стоило это сказать сразу) В таком случае, где проблема с узнаванием момента добавления данных в БД?
Ну, и собственно, решение: учимся кластеризировать ноду, и мы успешно обходим блокировки, словно Телеграм. Да, не как на пихаре, не будет сама по потокам раскидывать, но если все-таки научится, можно восхищаться распараллеленной асинхронностью.
Джавараст Скриптович, допустим у тебя 5000 пользователей, каждый из них делает запросы, даже допустим 10% будут из них блокирующими, даже по 1сек, это большой отрезок времени в сумме на 500 пользователей.
Ты не сможешь бесконечно расширять свои кластеры.
По итогу ты или сразу клиенту отдаешь ответ без данных, и говоришь типа запроси через 1сек, я тебе отдам че получилось.
Или делаешь бекенд синхронным многопотоковым как пыха или подобное.
Должен быть всегда максимально быстрый ответ для КАЖДОГО пользователя, никто не должен ждать кого то. Который ждет чего то серьезного, он пусть хоть 20 сек висит, а другие 4999 пользователей должны получить что хотят сразу
Мне так нравятся синтетические примеры вкупе с топкой за "более крутые технологии")
Должен быть всегда максимально быстрый ответ для КАЖДОГО пользователя, никто не должен ждать кого то. Который ждет чего то серьезного, он пусть хоть 20 сек висит, а другие 4999 пользователей должны получить что хотят сразу
когда у вас заканчиваются все свободные потоки, потому, что все заблочено ожиданием, у вас другие языки начинают магию применять?
Сначала свои собственные определения терминов "Фронтенд" и "Бекенд"..
Потом "лучше PHP вместо ноды" (как окажется потом, из-за дешевизны и наличия крупных фреймворков)..
Кормить страшилками про SSR по 3 секунды (хотя, видимо, проблема в самом проектировании)( или это опять неявное уползание темы в решение других задач (не SSR) сервером)..
Запросы к базе у него блокирующие и безответные..
Асинхронщина у него проблемная..
PHP у него используется "для серьезных вещей" и это не потому, что изначально древний проект писался на нем... А, или нет, мы опять уползаем и на самом деле говорили про Go и пр. очевидно более крутых технологиях, но так, что бы было размыто..
Элементарно было бы просто пройтись по гуглу, чем такое писать)
Все что я написал взято не из облаков мыслей, а заюзал на практике.
Судя по тому что вы пишите, еще не сталкивались с этими проблемами, но предстоит как только начнешь писать на фреймворке под нодой.
начала свои собственные определения терминов "Фронтенд" и "Бекенд"..
Александр Дроздов, работаю с нодой уже лет 6. Используем ее в разных проектах и как фронт и как бек или для всего сразу.
Мне кажется вы не до конца разобрались в технологии и переносите собственные архитектурные ошибки на недостатки технологии.
PHP это что бы быстро накидать, но если работать на перспективу то сейчас нода объективно интересней.
Там внизу табличка есть, где Python на втором месте после C и перед Rust по показателю RPS, есть предположения, что за магия?) Ужаснула такая несправедливость)
Джавараст Скриптович, Нужно смотреть код.
Я этого делать сейчас не хочу) Поэтому могу только высказать очень субъективное мнение.
Ничего "несправедливого" в этом нет (под капотом там uvloop и picohttpparser, которые, кстати, написаны на C). Фреймворк асинхронный, что дает приемущество перед синхронными в RPS.
Простой
Простой
Такие картинки, почему-то, считают иначе.
