Comments 38
Последние несколько лет пишу бэкенд на ноде для крупных проектов. По факту основные причины такие:
- Высокая производительность. Да, ясное дело, что тот же Go может быть быстрее, но не на порядок. Редко когда разница актуальна.
- Огромная скорость разработки
- Огромная экосистема
- Кроссплатформенность
- Бэкенд и фронтенд команды говорят на одном языке и переиспользуют компоненты
- Лёгкость отладки
- Гибкость и возможность подстроить под свои нужды и парадигмы
А насчёт низкого порога вхождения — как ни странно, это не так. Должно пройти немало времени, чтобы человек начал писать нормально серверный код. Ну или это должен быть разработчик с опытом работы на другом языке — тогда хватает 2-3 месяца.
К сожалению, сейчас примерно одинаковое количество внятных соискателей на Node.JS, Go и, например, питоне. Поэтому в текущей компании мы берём любых хороших разработчиков на несколько наших стеков, а потом собираем из них команды. И то нового коллегу найти получается очень редко — и это при условии отличных условий и зарплаты выше средней по рынку.
А насчёт низкого порога вхождения — как ни странно, это не так.
Поддерживаю. Тут скорее приравнивают порог вхождения в JS и в Node.js.
Порог вхождения именно в язык JS – да, он довольно низкий.
Порог вхождения уже готового JS разработчика в Node.js для серверной разработки – да, для такого человека порог вхождения в Node будет ниже, чем в какой-то новый для него ЯП, но этот порог снижается исключительно за счёт уже знания JS.
Говорить про порог вхождения именно в Node.js, как по мне это странно и не очень правильно, он действительно не такой уж и низкий.
А что такое хайп? И почему из-за него люди выбирают ноду?
А еще «хайп» — это Универсальный Контраргумент, используемый динозаврами для оправдания своего сидения на устаревших технологиях.
автор ноды> чуваки, я тут прикрутил V8 к сокетам, можно фигачить JS на сервере. Там тредов только нету, но можно колбеками — так даже быстрее. С глобальными переменными только поаккуратнее, ну и прикрутите там чтобы если память утекла и все упало — сервак бы ребутался.
джависты и прочие дотнетчики> Вы там головой-то не поехали часом?
… конференции, доклады, активный пиар про асинхронный подход и перформанс, основанный на искажении реальности…
молодежь> ура! Node — самый быстрый способ писать серваки, колбеки — самый крутой способ писать код
… проходит 8 лет
автор ноды> я тут подумал что не очень была идея. Ну типа с потоками все-таки лучше, и вообще. Я сам на GO спрыгнул, гоп до кучки.
джависты и прочие дотнетчики> Ну наконец у них отлегло-то…
авторы GO> мы тут язык придумали, все быстро пыщ-пыщ, дженериков только нету, но они вам не нужны, чтобы лишний раз головой ну думать. Тулинга только толком нету, ну ничего, напишем. Не на джаве же писать? Хаха!
джависты и прочие дотнетчики> Вы там головой-то не поехали часом?
Cудя по вашему описанию, "джависты и прочие дотнетчики" руководствуются философией "если долго сидеть на берегу реки, то можно увидеть, как по ней проплывет труп твоего врага". Подход интересный, но развития никакого.
На самом деле, кстати, "прочие дотнетчики" давно уже научились использовать ноду для серверного рендера реактовых или ангуляровых шаблонов.
UPD: упс, надо было минус убрать :-)
Выглядит как обычная проблема возникающая при попытке пересоздания папки которая открыта другим процессом. Перезагрузка не нужна, надо просто не забывать останавливать сервер и всякие вотчи (webpack, gulp, tsc) во время обновления библиотек.
К слову последние три года эта ошбика – едва ли не единственная ошибка, возникавшая у меня при разработке на винде.
Подход чем-то похож на GraphQL. К нему не присматривались?
- «автоматическую сериализацию/десериализацию моделей (например, не нужно проверять пришло ли поле с клиента, все проверяется автоматически)» — это в GraphQL из коробки и, в целом, и является одной из основных фишек GraphQL.
- «возможность генерации схемы API» — аналогично есть в GraphQL
- «генерацию документации на основе схемы» — если под документацией является графическое представление имеющегося API, то это решается инструментами типа github.com/gjtorikian/graphql-docs
- «генерацию полностью типизированного SDK для клиента » — есть очень много готовых клиентов для GraphQL на всех популярных платформах, в т.ч. на JS с хорошей интеграцией с React (Apollo или Relay от Facebook). См. github.com/chentsulin/awesome-graphql#lib
В силу того, что GraphQL — это стандартизированная спецификация, существует множество решений «вокруг», которые дают очень большое количество функциональности «на вырост» (типа выемка только тех полей моделей, что были запрошены, подписки на изменения, графическая «песочница» для работы с API (GraphiQL), всевозможные расширения для популярных IDE и т.д.).
А вообще есть не только на JS, вы можете поискать тут по слову server — github.com/chentsulin/awesome-graphql
Ну, а теперь к сладкому:
- чем это принципиально отличается от sails.js, loopback/strongloop и ещё пачки конструкторов api, которые хоть и убоги по моему скромному мнению, но обладают невероятным набором плагинов и огромным комьюнити (и даже иногда работают так как надо)
- как во всем этом добре добраться до тонкого тюнинга уровня http?
Мое личное мнение — нода вместе с нпм сама по себе и есть отличный фреймворк, расширяемый буквально до небес. Посмотрите как устроен express внутри. Если срезать пару углов в реализации, то это не более чем тоненькая обертка над стандартным нодовым api
Пишем масштабируемые и поддерживаемые сервера на Node.js и TypeScript