Перейти к содержимому

После года использования NodeJS для разработки

Node очень легок для обучения. Особенное если вы знаете Javascript. Нагуглите разные туториалы для начинающих, поюзайте Express и вы уже в теме, не так ли? Затем вы начнете осознавать, что нужно как-то конектить с базами данных. Нет проблем, запускаем NPM… Это, всего лишь горстка SQL пакетов. Позднее вы поймете, что все инструменты ORM никуда не годятся и то, что базовый драйвер — это лучшее. Теперь должны возникнуть c реализацией модели и проверкой логики. Скоро вы начнете писать еще более сложные запросы и просто запутаетесь в callback'ах. Естественно, вы прочитаете про 'callback hell', плюнете на это дело и начнете юзать одну из многих библиотек pomise .

Всё это означает, что как-будто экосистема Node постоянно движется. И вектор этого движения так себе. Новые инструменты, которые вроде как «намного лучше и круче» старых, буду встречаться ежедневно. Только представьте: всегда можно найти то, что у вас есть, но только еще и солиднее. Вы будете удивлены и, похоже, сообщество это только поощряет.

Пакеты, которые состоят из тривиального кода не более чем на 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. Это способ писать код, который выглядит более-менее синхронно, без ytcnthgbvjq callback логики. К сожалению, пока не существует ни одного «стандарта» (как и для ничего другого в Javascript'е) для реализации или использования Promis.

Самая часто упоминаемая библиотека сейчас — это Bluebird. Она довольно быстро работает и заставляет просто работать. Как бы там ни было, я нашел в меру полезным оборачивать всё, что мне нужно в Promise.promisifyAll().

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

Плохая стандартизация

Последней каплей было то, что я открыл отсутствие стандартов. Такое чувство, что первый и каждый имеет свое собственное представление о том, как работать с вещами, описанными выше. Callback'и? Promis'ы? Обработка ошибок? Build скрипты? Этому нет конца...

Никто не может сказать, как написать стандартизированный Javascript-код. Просто забейте в гугле «Javascript Coding Standards» и вы поймете.

Я понимаю, что много языков не имеют строгой структуры, но они обычно имеют стандартный гайдлайн, созданный мейнтейнерами языка.

Итоги по Node

Я потратил около года, пытаясь заставить Javascript и более специфичный Node работать на нас. К сожалению, за это время мы потратили больше часов на поиск документации, знакомство с «стандартами», споры о библиотеках и отладку тривиального кода, чем на что-то полезное.

Посоветовал бы я Node для больших проектов? Абсолютно нет. Будут ли люди использовать его всё равно? Конечно будут. Мы ведь пытались.

Как бы там ни было, я бы рекомендовал Javascript для фронтенд разработчиков, таких как Angular или React .

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

(habrahabr)