Як вирішити, коли використовувати Node.js?


2195

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

З усіх домашніх завдань, які я робив за останні кілька днів, я отримав таку інформацію. Node.js

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

Деякі з джерел, які я натрапив на це:

Враховуючи те, що Node.js може бути запущений майже в нестандартному порядку в екземплярах Amazon EC2 , я намагаюся зрозуміти, який тип проблем потребує Node.js на відміну від будь-якого з могучих королів, таких як PHP , Python та Ruby . Я розумію, що це дійсно залежить від досвіду роботи з мовою, але моє запитання більше входить до загальної категорії: Коли використовувати певний фреймворк та який тип проблем він особливо підходить?


4
Це питання обговорюється на мета ( meta.stackoverflow.com/q/332386/497418 ).
zzzzBov

Відповіді:


1355

Ви зробили чудову роботу, підсумовуючи, що дивовижно в Node.js. Моє відчуття, що Node.js особливо підходить для програм, де ви хочете підтримувати стійке з'єднання від браузера назад до сервера. Використовуючи техніку, відому як "тривале опитування" , ви можете написати програму, яка надсилає оновлення користувачеві в режимі реального часу. Якщо довго проводити опитування багатьох гігантів Інтернету, таких як Ruby on Rails або Django , створюється величезне навантаження на сервер, оскільки кожен активний клієнт з'їдає один серверний процес. Така ситуація означає атаку на брезент . Коли ви використовуєте щось на зразок Node.js, серверу не потрібно підтримувати окремі потоки для кожного відкритого з'єднання.

Це означає, що ви можете створити браузерну програму чату на Node.js, яка майже не потребує системних ресурсів для обслуговування багатьох клієнтів. У будь-який час, коли ви хочете зробити такий вид тривалого опитування, Node.js - це чудовий варіант.

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

Я з нетерпінням чекаю тут інших відповідей, це питання фантастичне.

Варто зазначити, що Node.js також чудово підходить для ситуацій, коли ви будете використовувати багато коду через розрив клієнт / сервер. Рамки Meteor робить це дуже легко, і багато людей припускають , що це може бути майбутнє веб - розробки. Я можу сказати з досвіду, що писати код у Meteor дуже цікаво, і значна частина цього витрачає менше часу на роздуми над тим, як ви збираєтеся реструктурувати свої дані, тому код, який працює в браузері, може легко маніпулюйте ним і передайте назад.

Ось стаття про Піраміду та тривалий опитування, яку, як виявляється, дуже легко створити за допомогою невеликої допомоги gevent: TicTacToe та Long Polling with Pyramid .


12
Так, я думаю, що дуже важливо думати, що 'node.js особливо підходить для програм, які потребують постійного підключення від браузера назад до сервера. - наприклад, програми для чатів або інтерактивні ігри "Якщо хтось лише створює додаток, який не обов'язково потребує спілкування між користувачем і сервером, розвиток з іншими рамками буде просто чудовим і забиратиме набагато менше часу.
user482594

1
Дякую за це ... Великий Q і A ;-) Я б також подумав про це з точки зору освоєння однієї чудової технології як для переднього, так і для зворотного кінців в декількох різних;)
Stokedout

12
Навіщо використовувати довге опитування? Що сталося з майбутнім і розетками ?
hitautodestruct

1
Моя коротка відповідь - фоновий процес. Запит та відповідь (включаючи API відпочинку) все можна досягти за допомогою будь-якої іншої мови та сервера. Тож для тих, хто думає перетворити свої веб-проекти у вузол. Подумайте знову це те саме! Використовуйте вузол як фоновий процес, як читання електронних листів із зображеннями, обробка зображень, завантаження файлів у хмару, чи будь-які тривалі або ніколи не закінчені процеси, в основному орієнтовані на події ...
Vikas

409

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

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

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

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

Плюс це весь час JavaScript. Lingua Franca на цілій стеці.


17
Просто спостереження від того, хто переходить між .Net і Node. Різні мови для різних областей системи дуже допомагають при переключенні контексту. Коли я дивлюся на Javascript, я працюю в Клієнті, C # означає сервер додатків, SQL = база даних. Працюючи в Javascript протягом усього часу, я виявив, що я плутаю шари або просто займаю більше часу, щоб переключитися на контекст. Ймовірно, це артефакт роботи над стеком .NET цілий день та Noding вночі, але це має значення.
Майкл Блекберн

9
Цікаво, що практика міжкультурних індивідів, що перемикають діалекти, рухаючись між основною та рідною культурами, називається "переключенням коду".
Майкл Блекберн

1
Лише днями я замислювався над тим, як би я міг .jsякось інакше призначити різні кольори моїм файлам. Зелений для клієнта, синій для сервера. Я постійно "втрачаю" себе.
AJB

209

Причини використання NodeJS:

  • Він працює у Javascript, тому ви можете використовувати ту саму мову на сервері та клієнті і навіть обмінюватися деяким кодом між ними (наприклад, для перевірки форми або для перегляду представлень на будь-якому кінці.)

  • Однопоточні подієва система швидко , навіть при обробці багато запитів відразу, а також просто, по порівнянні з традиційними багатопоточних Java або ROR рамки.

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

  • Це стало стандартним середовищем дефакто, в якому запускати інструменти, пов’язані з Javascript та інші інструменти , пов’язані з веб-сторінками , включаючи запуски завдань, міні-фейєри, красувачі, підводки, препроцесори, пакети та процесори аналітики.

  • Це здається цілком придатним для прототипування, спритного розвитку та швидкої ітерації продукту .

Причини не використовувати 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 ... :)


1
@nane Так, я думаю, що вони можуть вирішити цю проблему, однак ви повинні обмежитися використанням лише бібліотек, написаних на мовах typesafe, або прийняти, що не вся ваша база коду вводиться статично. Але один аргумент іде: оскільки ви повинні написати хороші тести для свого коду незалежно від мови, то рівень вашої довіри повинен бути рівним навіть для динамічно набраного коду. Якщо ми приймемо цей аргумент, то переваги сильної типізації зводяться до сприяння розробці / налагодженню часу, спроможності та оптимізації .
joeytwiddle

1
@kervin, я погоджуюся, що деякі орієнтири були б чудовими, але я був розчарований тим, що міг знайти в Інтернеті. Дехто стверджував, що продуктивність .NET порівнянна з Node, але важливо, що ви насправді робите. Вузол може бути чудовим для доставки невеликих повідомлень з безліччю одночасних з'єднань, але не настільки чудовий для важких математичних обчислень. Хороше порівняння ефективності потребує тестування різних ситуацій.
joeytwiddle

2
@joeytwiddle чи не допоможуть такі речі, як Typescript, Node.js, коли мова йде про обробку великих складних програм та статичну перевірку типу?
CodeMonkey

2
@joeytwiddle для чого варто, ви можете скористатися stillmaintain.com, щоб визначити, чи зберігається пакет npm-пакет (оскільки більшість є в github). Крім того, npm searchі npm showпокаже вам дату останнього випуску пакета.
Денна комора

3
Порівнюючи рейки з вузлом, ви плутаєте платформу з рамкою. Rails є основою для Ruby так само, як Sails і meteor є основою для Javascript.
BonsaiOak

206

Коротше кажучи:

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

Гарна стаття про цикл обробки подій в Node.js є Mixu в технічному блог: Розуміння Node.js циклу подій .


127

У мене є один приклад у реальному світі, де я використовував 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 був приголомшливим вибором.


7
Як ви приймаєте щось подібне? Чи потрібно вам тоді встановити nodejs на виробничому сервері? У Linux?
Мігель Стівенс

1
Є кілька PaaS, таких як nodejitsu та Heroku. Або ви дійсно можете встановити nodejs на вікні linux, тобто з amazon ec2. дивіться: lauradhamilton.com/…
harry young

13
200 000 відвідувань протягом 1814 400 секунд. Не стосується взагалі. Навіть баш може подати стільки запитів, на найповільнішому сервері. Сервер подряпин. Найповільніший ВМ.
Tiberiu-Ionuț Stan

105

Найважливіші причини розпочати наступний проект за допомогою вузла ...

  • Усі найкрутіші чуваки - це так і треба бути цікаво.
  • Ви можете поспілкуватися в кулері та похвалитися безліччю пригод Вузла.
  • Ви є копійчиком, якщо мова йде про хмарні хостингові витрати.
  • Зробив це з Рейлами
  • Ви ненавидите розгортання IIS
  • Ваша стара IT-робота стає досить тьмяною, і ви хочете, щоб ви були в новому блискучому старті.

Чого очікувати ...

  • Ви почуватиметесь безпечно та захищено за допомогою Express без усієї програми, яка вам ніколи не потрібна.
  • Біжить як ракета і добре лущиться.
  • Ви мрієте про це. Ви його встановили. Пакет вузлів repo npmjs.org - це найбільша екосистема бібліотек з відкритим кодом у світі.
  • Ваш мозок буде викривленим часом у країні вкладених зворотних викликів ...
  • ... поки ви не навчитеся виконувати свої обіцянки .
  • Sequelize та Passport - ваші нові друзі API.
  • Налагодження здебільшого асинхронного коду отримає ммм ... цікаво .
  • Час для всіх Noders освоїти машинопис .

Хто ним користується?


18
Так, я міг би відповісти на це питання традиційним чином. Я думаю, що я кваліфікований для цього, але більшість із них вже було сказано, і я думав, що якась весела радість порушить монотонність. Я регулярно надаю технічні відповіді на інші запитання.
Тоні О’Хаган

1
вкладених зворотних викликів можна уникнути, використовуючи генератори ES6 для коду асинхронізації
рефактор

1
@CleanCrispCode: Так! ES6 прийняв C # стиль async/ , awaitтак що тепер ми можемо викотити багато прибиральника асинхронного вузла коду , який також підтримує традиційні try/ catch. У 2016/17 JS-кодери переходять на ES6.
Тоні О'Хаган

1
десять тисяч разів це "Ви будете почувати себе безпечно та захищено за допомогою Express без усієї програми, яка вам ніколи не потрібна",
Симоне Поггі

60

Немає нічого, як «Срібна куля». Все пов'язане з деякими витратами, пов'язаними з цим. Це як якщо ви їсте жирну їжу, ви будете ставити під загрозу своє здоров’я, а здорова їжа не прийде зі спеціями, як жирна їжа. Індивідуальний вибір, бажають вони здоров’я чи спецій, як у їжі. Таким же чином Node.js вважають використаним у конкретному сценарії. Якщо ваш додаток не відповідає цьому сценарію, ви не повинні враховувати його для розробки додатків. Я просто викладаю свою думку на те саме:

Коли використовувати Node.JS

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

Коли НЕ використовувати Node.JS

  1. Ваш запит на сервер залежить від алгоритму / Job, що споживає великий процесор.

Розгляд масштабності з Node.JS

  1. Сам Node.JS не використовує все ядро ​​базової системи, і він за замовчуванням є єдиним потоком, ви повинні написати логіку самостійно, щоб використовувати багатоядерний процесор і зробити його багатопотоковим.

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

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


24
Я не впевнений у тому, що "Якщо ваш запит на стороні сервера включає в себе блокування опцій, таких як File IO або Socket IO", зазначених у "Коли НЕ використовувати". Якщо я розумію правильно, однією з сильних сторін node.js є те, що він має потужні асинхронні засоби для обробки IO без блокування. Тож Node.js можна розглядати як «ліки» для блокування IO.
Ondrej Peterka

3
@OndraPeterka: Ви маєте рацію, що Node.js виправляє блокування IO сервера, однак, якщо ваш обробник запитів на сервері, він здійснює блокування дзвінка до якоїсь іншої веб-служби / файлової операції, Node.js тут не допоможе. Він не блокує IO лише для вхідних запитів на сервер, але не для вихідних запитів від вашого обробника запиту додатків.
Аджай Тіварі

4
@ajay з nodejs.org вони кажуть "не блокуючи введення-виведення", будь ласка, перевірте свої "Коли НЕ" 2 та 3.
Омар Аль-Ітаві

5
з поточною версією, вузол фактично підтримує багатоядерну підтримку, використовуючи кластер. Це дійсно підвищить ефективність додатка Node хоча б удвічі. Однак, я думаю, що продуктивність повинна бути більше, ніж удвічі, коли вони стабілізують кластерну область.
Нам Нгуен

4
Ви можете використовувати node.js для великих обчислень. Використовуйте fork. Дивіться stackoverflow.com/questions/9546225/… . Вузол дуже добре обробляє декілька ядер з clusterмодулем. nodejs.org/api/cluster.html
Джесс

41

Ще одна чудова річ, яку, на мою думку, ніхто не згадував про Node.js - це дивовижна спільнота, система управління пакунками (npm) та кількість існуючих модулів, які ви можете включити, просто включивши їх у свій файл package.json.


6
І всі ці пакунки відносно свіжі, тому вони мають перевагу заднього огляду і, як правило, відповідають останнім веб-стандартам.
joeytwiddle

3
При всій повазі, багато пакетів на npm страшні, тому що npm не має механізму оцінювання пакетів . Зауваження від CPAN кого-небудь?
Дан Даскалеску

занадто погано жодна з бібліотек websockets не може задовольнити специфікації rfc 6455. Фанати node.js глухі, німі та сліпі, коли цей факт дається.
r3wt

1
Я не знаю про те, коли ви зробили коментар, але зараз бібліотека ws підтримує цю специфікацію
Джонатан Грей

37

Мій твір: nodejs чудово підходить для створення в режимі реального часу систем, таких як аналітика, чат-додатки, apis, рекламні сервери і т.д.

Редагувати

Пройшло кілька років, як я почав використовувати nodejs, і я використав це для створення багатьох різних речей, включаючи статичні файлові сервери, просту аналітику, чат-програми та багато іншого. Це мій погляд, коли використовувати nodejs

Коли використовувати

При створенні системи, яка робила акцент на одночасність і швидкість.

  • Сокети лише для серверів, таких як програми для чату, програми irc тощо.
  • Соціальні мережі, які роблять акцент на таких ресурсах, як геолокація, відеопотік, аудіопотік тощо.
  • Обробка невеликих фрагментів даних дійсно швидка, як аналітичний веб-сайт.
  • Як виставлення REST лише api.

Коли не користуватися

Це дуже універсальний веб-сервер, тому ви можете використовувати його де завгодно, але, мабуть, не в цих місцях.

  • Прості блоги та статичні сайти.
  • Так само, як статичний файловий сервер.

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


Прості блоги все ще можуть скористатися Node.js. Для обслуговування статичних файлів ви все ще можете використовувати Node.js, і якщо навантаження збільшується, просто додайте зворотний проксі-сервер Nginx перед ним, згідно з поточними найкращими методами. Сервер Apache httpd - це динозавр, який вмирає - див. Опитування Netcraft .
Ендрю

Я б сказав інакше - погляньте на ghost.org , виглядає дивовижно і будується на версії NodeJs - співпраця, редагування статей у реальному часі. Крім того, створити просту сторінку в NodeJs, скажімо, за допомогою sailsjs.org , легко, швидко, і вам не потрібно заважати вивчати будь-яку з мов програмування на стороні сервера
Bery

30

Його можна використовувати де

  • Програми, які керуються великими подіями та сильно пов'язані з входом / виводом
  • Програми, що обробляють велику кількість підключень до інших систем
  • Програми в режимі реального часу (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/


20

Вузол найкращий для одночасної обробки запитів -

Отже, почнемо з розповіді. Останні 2 роки я працюю над JavaScript і розробляю веб-фронт, і мені це подобається. Хлопці із зворотнього боку надають нам деякі API, написані на Java, python (нас не хвилює), і ми просто пишемо AJAX-дзвінок, отримуємо наші дані та здогадуємося про що! ми зробили. Але насправді це не так просто. Якщо дані, які ми отримуємо, невірні або є якась помилка сервера, то ми застрягли, і нам доведеться зв’язатися з нашими хлопцями з заднього кінця по електронній пошті чи в чаті (іноді теж на WhatsApp :)). Це не круто. Що робити, якщо ми написали API в JavaScript і зателефонували цим API з нашого переднього кінця? Так, це здорово, тому що якщо ми стикаємося з будь-якою проблемою в API, ми можемо розібратися в цьому. Вгадай що ! ви можете це зробити зараз, як? - Вузол для вас є.

Гаразд погодився, що ви можете написати свій API в JavaScript, але що робити, якщо я все в порядку з вищевказаною проблемою. Чи є у вас інші причини використовувати API для відпочинку API?

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

Повернемося до нашої традиційної системи відпочинку API, яка базується на операціях блокування або нарізуванні різьби. Припустимо, відбувається два паралельних запиту (r1 і r2), кожен з яких потребує роботи з базою даних. Тож у традиційній системі що буде:

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

2. Спосіб нитки : Наш сервер створить два потоки для обох запитів r1і r2виконуватиме їх призначення після того, як база даних запитів так охолола його швидко. Але це забирає пам'ять, тому що ви можете побачити, що ми почали два потоки, і проблема збільшується, коли обидва запити запитують однакові дані. тоді вам доведеться вирішувати проблеми з тупиком. Тож це краще, ніж спосіб очікування, але проблеми все ж є.

Тепер ось, як це буде робити вузол:

3. Nodeway: Коли той самий паралельний запит надходить у вузол, він зареєструє подію за допомогою зворотного виклику і рухатиметься вперед, він не чекатиме відповіді на запит на конкретний r1запит. Отже, коли запит надходить, тоді цикл подій вузла (так, є цикл подій у вузлі, який служить цій цілі.) зареєструвати подію за допомогою функції зворотного дзвінка і рухатися вперед для подання r2запиту і аналогічно реєструвати подію за допомогою зворотного дзвінка. Щоразу, коли будь-який запит закінчується, він запускає відповідну подію та виконує зворотний виклик до завершення, не перериваючись.

Тож ні очікування, ні нарізка, ні споживання пам’яті - так, це сьогодні для відвідування API відпочинку.


1
Привіт Аншул. Чи можете ви розробити або запропонувати якийсь ресурс щодо того, як може виникати тупикова ситуація в нарізному способі.
jsbisht

16

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

Умійте робити чисті хмарні розробки

Я деякий час використовував Cloud9 IDE , і тепер я не уявляю без нього, він охоплює всі життєві цикли розвитку. Все, що вам потрібно, - це браузер, і ви можете кодувати будь-коли в будь-якому місці на будь-яких пристроях. Вам не потрібно перевіряти код в одному комп’ютері (як, наприклад, вдома), а потім замовити на іншому комп'ютері (наприклад, на робочому місці).

Звичайно, може бути хмарний IDE для інших мов чи платформ (Cloud 9 IDE додає підтримку і для інших мов), але використання Cloud 9 для розробки Node.js - це справді чудовий досвід для мене.


1
Насправді Cloud9 IDE та інші (кодуючи ту, яку я використовую) підтримують майже всі види веб-мови.
Wanny Miarelli

7
Ви серйозний чувак? це критерії вибору стека? :) щаслива, що працює для вас!
matanster

15

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

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


15

Донжинг азбестових лонгйонів ...

Вчора моя назва з публікаціями Packt, Реактивне програмування з JavaScript . Це насправді не Node.js-орієнтована назва; ранні глави призначені для висвітлення теорії, а пізніші кодові важкі глави охоплюють практику. Тому що я дійсно не думаю , що було б доцільно , щоб не дати читачам веб - сервер, Node.js , здавалося , безумовно , очевидним вибором. Справа була закрита ще до того, як її навіть відкрили.

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

Дозвольте мені включити кілька цитат, які тут є актуальними:

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

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

Є єчі, які не просто дратують людей, які приїжджають з Python / Django, які негайно перезавантажують джерело, якщо ви щось зміните. У Node.js поведінка за замовчуванням полягає в тому, що якщо ви внесете одну зміну, стара версія продовжує бути активною до кінця часу або поки ви вручну не зупините і не перезапустите сервер. Така невідповідна поведінка не просто дратує піфоністів; це також дратує рідних користувачів 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 МБ не дуже швидко піддається обробці на стороні Big Data, але є дуже велика допомога, яку винахідливі розробники можуть зробити багато. Але з іншого боку, 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 має декілька парадизів ».


9

Якщо ваша програма в основному прив’язує веб-apis чи інші канали io, надає або приймає користувальницький інтерфейс, node.js може стати для вас справедливим вибором, особливо якщо ви хочете вичавити найбільш масштабованість, або, якщо ваша основна мова в житті це javascript (або різновиди javascript-транспіляторів). Якщо ви створюєте мікросервіси, node.js також добре. Node.js також підходить для будь-якого невеликого або простого проекту.

Його головна продажна точка полягає в тому, що вона дозволяє переднім учасникам брати на себе відповідальність за речі, що не є типовими. Ще одна виправдана точка продажу - якщо для початку ваша робоча сила орієнтована на JavaScript.

Крім певного моменту, ви не можете масштабувати свій код без страшних злому для примушування модульності, читабельності та контролю потоку. Деякі люди люблять ці хаки, хоча, особливо виходячи з події Javascript, керованої подіями, вони здаються знайомими або прощальними.

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


3
Існує багато існуючих підходів до масштабування програм Node.js, і ви, схоже, не надаєте жодних посилань щодо претензій на "напівфабрикати", "жахливі хаки" та "жахливі API". Розум розширюється на тих?
Свен Слоутвег

Я залишаю це як вправу для читача, але достатньо подивитися на так звані рішення для контролю потоку.
matanster

2
Це насправді не відповідь. Ви стверджуєте, що існуючі рішення є "жахливими хаками", але не вдається вказати жодне з них. Чи вважали ви, що, можливо, просто не розумієте або не знаєте правильних методів масштабування програм Node.js?
Свен Слоотвег

Я трохи оновив свою відповідь. Можливо, у вас все ще є скарги, але якщо ви вважаєте, що це неправильно, слід коментувати деталі ... а не вказувати на їх відсутність у відповіді. Це було б більш продуктивним для спільноти imo.
matanster

-2

Я можу поділитися кількома пунктами, де і навіщо використовувати вузол js.

  1. Для таких додатків у реальному часі, як чат, спільне редагування, ми краще працюємо з nodejs, оскільки це база подій, де проводяться події та дані клієнтам із сервера.
  2. Простий і легкий для розуміння, оскільки це база JavaScript, де більшість людей мають ідею.
  3. Більшість поточних веб-додатків спрямовані на кутовий js та магістраль, з вузлом легко взаємодіяти з кодом клієнтської сторони, оскільки обидва будуть використовувати дані json.
  4. Доступно багато плагінів.

Недоліки: -

  1. Node підтримуватиме більшість баз даних, але найкращим є mongodb, який не підтримує складні об'єднання та інші.
  2. Помилки компіляції ... розробник повинен обробляти всі винятки, крім інших, якщо будь-яке додаток до помилок перестане працювати там, де нам знову потрібно запустити і запустити його вручну або використовувати будь-який інструмент автоматизації.

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


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

  2. Вузол особливо болючий за підтримку коду, який ви не відвідували деякий час. Інформація про тип та виявлення помилок у часі компіляції - ДОБРІ ЧОТИ. Навіщо все це викидати? Для чого? І бовтається, коли щось йде на південь, стеки часто трапляються абсолютно марно.


2
Хоча ви не перевіряєте час компіляції, JSDoc дозволяє додавати будь-яку інформацію про тип, яку ви хочете, щоб речі мали більше сенсу, коли ви повернетесь. Правильно розкладені (малі) функції також зазвичай досить легко виправитись через їх чітко визначене оточення (закриття). Погані сліди стека часто можна вирішити за допомогою деякого повторного факторингу, щоб уникнути розбиття вашої логіки на асинхронному зворотному звороті між ними. Зберігання зворотних викликів асинхронізації в межах одного закриття дозволяє легко міркувати та підтримувати.
Річ Ремер

2
Я провів 30 років з компільованими мовами, але після використання ним лише близько року JavaScript тепер є моєю мовою на вибір. Це просто так продуктивно - я можу зробити набагато більше із значно меншим кодом, ніж Java C # C ++ чи C. Але це інший спосіб мислення. Невведена змінна насправді є перевагою у багатьох випадках. JSLINT є важливим. Коли вам потрібно робити речі одночасно, асинхронні зворотні виклики набагато безпечніші, простіші та в кінцевому підсумку продуктивніші, ніж будь-яка мова, де вам потрібно використовувати потоки. І ви все одно повинні знати JavaScript, оскільки це мова браузера.
Джеймс

Я симпатизую висловленим проблемам, і зазначаю, що докладено певних зусиль для їх подолання, хоча вони, звичайно, не застосовуються повсюдно. Існує дивовижний проект під назвою Tern, який може забезпечити виведення типу зі статичного аналізу коду Javascript та бібліотек. У ньому є плагіни для різних редакторів. Є також Typescript, JSDoc і BetterJS . І тоді є Go , одна з багатьох мов компіляції на Javascript !
joeytwiddle
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.