Как решить, когда использовать 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., Я понимаю, что это действительно зависит от того, насколько хорошо вы владеете языком, но мой вопрос больше относится к общей категории: когда использовать конкретную структуру и для каких типов проблем она особенно подходит?
17 ответов
Вы проделали большую работу, суммируя то, что удивительно в Node.js. Мне кажется, что Node.js особенно подходит для приложений, в которых вы хотите поддерживать постоянное соединение браузера с сервером. Используя технику, известную как "длинный опрос", вы можете написать приложение, которое отправляет обновления пользователю в режиме реального времени. Выполнение длинных опросов многих веб-гигантов, таких как Ruby on Rails или Django, создаст огромную нагрузку на сервер, поскольку каждый активный клиент съедает один серверный процесс. Эта ситуация сводится к атаке тарпита. Когда вы используете что-то вроде Node.js, серверу не нужно поддерживать отдельные потоки для каждого открытого соединения.
Это означает, что вы можете создать браузерное приложение для чата в Node.js, которое почти не требует системных ресурсов для обслуживания большого количества клиентов. В любое время, когда вы захотите сделать такой длинный опрос, Node.js будет отличным вариантом.
Стоит отметить, что у Ruby и Python есть инструменты для таких вещей ( http://rubyeventmachine.com/ и 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 то, что по этому вопросу есть вопрос Stackru с более чем 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 в этом случае
- Это очень легкий и быстрый. За три недели на этом сайте было более 200000 посещений, и минимальные ресурсы сервера смогли справиться со всем этим.
- Счетчик действительно легко сделать в режиме реального времени.
- Node.js был прост в настройке.
- Есть много модулей, доступных бесплатно. Например, я нашел модуль Node.js для PayPal.
В этом случае Node.js был отличным выбором.
Наиболее важные причины, чтобы начать свой следующий проект с использованием Node ...
- Все самые крутые парни в этом... так что это должно быть весело.
- Вы можете потусоваться в кулере и иметь множество приключений на Node.
- Вы - мелочь, когда дело доходит до облачного хостинга.
- Там было сделано это с Rails
- Вы ненавидите развертывание IIS
- Ваша старая ИТ-работа становится довольно скучной, и вы хотели бы, чтобы вы были в новом блестящем стартапе.
Что ожидать...
- Вы будете чувствовать себя в безопасности с Express без всего того, что вам никогда не понадобилось.
- Работает как ракета и хорошо масштабируется.
- Вы мечтаете об этом. Вы установили это. Репозиторий пакетов узлов http://npmjs.org/ является крупнейшей в мире экосистемой библиотек с открытым исходным кодом.
- Ваш мозг будет искажен временем в стране вложенных обратных вызовов...
- ... пока вы не научитесь выполнять свои обещания.
- Sequelize и Passport - ваши новые друзья по API.
- Отладка в основном асинхронного кода получится... интересной.
- Время для всех Нодеров освоить Typescript.
Кто этим пользуется?
- PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
- Вот почему они перешли на узел.
Нет ничего лучше Серебряной пули. Все идет с некоторой стоимостью, связанной с этим. Это как если вы едите жирную пищу, вы рискуете своим здоровьем, а здоровая пища не содержит специй, таких как жирная пища. Это индивидуальный выбор, хотят ли они здоровья или специй, как в еде. Точно так же, как и Node.js, предполагается использовать в конкретном сценарии. Если ваше приложение не вписывается в этот сценарий, вы не должны учитывать его при разработке приложения. Я просто думаю о том же:
Когда использовать Node.JS
- Если ваш код на стороне сервера требует очень мало циклов процессора. В другом мире вы выполняете неблокирующую операцию и не имеете тяжелого алгоритма / задания, которое потребляет много циклов ЦП.
- Если вы из Javascript и знаете, как писать однопоточный код так же, как JS на стороне клиента.
Когда НЕ использовать Node.JS
- Ваш запрос к серверу зависит от загруженного процессора / алгоритма работы.
Рассмотрение масштабируемости с Node.JS
- Сам 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 для разработчиков, чтобы обрабатывать более 120000 активных соединений на процесс 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 for rest?
так вот и начинается волшебство. Да, у меня есть другие причины использовать узел для наших 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, Реактивное программирование с JavaScript. На самом деле это не Node.js-ориентированный заголовок; ранние главы предназначены для охвата теории, а последующие главы, насыщенные кодами, охватывают практику. Поскольку я действительно не думал, что было бы уместно не дать читателям веб-сервер, Node.js казался очевидным выбором. Дело было закрыто еще до открытия.
Я мог бы дать очень радужный взгляд на мой опыт работы с Node.js. Вместо этого я был честен в отношении хороших и плохих моментов, с которыми столкнулся.
Позвольте мне включить несколько цитат, которые имеют отношение здесь:
Предупреждение: Node.js и его экосистема горячие - достаточно, чтобы сильно сжечь вас!
Когда я был помощником учителя по математике, одно из неочевидных предложений, которые мне сказали, состояло в том, чтобы не говорить студенту, что что-то "легко". Причина была несколько очевидна в ретроспективе: если вы говорите людям, что что-то легко, кто-то, кто не видит, что решение может привести к тому, что вы почувствуете себя (даже более) глупо, потому что они не только не понимают, как решить проблему, но и проблема, которую они слишком глупы, чтобы понять, что это легко!
Есть ошибки, которые не просто раздражают людей, пришедших из Python / Django, которые сразу же перезагружают исходный код, если вы что-то меняете. С Node.js поведение по умолчанию таково, что если вы сделаете одно изменение, старая версия будет оставаться активной до конца времени или до тех пор, пока вы не остановите и не перезапустите сервер вручную. Это неуместное поведение не только раздражает Pythonistas; это также раздражает местных пользователей Node.js, которые предоставляют различные обходные пути. На вопрос Stackru "Автоматическая перезагрузка файлов в 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 МБ на веб-сайт - это действительно щедрое и полезное пространство, позволяющее разработчикам работать с ним. Вы можете установить гораздо более низкую квоту и при этом предложить разработчикам неизмеримое улучшение по сравнению с хромотой и управлением файлами cook ie. Ограничение в 5 МБ не очень подходит для обработки больших данных на стороне клиента, но есть действительно довольно щедрое преимущество, которое изобретательные разработчики могут использовать для многих целей. Но с другой стороны, 5 МБ - это не особенно большая часть большинства дисков, приобретенных в последнее время, а это означает, что если вы и веб-сайт не согласны с разумным использованием дискового пространства, или какой-то сайт просто фальшивый, это не стоит больших затрат. Вы много, и вы не рискуете забить жесткий диск, если ваш жесткий диск уже был слишком переполнен. Возможно, нам было бы лучше, если бы баланс был немного меньше или чуть больше, но в целом это достойное решение для преодоления внутренней напряженности для контекста на стороне клиента.
Тем не менее, можно осторожно отметить, что когда вы пишете код для своего сервера, вам не нужна дополнительная защита от создания базы данных размером более 5 МБ. Большинству разработчиков не нужны и не нужны инструменты, которые действуют как няни и защищают их от хранения более 5 МБ данных на стороне сервера. А 5-мегабайтная квота, которая является золотым балансом на стороне клиента, довольно глупа на сервере Node.js. (И для базы данных для нескольких пользователей, как описано в этом Приложении, можно несколько болезненно отметить, что это не 5 МБ на учетную запись пользователя, если вы не создадите отдельную базу данных на диске для каждой учетной записи пользователя; это 5 МБ, которые совместно используются все учетные записи пользователей вместе. Это может стать болезненным, если вы заразитесь вирусом!) В документации говорится, что квота настраивается, но неделю назад разработчик отправил электронное письмо с просьбой изменить квоту, как и вопрос Stackru, задающий тот же вопрос., Единственный ответ, который мне удалось найти, находится в исходном коде 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.
- Для приложений реального времени, таких как чат, совместное редактирование, мы лучше используем node js, так как это база событий, где запускаются события и данные для клиентов с сервера.
- Просто и легко понять, так как это основа javascript, в которой большинство людей имеют представление.
- Большинство современных веб-приложений идут в направлении угловых js и backbone, с узлом легко взаимодействовать с кодом на стороне клиента, так как оба будут использовать данные json.
- Много доступных плагинов.
Недостатки: -
- Node будет поддерживать большинство баз данных, но лучше всего это mongodb, который не поддерживает сложные объединения и другие.
- Ошибки компиляции... Разработчик должен обработать все исключения в остальном, если какое-либо приложение с ошибкой перестанет работать, и нам снова нужно будет запустить его вручную или с помощью любого средства автоматизации.
Вывод:- Nodejs лучше всего использовать для простых приложений и приложений реального времени. Если у вас очень большая бизнес-логика и сложная функциональность, лучше не использовать node js. Если вы хотите создать приложение вместе с чатом и любыми функциями для совместной работы.. узел можно использовать в определенных частях, и он должен соответствовать вашей удобной технологии.
Node отлично подходит для быстрых прототипов, но я бы никогда не использовал его снова для чего-то сложного. Я потратил 20 лет на развитие отношений с компилятором, и я уверен, что скучаю по нему.
Node особенно больно поддерживать код, который вы давно не посещали. Тип информация и обнаружение ошибок времени компиляции ХОРОШИЕ ВЕЩИ. Зачем все это выбрасывать? Для чего? И черт, когда что-то идет на юг, следы стека довольно часто совершенно бесполезны.