Після року використання NodeJS для розробки

Пропоную читачам «Хабрахабра» переклад сподобалася мені статті «After a year of using NodeJS in production» за авторством Gavin Vickery. Це продовження його статті «Why i'm switching from to Python Node.js». Він написав її трохи більше року тому у відповідь на розчарування при використанні Python і як обгрунтування переходу на Node.



Рік розробки з штатними інструментами командного рядка, клієнтські проекти і випуск оновлень для продуктів нашої компанії, у двох словах, це те, чого я навчився за цей час. Я б хотів поділитися досвідом, але мова піде не стільки про Node, скільки за весь Javascript в цілому.

Легко навчитися, але стати майстром неможливо

Node дуже простий для освоєння. Особливе якщо ви знайомі з Javascript. Нагуглите кілька туториалов для початківців, поиграйтесь з Express і ви вже в темі, чи не так? Потім ви почнете усвідомлювати, що потрібно якось взаємодіяти з базами даних. Немає проблем, запускаєте NPM… Ага, всього лише жменька пристойних SQL пакетів. Пізніше ви зрозумієте, що всі існуючі ORM інструменти нікуди не годяться і те, що базовий драйвер — це кращий вибір. Тепер у вас проблеми з реалізацією своєї моделі і перевіркою логіки. Скоро після цього, ви почнете писати більш складні запити і просто загубитеся в callback'ах. Природно, ви прочитаєте про 'callback hell', плюнете на цю справу і почнете використовувати одну з багатьох pomise бібліотек. З цих пір ви просто начинете «промисифицировать» всі штуки, що робите, в замін на спокійні вихідні.

Все це змушує сказати, що ніби-екосистема Node постійно рухається. І вектор цього руху не дуже хороший. Нові інструменти, які ніби як «набагато крутіше» старих, буду зустрічатися кожен день. Тільки уявіть: завжди можна знайти те, що у вас є, але тільки ще й «світиться». Ви будете здивовані як це може трапитися з вами. І схоже, спільнота це тільки заохочує. Ви використовуєте Grunt!? Всі використовують Gulp!? Зачекайте хвилинку, використовуйте NPM нативні скрипти!

Пакети, які складаються з тривіального коду не більше ніж на 10 рядків завантажуються тисячі разів щодня з NPM. Ви серйозно? Вам правда потрібно встановити всю цю низку залежностей, щоб просто перевірити тип масиву? І ці самі пакети використовуються такими гігантами як React і Babel.

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

Обробка помилок за принципом «пощастило\не пощастило»

Якщо ви прийшли з іншої мови, такого як Python, Ruby або PHP, то ви будете чекати, що щось кине вам виняток, щось його зловить, на худий кінець функція поверне помилку. І це нормально. Абсолютно нормально… Але в Node це не так. Навпаки, ви передаєте помилки у ваші callback'і чи promis'и — все вірно, ніяких кидків винятків. Але це працює рівно до тих пір, поки ви не захочете отримати стек викликів у декількох вкладених callstack'ів. Не кажучи вже про те, що якщо ви забудете повернути callback у разі помилки, то скрипт продовжить виконуватися і викличе набір інших помилок, у добавок до першої. Вам доведеться подвоїти кількість налагоджувальної інформації, щоб нормально дебажити.

Навіть якщо ви почнете серйозно» за стандартом обробляти свої власні помилки, ви не можете (без читання исходников) переконатися, що більша частина пакетів, встановлених з NPM, використовують той же підхід.

Ці проблеми приведуть вас до використання «catchall» обробників винятків. Які зможуть залогировать проблемне місце і дозволять вашій програмі не просто граціозно «впасти». Запам'ятайте, Node однопотоковий. Якщо що-то заблокує процес, все навколо порушится до біса. Але це круто, ви ж використовуєте Forever, Upstart and Monit, вірно?

Callback, Promise або Generator!?

Щоб управляти 'callback hell', помилками і головної 'hard-to-read', логікою все більше і більше розробників починають використовувати Promis'и. Це спосіб писати код, який виглядає більш-менш синхронно, без божевільною 'callback' логіки. На жаль, не існує жодного «стандарту» (як і для іншої Javascript'е) для реалізації або використання Promis'ів.

Найбільш часто згадується бібліотека зараз — це Bluebird. Вона досить гарна, швидко працює і змушує речі «просто працювати». Як би там не було, я знайшов дуже корисним обертати все, що мені потрібно в Promise.promisifyAll().

Для більшості проектів я закінчив використати чудову бібліотеку async, щоб зовсім відмовитися від callback'ів. Тепер все виглядає більш природно.

Ближче до кінця мого досвіду з Node генератори стали більш популярні. Я так і не закінчив своє «занурення» у них і тому не можу толком нічого сказати. Хотілося б почути кого-небудь, хто з ними знайомий ближче.

Погана стандартизація

Останньою краплею було те, що я виявив відсутність стандартів. Таке відчуття, ніби кожен має своє власне уявлення про те, як працювати з речами, описаними вище. Callback'і? Promis'и? Обробка помилок? Build скрипти? Та цього немає кінця.

Це все розпалює… Ніхто не може сказати, як написати стандартизований Javascript-код. Просто забийте в гуглі «Javascript Coding Standards» і ви зрозумієте, що я маю на увазі.

Я розумію, що багато мов не мають строгої структури, але вони зазвичай мають стандартний гайдлайн, створений мейнтейнерами мови.

Єдине, що хоч якось типово, написали Mozilla.

Підсумки по Node

Я витратив рік, намагаючись змусити Javascript і більш специфічний Node працювати на нашу команду. На жаль, за цей час ми витратили більше годин на пошук документації, знайомство з «стандартами», спори про бібліотеки і налагодження тривіального коду, ніж на щось корисне.

Порадив би я Node для великих проектів? Абсолютно ні. Чи будуть люди використати його все одно? Звичайно будуть. Я теж намагався.

Як би там не було, я б рекомендував Javascript для фронтенд розробників, таких як Angular або React (як ніби у вас є інший вибір).

Так само я б порадив Node для простих back-end серверів, використовуваних в основному для вебсокетов або надання API. Це можна просто зробити з Express, говорю так, тому що ми так і зробили для свого Quoterobot PDF-процесинг сервера. Це один файл, який містить 186 рядків коду, включаючи пробіли та коментарі. І він так само добре працює, наскільки він простий.

Повернення на Python

Цілком можливо, ви здивовані, що я роблю зараз? Зараз я продовжую писати головні частини наших продуктів і API, використовуючи Python. В основному на Flask або Django, використовуючи або Postgres або MongoDb.

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

Я сподіваюся, Javascript і Node поліпшать в майбутньому. Я буду щасливий спробувати його знову.

Розкажіть про свій досвід? Чи були у вас проблеми, які я відчував? Закінчили ви «перескакувати» тому, на більш комфортний мову?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.