Задать вопрос

Node.js в качестве server-side для enterprise приложения?

Задача:

Разработать веб-приложение с хитрой бизнес-логикой и возможностью использовать один код для расчетов как на клиенте так и на сервере.


Java не рассматривается, поскольку:

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

2. есть команда веб-разработчиков, нет команды Java разработчиков.


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

Вопрос:

Расскажите, пожалуйста, о своем опыте использования node.js в качестве сервера для приложений со сложной бизнес-логикой. Какие технологии/фреймворки использовали, на какие подводные камни натолкнулись?


Заранее спасибо.

Похожий, но другой по сути, вопрос: habrahabr.ru/qa/45892/
  • Вопрос задан
  • 8290 просмотров
Подписаться 21 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 6
Stdit
@Stdit
По моему опыту, nodejs — удобная, стабильная и быстрая штука, имеющая отличное сообщество и много хороших библиотек в npm. Преимущества можно перечислять долго, лучше сразу перейти к проблемам.

— Сложно найти готовых к работе толковых программистов, даже среди фронтендщиков. Но можно обучить. На обучение и понимание среды nodejs, API, асинхронности, замыканий, калбэков, событий, функционального подхода — уходит примерно месяц-два.
— Библиотеки из форнтендов использовать можно, но только если они грамотно написаны и оптимизированы для перманентной работы. Иначе есть риск, что они сожрут всю память или повесятся.
— Сервер nodejs обычно однопоточный, со всеми вытекающими. Имеется возможность форкать и открывать дочерные процессы, на это нужны дополнительные затраты труда. Но это требуется только в исключительных случаях.
— Код пишется в основном легко, если следовать чёткому стандарту, который обычно навязывается используемым фреймворком. Однако javascript, ввиду своей нестрогости, неустойчив к коррозии, в спешке или по неопытности можно наделать рака и превратить жизнь своей команды в ад.
— При сложной логике со множеством вызовов можно без злого умысла нагородить «лестниц» из калбеков. Однако, проблема решается разными вариантами библиотек управления задачами (async, Q, и т.д.). Вообще лучше делать максимальную декомпозицию кода, создавать бесчисленные функции внутри функций — не очень хорошая практика.

По поводу камней:
— Обычно, всякие руководства и мануалы типа «hello world» используют один сокет для соединения с БД. На практике оказалось, что если этот сокет зависает под тяжёлым запросом, то все остальные запросы прилежно ждут его освобождения. Поэтому первое, что нужно сделать в новом проекте — это подключить database connection pool.
— Случилось так, что количество одновременных подключений к серверу перевалило за тысячу, и внезапно возникли необъяснимые аномалии и отказы. Как выяснилось, страшного ничего не произошло, и нужно было просто в операционной системе разрешить открывать на порядок больше файловых/сокетных дескрипторов.
— Память для nodejs лучше ограничивать ключами запуска и отдавать больше для БД (если они на одной машине). В противном случае nodejs не спешит запусктать сборщик мусора (это ведь затратная операция) и разрастается.
— Перезагрузки nodejs из-за внезапных падений от багов решаются специальными библиотеками, например forever.
— Чтобы nodejs не вылетал из-за исключений, нужно ставить глобальный обработчик uncaughtException, который пишет их в лог или сразу шлёт на мыло ответственному лицу.
— Нужно не забывать отвязыватсь обработчики от событий по окончании работы подписанного на событие объекта (removeListener()).

По поводу фреймворков, используем express, потому что он красивый, простой и мы к нему привыкли.
Ответ написан
hell0w0rd
@hell0w0rd
Просто разработчик
tech.yandex.ru/events/yasubbotnik/ekb-jul-2013/talks/970/ — советую посмотреть вот этот доклад и поискать прочие доклады по nodejs с яндекс-субботников. auto и sport у яндекса как раз на ноде
Ответ написан
Комментировать
Расскажу свою историю. Раньше моим идеалом приложения было — толстый фронтенд + тяжелые WCF(asp.net) сервисы. Мы как порядочные разработчики и свой фронтэндовый фрэймворк создали. И радовались до тех пора пока не получили заманчивый заказ, но одним из условий — некоторые клиенты с выключенным javascript. Возвращаться к asp.net mvc не хотелось, так и пришло знакомство с нодой. Переделали немного фронтенд фрэймворк, и теперь все компоненты летают и там, и там. И что интересно, можем ограничивать компонент только фронтэндом, или если он манипулирует важными моделями — то только бэкенд. Ещё хорошим открытием стал для нас iisnode модуль — о всех кластерах ноды, логированиe, рестартаx (или падениях ноды) нам даже не нужно беспокоится, и плюс все работает параллельно с WCF сервисами. Вообщем мы пока что рады как слоны)
Ответ написан
Комментировать
@rozhik
Я рекомендовал бы делать движение в эту сторону поэтапным.
1. оставить PHP снаружи.
2. писать на ноде участки кода расчета, делать к ним RPC доступ из PHP. В PHP постепенно заменять расчеты на вызовы ноды.
3. дождаться критической массы — и принять решение а) оставить как есть, б) изменить архитектуру (выставить в наружу ноду итп)
Ответ написан
EugeneOZ
@EugeneOZ
Не совсем ответ, но может быть интересно Вам:
www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/
Ответ написан
Комментировать
MarcusAurelius
@MarcusAurelius Куратор тега Node.js
автор Impress Application Server для Node.js
Попробуйте сервер приложений Impress — http://habrahabr.ru/post/194250/
Для PHP-разработчиков он будет более понятным, чем другие фреймворки, потому, что делать новые API-обработчики (урлы для AJAX запросов) можно без перезапуска всей системы, просто созданием файла. Решено много вопросов, многопоточный запуск, перезапуск отдельных потоков при вылетании, логирование, обмен данными между потоками, отдача статики, кеширование в памяти как статики, так и кода и данных, которые этот код плодит, кукизы, хорошие драйвера к СУБД, и много другого, в общем, все необходимое для разработки серверов приложений.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы