Оправдано ли будет использование NodeJS в качестве бэкенда крупного приложения?
Доброго времени суток,
У кого есть (или знает) крупные проекты на NodeJS с большим количеством посетителей (именно одновременных запросов). Сейчас backend написан одним человеком на коленке для быстрого запуска и сейчас стоит большая задача, переписать с нуля. Хочется взять NodeJS в качестве бэкенда приложения (конечно же с TypeScript для типизации и прочих плюшек). Чем-то NodeJS меня подкупает, но опасаюсь, что не справится с очень большими нагрузками. Хочется услышать мнение людей, которые действительно работали с NodeJS и с большими нагрузками на него. Фронт стоит на Angular (5 мажорная версия на данный момент), тем самым снижая n-нагрузки (ощущается, кстати, прилично)
Участвовал на highload cup с NodeJS, сначала очутился в "попе" рейтинга, из-за некоторых блокирующих запросов, но после правок вышел в 80, но после, конечно же, сместили меня C, C++, GO с нестандартными решениями (которые, конечно же, в большинстве случаев не сработали бы в настоящих проектах). И вот тут у меня по сей день возникает смешанное чувство. В какой-то мере NodeJS меня порадовал, но всё же я думал, что будет намного лучше...
sim3x, нет нет, вы не так поняли, точнее это я не так выразился. Я про написанный код на капе имел в виду. На Go у нас написано внешнее API на нескольких проектах. Уважаю язык, но не готов его использовать для бэкенда этого приложения
Если абстрактно сравнивать жс и го, интерпретируемый и компилируемый, то нет никаких причин выбирать жс
ПС обычно, что-то большое, переписывают с чего-то на ноду, матерятся и переписывают на джаве/го/кложуре
Историй про переписывание после етой операции на ноду еще не встречал
пишут, что потенциально С++ все равно быстрее nodejs
Following are the areas where Node.js is proving itself as a perfect technology partner. - В этих областях nodejs зарекомендовал себя как отличный партнер в технологии
● I/O bound Applications
● Data Streaming Applications
● Data Intensive Real-time Applications (DIRT)
● JSON APIs based Applications
● Single Page Applications
It is not advisable to use Node.js for CPU intensive applications. - не рекомендуется использовать nodejs для приложений, которые интенсивно используют CPU
sim3x, одной из главных причин является недостаточное, а то и полное отсутствие знаний данного языка в нашей команде. А в два человека мы писать данный проект не можем) Да и были некоторые трудности при написании внешнего API, связанные с рядом нестандартных решений. Но по скорости да, споров нету:)
Но я не хочу в данном случае обсуждать, что GO лучше. Это факт. По всей сути, у нас 3 варианта: php, python, nodejs. В противном случае придется либо делать обучение для всей команды, либо вовсе менять команду, чего делать, конечно же, не хочется. Почему-то хочется попробовать ноду, но хочу послушать мнение людей, которые работали с нею на реальных больших проектах, чтобы в конец убедиться. Потому что у нас опыт с nodejs заключался лишь в маленьких проектах, либо стыковке с другими стэками на бэкенде, ну и highload
sim3x, в понедельник ещё рассмотрю возможность использования GO. Если сделать обучение и внедрение хорошего Лида по данному языку. Правда будет довольно затратно, но наше с Вами обещание дало плоды в эту сторону
Иван Стройкин, видимо, можно упростить себе задачу и оставить языкам C или GO только то, что без них никак, типа интенсивные математические вычисления, с остальным хорошо справится node.js
Не слушай ты sim3. Он херню и говно по тостеру разбрасывает. Если команда хорошо знает js и в команде разбираются в математике и алгоритмах - пишите на чем угодно, лишь бы оно искусственно не тормозило все. Нода уже отлично себя зарекомендовала и продвигается и развивается уже который год, причем развивается семимильными шагами.
Все 4 яп ок для написания нагруженных решений
Если проект реально на года разработки и поддержки, то стоит потратить пару месяцев на параллельное создание на нескольких и смотреть как они себя ведут под нагрузкой на коде в исполнении вашей команды
Стоимость толкового спеца для всех ЯП примерно одинакова
Нанимать ТЛ со стороны, для уже сложившейся комманды - я б не советовал
А вот нанять гуру для ускоренного ввода в ЯП - неплохая идея
А после уже из своих выбрать ТЛ
Иван Стройкин, learning curve у go хороший - без доп наема справляются. Но если json может быть практически free form - типа для прямой записи в nosql, то такие объекты существенно хлопотнее на го обрабатывать
Мопед не мой.. Но знаю одного вендора игр для мобилок. Пару штук у них весьма популярны.
У них Nodejs (express, koa, sails - не знаю), основное хранилище - redis, вспомогательное - postgres.
Так же, есть общение по WebSocket и фоновый дэмон (вроде как на Kue). И немало Lua запросов в redis.
Я считаю, что с помощью многих инструметов можно написать одинаково как и хорошее приложение, так и плохое. Главное, как будете писать.
Само собой, будет несколько лидеров по производительности. Но не стоит забывать про экосистему/поддержку выбранного стэка.
Выбор за Вами. И совет, если возьмете NodeJS: никаких babel-node и ts-node не использовать. Только обычную ноду, без всяких флагов --harmony итд.
Mikhail OsherAnton Mashletov, зависит от проекта. ООП на беке нужно всегда, в 100% случаев без оговорок и тут поможет только TS. В то же время фронт не требует ООП и вообще 90% фич TS.
Так и не понял, имелось ввиду не использовать babel-node и ts-node на проде, т.е. использовать их локально, но в продакшене транспайлить в нативный JavaScript?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
