Node.js як бекенд: найкращі випадки використання, інструменти та обмеження

У 2009 році нова технологія зробила свої скромні початки у величезному всесвіті розробки.

Node.js була першою законною спробою встановити JavaScript на стороні сервера.

Сьогодні вам важко буде знайти веб-розробника, який не чув про Node.

Після свого заснування він розділив громади, розпочав форумні війни і багатьох привів у відчай.

Думаєте, я звучу драматично?

Швидкий пошук у Google. Ви приземлитеся на золоту шахту суперечок. Деякі аргументи, на які ви натрапите:

"Що б сталося з аксіомою" Використовуйте найкращий інструмент для роботи "? JavaScript на стороні сервера НІКОЛИ не найкращий інструмент для роботи ».

Деякі навіть звучать поетично:

«Пекло зворотного дзвінка справжнє
Налагодження - сука
JavaScript не створений для сервера
[…] “

А деякі більше ... прямо:

"Node.js - це неприємна бібліотека програмного забезпечення, і я не буду її використовувати."

Для цієї публікації я подумав, що прийшов час встановити запис прямо про Node.js та JavaScript як мову резервного використання.

Сьогодні я збираюся обговорити:

  • Поточний стан Node.js;
  • Його найкращі випадки використання;
  • Його обмеження;
  • Чого ми можемо очікувати від руху Вузла вперед.

Стан Node.js як бекенд

Перш ніж ми розпочнемо це, давайте нагадаємо собі, що саме таке Node.js:

Це JavaScript, створений на основі двигуна V8 JS Chrome. Node.js використовує подію, що не блокує модель вводу / виводу, яка робить її легкою та ефективною.

Тепер я знаю, що вступ малював Node як кошмар розробника. Правда, вона набула широкої популярності. Але не візьми на це моє слово:

Опитування розробників стека Overflow за 2017 рік показує, що це на даний момент розробники, які найбільш використовуються.

Це також мова з найбільш швидко зростаючою популярністю за останні п’ять років, тоді як мови на зразок C # і PHP втрачають пар. Сам JavaScript також піднімається.

Як можна пояснити швидкий перехід від вихідного люфта до прийняття основного для Node.js та JavaScript як резервної мови?

Простіше кажучи, Node пережив період "просто примх" і вступив у солідний зрілий стан. Він створив навколо себе сильну і постійно зростаючу спільноту та екосистему. Насправді його менеджер пакунків, npm, зараз є найбільшим реєстром програмного забезпечення в Інтернеті.

Node.js не тільки здійснив революцію в розробці веб-серверів, але й сприяв підвищенню продуктивності інтерфейсу завдяки впровадженню серйозної інженерії на стороні клієнта. Він також відіграв роль у розширенні загальної екосистеми JavaScript та вдосконаленні сучасних систем JS, таких як Angular, React або Vue.

З часом вона виявила помилкою багато попереджень, які люди мали в перші дні:

JavaScript та Node.js, як відомо, важко налагоджувати.

→ Ви можете скористатися тим самим досвідом налагодження, що й у фронталі, використовуючи інспектор вузлів, який пакує вбудовані Інструменти розробника Chrome.

Люди з Joyent також знають щось інше про вдосконалену налагодження та профілювання Node: їх універсальний налагоджувач DTrace був випущений давно!

Ви не можете використовувати його для серверних програм корпоративного рівня.

→ Такої інженерії можна досягти за допомогою Node.js: вона просто не має стільки вбудованих інструментів, які б взяли вас за руку. Великі гравці, такі як Netflix, PayPal, Walmart та Yahoo! усі це використали. Детальніше про це пізніше.

JavaScript - це динамічна мова, тому ви не отримаєте статичний пропуск від компілятора.

→ Це правда. Однак такі інструменти, як TypeScript і Flow, з’явилися для забезпечення такого типу захисту мови. Тут може зробити і фокусник із закриття Google.

JavaScript не створений для сервера.

→ Ну, JavaScript вже був на сервері в той же час, коли Netscape вбудував JS у свій браузер ще в 1995 році! Це був тип фронтового типу, тому що він мав повну монополію над ним.

І список продовжується і продовжується.

Тож давайте просто перейдемо до деяких найкращих випадків використання та обмежень, щоб краще зрозуміти позиціювання Node.

JavaScript для бекенда: найкращі випадки використання вузла

То чому б ви навіть розглядали Node.js як бекенд у своєму стеці?

Загальні переваги та характеристики

Дозвольте мені запустити кілька швидких запитів для вас:

  • З великою ймовірністю можна припустити, що ви вже керуєте своїм фронтом із JavaScript. У цьому випадку універсальність коду у вашому стеку є великою перевагою, яку потрібно пам’ятати.
  • Такі інструменти, як веб-пакет, допомагають повторно використовувати код на обох кінцях і залишатися узгодженими на всіх системних рівнях.
  • З повним стеком JavaScript ви можете написати веб-додаток, який візуалізується і на браузері, і на сервері. Це хвилююче

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

Скажімо, вам потрібно зробити кодування відео, ви не будете шукати езотеричну бібліотеку Node.js: просто викличете перевірені інструменти в командному рядку з Node. Або якщо вже є бібліотека Python, яка може виконати необхідний складний обчислення, ви можете створити мікросервіс і викликати ці функції через API REST.

  • Функція асинхронізація / очікування повністю змінила спосіб написання асинхронного коду, фактично зробивши його схожим і поводившись трохи більше як синхронний код. Підтримувана Node.js з версії 7.6, ця функція стала частиною рішення для сумнозвісного пекла Callback.

Все вищезазначене робить Node.js чудовим для наступних випадків використання.

Використовуйте випадок 1: програми в режимі реального часу

Додатки для спільної роботи (Trello, Google Docs), чат в чаті, обмін миттєвими повідомленнями та онлайн-ігри - все це приклади RTA, які користуються архітектурою Node.js.

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

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

Використовуйте випадок 2: Програми для однієї сторінки

SPA - це веб-програми, які завантажують одну HTML-сторінку і динамічно оновлюють її під час взаємодії користувача з додатком. Значна частина роботи відбувається на стороні клієнта, в JavaScript.

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

Використовуйте випадок 3: Масштабованість

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

Навіть його назва підкреслює, що він створений для збирання декількох маленьких розподілених вузлів, що спілкуються один з одним.

Модульність вузла дозволяє створювати невеликі додатки, не маючи справи з роздутою, надмірною екосистемою. Ви вибираєте інструменти, необхідні для роботи, а потім масштабуєте за потребою.

Ця масштабність не позбавлена ​​ускладнень, і якщо ви не будете обережні, Node.js може стати… небезпечним.

Обмеження в резервному режимі Node.js

Відверто кажучи, Node.js дозволяє легко стріляти в ногу. Конфігурація та налаштування ціна, і якщо ви недосвідчені чи недисципліновані, ви можете втратити себе - або свого клієнта.

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

Наприклад, з іншими мовами, такими як Ruby та добре відомим фреймворком Ruby on Rails, ми звикли до парадигми «конвенція про конфігурацію». Ці традиційні рамки взяли розробників за руку і відхилили трохи світла на безпечний шлях.

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

І тоді ви дізнаєтесь, що «пекло зворотного дзвінка» справді реально.

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

Навіть творець Node.js, Райан Дал, врешті-решт усвідомив обмеження системи перед тим, як піти працювати над іншими проектами. Він дуже прозоро поставився до цього:

“[…] Я думаю, що Node - не найкраща система для створення масивної серверної мережі. Я б використовував Go для цього. І чесно кажучи, саме тому я покинув Вузол. Це було усвідомлення того, що: о, насправді, це не найкраща система на сервері коли-небудь ».

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

Популярні інструменти для запуску JavaScript

Не так давно, якщо ви думали зібрати повний стек JS, першим, що прийшло в голову, був стек MEAN (MongoDB, Express, Angular & Node).

Сьогодні це відповідна група інструментів, але екосистема JavaScript тепер може запропонувати набагато більше, ніж на задньому плані, так що ви не можете обмежитися цим.

Ось декілька найпопулярніших рамок для резервних програм JavaScript у 2017 році:

  • Express.js все ще є найпопулярнішим фреймворком Node.js там. Це швидкий, непідданий та мінімалістичний веб-фреймворк. Вона розвивалася швидко, тому що вона стала простою та простою. Це, мабуть, ближче до основних ідей Node.js про легку систему з модульним підходом.
  • Meteor, з іншого боку, використовує чистий JavaScript і Node.js всередині архітектури. Метеор - сама екосистема, яка може бути корисною для створення більш складних серверних додатків. Однак його використання може стати складнішим, якщо ви хочете робити щось, що не вбудовано.
  • Sails.js - це система MVC в реальному часі. Він був розроблений для імітації MVC-картини Ruby on Rails, але підтримує вимоги сучасних програм. Це робиться через API, керовані даними, з масштабованою, орієнтованою на сервіс архітектурою.
  • Koa.js була створена командою, що стоїть за «Експресом». Позначається як "веб-рамка нового покоління для Node.js", це менша, більш виразна та більш міцна основа для веб-додатків та API.

Є ще багато, щоб вивчити, тому я віддам декілька справжніх швидко: Nest.js, Hapi.js, Socket.io, Mean.js, Total.js, Derby.js & Keystone.js.

Рухатися вперед

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

І я, безумовно, не вийду там і скажу, що це краще, ніж інші популярні мови, які містять бекенд, такі як Java, C #, C ++, PHP, Python, Go або Ruby.

Я думаю, що метою цього є пофарбувати сіру область між чорно-білими думками, які я читав на Node.js та JavaScript, як мову зворотного зв'язку.

Вам подобається чи ні, Node.js помітно тут, щоб залишитися. ;)

З часом інтерес Node.js

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

Після цього завдання кожного розробника ретельно продумати правильний стек для будь-якого нового проекту. Важливо знати всі свої варіанти і не списувати будь-яку альтернативу з початку роботи.

Наприклад, Snipcart працює на архітектурі .NET, яка також має неабияку частку найсайєрів. Чому ми її обрали?

Це був правильний інструмент для роботи, на той момент часу.

Ось сподіваємось, що цей огляд допоможе вам подумати про Node!

Які ваші думки щодо Node.js? І JavaScript як мова для бекенду? Досвід, яким ви хочете поділитися? Я впевнений, що у багатьох з вас є що сказати, тому сміливо починайте / приєднуйтесь до дискусії в коментарях! Якщо вам сподобалася ця публікація, будь-ласка, поділіться нею в Twitter.

Ця публікація була спочатку опублікована в блозі та інформаційному бюлетені Snipcart.