ий Об'єкт. Всі змінні верхнього рівня «звалюються» до Глобального Об'єкт, і при використанні одночасно декількох модулів це може призвести до некерованого хаосу. Оскільки веб-додатки зазвичай складаються з безлічі об'єктів, можливо, що створювалися різними організаціями, то може виникнути побоювання, ніби програмування для Node те саме ходіння по мінному полю, нашпигованому конфліктуючими між собою глобальними об'єктами. Однак це не так. Насправді в Node використовується система організації модулів CommonJS, а це означає, що локальні змінні деякого модуля так і будуть локальними в ньому, нехай навіть виглядають як глобальні. Таке чітке розмежування між модулями вирішує проблему Глобального Об'єкту.
Використання єдиної мови програмування на сервері і на клієнті давно вже було мрією розробників для веб. Своїм корінням ця мрія йде в період становлення Java, коли аплети представлялися клієнтським інтерфейсом до написаних на Java серверним додаткам, a JavaScript спочатку бачився як полегшений скриптова мова взаємодії з апплетами. Але щось на цьому шляху не склалося, і в результаті, не Java, a JavaScript стала основною мовою на стороні клієнта-браузера. З появою Node ми, нарешті, зможемо реалізувати мрію - зробити JavaScript мовою, використовуваним по обидві сторони веб - на стороні клієнта і сервера.
У єдиної мови є кілька потенційних плюсів:
одні й ті ж програмісти можуть працювати над обома сторонами додатки;
код простіше переносити з сервера на клієнт і назад;
загальний для клієнта і сервера формат даних (JSON);
загальний програмний інструментарій;
загальні для клієнта і сервера засоби тестування і контролю якості;
на обох сторонах веб-додатки можна використовувати загальні шаблони уявлень;
спільну мову спілкування між групами, що працюють над клієнтської і серверної частью.упрощает реалізацію цих (та інших) достоїнств, пропонуючи грунтовну платформу і активне співтовариство розробників.
Архітектура: потоки або асинхронний ввід/вивід з керуванням по подіях.
Кажуть, що саме завдяки асинхронної подієво-орієнтованій архітектурі Node демонструє таку високу продуктивність. Так і є, тільки до цього треба додати ще стрімкість движка V8 JavaScript. У традиційній моделі сервера додатків паралелізм забезпечується за рахунок використання блокуючого вводу/виводу і декількох потоків. Кожен потік повинен чекати завершення введення/виводу, перед тим як приступити до обробки наступного запиту.
У Node є єдиний потік виконання, без будь-якого контекстного перемикання або очікування вводу/виводу. При будь-якому запиті введення/виведення задаються функції обробки, які згодом викликаються з циклу обробки подій, коли стануть доступні дані або відбудеться ще щось значуще. Модель циклу обробки подій і обробника подій - річ поширена, саме так виконуються написані на JavaScript скрипти в браузері. Очікується, що програма швидко поверне управління циклу обробки, щоб можна було викликати наступне вартісне в черзі завдання. Щоб повернути наші думки в потрібному напрямку, Райан Дав (в презентації «Cincode Node») запитує, що відбувається при виконанні такого коду:
result=query ('SELECT * from db);
Зрозуміло, програма в цій точці призупиняється на час, поки шар доступу до бази даних відправляє запит базі, яка обчислює результат і повертає дані. Залежно від складності запиту його виконання може зайняти дуже помітне час. Це погано, тому що поки потік простоює, може прийти інший запит, а якщо зайняті всі потоки, то запит буде просто відкинутий. Марнотратно це якось. Та й контекстне перемикання обходиться не безкоштовно; чим більше запущено потоків, тим більше часу процесор витрачає на збереження та відновлення їх стану. Крім того, стек кожного потоку займає місце в пам'яті. І просто за рахунок асинхронного подієво-орієнтованого введення/виведення Node усуває більшу частину цих накладних витрат, привносячи зовсім небагато власних.
Часто розповідь про реалізацію паралелізму за допомогою потоків супроводжується застереженнями типу «дорого і загрожує помилками», «ненадійні примітиви синхронізації в Java» або «проектування паралельних програм може виявитися складним, і не виключені помилки» (фрази взято з результатів, виданих пошуковою системою). Причиною цієї складності є доступ до поділюваних змінним і різні стратегії запобігання взаімоблокіровок і змагань між потоками. «Примітиви синхронізації в Java» - один із прикладів такої стратегії, і, очевидно, багато програмістів вважають, що користуватися ними важко. Щоб якось приховати складність, притаманну багатопоточність паралелізму, створюються каркаси типу java.util.concurr...
