Как стать автором
Обновить

Комментарии 24

Может потребоваться реализовать конкурентность на многоядерном сервере, для этого команда разработчиков ядра Node уже занимается подготовкой специального кластерного модуля.

В каких случаях не следует использовать Node.js? СЕРВЕРНОЕ ВЕБ-ПРИЛОЖЕНИЕ, ЗА КОТОРЫМ РАСПОЛОЖЕНА РЕЛЯЦИОННАЯ БАЗА ДАННЫХ

Сколько лет этой книге? Есть подозрение что информация в ней изрядно устарела.
книга — июль 2014. Дата статьи не указана
Тогда очень странно.

Специальный кластерный модуль, «подготовкой которого занимается команда разработчиков ядра Node» (cluster) присутствует в ней аж с версии 0.8 и вполне пригоден для эксплуатации. Может автора смущает, что в документации он помечен как Unstable?

Про работу реляционными базами данных, тоже не понятно с чего такой вывод. Для того же mySQL существует шикарный модуль node-mysql. Запросы к базе основной поток не блокируют.

Складывается ощущение, что книга писалась года четыре назад. Я такое точно не посоветовал бы к приобретению для изучения Node.js.
Судя по всему, автор имеет ввиду не то, что подключиться тяжело, а что хорошей ORM нет (могу быть не прав, ноду для web не использовал).
Судя по датам первых комментариев — статье чуть более 2-х лет — а это треть всего времени существования Node.js.
Я бы не купил. В мире Node.js всё очень быстро меняется. Express тоже, вплоть до обратной несовместимости. Так что актуальность этой книги будет крайне коротка.
Плюс, не факт что разрабатывать на чистом Express хороший план, сейчас уже подоспели фремворки вроде Sails.js
Использовал Sails.js на продакшне и столкнулся с вялым исправлением багов, недопиленностью ORM Waterline (например отсутствие поддержки вложенных атрибутов для монги, PR наличиствует) и некоторыми ограничениями. В итоге от фреймворка осталась файловая структура, хуки и сервисы. Вместо Waterline используется Mongoose и запускаются два сервера — для tcp и http/websocket-ов на разных портах.
Для быстрого старта и максимум средних по сложности проектов можно использовать легко и с удовольствием. В остальном я выбираю чистый Express.
В итоге тоже пришел к этому. Немного больше boilerplate-а, но все это все равно становится либами/пакетами. С Sails есть свои косяки, хотя API хорош, на самом деле. Одним из последних камней преткновения в одном из проектов было использование в Sails-е Express 3.x, в то время как уже вовсю 4-й был в ходу.
Народ, я тут генератор запилил, которые многие траблы решает — github.com/ghaiklor/generator-sails-rest-api. Если вам нужен чистый рест апи, то думаю это быстрый и хороший старт.

Аналогично сейчас стоит вопрос о моем внедрении в команду к ним, поэтому буду делать все возможное — в первую очередь апгрейд експресса и лодаша.
Это было бы здорово. Ибо Sails как таковой — нравится в целом, но давно не используется именно по вышеупомянутым причинам.
Они почему-то закрылись в Slack'е, в гиттер не выходят. Мне трудно было добиться к ним, но все-таки я попал в группу в Slack и теперь активно начинаю их пинговать за всякие фичи.
P.S. А вообще я свой фреймворк пишу :) У которого компонентная структура, сервером является Hapi, ORM Mongoose и Sequilze. Хочу сделать все что круто у Sails, но без бажных проблем (когда пытаешься все сделать сам).
Мне кажется 90% в итоге приходят к своему лунапарку. Проблема-то все равно главная останется — документированность кода.
Почему Hapi?
У меня есть опыт построения фреймворков, так что лучше Sails точно может получится. Hapi из-за декларативности и отсутствия middleware.
Когда ждать на гитхабе?
Еще очень не скоро. Я сейчас на этапе размышлений архитектуры. Однозначно это будет компонентная архитектура и нужно будет наследовать все компоненты от базового (это уже сделано). Также все это дело пишется на ES6\7, так что я иду в ногу со временем, так сказать. Пилить свои ORM и прочие монстры я не буду, т.к. есть вещи в которых это и так уже хорошо сделано. Я как закончу тестовые образцы базовых компонентов и устаканюсь с интерфейсом и документация для создания своих компонент, тогда все задокументирую и выложу в отдельную организацию на GitHub.
Какая версия Express рассматривается в книге?
Из статьи не очень понятно, на основании чего можно отвечать на опрос в конце. Чем книга отличается от статьи? Статья выглядит достаточно целостной, законченной и вроде как исчерпывающей. О чем тогда книга?
Я тоже не понял о чем тогда книга. По статье — сами применяли стек из nodejs+ws+rabbitmq. Это действительно очень эффективно.
НЛО прилетело и опубликовало эту надпись здесь
Чем больше в книге express, тем меньше ее полезность в будущем. Тем более, что уже есть koa, использующий генераторы и написание асинхронного кода в синхронном стиле. А в скором времени появится async/await. На текущий момент все слишком быстро меняется, только базовая информация по node актуальна и полезна долгое время.
Незавидная участь ждёт любую литературу претендующую на описание языка, но при этом концентрирующуюся на конкретном фреймворке. В случае с JavaScript это возведено в квадрат.
НЛО прилетело и опубликовало эту надпись здесь
В большинстве случаев тяжелые вычисления не представляют собой проблемы для однопоточной событийной архитектуры, если их правильно готовить — разбивать их на итерации или шаги, обрабатывая за один «тик» лишь часть необходимых вычислений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий