разработчик
0,0
рейтинг
28 апреля 2011 в 16:16

Разработка → Node.js — руководство по убеждению начальства перевод

От переводчика: Я только начинаю присматриваться к Node.js, и, обнаружив это руководство, сильно пожалел, что оно не попалось мне на глаза раньше. Надеюсь, что этот перевод поможет многим разобраться, что же такое Node, и с чем его едят.

У вас уже чешутся руки попробовать Node.js и пора начинать обрабатывать начальство? Не торопитесь! Для некоторых компаний, которые я консультировал на предмет того, подходит ли им Node.js, правильный ответ был — «Нет!»

Это руководство — набор основанных на моём личном опыте советов для тех, кто хочет узнать, имеет ли смысл применять Node у себя в компании, и, если да, то как убедить в этом начальство.


Плохие варианты


Тяжелые вычисления

Хоть я и люблю Node.js, но есть несколько случаев, когда его применение лишено смысла. Самый очевидный из них — приложения с длительными сложными вычислениями и небольшим количеством операций ввода-вывода. Так что если вы собираетесь писать перекодировщик видео, искусственный интеллект или ещё какую цифродробилку, пожалуйста, не используйте Node.js. Это в принципе возможно, но лучше писать на C/C++.

С другой стороны, node.js позволяет легко писать дополнения на C++, так что вы, конечно, можете использовать его как скриптовой движок поверх ваших сверхсекретных алгоритмов.

Простые приложения CRUD/HTML

Хотя Node.js может со временем стать классным инструментом для любых типов веб-приложений, пока не стоит надеяться, что он даст вам больше преимуществ по сравнению с PHP, Ruby или Python. Да, ваше приложение может получиться немного лучше масштабируемым, но то, что оно сможет справляться с большим потоком трафика, не значит, что этот поток вдруг увеличится только от того, что вы использовали Node.

Несмотря на то, что сейчас уже появляются неплохие фреймворки для Node, пока ещё и близко нет ничего сравнимого с Rails, CakePHP или Django. Если ваше приложение в основном занимается заполнением шаблонов HTML данными из базы, Node.js пока не даст вам каких-либо ощутимых преимуществ.

NoSQL + Node.js + Всякая модная фигня

Если архитектура вашего будущего приложения напоминает сборник рецептов из серии «Кухни народов NoSQL», выдохните, сделайте паузу и прочтите следующий абзац.

Да, Redis, CouchDB, Cassandra, MongoDB, Riak и так далее выглядят очень аппетитно. Примерно, как то яблочко, которым соблазнилась Ева. Вы уже рискуете, используя Node.js, и вам не стоит усугублять этот риск еще одной новой технологией, в которой вы, скорее всего, пока не разобрались до конца.

Конечно, можно найти много аргументов в пользу документ-ориентированных БД, но если ваше приложение должно приносить прибыль, надежность использования проверенных технологий (Postgres или MySQL) должна быть для вас важнее возможности поднять своё гиковское ЧСВ и похвастаться перед друзьями.

Хорошие варианты


JSON API

Node.js блестяще справляется с построением легковесных REST / JSON интерфейсов.
Неблокирующй ввод-вывод и JavaScript делают Node отличным вариантом для написания обертки вокруг базы данных или веб-сервиса, которая общается с клиентом в формате JSON.

Одностраничные приложения

Если вы пишете сложное AJAX-приложение вроде Gmail, Node тоже очень хорош. Для современных веб-приложений, делающих большую часть работы в браузере, отлично подходит сервер, который может одновременно обрабатывать тысячи запросов и имеет низкое время отклика. Возможность повторного использования одного и того же кода, например валидации, на сервере и клиенте — тоже плюс.

Использование инструментов командной строки

Пока Node.js еще очень молод, есть соблазн написать специально для него всё, что только может понадобиться. Но может оказаться гораздо более выгодным использовать огромный выбор уже существующих инструментов командной строки. Node способен порождать тысячи дочерних процессов и работать с их выходными потоками данных, что может дать серьёзные преимущества тем, кто не хочет изобретать велосипеды.

Потоковая обработка данных

Традиционные стеки веб-приложений обычно трактуют запросы и ответы HTTP, как атомарные события. Но на самом деле это потоки, и приложения Node.js могут воспользоваться этим фактом. Отличные примеры — обработка файлов во время загрузки на сервер или передача данных между разными слоями.

Системы мягкого реального времени

Ещё одна отличная черта Node.js — легкость, с которой можно создавать системы мягкого реального времени. Я имею в виду штуки вроде Твиттера, чатов, приема ставок на спортивные события или интерфейсов к IM-протоколам.

Только будьте осторожны! Это JavaScript, и время отклика может сильно варьировать, если вдруг вклинится сборщик мусора (который, увы, блокирует поток выполнения JavaScript). Так что не пытайтесь построить на Node систему жесткого реального времени с гарантированным временем отклика. Для этого гораздо лучше подойдет Erlang.

Как же убедить начальство?


Теперь, если вы уверены, что Node.js вам подходит, пора убедить начальство попробовать.

Сделайте прототип

Лучший способ начать наступление — предложить за недельку набросать прототип системы или её части. Обычно начальник легко соглашается, так как это его ни к чему не обязывает.

А когда у вас на руках будет работающий прототип и результаты тестов — это уже гораздо более убедительные аргументы в пользу Node.js.

Где взять разработчиков?

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

Это означает огромный выбор программистов на любой вкус и цвет на рынке труда, да и у вас в компании скорее всего уже есть нужные кадры. Так что если вы работаете в растущей компании, которая активно нанимает, это ещё один аргумент в пользу Node.js.

Активное сообщество

Сообщество Node.js сейчас растет с бешеной скоростью, привлекая лучших разработчиков в отрасли. Это значит, что растет и экосистема Node, всё легче получить поддержку бесплатно или на коммерческой основе.

Производительность

Этот аргумент лучше не форсировать, но если производительность критична для вашего приложения, то Node.js есть что предложить. Лежащий в основе Node движок V8 от Google уже очень быстр, и становится всё лучше с каждым днем, ведь сейчас все пять крупных игроков на рынке браузеров (Mozilla, Google, Apple, Microsoft и Opera) стремятся создать движок JavaScript круче, чем у конкурентов.

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

Поддержка крупных корпораций

Один из рисков при использовании молодого Open Source проекта — отсутствие долгосрочных гарантий от авторов. Но это не проблема для Node.js. Joyent наняла Райана Дала (Ryan Dahl) и еще нескольких ключевых разработчиков Node и спонсирует проект, так что сейчас будущее Node.js гарантирует серьезная экономическая сила.

Во многом благодаря этому, такие компании, как Yahoo! и HP уже решились использовать Node в своих новых продуктах, так что вы можете придать своему боссу дополнительной уверенности, приводя их в пример.

Как убедить клиента?


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

Мой совет — будьте более консервативными, лучше проверьте дважды, действительно ли Node им подходит. Если да, то убедитесь, что у вас достаточно времени и ресурсов для поддержки. Новые версии Node выходят часто, и стоит учесть необходимость обновляться каждые 3-6 месяцев.

Твиттер и блог автра.
Перевод: Felix Geisendörfer
Илья Сименко @ilya42
карма
526,7
рейтинг 0,0
разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (102)

  • +1
    Интересно было-бы почитать сравнение (нормальное) между Node.JS и PHPDaemon.
    • 0
      Было бы интересно узнать — какие, на ваш взгляд, у PHP есть преимущества перед Javascript?
      • +1
        Это был не позыв к холивору, просто интересны действительно факты.

        Большой плюс к Node.JS это в его поддержке. Очеь много манов, доков, модулей. Для PHPDaemon'a к сожалению найти что-то очень тажело.
        • +4
          Это несовсем холивар. Мне действительно интересно — что движет людьми, которые выбирают PHPDaemon для построения приложений.

          В чем причина? В том, что PHP знают практически все?
          • +13
            >PHP знают практически все?

            Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем PHPDaemon, ведь мы уже знаем PHP!
            • 0
              О да, Erlang правда хорош. Но во многих случаях event-loop показывает себя немногим хуже по производительности, чем многопоточное приложение. (тем не менее у Erlang очень много преимуществ, кроме скорости самой виртуальной машины, v8 действительно быстрее)
            • +5
              У меня дежавю.
              • +5
                Нет, это у меня дежавю :) Тот топик тоже мой.
      • –1
        Отсутствие внятных и быстрых шаблонизаторов.
        Конкатенация строк в JS может превратить в ад работу разработчика.

        Хотя, я могу и ошибаться по обоим пунктам.
        • +1
          • +2
            В принципе, server-side templating не особо нужен, так как, из-за event-driven платформы, большая часть взаимодействий с сервером происходит через AJAX. И все шаблоны можно обрабатывать на client-side
            • +1
              JSON вынуждает переносить тонны кода на сторону клиента. Это неплохо для сервера, но не сильно хорошо для самого клиента. Особенно, когда количество данных превышает 1Мб за транзакцию.
              • +2
                На мой взгляд, мы сейчас говорим о разном…
                Вы считаете, что перезагружая каждую страницу целиком клиент будет тратить меньше времени, чем если бы он динамически менял изменившиеся элементы и делал небольшие JSON POST запросы?
                • +1
                  Вы забываете, что есть еще и третий вариант. Когда клиент получает кусочками HTML. И этот вариант гораздо дешевле и для разработчика, и для пользователя.
                  • +1
                    Ну так можно и HTML выдавать :) Могу вас уверить, это быстрее чем в PHP
                    • +1
                      Быстрота — вещь относительная.
          • 0
            mustache — застрелите меня сразу, отсутствие логики генерирует тонны микрофайликов.
            ejs — темплейт система из 90х
            jade — вот это действительно интересно! Но хочется посмотреть на более сложные примеры, а не на hello world.

            В общем заинтриговали
            • 0
              Лучше сразу смотрите в сторону github.com/creationix/haml-js
              • НЛО прилетело и опубликовало эту надпись здесь
                • +1
                  Нет, конечно. Есть серьезный аргумент за HAML, — он очень удобен и кроссплатформенен.
                • 0
                  Как насчет этого
                  Это не аргумент «против» — это просто сравнительный тест. Взял doT для текущего проектика — доволен.
                  • НЛО прилетело и опубликовало эту надпись здесь
                    • 0
                      Ну, исходник там приведен. Мне кажется все довольно очевидно — вызывается компиляция шаблона. Кстати, изначально я дал ссылку на устаревшую версию. Вот обновленная
        • +1
          Насчет конкатенации не совсем вас понял, вы о чем?
          • +1
            Если мне захочется скармливать клиенту не только JSON, но и кусочки HTML, то придется туго.
            • +1
              Ну можно streaming output сделать же, да и в чем проблема с html?
        • +2
          • 0
            Спасибо! То что нужно
        • 0
    • 0
      Некоторое сравнение PHP и nodejs можно посмотреть тут:
      b.brainscode.com/2011/04/nodejs-vs-php.html
      • 0
        а есть тест с включенным apc, xcache или eaccelerator?
    • +3
      Лучше буду на наркоманском ерланге писать, чем на мерзком PHP.
  • +1
    Для особо интересующихся могу порекомендовать бесплатный (на время beta-тестирования) хостинг для node.js: nodejitsu.com/
    • +1
      Joyent тоже дает бесплатный (пока?) хостинг.
    • +1
      Есть еще наш www.akshell.com который поддерживает CommonJS modules но использует синхронный I/O.
  • +2
    >… использовать огромный выбор уже существующих инструментов командной строки. Node способен порождать тысячи дочерних процессов и работать с их выходными потоками данных

    >Это означает огромный выбор программистов на любой вкус и цвет на рынке труда, да и у вас в компании скорее всего уже есть нужные кадры.

    издеваетесь, да?
    • 0
      По-моему, сейчас javascript знает практически каждый второй web-developer (хотя бы на базовом уровне).
      • +8
        на базовом уровне его знает какждый первый, а так чтобы нормально структурированные программы писать, а не огрызки скриптов-затычек — днем с огнем найти не можем.
        • 0
          Простите, а где вы работаете, если не секрет?
          • +4
            не секрет. работаю в ipark ventures и у нас есть вакансия js-девелопера.
        • 0
          И в этом он очень похож на PHP. Увы, это судьба любого очень популярного языка с низким порогом вхождения. А по JS еще и ресурсы трудно найти — 9 из 10 сайтов и туториалов — про рисование финтифлюшек в браузере, большая часть книг — тоже про DOM.
          • +1
            Вы про русские издания книг?
            • +1
              В основном про них. Я, если честно, уже почти забыл, как русские буквы выглядят рядом с кодом JavaScript :) Хотя быстро пробежать по диагонали всё-таки удобнее, если по-русски…
              • +1
                Просто очень много русских изданий выходят с задержкой в полгода — год, что неприемлемо для современных технологий, развивающихся со значительно большей скоростью.
          • +2
            На самом деле для разработки RIA на JavaScript вовсе не требуется каких-то «магических» знаний. Нет таких ресурсов — зашел, великий гуру поделился своими секретами, и ты — мастер JavaScript.

            Вобщем-то знаний по JavaScript хватит из одной книги с носорогом (JavaScript: The Definitive Guide).

            Но вот дальше начинается то, из чего и состоит так называемый профессиональный уровень разработчика: понимание ООП без привязки к конкретному языку, паттерны проектирования, разработка архитектуры и проектирование, юнит-тестирование и т.д.

            Т.е. с большой долей вероятности профессионал, разбирающийся в вышеперечисленном, но использующий другой язык программирования, изучив книгу с носорогом или ей подобную, попрактиковавшись немного, сможет создать хорошее RIA приложение с толстой клиентской частью.
      • +6
        Cейчас jQuery знает практически каждый второй web-developer. А вот JavaScript на достаточно высоком уровне знают не многие, ибо знание jQuery !== JavaScript. Многие знают JavaScript на уровне «прикрутить плагин jQuery по мануалу», «написать не сложный плагин к jQuery».
      • +1
        Только вот с одним «базовым уровнем» в данной технологии далеко не уедешь. Всёравно PHP больше людей знает.
        • +1
          Можно подумать, что эти люди PHP знают очень хорошо :)
    • +3
      Насчет разработчиков согласен.
      Людей, действительно хорошо разбирающихся в JS, мало. Отчасти это вызвано тем, что сложные client-side приложения приходится разрабатывать куда реже, чем серверные. Также Дуглас Крокфорд, например, заявляет, что не видел ни одной приличной книги по JS за исключением The Definitive Guide от Дэвида Флэнагана. Ну и в целом отсутствие привычной модели ООП (c классами и интерфейсами) тоже играет свою роль.

      JavaScript — Самый недооцененный язык в мире (несколько старовата, но тем не менее)
  • +4
    Руководство по убеждению руководства ;)
  • +1
    Поправьте, пожалуйста:
    • +1
      Joynet => Joyent
      • +1
        Спасибо!
  • +1
    Да, Redis, CouchDB, Cassandra, MongoDB, Riak и так далее выглядят очень аппетитно. Примерно, как то яблочко, которым соблазнилась Ева. Вы уже рискуете, используя Node.js, и вам не стоит усугублять этот риск еще одной новой технологией, в которой вы, скорее всего, пока не разобрались до конца.

    Конечно, можно найти много аргументов в пользу документ-ориентированных БД, но если ваше приложение должно приносить прибыль, надежность использования проверенных технологий (Postgres или MySQL)


    А мне кажется более оправданным вариант с использованием, скажем, MongoDB + традиционная технология типа PHP/ASP.NET/Java/Ruby.
    • +1
      Соглашусь насчет Ruby, но только если на базе EventMachine
      • +1
        Ruby с EventMachine не такая уж и хорошая альтернатива ноде. Там свои цели преследуются, скорее как бесшовная интеграция с основным проектом (Active Record, etc)…
  • +3
    Ещё Node.js манит тем, что один код без изменений может быть выполнен как на клиенте так и на сервере. Пример: валидация форм, шаблоны
    • –1
      Всё же клиентская и серверная валидация форм зачастую отличается
    • +4
      Дело не столько в коде, сколько в модели данных. Одни и те же структуры данных могут использоваться одновременно сервером и клиентом, а также передаваться по сети.
      • +2
        Да, также некоторые конфиги и хэш-таблицы для локализации
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Чем руководствовались при выборе между технологиями?
      • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    Вы уж меня простите, но я немного посравниваю PHPDaemon и Node.JS (без конкретных характеристик — какашками чур не кидаться):
    Задача: чат с каналами. В результате вместо текстовых сообщений будем гонять разные команды, типа «Счётчик, обновись на такую-то величину», «Блок со списком ХХХ — вставь в себя такие-то данные и т.д.»

    Этап 1 — Hello World
    PHPDaemon: 18 часов настройки окружения, доустановки всего-всего-всего, установки собственно демона и получения внятного ответа в браузер
    Node.JS — 1 час на установку + час на написание демонизирующего скрипта .sh (start|stop|restart)

    Этап 2 — Транспорт
    PHPDaemon — 6 часов на реализацию и прикручивание бесконечного iframe
    Node.JS — 20 минут на установку socket.io + 2 часа на придумывание — как бы не броадкастить всех, а только в канал засылать данные

    Этап 3 — Логика приложения (callbacks, команды, защита от падучести (несловленного исключения и т.д.) и иже с ними)
    PHPDaemon — уже не участвует
    Node.JS — несколько часов, сейчас точно не вспомню

    Итого. Примерно за 2-3 вечера не напрягаясь был построен рабочий прототип (не просто рабочий, а выполняющий все поставленные задачи, пусть и немного нерационально, там есть ещё что оптимизировать). PHPDaemon заставил меня выкурить много-много сигарет, перелопатить всё, что находилось из скудной документации и примеров, выпить много-много кофе и т.д за неделю.

    П.С. Может кто-то скажет, что я просто не умею готовить PHPDaemon — я соглашусь, но не настолько же!

    П.П.С — если что — сервер собственный, на базе Atom N450, 2 ГБ памяти.
    • +3
      Добавлю — оба фреймворка я видел впервые. Разрабатываю на PHP и JS уже давненько так что вопрос изучения основ не стоял.
    • +2
      демо: nitrogenproject.com/demos/comet2
      код всей страницы: nitrogenproject.com/demos/viewsource?module=demos_comet2
      думаю, ноджс нервно покуривает в сторонке.
      • +1
        Это эрланг. Я выбирал инструмент по критерию: «Я знаю основы языка»
        • –2
          Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем PHPDaemon и node.js, ведь мы уже знаем PHP и JavaScript!
          • 0
            Вы сговорились? Или это уже мем?
            • +1
              Нет, просто я не нашёл ничего лучше, чем перепостить свой же коммент.
              • 0
                Взгляните сюда :)
                • +1
                  Комментарий пошёл в народ, видимо :)
                  • 0
                    Через пару месяцев ждем статью на Лурке?
                    • –1
                      Надеюсь, нет.
                    • –1
                      Надеюсь, да.
                    • –1
                      Вай-вай, зачем пару месяцев? Бери, да пиши.
                      Только туда поставят плашки «форсед мем» и «локальный мем».
          • +2
            нет, ну правда же.

            мне вот ерланг очень нравится, основы языка знаю, пару прототипчиков наваял, но чтобы серьезно этим заниматься — надо валить, напрашиваться юнгой в какой-нибудь опиумный притон — и то зачморят сишечкой и окамлем.
            • +1
              Совсем не обязательно. В эрланг-рассылке время от времени возникают вакансии, например.
        • 0
          На самом деле разобраться с синтаксисом Erlang и написать простой «чат с каналами» без использования OTP можно за неделю вечеров. Дня 2 на осваивание www.rsdn.ru/article/erlang/GettingStartedWithErlang.xml чтоб синтаксис и основы работы узнать, день чтоб с сокетами разобраться и потренироваться и остальное чтоб дописать само приложение ИЛИ собрать из готовых библиотек.

          Если же вникать в OTP то еще на месяц-другой может растянуться.

          Фишка в том, что знание синтаксиса JS и того как программировать на нем веб-странички избавит вас только от первого этапа, но от вникания в фреймворк и изучения специфики разработки под этот фреймворк знание JS вас не избавит.
          • 0
            Сам по себе синтаксис не пугает. Очень помогает при написании чего-либо на Node.JS понимание принципов:
            — замыкания
            — контекст
            — асинхронное программирование

            Плюс — как я говорил выше — я вообще не заботился о транспорте до клиента. Socket.io умеет:
            — WebSocket
            — если нет — Flash WebSocket
            — если нет — Ajax Streaming
            — если нет — Jsonp Polling
            — если нет — File Polling (aka бесконечный ифрейм)
            — если нет — Long Polling
            — и наконец — обычный Polling на таймаутах
            (в порядке могу ошибаться, советую почитать на сайте: http://socket.io/)
            • 0
              В общем то замыкания, контекст, в каком-то смысле и асинхронное программирование активно используются и в Erlang.

              Бэкенд для Socket.io есть и для Erlang github.com/yrashk/socket.io-erlang, проект довольно активно развивается крутым эрланговцем хабраюзером yrashk (последний коммит 2 дня назад). Проект правда молодой достаточно.

              Ладно, с другой стороны я вас понимаю конечно)
      • +1
        не вижу ничего erlang специфичного, такой же точно шаблонизатор, сваливающий в кучу представление и логику, можно хоть на pascal'е написать.

        а в случае nodejs даже веселее получится, чем в случае erlang'а и паскаля, как раз из-за того, что язык один и тот же на клиенте и на сервере (сей заезженный аргумент тут оказывается как раз к месту).

        там где на nitrogen'е приходится писать мутный код в стиле page.apiThree(Bert.atom('hello'), Bert.atom('robert'), 12345) и заворачивать его в строчку с (о боги-боги) написанным руками тэгом a (см. nitrogenproject.com/demos/viewsource?module=demos_api), в nodejs все будет единообразно.
      • 0
        думаю, нервно покуриваете в сторонке вы.

        nowjs.com/
      • 0
        Хотя в глубине души поддерживаю, но вроде как Nitrogen уже не развивается?
        • 0
          Да нет, вон github.com/nitrogen/nitrogen 88 форков и последний коммит в этом году, так что всё нормально.
  • 0
    >не пытайтесь построить на Node систему жесткого реального времени с гарантированным временем отклика. Для этого гораздо лучше подойдет Erlang.
    Автор статьи про эрланг не знает ничего. Какой, нафиг, жёсткий риал-тайм? Это вообще-то от ОС зависит в немалой степени.
  • 0
    node.js работает на движке, который создан для браузеров. Ведь там совсем другая специфика, страницы живут недолго, очищаются при закрытии, а для node.js нужен 24/7/365.

    Вот интересно, если разработчики V8 вдруг встретят развилку, где одно решение ухудшит работу в браузере, а другое в node.js, что они выберут?
    • 0
      Выберут первое, естественно. Уже заметно на примере node 4.x. Он на 64-битных системах медленнее, чем node 2.x.

      Надеюсь, позднее V8 допилят :)
      • 0
        Это потому что Crankshaft пока не работает на 64битной архитектуре (он и в браузере медленнее)
        • 0
          Он уже в 3.1 работал, но не был включен по умолчанию.

          В 3.2 включили по умолчанию для x64/ARM.

          Сейчас trunk V8 уже 3.3
      • 0
        Ryan держит 0.4.x на V8 3.1.x. Crankshaft включили для x64/ARM по умолчанию в 3.2.x
        • 0
          Да, кстати на сколько я помню был параметр, включающий Crankshaft.
          • 0
            да, был такой: --crankshaft. им же можно было его выключить и переключиться на «классический» кодогенератор (--nocrankshaft); но теперь классический убрали полностью.
  • +4
    Значительная часть расширений ноды, использующих внешние линкуемые библиотеки, работает очень нестабильно. Утечки памяти и падения на каждом шагу. Интересующимся деталями могу посоветовать попробовать, например, распарсить подряд несколько сотен мелких XML-файлов (или один большой) при помощи одного из рекомендуемых модулей.

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

    И так далее, по мелочам и по-крупному иногда.

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

    Лучшим способом решить, подходит нода или нет — создать прототип, по максимуму использующий требующиеся возможности, сразу выбрать, какие модули вы используете, и хорошенько все это погонять. Если сомневаетесь — пишите под Торнадо (для которого даже Socket.IO-шный сервер есть) и ждите еще пару лет, пока проект немного созреет.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Ура, стандартную библиотеку нода ждёт судьба стандартных библиотек пхп!
        * просто злорадствую. Сам пишу на js, только клиентскую часть
        • 0
          Тогда вы и сами знаете, сколько для JS разных фреймворков. Так что единого и не будет.
  • +1
    Слава богу мне никого убеждать не пришлось.
    Просто были у меня скрипты, который крутились под Microsoft Active Scripting и Windows в собственном Active Scripting Host приложении. Опрос датчиков и запись в БД. За пол дня это все переехало на NodeJS и Linux. Без изменений в основном коде скриптов. Глобальный объект, конечно, надо было подстраивать под методы и объекты, которые предоставляло старое приложение, но это не заняло много времени.
    Нет вру конечно. Не пол дня. Мне нужен был доступ к Firebird, а такового в NodeJS не было. Но я сделал. За 3 месяца где-то, на нужном мне уровне функциональности.
  • 0
    А да забыл добавить, что еще по событиям от датчиков и не только оповещаются HTTP клиенты, но это, собственно, классическая задача для NodeJS.

    И есть у меня еще одна вещь, которую я бы переделал на NodeJS, это сервис репликации данных, но с такой особенностью, что репликация идет из Oracle в сокет-сервер, который поддерживает только одно подключение, а надо реплицировать несколько наборов данных одновременно, т.е. это что то вроде своеобразного мультиплексора. Сейчас сделано как многопоточное приложение, ну и все прелести с синхронизацией на лицо. Разобраться как оно работает, кому-то другому будет нелегко. Да и я уже подзабыл, хотя доки есть и код относительно чистый. Вот на Node оно было бы красивее и проще, только с Oracle он пока не работает. Я во всяком случае не видел ничего. Но можно переделать на MS Active Scripting пока — это 100%. Скорость там не критична. Да и движок из 9го IE вполне себе шустр. Не знаю только как у него с текучестью :-).

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.