Есть сервера, которые стоит написать именно на Java, а не на Node?

Question

[MishaXXL]

Из прочитанных статей я понял, что для REST серверов лучше Node не найти, но выходя за эти рамки, есть сервера, которые на Node сильно уступают серверам, написанным на Java?
Например стриминговый сервер или сервер для чата, он же относится к разряду типичных запрос/ответ и так же на Node будет эффективней?

Если выбирать Java для веба, то в чем она лучшая там?

Comments

[Asker1987]

При прочих равных (грубо равных) выбирают Node, так как порог входа очень низкий, что очень удобно для тех же фронтендеров.
Если же посмотреть вакансии Java, можно обнаружить сплошные highload системы, микросервисные архитектуры и т.д. Игрушечные стартапы и проекты можно на NodeJS писать, однако enterprise только Java. При этом небольшие проекты на Java тоже легко пишутся с помощью экосистемы spring, просто фронтендеры стоят дешевле.

[VolgaVolga]

Asker1987,

что очень удобно для тех же фронтендеров.

Я думал, адепты этого мифа вымерли либо поумнели.

Answer 1

[Everything_is_bad]

что для REST серверов лучше Node не найти

это твой главный неправильный вывод, лучший будет тот, который написан на технологии, которую лучше всего знает исполнитель.

Например стриминговый сервер или сервер для чата, он же относится к разряду типичных запрос/ответ

еще одна большая ошибка, вообще всё смешал в кучу, "стриминговый" это больше про максимальный pull c сервера, "чата" это про полноценный обмен в обе стороны, а "запрос/ответ" это про базовый http и он для этих обоих случаев, очень невыгодная стратегия, поэтому для них в http написаны свои частные протоколы, например, websocket для нормальной реализации чатов.

Comments

[MishaXXL]

Так есть разница в реализации этих серверов на Java и Node?
Или эффективность работы серверов будет одинаковой и нет смысла какие-то сервер писать на Java, а какие-то на Node?

[Everything_is_bad]

MishaXXL,

эффективность работы серверов будет одинаковой

эффективность работы будет разной даже при написании на одинаковых технологиях. Чем больше сложность, тем больше она уже зависит от исполнителя. Кстати, ты вообще сравниваешь ЯП и среду исполнения другого языка, это уже не сильно корректно.

[Everything_is_bad]

MishaXXL, вопрос вообще про сферического коня в вакууме, по факту, в реальном мире есть реальные исполнители, разной квалификации и реальное ограничение ресурсов. А сложные проекты приходят к кому, что их части могут быть написаны на разных ЯП и технологиях.

[Влад aka iamkisly]

Например стриминговый сервер или сервер для чата, он же относится к разряду типичных запрос/ответ

Поддержу предыдущих комментаторов, тут намешалось тёплое с мягким. Почитай что такое QoS, и какие требования к задержкам у стриминга, у чатов, и у веб приложений. У тебя даже провайдер потоки данных разных типов по разному приоритезирует.

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

Node специфически работает с потоками. Они организованы иначе чем в Java или dotnet. Воркеры, это скорее мультипиоцессинг.. зато это позволяет относительно легко масштабировать приложение, но не только лишь все могут это эффективно использовать.

[QWERTYUIOPas]

и он для этих обоих случаев, очень невы

Вместо запятой должно быть тире.
Сравните:
москва - очень большой город
он - очень невыгодная стратегия

Answer 2

[VolgaVolga]

Если выбирать Java для веба, то в чем она лучшая там?

Примерно ни в чем.
Был вопрос насчет реализации многопоточности в Node, но и его вроде как решили.

Comments

[MishaXXL]

Т.е. Java для веба это что-то устаревшее с чего уходят и оно живо лишь в тех компаниях, откуда его уже не убрать?

[Everything_is_bad]

MishaXXL, ограничение ресурсов
1. у тебя в наличие свободная команда лучше всего пишущая на PHP
2. у тебя в наличие один крутой спец по C#
так на чем будет новый проект на JS или на Java?

[VolgaVolga]

MishaXXL, нет, просто в умелых руках - всё балалайка.

Answer 3

[Vahman]

Закидают меня тряпками, но Java будет лучше во всем, но все ещё недостаточно хороша. Для сервер сайд посмотрите на .net, go, rust. Если вам нужно примитивные рест апи сделать, то нода отлично сработает, есть и фреймворки неплохие. Но для чего-то серьёзного по ресурсам не стоит выбирать ноду, имхо

Comments

[VolgaVolga]

Java как минимум не хуже .NET, Go - для небольших и шустрых сетевых сервисов и не более, Rust - вообще для вселенной C и C++.

[Бектур Муратов]

На ноде можно выполнять тяжёлые задачи, передав задачу либо другим потоками либо выполняя задачу асинхроно:

let i = 0;

let start = Date.now();

function count() {

  // делаем часть тяжёлой работы (*)
  do {
    i++;
  } while (i % 1e6 != 0);

  if (i == 1e9) {
    alert("Done in " + (Date.now() - start) + 'ms');
  } else {
    setTimeout(count); // планируем новый вызов (**)
  }

}

count();

[Odissey Nemo]

Бектур Муратов, писать асинхронно можно почти на чём угодно. И скорее всего, без применения дополнительных библиотек.
Я бы писал на том, на чём привык в любом случае, когда не спускают язык в задании сверху.
Например, недавно ВЕБ-сервис приказали писать на Kotlin, т.к. он перспективный и для Смартфонов получше. Пришлось подучить и написать, вместо Java. Получилось в коде короче плюс асинхронность весьма удобная, но - дольше.
И никакой разницы снаружи. Плюс строка в резюме, которая мне уже не нужна.

[Бектур Муратов]

Odissey Nemo, я просто пояснил что ноду можно использовать в тяжёлых задачах. Главное не блокировать основной поток

Answer 4

[Орхан Гасанлы]

Многое зависит от ваших умений и знаний, а также от задачи, которую нужно решить..

Если вы владеете лучше нодой, то пишите на ноде. Другое дело, сможет ли нода решить задачу, которую вам нужно решить. На java написано куча библиотек, которые решают множество повседневных задач. Сам язык и его фреймворки используются в highload cистемах в энтерпрайз.

Я широко использую язык Java для повседневных задач, но также иногда предпочитаю использовать Go.

Answer 5

[Dmitry Roo]

Если выбирать Java для веба, то в чем она лучшая там?

Примерно всем.
Был вопрос насчет времени запуска приложения, но и его вроде как решили.

Comments

[MishaXXL]

Примерно всем это чем?
Чем будет лучше сервер написанный под стриминг или чат на Java, чем на Node?

[Dmitry Roo]

MishaXXL, ну, во-первых, если мы говорим про ноду - это автоматически богомерзкий js со всеми его уродствами, в противовес прекрасной джаве. Как по мне - этого уже вполне достаточно.
Во-вторых - производительность.
В-третьих - инструментарий, который для всей js экосистемы абсолютно чудовищный.
В-четвёртых - писать на js что-то сложнее hello world совершенно невозможно.
В-пятых - у вас неправильно поставлен вопрос. REST - это только точка входа, сама по себе не имеющая смысла.

[Kentavr16]

Dmitry Roo, очень смешно читать про прекрасную джаву и богомерзкий джаваскрипт в разрезе веба. Я бы ещё понял шарписта который бы рекламировал дотнет, но джава... Надеюсь ответ был на сто процентов ироничен.

[Dmitry Roo]

Kentavr16, с радостью почитаю ваши контраргументы.

[Kentavr16]

Dmitry Roo, а были аргументы? Из всего написанного - вменяемое слово производительность, но и оно не подкреплено ничем.

[egribanov]

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

Answer 6

[Влад aka iamkisly]

для REST серверов лучше Node не найти

РЕСТ может быть выполнен на чем угодно, хоть на pure c. Вопрос скила и удобства. Node полюбили за то что фронтэндерам не надо вкатываться с нуля, но это не делает его лучшим.

Answer 7

[My1Name]

Обычно в Node.js весь код на JavaScript выполняется в одном потоке. Для асинхронного выполнения задача помещается в очередь задач. Иными словами, при создании 1000+ сокет соединений, JS будет создавать очередь и тормозить. И это ограничение производительности распространяется буквально на всё, в том числе при работе с файлами, а не только на REST приложения.

JavaScript — это высокоуровневый ЯП, а компьютер понимает только единицы и нули. Проще говоря, JS проходит через интерпретатор, который построчно преобразует исходный код в эквивалентный машинный код.

Java в умелых руках работает с байт-кодом. Java проходит через компилятор и окончательный код, который выдает компилятор, оптимизирован и выполняется намного быстрее.

Плюсы и минусы интерпретатора и компилятора

Кроме того, невзирая на все нарекания фронтов, гораздо проще и удобней использовать jQuery в сочетании с Ajax и Java сервером, когда речь идёт о web разработке.

Comments

[MishaXXL]

Разве при создании 1000 сокет соединений на Java, он не начнет тупить из-за нехватки памяти на каждый новый поток?

[My1Name]

MishaXXL, Во-первых на 1000 соединений проблем с нехваткой памяти быть не должно. А во-вторых в Java проблемы с памятью решаемы.
https://javaupdate.ru/help/kak-uvelichit-pamyat

https://habr.com/ru/articles/549176/

Я когда-то писал "web-spider", который коннектился каждую секунду к 50 разным доменам (это Max. на моём старом ПК на win7), через мин. ~2-3 возникала проблема с нехваткой сокетов, но не с памятью.

https://habr.com/ru/articles/661169/

[Everything_is_bad]

JS будет создавать очередь и тормозить. И это ограничение производительности распространяется буквально на всё, в том числе при работе с файлами, а не только на REST приложения.

это без проблем решается запуском нескольких инстансов, главное сразу подумать про такую работу

Проще говоря, JS проходит через интерпретатор

там уже всё намного сложнее и Node.js умеет много из компилятор про оптимизацию кода

Java в умелых руках работает с байт-кодом.

а в неумелых уже с чем-то другим работает?

гораздо проще и удобней использовать jQuery в сочетании с Ajax и Java сервером

вот и уехали на 10 лет назад, jQuery уже фактически легаси, pure js в современных браузерах достаточно

[My1Name]

Everything_is_bad,

уже всё намного сложнее и Node.js умеет много из компилятор про оптимизацию кода

Сложнее != Лучше. В любом случае JavaScript проходит через интерпретатор и парсеры. А программист Java сам пишет интерпретатор... Код Java в скомпилированном виде - это байт-код. JavaScript проходит через парсер и конвертируется в байт-код в процессе выполнения. То есть Java уже на этой ступени в 2 раза быстрее.

в неумелых уже с чем-то другим работает?

Можно построчно работать с файлами как в JavaScript... Особенности Java - это возможность использовать stream практически везде. И эта особенность позволяет использовать железо по максимуму. Рангом ниже - C/C++ и ассемблер (машинный код).

вот и уехали на 10 лет назад, jQuery уже фактически легаси, pure js в современных браузерах достаточно

Достаточно - это кто сказал!? О_0 Тот, кто утверждает, что читая построчно кучу строк кода в одном потоке, JavaScript работает быстрее?

[Everything_is_bad]

My1Name,

А программист Java сам пишет интерпретатор

чего, зачем ему писать интерпретатор?

JavaScript проходит через парсер и конвертируется в байт-код в процессе выполнения. То есть Java уже на этой ступени в 2 раза быстрее.

откуда взялась цифра 2, почему не 3?

Можно построчно работать с файлами как в JavaScript... Особенности Java - это возможность использовать stream практически везде.

как это связано с "Java в умелых руках работает с байт-кодом."

[Everything_is_bad]

My1Name,

Достаточно - это кто сказал!?

то что jquery устарел это давно известный факт

О_0 Тот, кто утверждает, что читая построчно кучу строк кода в одном потоке, JavaScript работает быстрее?

ты придумываешь какие-то фантастические связи, вот теперь связал jquery с каким-то "утверждением", которые еще и сам выдумал

[Turbine]

My1Name, чувак, успокойся. По твоему первому сообщению уже видно, что ты не шаришь в выполнении js и java кода. По секрету тебе скажу, что в js тоже есть компилятор. Почитай, как работает v8 (движок js в node), что такое jit. Потом про event loop и web workers. Никто никаких своих интерпретаторов не пишет и код в Java, если что, тоже проходит через парсер. Стадия "парсинга" вообще во всех языках есть так-то и она может быть хоть в 10 потоках. Это выполнение кода по дефолту происходит в одном потоке, как и в Java.
Ну и jquery в 24 году...
Короче, как поржать с того, как ты пытаешься казаться умным, но при этом не шарить нормально ни в чëм и ещë застрять где-то в 2010 - пойдëт

[Андрей Молчанов]

My1Name, а ну то есть обзывание юзеров другого ЯП теперь называется "пишу фактами"? Да, обмельчали конечно джависты. Срать другие ЯП в хорошем обществе уже моветон. А по поводу "фактов" половину вообще можно списывать в утиль ибо это откровенное набрасывание на вентилятор не подкреплённое никакими фактами.

Порой охреневаешь от того сколько всяких разных технологий появляется, за всеми следить не успеваешь, а у вас Java+jQuery топ стек оказывается, да вы дяденька тот ещё ретроград))

А по поводу подноготной js, v8, event loop и прочих вещей, как и человек выше, всё же рекомендую ознакомиться. А то вы что-то говорите про обучение, а сами походу это дело забросили где-то лет 10 назад.

Answer 8

[DamirMur]

А дело даже не в языке, скорее плясать надо от конкретных задач, окружения, потребностей заказчика.
"WhatsApp - это XMPP и работает он на ejabberd, опенсорсном XMPP-сервере. А ejabberd написан на эрланге, да."
Веб-сервера - это зачастую посредники, и не надо на них всё навешивать. В Node.js есть NPM-пакеты, которые при инсталле компилируются из Си и здесь производительность явно не хуже Java.
Если разрабатывать проект (front-, back-end) в одиночку, по мне, лучше на чем-то одном, а это, по определению, JS. Если проект большой и куча бабла, то да, можно и повыбирать что на чем делать, под него и спецов поискать.
Ну и кстати, сейчас всякие ИИ достаточно хорошо и быстро переписывают библиотеки и модули, с одного языка на другой.

Answer 9

[Виктор Кожухарь]

Выскажу свою личную точку зрения:
1. Изучаем, каким будет трафик сервиса на старте. Если это замена уже работающему высоконагруженному сервису, либо вы на 200% уверены, что нагрузка прямо сразу будет высокой и дальше на 200% точно уверены, что нагрузка будет расти, не выбирайте ни ноду ни Java. Берите, например, Go. Он гораздо быстрее ноды, там даже стандартная библиотека уже имеет готовые решения для всего нужного REST, и есть куча прекрасных сторонних библиотек и фреймворков.
2. А вот если ваш проект новый, вы не знаете, сколько у вас будет пользователей, какая будет нагрузка, то не надо даже думать: берите то решение, которым вы владеете, и с помощью которого вы сможете быстро и дёшево собрать первую версию. Если это даже PHP, то пусть он и будет. С огромной вероятностью ваш сервис будет всё равно переделан и переписан позже, поэтому, чем меньше вы потратите времени и денег в самом начале, тем быстрее выйдете на рынок, и тем больше сэкономите первоначальных инвестиций. А когда проект начнёт приносить прибыль, вот тогда при помощи уже этой прибыли будете решать проблемы производительности

Answer 10

[goleon]

Полагаю дело в стереотипах: под node неблокирующий io, под java - блокирующий и нет зеленых тредов. Но это не так. В можете взять quarkus с его mutiny и базу поддерживающую неблокирующий вывод (постгре или другую) и будет счастье. Правда java хочет больше памяти, т. к. пока нет возможности маппить сложные стуктуры в память, все через кучу объектных ссылок. Но навряд ли это будет проблемой, если речь не про миллион соединений.
Пишите на том, что вы знаете хорошо. Можете на node, можете на go, можете на java, если хотите - на rust и tokio