Как решить, когда использовать Node.js?

Я новичок в такого рода вещи, но в последнее время я слышал много о том , как хорошо Node.js есть. Учитывая то, насколько я люблю работать с jQuery и JavaScript в целом, я не могу не задаться вопросом, как решить, когда использовать Node.js. Я имею в виду веб-приложение, похожее на Bitly - оно берет некоторый контент, архивирует его.

Из всей домашней работы, которую я делал за последние несколько дней, я получил следующую информацию. Node.js

• это инструмент командной строки, который может быть запущен как обычный веб-сервер и позволяет запускать программы JavaScript
• использует отличный движок V8 JavaScript
• очень хорошо, когда нужно сделать несколько вещей одновременно
• основанный на событиях, так что все замечательные Ajax- подобные вещи могут быть сделаны на стороне сервера
• позволяет нам делиться кодом между браузером и бэкэндом
• давайте поговорим с MySQL

Вот некоторые источники, с которыми я столкнулся:

• Погружение в Node.js - Введение и установка
• Понимание NodeJS
• Узел на примере ( Archive.is )
• Давайте сделаем веб-приложение: NodePad

Учитывая, что Node.js можно запускать практически из коробки на инстансах Amazon EC2 , я пытаюсь понять, какой тип проблем требует Node.js, в отличие от любого из могучих королей, таких как PHP , Python и Ruby. , Я понимаю, что это действительно зависит от того, насколько хорошо вы владеете языком, но мой вопрос больше относится к общей категории: когда использовать конкретную структуру и для каких типов проблем она особенно подходит?

Вы проделали большую работу, суммируя то, что удивительно в Node.js. Мне кажется, что Node.js особенно подходит для приложений, в которых вы хотите поддерживать постоянное соединение браузера с сервером. Используя технику, известную как «длинный опрос» , вы можете написать приложение, которое отправляет обновления пользователю в режиме реального времени. Выполнение длинных опросов многих веб-гигантов, таких как Ruby on Rails или Django , создаст огромную нагрузку на сервер, поскольку каждый активный клиент съедает один серверный процесс. Эта ситуация сводится к атаке тарпита . Когда вы используете что-то вроде Node.js, серверу не нужно поддерживать отдельные потоки для каждого открытого соединения.

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

Стоит отметить, что у Ruby и Python есть инструменты для такого рода вещей ( eventmachine и twisted соответственно), но Node.js делает это исключительно хорошо и с нуля. JavaScript исключительно удачно расположен в модели параллелизма на основе обратного вызова, и здесь он превосходен. Кроме того, возможность сериализации и десериализации с помощью JSON native как для клиента, так и для сервера довольно проста.

Я с нетерпением жду, чтобы прочитать другие ответы здесь, это фантастический вопрос.

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

Вот статья о пирамиде и длинном опросе, которую очень легко настроить с небольшой помощью Gevent: TicTacToe и Long Polling with Pyramid .

Я считаю, что Node.js лучше всего подходит для приложений реального времени: онлайн-игр, инструментов для совместной работы, чатов или чего-то еще, где то, что делает один пользователь (или робот? Или датчик?) С приложением, должно быть немедленно замечено другими пользователями, без обновления страницы.

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

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

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

Плюс это все время JavaScript. Лингва Франка на весь стек.

Причины использования NodeJS:

• Он запускает Javascript, поэтому вы можете использовать один и тот же язык на сервере и клиенте и даже делиться между ними некоторым кодом (например, для проверки формы или для отображения представлений на любом конце).

• Однопоточных система событийного это быстро , даже при обработке много запросов сразу, а также просто, по сравнению с традиционными многопоточных Java или ROR рамки.

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

• Это стало стандартной средой defacto для запуска инструменты, связанные с Javascript, и другие инструменты , связанные с веб-технологиями , включая средства запуска задач, минификаторы, beautifiers, линтеры, препроцессоры, упаковщики и аналитические процессоры.

• Это кажется вполне подходящим для прототипирования, гибкой разработки и быстрой итерации продукта .

Причины не использовать NodeJS:

• Он запускает Javascript, который не имеет проверки типов во время компиляции. Для больших сложных систем или проектов, критически важных для безопасности, включая сотрудничество между различными организациями, язык, который поддерживает контрактные интерфейсы и обеспечивает статическую проверку типов, может сэкономить вам время на отладку (и в долгосрочной перспективе взрывы ). (Хотя JVM застрял null, поэтому, пожалуйста, используйте Haskell для своих ядерных реакторов.)

• Кроме того, многие из пакетов в NPM немного сыры и все еще находятся в стадии быстрой разработки. Некоторые библиотеки для старых фреймворков прошли десятилетие тестирования и исправления ошибок, и сейчас они очень стабильны .Npmjs.org не имеет механизма для оценки пакетов , что привело к распространению пакетов, делающих более или менее одно и то же, из-за чего большой процент больше не поддерживается.

• Вложенный обратный вызов ада. (Конечно есть 20 различных решений для этого ...)

• Постоянно растущий пул пакетов может сделать один проект NodeJS радикально отличающимся от следующего. Существует большое разнообразие реализаций из-за огромного количества доступных опций (например, Express / Sails.js / Meteor / Derby ). Иногда это может усложнить переход нового разработчика к проекту Node. Сравните это с разработчиком Rails, присоединяющимся к существующему проекту: он должен довольно быстро познакомиться с приложением, поскольку всем приложениям Rails рекомендуется использовать аналогичную структуру .

• Работа с файлами может быть немного болезненной. Вещи, тривиальные в других языках, такие как чтение строки из текстового файла, достаточно странны, чтобы делать с Node.js, что есть вопрос StackOverflow по этому вопросу с 80+ ответами. Нет простого способа прочитать одну запись за раз из файла CSV . И т.п.

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

Чтобы сделать это коротким:

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

Хорошая статья о цикле обработки событий в Node.js является Mixu в техническом блог: Понимание Node.js цикла событий .

У меня есть один пример из реальной жизни, где я использовал Node.js. В компании, где я работаю, появился один клиент, который хотел иметь простой статический HTML-сайт. Этот веб-сайт предназначен для продажи одного товара с использованием PayPal, и клиент также хотел иметь счетчик, который показывает количество проданных товаров. Ожидается, что у клиента будет огромное количество посетителей этого сайта. Я решил сделать счетчик используя Node.js и Express.js фреймворк .

Приложение Node.js было простым. Получите количество проданных предметов из базы данных Redis , увеличьте счетчик при продаже товара и предоставьте значение счетчика пользователям через API .

Некоторые причины, по которым я решил использовать Node.js в этом случае

1. Это очень легкий и быстрый. За три недели сайт посетило более 200000 человек, и минимальные ресурсы сервера смогли справиться со всем этим.
2. Счетчик действительно легко сделать в режиме реального времени.
3. Node.js был прост в настройке.
4. Есть много модулей, доступных бесплатно. Например, я нашел модуль Node.js для PayPal.

В этом случае Node.js был отличным выбором.

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

• Все самые крутые парни в этом ... так что это должно быть весело.
• Вы можете потусоваться в кулере и иметь множество приключений на Node.
• Вы - мелочь, когда дело доходит до облачного хостинга.
• Там было сделано это с Rails
• Вы ненавидите развертывание IIS
• Ваша старая ИТ-работа становится довольно скучной, и вы хотели бы, чтобы вы были в новом блестящем стартапе.

Что ожидать ...

• Вы будете чувствовать себя в безопасности с Express без всего того, что вам никогда не понадобилось.
• Работает как ракета и хорошо масштабируется.
• Вы мечтаете об этом. Вы установили это. Узел пакета репозитория npmjs.org является крупнейшей в мире экосистемой библиотек с открытым исходным кодом.
• Ваш мозг будет искажен временем в стране вложенных обратных вызовов ...
• ... пока вы не научитесь выполнять свои обещания .
• Sequelize и паспорт - ваши новые друзья по API.
• Отладка в основном асинхронного кода получится ... интересно .
• Время для всех Нодеров освоить Typescript .

Кто это использует?

• PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
• Вот почему они перешли на узел .

Нет ничего лучше Серебряной пули. Все идет с некоторой стоимостью, связанной с этим. Это как если вы едите жирную пищу, вы рискуете своим здоровьем, а здоровая пища не содержит специй, таких как жирная пища. Это индивидуальный выбор, хотят ли они здоровья или специй, как в еде. Точно так же, как и Node.js, предполагается использовать в конкретном сценарии. Если ваше приложение не вписывается в этот сценарий, вы не должны учитывать его при разработке приложения. Я просто думаю о том же:

Когда использовать Node.JS

1. Если ваш код на стороне сервера требует очень мало циклов процессора. В другом мире вы выполняете неблокирующую операцию и не имеете тяжелого алгоритма / задания, которое потребляет много циклов ЦП.
2. Если вы из Javascript и знаете, как писать однопоточный код так же, как JS на стороне клиента.

Когда НЕ использовать Node.JS

1. Ваш запрос к серверу зависит от загруженного процессора / алгоритма работы.

Рассмотрение масштабируемости с Node.JS

1. Сам Node.JS не использует все ядро ​​базовой системы и по умолчанию является однопоточным, вы должны самостоятельно написать логику, чтобы использовать многоядерный процессор и сделать его многопоточным.

Node.JS Альтернативы

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

Еще одна замечательная вещь, которую, я думаю, никто не упомянул о Node.js, - это удивительное сообщество, система управления пакетами (npm) и количество существующих модулей, которые вы можете включить, просто включив их в файл package.json.

Мой кусок: nodejs отлично подходит для создания систем реального времени, таких как аналитика, чат-приложения, apis, рекламные серверы и т. Д. Черт, я сделал свое первое чат-приложение с использованием nodejs и socket.io менее чем за 2 часа, и это тоже во время экзаменационной недели!

редактировать

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

Когда использовать

При создании системы, которая делает упор на параллелизм и скорость.

• Сокеты только для серверов, таких как приложения чата, приложения irc и т. Д.
• Социальные сети, которые делают акцент на ресурсах реального времени, таких как геолокация, видеопоток, аудиопоток и т. Д.
• Очень быстрая обработка небольших порций данных, как в веб-приложении для аналитики.
• Как выставление REST только API.

Когда не использовать

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

• Простые блоги и статические сайты.
• Так же, как статический файловый сервер.

Имейте в виду, что я просто придираюсь. Для статических файловых серверов apache лучше в основном потому, что он широко доступен. Сообщество nodejs выросло за последние годы и стало более зрелым, и можно с уверенностью сказать, что nodejs можно использовать практически везде, если у вас есть собственный выбор хостинга.

Может использоваться где

• Приложения, которые сильно зависят от событий и сильно связаны с вводом / выводом
• Приложения, обрабатывающие большое количество соединений с другими системами
• Приложения реального времени (Node.js был разработан с нуля для реального времени и прост в использовании.)
• Приложения, которые смешивают потоки информации с другими источниками
• Высокий трафик, Масштабируемые приложения
• Мобильные приложения, которые должны взаимодействовать с API платформы и базой данных, не занимаясь анализом данных.
• Создание сетевых приложений
• Приложения, которым нужно общаться с бэкэндом очень часто

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

LinkedIn является выдающимся пользователем. Весь их мобильный стек построен на Node.js. Они перешли от запуска 15 серверов с 15 экземплярами на каждой физической машине к 4 экземплярам - которые могут обрабатывать двойной трафик!

eBay запустил ql.io, язык веб-запросов для HTTP API, который использует Node.js в качестве стека времени выполнения. Они смогли настроить обычную рабочую станцию ​​Ubuntu для разработчиков, чтобы обрабатывать более 120 000 активных соединений на процесс node.js, причем каждое соединение потребляет около 2 КБ памяти!

Walmart переработал свое мобильное приложение для использования Node.js и перенес обработку JavaScript на сервер.

Узнайте больше на: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

Лучший узел для одновременной обработки запросов -

Итак, начнем с истории. Последние 2 года я работаю над JavaScript и разрабатываю веб-интерфейс, и мне это нравится. Ребята предлагают нам API, написанные на Java, python (нам все равно), и мы просто пишем AJAX-вызов, получаем наши данные и угадаем, что! мы сделали. Но на самом деле это не так просто, если данные, которые мы получаем, неверны или есть какая-то ошибка на сервере, то мы застряли, и нам нужно связаться с нашими бэкэндами по почте или в чате (иногда и в WhatsApp тоже :).) не круто Что если мы написали наши API на JavaScript и вызвали эти API с нашего интерфейса? Да, это очень круто, потому что, если мы столкнемся с какой-либо проблемой в API, мы сможем разобраться в этом. Угадай, что ! Вы можете сделать это сейчас, как? - Узел там для тебя.

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

так вот и начинается волшебство. Да, у меня есть другие причины использовать узел для нашего API.

Давайте вернемся к нашей традиционной системе API отдыха, которая основана на операции блокировки или многопоточности. Предположим, что происходит два одновременных запроса (r1 и r2), каждый из которых требует работы базы данных. Итак, в традиционной системе, что произойдет:

1. Путь ожидания: наш сервер начинает обслуживать r1запрос и ожидает ответа на запрос. после завершения r1сервер начинает обслуживать r2и делает это таким же образом. Так что ждать не очень хорошая идея, потому что у нас не так много времени.

2. Потоки потоков : наш сервер создаст два потока для обоих запросов r1и будет r2выполнять их назначение после запроса базы данных, поэтому охладите ее быстро. Но это занимает много памяти, потому что, как вы видите, мы запустили два потока, также проблема возрастает, когда оба запроса запрашивают одни и те же данные. тогда вам придется иметь дело с тупиковыми проблемами. Так что лучше, чем ждать, но проблемы все же есть.

Теперь вот, как узел будет это делать:

3. Узел: Когда такой же параллельный запрос поступает в узел, он регистрирует событие с помощью своего обратного вызова и продвигается вперед, он не будет ждать ответа на запрос для конкретного r1запроса. Так что, когда приходит запрос, тогда цикл событий узла (да, есть цикл событий). в узле, который служит этой цели.) зарегистрировать событие с помощью его функции обратного вызова и продвинуться вперед для обслуживания r2запроса и аналогичным образом зарегистрировать свое событие с помощью обратного вызова. Всякий раз, когда любой запрос завершается, он запускает соответствующее событие и выполняет свой обратный вызов до завершения, не прерываясь.

Так что нет ожидания, нет потоков, нет потребления памяти - да, это узел для обслуживания остальных API.

Мой еще одна причина , чтобы выбрать Node.js для нового проекта:

Уметь делать чистую облачную разработку

Я использовал Cloud9 IDE некоторое время, и теперь я не могу представить без него, он охватывает все жизненные циклы разработки. Все, что вам нужно, это браузер, и вы можете в любое время кодировать в любом месте на любых устройствах. Вам не нужно проверять код на одном компьютере (как дома), а затем проверять на другом компьютере (например, на рабочем месте).

Конечно, может быть облачная интегрированная среда разработки для других языков или платформ (в Cloud 9 также добавлена ​​поддержка для других языков), но использование Cloud 9 для разработки Node.js - это действительно хороший опыт для меня.

Еще одна вещь, которую предоставляет узел, - это возможность создавать несколько экземпляров v8 узла, используя дочерний процесс узла ( childProcess.fork (). каждый из которых требует 10 МБ памяти согласно документам) на лету, таким образом, не затрагивая основной процесс, выполняющий сервер. Таким образом, разгрузка фоновой работы, которая требует огромной нагрузки на сервер, становится детской игрой, и мы можем легко убить их по мере необходимости.

Я часто использую ноды, и в большинстве приложений, которые мы создаем, требуются подключения к серверу одновременно, что приводит к интенсивному сетевому трафику. Такие фреймворки, как Express.js и новый Koajs (который убрал ад- коллбэк ) сделали работу с узлом еще проще.

Надевание асбеста лонгджонс ...

Вчера мой заголовок с Packt Publications, Реактивное программирование с JavaScript . На самом деле это не Node.js-ориентированный заголовок; ранние главы предназначены для охвата теории, а последующие главы, насыщенные кодами, охватывают практику. Потому что я действительно не думаю , что было бы целесообразно , чтобы не дать читателям веб - сервер, Node.js , казалось , безусловно , очевидным выбором. Дело было закрыто еще до открытия.

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

Позвольте мне включить несколько цитат, которые имеют отношение здесь:

Предупреждение: Node.js и его экосистема горячие - достаточно, чтобы сильно сжечь вас!

Когда я был помощником учителя по математике, мне сказали, что одно из неочевидных предложений - не говорить ученику, что что-то «легко». Причина была несколько очевидна в ретроспективе: если вы говорите людям, что что-то легко, тот, кто не видит решения, может в конечном итоге почувствовать себя (даже более) глупым, потому что он не только понимает, как решить проблему, но и проблему они слишком глупы, чтобы понять это легко!

Есть ошибки, которые не просто раздражают людей, пришедших из Python / Django, которые сразу же перезагружают исходный код, если вы что-то меняете. С Node.js поведение по умолчанию таково, что если вы сделаете одно изменение, старая версия будет оставаться активной до конца времени или до тех пор, пока вы не остановите и не перезапустите сервер вручную. Это неуместное поведение не только раздражает Pythonistas; это также раздражает нативных пользователей Node.js, которые предоставляют различные обходные пути. На вопрос StackOverflow «Автоматическая перезагрузка файлов в Node.js» на момент написания этой статьи было более 200 ответов и 19 ответов; редактирование направляет пользователя к сценарию няни, нод-супервизору, с домашней страницей по адресу http://tinyurl.com/reactjs-node-supervisor, Эта проблема дает новым пользователям прекрасную возможность почувствовать себя глупо, потому что они думали, что решили проблему, но старое, глючное поведение полностью не изменилось. И легко забыть сбросить сервер; Я сделал это несколько раз. И сообщение, которое я хотел бы дать: «Нет, вы не глупы, потому что такое поведение Node.js кусает вас в ответ; просто дизайнеры Node.js не видели причин для обеспечения соответствующего поведения здесь. Попытайтесь справиться с этим, возможно, воспользовавшись небольшой помощью от администратора узлов или другого решения, но, пожалуйста, не уходите, чувствуя, что вы глупы. Вы не тот, у кого проблема; проблема в поведении Node.js по умолчанию ».

Этот раздел после некоторой дискуссии был оставлен именно потому, что я не хочу создавать впечатление «это легко». Я неоднократно порезал себе руки, когда заставлял вещи работать, и я не хочу сгладить трудности и заставить вас поверить, что заставить Node.js и его экосистему нормально функционировать - дело простое, и если это не так просто для вас тоже Вы не знаете, что делаете. Если вы не столкнетесь с неприятными трудностями при использовании Node.js, это замечательно. Если вы это сделаете, я надеюсь, что вы не уйдете, чувствуя: «Я глупый - со мной должно быть что-то не так». Вы не глупы, если испытываете неприятные сюрпризы, связанные с Node.js. Это не ты! Это Node.js и его экосистема!

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

Еще одна база данных, которая казалась идеально подходящей и, тем не менее, пригодной для погашения, представляет собой реализацию хранилища значений ключей HTML5 на стороне сервера. Этот подход имеет кардинальное преимущество API, который достаточно хорошо понимают большинство хороших разработчиков. В этом отношении это также API, который большинство не очень хороших разработчиков интерфейса понимают достаточно хорошо. Но с пакетом node-localstorage, хотя доступ к словарному синтаксису не предоставляется (вы хотите использовать localStorage.setItem (ключ, значение) или localStorage.getItem (ключ), а не localStorage [ключ]), реализована полная семантика localStorage. включая квоту по умолчанию 5 МБ - ПОЧЕМУ?Должны ли разработчики JavaScript на стороне сервера быть защищены от самих себя?

Для возможностей базы данных на стороне клиента квота в 5 МБ на веб-сайт - это действительно щедрое и полезное пространство, позволяющее разработчикам работать с ним. Вы можете установить гораздо более низкую квоту и при этом предложить разработчикам неизмеримое улучшение по сравнению с хромотой и управлением файлами cookie. Ограничение в 5 МБ не очень подходит для обработки больших данных на стороне клиента, но есть действительно довольно щедрое преимущество, которое изобретательные разработчики могут использовать для многих целей. Но с другой стороны, 5 МБ - это не особенно большая часть большинства дисков, приобретенных в последнее время, а это означает, что если вы и веб-сайт не согласны с разумным использованием дискового пространства, или какой-то сайт просто фальшивый, это не стоит больших затрат. Вы много, и вы не рискуете заболоченный жесткий диск, если ваш жесткий диск уже был переполнен.

Тем не менее, можно осторожно отметить, что когда вы пишете код для своего сервера, вам не требуется дополнительная защита от создания базы данных размером более 5 МБ. Большинству разработчиков не нужны и не нужны инструменты, которые действуют как няни и защищают их от хранения более 5 МБ данных на стороне сервера. А 5-мегабайтная квота, которая является золотым балансом на стороне клиента, довольно глупа на сервере Node.js. (И для базы данных для нескольких пользователей, как описано в этом Приложении, можно несколько болезненно отметить, что это не 5 МБ на учетную запись пользователя, если вы не создадите отдельную базу данных на диске для каждой учетной записи пользователя; это 5 МБ, совместно используемых между все учетные записи пользователей вместе. Это может получить больноесли вы идете вирусно!) В документации говорится, что квота настраивается, но неделю назад разработчик отправил электронное письмо с просьбой изменить квоту, как и вопрос StackOverflow, задающий то же самое. Единственный ответ, который мне удалось найти, находится в исходном коде Github CoffeeScript, где он указан в качестве необязательного второго целочисленного аргумента для конструктора. Это достаточно просто, и вы можете указать квоту, равную размеру диска или раздела. Но помимо переноса функции, которая не имеет смысла, автору инструмента не удалось полностью следовать очень стандартному соглашению интерпретации 0 как значения «неограниченного» для переменной или функции, где целое число должно указывать максимальный предел для некоторого использования ресурса. Лучшее, что можно сделать с этой ошибкой, - это указать бесконечность:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Меняем местами два комментария по порядку:

Люди без нужды постоянно стреляли себе в ногу, используя JavaScript в целом, и частью JavaScript, сделавшимся респектабельным языком, был Дуглас Крокфорд, по сути говоря, «JavaScript как язык имеет некоторые действительно хорошие и некоторые действительно плохие части. Вот хорошие части. Просто забудь, что там есть что-то еще. Возможно, горячая экосистема Node.js вырастит своего собственного «Дугласа Крокфорда», который скажет: «Экосистема Node.js - это кодирующий Дикий Запад, но есть некоторые настоящие жемчужины. Вот дорожная карта. Вот области, которых следует избегать практически любой ценой. Вот районы с самой богатой зарплатой на ЛЮБОМ языке или в любой среде ».

Возможно, кто-то еще может принять эти слова как вызов и последовать примеру Крокфорда и написать «хорошие части» и / или «лучшие части» для Node.js и его экосистемы. Я бы купил копию!

А учитывая степень энтузиазма и просто рабочее время для всех проектов, может потребоваться год, два или три, чтобы резко умерить любые замечания о незрелой экосистеме, сделанные во время написания этой статьи. Через пять лет действительно имеет смысл сказать: «В экосистеме Node.js 2015 года было несколько минных полей. В экосистеме Node.js 2020 года есть несколько райдов ».

Если ваше приложение в основном привязывает веб-интерфейс API или другие каналы ввода-вывода, предоставляет или принимает пользовательский интерфейс, то для вас может подойти нод.js, особенно если вы хотите выжать наибольшую масштабируемость или, если ваш основной язык в жизни является javascript (или своего рода транспортерами javascript). Если вы создаете микросервисы, то с node.js тоже все в порядке. Node.js также подходит для любого небольшого или простого проекта.

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

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

В частности, когда вашему приложению необходимо выполнять синхронные потоки, вы начинаете кровоточить из-за недоделанных решений, которые значительно замедляют процесс разработки. Если в вашем приложении есть части, требующие большого объема вычислений, следуйте осторожно, выбирая (только) node.js. Может быть, http://koajs.com/ или другие нововведения смягчают эти изначально острые аспекты по сравнению с тем, когда я первоначально использовал node.js или писал это.

Я могу поделиться несколькими моментами, где и почему использовать узел JS.

1. Для приложений реального времени, таких как чат, совместное редактирование, мы лучше используем nodejs, поскольку это база событий, где запускаются события и данные для клиентов с сервера.
2. Просто и легко понять, так как это основа javascript, где большинство людей имеют представление.
3. Большинство современных веб-приложений ориентированы на угловые js и backbone, с узлом легко взаимодействовать с кодом на стороне клиента, так как оба будут использовать данные json.
4. Много доступных плагинов.

Недостатки: -

1. Node будет поддерживать большинство баз данных, но лучше всего это mongodb, который не поддерживает сложные объединения и другие.
2. Ошибки компиляции ... Разработчик должен обработать все исключения в остальном, если какое-либо приложение с ошибкой перестанет работать, и нам снова нужно будет запустить его вручную или с помощью любого средства автоматизации.

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

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

2. Node особенно больно поддерживать код, который вы давно не посещали. Тип информации и обнаружение ошибок времени компиляции ХОРОШИЕ ВЕЩИ. Зачем все это выбрасывать? За что? И черт, когда что-то идет на юг, следы стека довольно часто совершенно бесполезны.