Комментарии 31
Возникает большой вопрос, а зачем нужны такие извращения? Ну если нужно общаться между приложениями можно использовать сокеты! А про потребление памяти вообще кто нибудь думал, что в nodejs утечки большие, что в jvm?! ИМХО
Согласен, извращенность в этом есть, хотя я бы скорее назвал это непривычностью. Общение через сокеты подразумевает ряд усложнений, нужен интерфейс взаимодействия, нужно настраивать окружение, следить за ошибкам и падениями в разных местах, обрабатывать ситуации когда один из сервисов недоступен. Автор предлагает более простой способ интеграции. Хотя, конечно, всё зависит от конкретного проекта.
Лучше jvm внутри node.js запускать :)
часто наблюдаю статьи, где описывается следующая архитектура:
нода выступает в качестве фронтенд-сервера (рендерит вьюшки, собирает данные с бэкенда), а бэкенд (который был написан 5 лет назад программистом, который уже сменил работу) остается прежним
нода выступает в качестве фронтенд-сервера (рендерит вьюшки, собирает данные с бэкенда), а бэкенд (который был написан 5 лет назад программистом, который уже сменил работу) остается прежним
Я могу понять людей, которые хотят перестать писать серверную часть на Java (хотя сам к ним не принадлежу), но выбор Js как языка, заменяющего Java, откровенно спорный, по крайней мере для меня.
Если у вас команда Js разработчиков, то все понятно, но зачем тащить Java рантайм и плюс к тому писать прокладки и подкладки на неродной Java, а если, наоборот, нужен сервер в JVM, но без Java, то кроме очевидных вариантов Groovy, Scala, Kotlin и т.д. есть довольно зрелые проекты, вроде JRuby.
Но мир велик, если у кого-то есть реальый юзкейс или был юзкей под который хорошо бы лег J2V8 — поделитесь=)
Если у вас команда Js разработчиков, то все понятно, но зачем тащить Java рантайм и плюс к тому писать прокладки и подкладки на неродной Java, а если, наоборот, нужен сервер в JVM, но без Java, то кроме очевидных вариантов Groovy, Scala, Kotlin и т.д. есть довольно зрелые проекты, вроде JRuby.
Но мир велик, если у кого-то есть реальый юзкейс или был юзкей под который хорошо бы лег J2V8 — поделитесь=)
Например, существует старое веб-приложение. Его новая клиентская часть написана на React, но у этого нового подхода есть один жирный минус — весь рендеринг происходит на клиенте и пользователи ненавидят ждать целых полсекунды, пока все отрендерится и спиннер уйдет с экрана.
Тут на помощь приходит сервер-сайд рендеринг при помощи J2V8.
Почему попросту не инсталлировать Node.js? А потому что приложение устанавливается на сервера клиентов, убедить которых в том, что им нужен Node.js настолько сложно (и, возможно, чревато потерей тех самых клиентов), что проще использовать J2V8.
Тут на помощь приходит сервер-сайд рендеринг при помощи J2V8.
Почему попросту не инсталлировать Node.js? А потому что приложение устанавливается на сервера клиентов, убедить которых в том, что им нужен Node.js настолько сложно (и, возможно, чревато потерей тех самых клиентов), что проще использовать J2V8.
НЛО прилетело и опубликовало эту надпись здесь
Вопрос не в скорости, а в совместимости. Плюс Node.js несколько шире чем просто JavaScript, посмотрите список модулей, которые есть в его ядре.
А вот кстати насчет совместимости. Я понимаю, что Rhino возможно достаточно устарел, по сравнению с V8, а вот Nashorn? Там по-идее ECMA 5.1, этого недостаточно, чтобы запустить Node?
НЛО прилетело и опубликовало эту надпись здесь
Node это АПИ поверх V8, другие движки именно нодой не запустишь. Но есть и другие сервера на JS, может их и можно будет запустить
Погодите, с чего это вдруг только V8, когда вот же другой движок — https://github.com/nodejs/node-chakracore?
Про другие сервера я в курсе, серверного JS в природе полно, в самых неожиданных местах. Хоть я и не фанат такого подхода — но для некоторых задач это удобно.
Все-таки, это официально не поддерживаемый аддон к обычной ноде, который, как написано у них в гитхабе является шимом для апи к V8
Ну и фраза с оф. сайта ноды: Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
А почему бы просто не сделать отдельный сервер для темплейтов и отдельный для API? Пусть ваш старый-проверенный API бегает на Java'е, а рендеринг React сделать на Node, и просто проксировать соответствующие URL'ы любым прокси сервером (а то и вообще написать фронт с учетом, что у вас 2 сервера)
Я определенное время назад искал именно такое решение. Мне в одном java приложении необходимо было запустить трансляцию jade. Существующая реализация jade на чистой java мне не подошла. А то что я нашел для работы node в jvm выглядело печально. Было несколько проектов, но они не развивались и поддерживали только древнюю версию ноды. Пришлось извращаться через запуск процесса ноды из приложения со скриптом враппером, с которым программа общалась через именованный канал. Оно конечно работает… как то)) Но в ближайшее свободное время я полезу копаться в J2V8 для оценки интеграции его в этот проект. И есть надежда что мне это развяжет руки в интеграции гулповых тасков в java приложение. Тогда я вообще буду доволен как слон))
Просто комбо говняных «технологий»
Это самое ужасное, что я видел в своей жизни. Смесь из строго типизированного языка и JS.
Как быть с типами? Object'ами общаться?
Как быть с типами? Object'ами общаться?
Запуск Node.js на JVM позволяет легче провести миграцию для любого, кто использует большой Java стек, но хочет начать использовать Node.js. Например, Вы можете запустить на Node.js сервер (такой как Express.js) и вызывать существующие методы Java для обработки запросов.
Интересно каким образом это облегчит миграцию?
Если у вас какой-то javaEE сервер, допустим TomCat — вам нужно будет задеплоить в него этот javaj-express-js и это уже будет Веб-сервер внутри веб-сервера. Чтобы уйти от EE монстра создадим еще большего монстра.
А для маленьких standalone серверов нету смысла использовать такой подход, легче будет сразу переписать все на node.js и не заморачиваться.
Указанный подход лишь породит ошибки, которые не свойственны ни js, ни java, которые будут где-то на стыке и которые никак не отловить. Кроме того, производительность такого решения будет хуже чем чистое JVM или чистое Node.JS решение, JNI вызовы дорогие и они плохо отпимизируются.
Указанная реализация больше похожа на попытку запустить express.js на jvm и проверить производительность. Или для попытки сделать более простым написание нативного кода, чтобы повысить производительность. Но никак не для того, чтобы предоставить мост для миграции с java на js.
Осталось только java запустить в node.js и все будет ок.
это возможно node-jvm
Выше писали — уже есть.
Особенно здорово будет отлаживать и править js код созданный путем конкатенации java-строк…
Астрологи объявили неделю J2V8, Количество людей, путающих Java и Javascript, увеличится вдвое.
Поскольку каждая библиотека пишется под свою среду, то иногда всё-таки очень удобно заграбастать что-то, написанное на javascript, php, python и других языках https://en.wikipedia.org/wiki/List_of_JVM_languages. По мне так это просто здорово, что я могу взять что-то на javascript и использовать в java. Единственную проблему, которую я вижу — отладка такого кода. Но для JavaScript эта проблема решена в Idea: https://blog.jetbrains.com/idea/2014/03/debugger-for-jdk8s-nashorn-javascript-in-intellij-idea-13-1/ а вот для Eclipse всё никак не сделают. Есть ли отладчики для других языков пока не слышал, но направление хорошее.
Использовать библиотеку для js поверх jvm — звучит хорошо!
Но ведь для этого есть все тот же nashorn и еще парочка других движков. Для использования js библиотек не нужно затягивать целую node.js экосистему в jvm.
А если все же по какой-либо причине нужно использовать библиотеку, которая работает только под node.js — лучше уже поднять node.js отдельно и настроить общение через какой-то канал связи (сокеты, вебсокеты, http, message queue). Но это уже пахнет проблемой в архитектуре.
Но ведь для этого есть все тот же nashorn и еще парочка других движков. Для использования js библиотек не нужно затягивать целую node.js экосистему в jvm.
А если все же по какой-либо причине нужно использовать библиотеку, которая работает только под node.js — лучше уже поднять node.js отдельно и настроить общение через какой-то канал связи (сокеты, вебсокеты, http, message queue). Но это уже пахнет проблемой в архитектуре.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запускаем Node.js на JVM