После Года Использования Nodejs Для Разработки

Особенно, если вы знакомы с JavaScript. Погуглите несколько руководств для начинающих, поиграйтесь с Express, и вы в курсе, верно? Тогда вы начнете понимать, что с базами данных нужно как-то взаимодействовать.

Нет проблем, запустите NPM. Да, всего несколько достойных пакетов SQL. Позже вы поймете, что все существующие инструменты ORM бесполезны и что базовый драйвер — лучший выбор.

Теперь у вас возникли проблемы с реализацией модели и тестированием логики.

Вскоре после этого вы начнете писать более сложные запросы и просто потеряетесь в обратных вызовах.

Естественно, вы прочитаете об «аде обратных вызовов», откажетесь от этого вопроса и начнете использовать одну из многочисленных библиотек обещаний.

С этого момента вы просто начнете «обещать» все, что делаете, в обмен на расслабляющие выходные.

Все это создает впечатление, будто экосистема Node постоянно движется.

И вектор этого движения не очень хороший.

Новые инструменты, которые кажутся «намного круче» старых, будут находить каждый день.

Только представьте: вы всегда можете найти то, что у вас есть, но оно еще и «светится».

Вы будете удивлены, насколько легко это может случиться с вами.

И похоже, что сообщество это поощряет. Вы используете Grunt!? Все используют Gulp!? Подождите, используйте собственные скрипты NPM! Пакеты, состоящие не более чем из 10 строк тривиального кода, загружаются из NPM тысячи раз каждый день.

Вы серьезно? Вам действительно нужно устанавливать всю эту цепочку зависимостей только для того, чтобы проверить тип массива? И эти же пакеты используют такие гиганты, как React и Babel. Вы никогда не станете хозяином чего-то, что движется с такой ошеломляющей скоростью.

И это не говоря ни слова об «стабильности» подобных движений.

И это нормально.

Совершенно нормально.

Но в Node это не так.

Напротив, вы передаете ошибки в свои обратные вызовы или обещания — это верно, никаких исключений не создается.

Но это работает только до тех пор, пока вы не захотите получить стек вызовов из нескольких вложенных обратных вызовов.

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

Для правильной отладки вам придется удвоить объем отладочной информации.

Даже если вы начнете «серьезно» стандартизировать собственную обработку ошибок, вы не сможете (не читая исходники) быть уверенными, что большинство пакетов, установленных из NPM, используют один и тот же подход. Эти проблемы заставят вас использовать обработчики исключений «catchall».

Который сможет выявить проблемную область и позволит вашему приложению не просто изящно «упасть».

Помните, Node однопоточный.

Если что-то заблокирует процесс, все вокруг пойдет к черту.

Это способ написать код, который выглядит более или менее синхронно, без сумасшедшей логики «обратного вызова».

К сожалению, не существует единого «стандарта» (как и всего остального в JavaScript) для реализации или использования промисов.

Наиболее часто упоминаемая библиотека сейчас — Синяя птица .

Она неплохая, работает быстро и заставляет все «просто работать».

В любом случае, я нашел очень полезным обернуть все, что мне нужно, в Promise.promisifyAll().

По большей части я использовал замечательную библиотеку асинхронный , чтобы держать обратные вызовы под контролем.

С ней все выглядело более естественно.

К концу моего опыта работы с Node генераторы стали более популярными.

Я еще не закончил свое «погружение» в них и поэтому ничего толком сказать не могу.

Хотелось бы услышать мнение кого-нибудь, кто с ними более знаком.

Такое ощущение, что у каждого свое представление о том, как работать с описанными выше вещами.

Обратные вызовы? Обещания? Ошибка обработки? Создавать скрипты? Этому нет конца.

Все накаляется.

Никто не может сказать вам, как писать стандартизированный код JavaScript. Просто введите в Google «Стандарты кодирования JavaScript», и вы поймете, что я имею в виду.

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

Единственное, что хоть как-то приемлемо, было написано в Мозилла .

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

Рекомендую ли я Node для крупных проектов? Точно нет. Будут ли люди по-прежнему использовать его? Конечно, они это сделают. Я тоже попробовал.

В любом случае, я бы рекомендовал JavaScript для фронтенд-разработчиков, например Angular или React (как будто у вас есть другой выбор).

Я бы также рекомендовал Node для простых внутренних серверов, используемых в основном для веб-сокетов или предоставления API. Это можно легко сделать с помощью Express, я говорю это потому, что мы сделали это для своего.

Цитатаробот Сервер обработки PDF. Это один файл, содержащий 186 строк кода, включая пробелы и комментарии.

И это работает так же хорошо, как и просто.

Конечно, у него есть и свои недостатки.

Но это хорошо, когда начинаешь на нем писать.

По какой-то причине Node привлек мое внимание и зацепил меня.

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

Я надеюсь, что JavaScript и Node улучшатся в будущем.

Я буду рад попробовать еще раз.