Java + NodeJS общение через сокет: плохая идея?

Question

Мне нравятся некоторые функции NodeJS, в частности, JQuerification, совместимость веб-сокетов с помощью socket.io, движки view и css, которые я не могу использовать с JSP (и, конечно, асинхронные вызовы). По крайней мере, насколько я знаю. Поэтому я планирую создать приложение, в котором серверной частью будет Java, а внешний интерфейс будет сгенерирован NodeJS. Внешние формы отправляют данные в NodeJS, который передает их в бэкэнд Java через соединения сокетов между NodeJS и бэкэндом Java. Таким образом, NodeJS в основном действует как промежуточное ПО между внешним интерфейсом и внутренним сервером Java.

Это будет довольно большое приложение, и мой план выглядит захватывающим, но буду ли я ненавидеть себя за то, что пойду по этому маршруту?

Преимущество, которое у меня есть, заключается в том, что я могу иметь много графиков и панелей мониторинга в реальном времени и улучшать взаимодействие с формами.

Answer 1

Проблема в том, что вы говорите об общей платформе.Node.JS в качестве внешнего интерфейса, JAVA в качестве внутреннего.В зависимости от ваших реальных потребностей это может быть изумительно или ужасно.

И что?Люди будут отвечать своим заполнением в зависимости от того, предпочитают ли они зрелые технологии или нет (или что-то еще).

Hype

Основная причина, по которой человек думает о node.js, - это реклама,Как база данных XML несколько лет назад.XML был классным, и все должно было быть сделано с XML ... если вы заметили, никто больше не говорит о базах данных XML.

Так что node.js - новый, блог о вас говорит об этом и связан сДля базы данных NoSQL она должна идеально подходить.

Асинхронный ввод-вывод

Затем идут оправдания, такие как асинхронный ввод-вывод.Ты знаешь?То, что находится в стандарте POSIX, может быть более 20 лет.Да, что вы узнали в школе на вашем курсе C.Кстати, стандартный JAVA API тоже его поддерживает.На самом деле, если вы слушаете создателя node.js, это не новая концепция, а использование только асинхронных библиотек.Большинство библиотек используют потоковую модель и не могут использоваться для асинхронной работы.Javascript не был целью как таковой, но отсутствие какой-либо стандартной библиотеки в JS было хорошей отправной точкой, так как это помогло бы избежать того, что среднестатистический пользователь joe испортил все, включая неправильную библиотеку.Это не я сказал это.

Дело в том, что сейчас есть несколько библиотек, но некоторые, если таковые имеются, поддерживаются компанией.Мы все еще не там.И в то же время стандартная профессиональная среда уже поддерживает асинхронное поведение при необходимости, например, длинный запрос HTTP-запроса.См. Lift Framework, см. Поддержка Jetty или Tomcat для NIO.

Как база данных XML.Теперь профессиональные базы данных, такие как Oracle, поддерживают XML.Так что, если вам это нужно, вы можете сохранить свою стандартную высокопроизводительную базу данных ... И специализированное решение, которое может сделать только это ... Ну, никто не помнит даже его имя.

Javascript

Теперь для JavaScript.Javascript был смелым выбором ... Из-за отсутствия библиотек.Вы знаете, чего еще не хватает.Вот почему вам нужен Java-сервер в любом случае!Но не только это ... Поддержка IDE для JavaScript не очень хороша.Автозаполнения?Еле работать.Рефакторинг?Вы шутите?Многопоточность?Нету.node.js похож на windows 3.1.Он использует совместную многозадачность.

Заключение

Node.js - это весело, но незрело.Вы сказали это сами, вы должны выбрать Java, чтобы вы могли делать реальные вещи, такие как подключение к базе данных.Этот стек добавляет сложности с другим слоем.

Либо вам это действительно нужно, и это может быть хорошим компромиссом ... либо вам это не нужно, и вы просто себе нравитесь ... и ненавидите себя позже, когда видите, что тратите больше времени на все.... просто чтобы сказать, что у вас есть 4-слойный стек (браузер, Node.js, JAVA, DB) вместо 3. Просто для обмана и теории удовольствия.

Answer 2

Для меня план звучит разумно само по себе. Но из моего опыта важно, что ваша команда достаточно сильна, чтобы выдержать это. В этом случае я бы не пошел по этому пути, если бы не было хотя бы двух хороших разработчиков, одного для серверной части и одного для внешнего интерфейса. В противном случае слишком просто потеряться при работе с таким количеством структур / концепций, и ничто не заканчивается.

Кроме того, я бы позаботился о том, чтобы сделать коммуникационный уровень между задним и внешним интерфейсом легко тестируемым, что исключило бы сокетные соединения. Если ваши требования к производительности это позволяют, я бы выбрал браузерный интерфейс в стиле REST. Это также позволило бы в дальнейшем отказаться от «причудливого» интерфейса с меньшими усилиями и внедрить что-то в JSP или что-то еще. На случай, если это выйдет из-под контроля ...

Answer 3

Лично я чувствую, что с NodeJ приятно пообщаться.Однако я бы не стал использовать его в производственной среде.Особенно, если производственная среда будет обрабатывать критические данные.

Я бы, вероятно, подождал, пока она не достигнет версии 1.0.

Но если вы планируете использовать ее для некритических приложенийЯ бы сказал, пойти на это.Это всегда хорошо для начала, и я думаю, что по мере роста вашего приложения NodeJS также будет развиваться.

Опять же, это мое личное мнение.Я использовал NodeJS только в своих сторонних проектах, я никогда не использовал NodeJ в любой производственной среде.

Answer 4

Собираетесь ли вы нанимать разработчиков для работы над вашим проектом или это соло?Если вы планируете когда-либо масштабировать команду разработчиков, я обнаружил, что минимизация общего количества дискретных технологий в вашем продукте обычно имеет преимущества в масштабировании команды, которые в массовом порядке перевешивают преимущества производительности и / или производительности, добавляя, чтотехнология.Каждая технология, которую вы добавляете, усложняет наем кого-то, кто является экспертом во всех из них, и значительно увеличивает вероятность того, что когда вы нанимаете кого-то, кто не является экспертом во всех из них, они что-то напортачат, потому что у них многоучиться.

Ваши аргументы в пользу использования node.js кажутся довольно слабыми;В Java нет ничего такого, что могло бы сделать ее неспособной создавать «графики и информационные панели в реальном времени и улучшать взаимодействие с формами».Добавление технологии в сочетание, поскольку она предлагает «функции», которые на самом деле не являются необходимыми для достижения ваших бизнес-целей, часто является ошибкой.Вы также упоминаете Redis, который я бы поставил в той же лодке.Оба узла и redis - это круто (возможность сказать, что о технологии, которую вы хотите добавить в свой микс, всегда должны звучать предупреждающие сигналы, кстати) и иметь законные варианты использования, но то, что вы описали, не похоже на одно.Если Java уже проделывает тяжелую работу, добавление асинхронного «среднего уровня» не принесет вам значительных результатов с точки зрения производительности.

Если вы опубликуете более подробную информацию о характеристиках вашего приложения, ожидаемую нагрузку,и обработка, выполняемая по запросу, вы, вероятно, получите более полезные комментарии о лучшей архитектуре.Удачи тебе!

Answer 5

Если вы собираетесь программировать какой-то бэкэнд в Java, почему бы не сделать все это в Java?

Не уверен, что вы подразумеваете под "Мне нравятся некоторые функции NodeJS, в частности, JQuerification, совместимость с веб-сокетами через socket.io, механизмы просмотра и CSS, которые я не могу использовать с JSP (и, конечно, асинхронные вызовы)."

jquerification - вы имеете в виду jquery? Вы можете сделать это с помощью JSP.

websockets в Java: http://caucho.com/resin-4.0/examples/websocket-java/index.xtp,, хотя вы могли бы также сделать комет сервера, так как он поддерживается сервлетом 3.0

какой движок css нельзя использовать с jsp?

что вы подразумеваете под асинхронными вызовами?

для меня node.js больше о том, хотите ли вы неблокирующий сервер. если это требование, вы можете сделать это и в Java - большинство современных серверов поддерживают настройку для NIO.

Answer 6

Я думаю, что nodejs отлично подходит для первого уровня, где мы работаем над заданиями по обработке ввода-вывода.

Второй слой может быть брокером, подобным rabbitmq. Последний уровень - это ваша бизнес-логика, которая реализована на Java. Поэтому я предлагаю взглянуть на

мой подход, который является своего рода хаб-спицами архитектуры:

https://github.com/farshad-nsh/nodejs-rabbitmq-Java

Используя этот подход, вы можете одновременно оценить nodejs и java world и использовать преимущества обоих миров в распределенном программном обеспечении.