Java + NodeJS, сообщающий через сокет: Bad Idea?

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

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

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

Ответ 1

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

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

Hype

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

Итак, Node.js является новым, блог рядом с вами говорит об этом, и в сочетании с базой данных noSQL он должен быть идеально подходящим.

Async IO

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

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

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

Javascript

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

Заключение

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Не уверен, что вы подразумеваете под "Мне нравятся некоторые функции NodeJS, в частности JQuerification, совместимость с websocket через сокеты, просмотр и 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.

Ответ 5

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

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

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