Проработав с C# по крайней мере половину своей карьеры (а позже и со стеком Java), я изначально смотрел на JavaScript свысока. С точки зрения «инженера на стороне сервера» это всегда была самая уродливая часть любой кодовой базы — она хороша для улучшения веб-приложений с помощью вызовов AJAX и другой магии на стороне клиента, но не для поддержки основных функций.
Node изменил все, не только с технической точки зрения, но и в том, как мы работаем вместе, чтобы привлечь клиентов.
Эволюция фронтенд-инженера
Большинство из нас работали в командах разработчиков программного обеспечения, где инженеры были сосредоточены исключительно на стороне сервера или на стороне клиента, или «Т-образно» — с некоторым участием в обоих.
«Организации, разрабатывающие системы… вынуждены создавать проекты, которые являются копиями коммуникационных структур этих организаций».
Хотя кросс-функциональные команды решают многие проблемы функциональных команд, они по-прежнему склонны к разрозненности. В частности, во внешнем интерфейсе они часто ограничены несоответствием классической архитектуры веб-приложений:
- Данные связываются с представлением на стороне сервера и отправляются клиенту
- Разметка «улучшается» на клиенте для улучшения опыта
Эти два состояния обычно создаются с использованием двух разных языков. Например, в межфункциональной команде это может быть человек, сидящий рядом с вами и выполняющий работу с Java, но что, если он захочет объединиться для решения проблемы с кем-то, кто действительно знает эту часть стек в глубину? Ей нужно либо выйти за пределы команды, чтобы получить помощь, либо сидеть и решать эту проблему. Этот сценарий представляет потенциальные проблемы для кросс-функциональной команды:
- Если существует плохая организационная (или командная) культура, она может чувствовать себя изолированной или несправедливо обвиненной в командной работе — плохо для морального духа.
- Она могла чувствовать, что ей нужно спешить и вводить ошибки
- Другие члены команды не могут работать над связанными заявками, что снижает поток
Прежде всего, возможность упущена — команды становятся сильнее, когда люди могут погрузиться в проблемы, поделиться идеями и с легкостью помочь друг другу.
Благодаря тому, что JavaScript можно запускать практически везде, Node позволил нашим фронтенд-командам полностью отказаться от понятия «серверная сторона» и «клиентская сторона» — инженеры теперь работают вместе не только над полным жизненным циклом запроса, но и над всю переднюю архитектуру. Комплексные инженеры (со специализацией) теперь могут кодировать серверы, полные наборы тестов, конвейеры сборки-развертывания и клиентскую логику на одном общем языке. По сути, бункер был удален, а переключение контекста уменьшено.
С точки зрения клиентского опыта, эта эволюция в команды «инженеров с полным стеком» означает, что мы можем быстрее решать проблемы как единое целое. Например, в YNAP мы регулярно отслеживаем количество ошибок наших приложений Node в дикой природе, чтобы убедиться, что количество необработанных исключений равно нулю.Если это изменится, несколько членов команды способный очень быстро исправлять проблемы в любом месте внешнего стека. Более старшим членам, возможно, потребуется время от времени давать рекомендации, но обычно это сводится к знанию анатомии жизненного цикла HTTP-запроса/ответа или более широкой архитектуры, чем глубокое знание самого уровня приложений.
«Представьте себе разработчика HTML, который должен попросить разработчика Java связать вместе страницы «А» и «Б». Вот где мы были»
Джефф Харрелл, PayPal
Наш опыт не уникален: некоторое время назад крупные игроки, такие как PayPal, сообщали об аналогичном росте производительности, а другие, такие как Netflix, даже создавали свои API с помощью Node.
Примечание об архитектуре: я считаю важным отметить, что хорошая архитектура (не говоря уже о людях) на практике имеет большое значение для "полного проектирования". Node позволяетнашим фронтенд-инженерам использовать полный стек где это имеет смысл. Хорошая архитектура микросервисов означает, что наши Node-приложения отвечают за доступ к данным, рендеринг и связь с клиентом, в то время как другие сервисы отвечают за компоновку больших объемов данных, вычисления и т. д. Разделение задач по-прежнему важно, чтобы гарантировать, что инженерные навыки не будут слишком распыляться. .
Клиентский опыт требует более быстрых изменений
По мере того, как технологии становятся дешевле, доступнее и проще в использовании, компании все чаще вынуждены не просто предоставлять свой продукт или услугу по каналам, ожидаемым их клиентами, но и по-настоящему понимать, чего клиент хочет от их взаимодействия с бизнесом. Искусственный интеллект скоро станет движущей силой пользовательского интерфейса, что в сочетании с растущим объемом и качеством собираемых нами данных означает, что у нас больше, чем когда-либо, потребность в создании легких систем, которые можно быстро развернуть. Мы движемся в направлении, когда организации должны не только отказаться от монолитных ИТ-систем, формируемых бизнесом, но и перейти к услугам, которые определяются самими клиентами. Если вам нужно создать специальный интерфейс, например, только для ваших основных клиентов, выполнение этого в рамках монолита, скорее всего, будет означать, что конкурент или революционер рынка сделает это лучше в качестве индивидуального сервиса, который можно обновлять. и развернуты постоянно.
Скорость инноваций важнее технологий
Многие крупные организации отреагировали на это, создав легкие микросервисы для поддержки определенных областей своих онлайн-предложений. Конечно, вы можете использовать множество технологий для создания микросервисов, однако то, что отличает Node от остальных продуктов, особенно в современных условиях, — это скорость прогресса и изменять в самом сообществе JavaScript (и, соответственно, в npm ec0system). Существует пугающе быстрая скорость продвижения, когда сообщество разработчиков открытого исходного кода выпускает модули, шаблоны приложений и инструменты, чтобы разработчики все время работали быстро.
С учетом того, что клиенты подталкивают к более быстрым изменениям, о которых я упоминал ранее, «культура хакерства», позволяющая быстро экспериментировать с новыми идеями и создавать прототипы, важна как никогда. Помимо конкретных технологий, JavaScript и экосистема Node хорошо подходят для опробования идей, инноваций и внедрения их в производство БЫСТРО. Например, в YNAP фронтенд-инженеры тратили много времени на то, чтобы монолит Java работал локально, прежде чем что-либо можно было сделать. Теперь мы раскручиваем приложения за считанные секунды, и если сторонний инструмент нам не подходит, мы создадим его с нуля за считанные дни, будь то фиктивный API или инструмент мониторинга.
Меньше - больше
В большей части кода, написанного для веб-приложений, мало ценности или конкурентного преимущества, никого не волнует ваш форматировщик даты. Модульная архитектура Node позволяет нам писать как можно меньше кода для решения бизнес-задач, создавая относительно небольшое количество функций с открытым исходным кодом, которые выполняют большую часть тяжелой работы за нас.
Написав меньший объем кода, мы можем больше сосредоточиться на качестве. В частности, мы можем сместить акцент на создание более сложных уровней автоматического контроля качества,что имеет решающее значение для обеспечения непрерывной доставки — наборы тестов, бенчмаркинг, автоматический анализ производительности и т. д. вещи, которые действительно влияют на клиента, поскольку вы можете тратить меньше времени на проблемы и больше времени на важные вещи. Прочтите этот пост инженерной команды Twitter о Twitter Lite, и вы увидите, сколько времени они тратят на производительность, использование данных и время загрузки через 2G/3G — вещи, которые значительно влияют на их пользователей. Трудно достичь этих целей, не сокращая время, затрачиваемое на что-то другое.
«Простота этой базовой архитектуры помогла нам обеспечить исключительную надежность и эффективность обслуживания в любом масштабе».
Николас Галлахер, Twitter
Все просто
Наши серверы тонкие — раньше «команде релиза», состоящей из людей из разных функций, требовалось более часа, чтобы выпустить изменения в установленную дату и в установленное время. Релиз обычно объединяет изменения кода от разных команд, что может привести к откатам и другим проблемам.
При правильной архитектуре приложение Node должно быть простым и узким в фокусе — это означает, что релизы вызывают больше доверия, а инженеры клиентской части могут сосредоточиться на клиентском опыте. Проблема может пройти путь от регистрации до исправления, тестирования и выпуска в тот же день, если это действительно необходимо. Все это означает, что клиент может увидеть выгоду почти так же быстро, как проблема может быть устранена. Однако, помимо автоматизации, большая часть этой уверенности исходит из того факта, что эти приложения сосредоточены на определенной части пути клиента.
Высокая производительность требует внешнего управления
Некоторое время говорили о прямой связи между взаимодействием с клиентами и производительностью, например. 40% пользователей покинут сайт, если он загружается дольше 3 секунд. Дело в том, что многие приложения легко достигают своего бюджета ответа сервера в 200 мс и более 80% времени ответа конечного пользователя затем тратится на внешний интерфейс.
Как я упоминал ранее, у многих внешних команд нет большого контроля над рендерингом на стороне сервера и доставкой ресурсов. Это неприемлемо, если вы действительно заботитесь о производительности внешнего интерфейса. Разработчики внешнего интерфейса должны иметь возможность точно определять, как и когда будут доставлены ресурсы и как именно визуализируется критический путь, чтобы обеспечить лучший в своем классе опыт. Стратегии оптимизации, такие как разделение кода (для динамической загрузки) и сервис-воркеры, требуют прямого контроля над серверным уровнем. Облегченные серверы Node идеально подходят для того, чтобы предоставить команде инженеров возможность полностью контролировать все аспекты производительности.
Например, в YNAP мы рендерим все наши приложения React на стороне сервера для повышения производительности и доступности. Для приложения следующего поколения члены моей команды хотели использовать styled-components для обработки доставки CSS — модуль, который может отображать и внедрять ровно столько CSS, сколько необходимо для отображения текущей страницы. Экосистема Node позволила им сразу же отказаться от всего подхода к доставке CSS для этого приложения (после некоторого тестирования) и заменить его чем-то, что будет ощущаться клиентом во внешнем интерфейсе (загрузка CSS — это огромный узкое место).
Значит, повсеместное использование JavaScript — это серебряная пуля?
Нет. Сама по себе технология никогда не поможет вашей команде работать лучше или приблизит вас к клиенту. В YNAP мы в течение нескольких лет находились в пути, развиваясь с помощью различных командных структур и гибких подходов в дополнение к нашему переходу на интерфейсные микросервисы и Node.
Я всегда считал, что технические команды существуют для того, чтобы приносить пользу, которую требуют их клиенты. Однако лучшие из них могут пойти дальше и повысить качество обслуживания клиентов, постепенно улучшая производительность, функции, качество и устраняя проблемы. Нет замены для:
- Поиск нужных людей (решателей проблем)
- Автономия и ответственность (собственность)
- Культура обучения, качество и доставка
Я также хочу отметить, что Node не всегда является правильным решением любой проблемы. Как я упоминал ранее, архитектура может играть ключевую роль в обеспечении успеха ее использования в производстве — и под этим я подразумеваю более широкую архитектуру, а не только архитектуру приложений.
Однако возможность использовать JavaScript во всем интерфейсном стеке, правильно выполненном, безусловно, может помочь избавиться от некоторой разрозненности, с которой я сталкивался в прошлом. Это также помогает нам быстро продвигаться вперед с новыми идеями, создавать инструменты там, где их нет, и повышать уровень участия инженеров во всех аспектах качества обслуживания клиентов, при этом производительность имеет огромное значение. часть этого.
