Node.js — это язык для написания серверных приложений на javascript, преимущества которого заключаются в неблокировке и высокой скорости ввода-вывода. Я полагаю, что многие проекты фронтенд-разработки жаждут увидеть это описание. Наконец-то у меня есть возможность конкурировать с фоновой разработкой, и уже не за горами свержение теории цепочки презрения к программистам (c>c++>java/.net>front-end).
Однако на самом деле Node.js пережил 10 лет, и он не вызвал слишком много волн в серверных приложениях, вместо этого он более широко используется в управлении пакетами и инструментах, таких как хранилище npm, веб-пакет и т. д. Таким образом, если исходным стеком серверных технологий вашей команды не является Node.js, потребуются некоторые усилия, чтобы убедить компанию использовать Node.js на стороне сервера.
Компания, в которой работает автор, использует Node.js более двух лет — от начала использования Node.js вместо Jsp для разделения фронтенда и бэкэнда до использования Node.js для реализации некоторых инновационных проектов компании. , я накопил определенный опыт. Далее в этой статье будет описано, как сложно убедить использовать Node.js? Как закрепиться и заставить лидеров принять Node.js? Любые комментарии и идеи приветствуются, чтобы оставить сообщение для обсуждения.
Статья написана 19.06.14. Возможно, в будущем не составит труда убедить использовать Node.js, и то, что описано в этой статье, не будет применяться.
Почему так сложно использовать Node.js как сервис
В большинстве компаний фоновые службы в основном контролируются такими языками, как java и c++. Таким образом, попытка использовать Node.js для оказания услуг сталкивается с различными трудностями, основные из которых следующие:
1. Зрелая фоновая система
Взяв в качестве примера java, после длительного периода разработки и онлайн-проверки экология java вполне совершенна. В контексте нынешней популярности микросервисных систем кажется, что для Java рождаются различные микросервисные решения, такие как использованиеSpring Cloudсистемы, вы можете построить полный набор решений. И Node.js все еще находится в зачаточном состоянии. К счастью, этот тип решения в основном обеспечивает стандартное решение для доступа, и также можно получить доступ к системным языкам, отличным от Java, таким как Node.js. Однако порог доступа относительно высок. Например, доступ java предоставляет соответствующий sdk, и нужно написать только соответствующие файлы конфигурации.Node.js должен написать свой собственный код для его реализации.
Кроме того, для снижения затрат на эксплуатацию и техническое обслуживание небольшие компании обычно принимают только один фоновый язык.В системе Java легче найти старших инженеров для устранения неполадок и решения проблем.
2. Отсутствие соответствующей технической грамотности у фронтенд-персонала
Фоновая разработка предъявляет более высокие требования к алгоритмам, интерфейсам данных, шаблонам проектирования, логическому анализу и другим возможностям и является более строгой. В традиционной фронтенд-разработке вам нужно нести ответственность только за пользователей, я думаю, вы слышали об этом.Don't let me thinkЭто предложение. Внешний интерфейс отвечает за пользовательский опыт и ориентирован на чувствительность. Делайте это хорошо, и вы сможете стать отличным фронтенд-разработчиком. Однако, если вы хотите, чтобы Node.js применялся на стороне сервера, соответствующие технические возможности должны быть дополнены.К счастью, обучение у окружающих больших коров и посещение технических форумов могут компенсировать это.
3. Стереотипы о JavaScript и интерфейсе в большой среде
«В конце концов, порог входа для фронтенда относительно низок.» Я считаю, что это предложение должны услышать все студенты фронтенда. а такжеJavaScriptЭто слабо типизированный язык, и он строго не используется в бэкенде (вместо него вы можете использовать Typescript). Изменение стереотипов — длительный процесс. Также хотелось бы поблагодарить крупных отечественных производителей.Масштабное использование Node.js в онлайн-среде меняет у людей прошлые впечатления.
4. Неопределенность экосистемы Node.js.
В основном это происходит по двум причинам:
- Автор node.js сделал новый
deno, что подорвало всеобщую уверенность в использовании Node.js; - Пакет npm, несмотря на его большое количество, не сертифицирован по безопасности.
Короче говоря, использование Node.js в качестве языка разработки на стороне сервера требует твердой решимости. Но решимости недостаточно, мы используем новую технологию и должны найти свою опору.
Фундамент — почему я использую Node.js
Когда мы, наконец, набрались смелости возглавить Amway Node.js, мы не могли сказать: «Смотрите, такая-то фабрика тоже его использует». Предупрежден — значит вооружен, не предугадывая потери. Мы должны найти правильную опору и дать понять руководителям, что это могут сделать только фронтенд-коллеги или сделать это лучше. Я думаю, что это можно обсудить со следующих аспектов.
1. Все для пользователя — для улучшения пользовательского опыта
Фронтенд-разработка должна отвечать за пользовательский опыт.
Когда-то разграничение между front-end и back-end разработкой не было столь очевидным, большую часть front-end страниц делал back-end персонал, а набор JQuery+BootStrap мог разойтись по всему миру. , такие как J2EE, PHP, ASP.NET и т. д. Но с появлением интерфейсных фреймворков (Angular, React, Vue) сложность и трудность начала работы перестали быть чем-то, что можно использовать из коробки в бэкенде. Постепенно нынешний персонал бэкенда «не понимает» интерфейс, и они имеют больше права голоса в опыте фронтенда.
В то же время сложный интерфейсный фреймворк также делает время первого экрана все больше и больше, а белый экран также приведет к потере пользователей, что требует от нас оптимизации.Обычные методы следующие:SSR,PWA. И этого трудно достичь без мощности Node.js.
2. Обязанности ясны — повысьте производительность команды разработчиков
Интерфейс, разработанный на стороне сервера, должен быть ориентирован на общие сервисы и иметь тенденцию быть стабильным, а команда back-end должна сосредоточиться на самом сервисе и уделять как можно меньше внимания пользовательскому интерфейсу. Один набор интерфейсов, применимый к нескольким терминалам.
Интерфейсы, ориентированные на пользовательский интерфейс, должны быть переданыBFF(Backends For Frontends), который реализует агрегацию данных, обрезку и форматирование. ПодождиСервисная автономия(Кто использует, кто отвечает, кто разрабатывает) этот слой должен быть передан фронтенд-команде.
3. Расширение прав и возможностей команды. Улучшите воображение и пространство для роста команды разработчиков.
Фронтенд — это область, которая требует постоянного обучения и подзарядки.Появляются и становятся популярными различные новые технологии, такие какPWA,GraphQL,SSRПодождите, нам нужно попробовать. Использование Node.js позволяет команде внедрить эти технологии и повысить жизнеспособность и технический уровень команды. Команда с простором для воображения может создать что-то другое.
Как заставить лидеров доверять вам владение Node.js
1. Создайте профессиональный имидж
Основная цель создания профессионального имиджа — завоевать доверие лидера и дать понять лидеру, что вы тот, кто может делать что-то хорошо, то есть позволить лидеру доверять вам в первую очередь как человеку или команде. Это требует большего общения с лидерами в обычное время, чтобы показать личные качества. Я думаю, что это в основном делится на два аспекта:
- Сильное чувство ответственности, сильная способность решать проблемы и способность учиться при столкновении с проблемами. Если вы уже сражались в тяжелых битвах, это будет хорошим вспомогательным материалом.
- Отличные технические способности. В дополнение к тому, что вы хорошо выполняете свою собственную работу, вы должны иметь соответствующую производительность в сети, безопасности, архитектуре кода и других внутренних аспектах.Обычно хорошим доказательством будет посещение форумов, обмен внутренними моментами и написание технических статей.
2. Камень других гор может атаковать нефрит
Подходите к технологиям с открытым и инклюзивным отношением. На фоне больших коров на заднем плане контент, который может сделать Node.js, все еще мал, и у них есть зрелые решения во всех аспектах. Например, в аспектах полноканального мониторинга, измерения производительности системы, алгоритма, базы данных и т. д. нам следует больше консультироваться с фоновым персоналом и прислушиваться к нему.
3. Говорите с данными и документами
Производительность Node.js и то, сможет ли она выдержать существующее давление, невозможно четко описать в нескольких словах, отчет о стресс-тестах является лучшим доказательством. Если это преобразование исходной системы, будет лучше иметь интуитивно понятное сравнение данных.Когда мы используем Node.js для преобразования сайта JSP, данные, полученные путем рендеринга того же измерения давления на странице, в 10 раз + улучшение производительности.
Хороший технический документ поможет каждому понять вашу архитектуру и сделать последующие расширения. Поэтому документ о долгосрочном обслуживании также очень важен. Как написать хороший документ, всем рекомендую прочитать эту статьюWhat nobody tells you about documentation
разное
Ниже приведены некоторые из моих взглядов на будущее развитие Node.js, только для справки:
-
service meshПосле масштабного использования микросервисов микросервисы можно разрабатывать на любом языке, не заботясь о том, как построить саму систему микросервисов. Это хорошая вещь для использования Node.js; - Существующая система эксплуатации и обслуживания является достаточно зрелой.
k8s+PrometheusВы можете выполнять мониторинг времени выполнения node.js, а онлайн-мониторинг, как правило, прост; - «Общая тенденция мира еще долго будет разделена».
немного полезной информации