Smashing Podcast Episode 29 с Лесли Кон-Вейн: как Netlify Dogfood The Jamstack?

В этом эпизоде ​​мы спрашиваем, как выглядит тестовая версия Jamstack в Netlify. Можете ли вы развернуть все приложение в CDN? Дрю Маклеллан разговаривает со штатным инженером Netlify Лесли Кон-Вейн, чтобы выяснить это.

Показать примечания

• личный сайт Лесли
• Лесли в Твиттере
• Нетлайф

Еженедельное обновление

• Погружение в React и Three.js с использованием react-three-fiber
  автор Fortune Ikechi
• Лучшие практики для дизайна пользовательского интерфейса электронной коммерции
  автор Сюзанна Скакка
• Аутентификация приложений React с помощью Auth0
  автор Нефе Эмадамерхо-Атори
• От экспертов: глобальные изменения в области цифровой доступности во время COVID-19
  автор Робин Кристоферсон
• Что нового в Vue 3?
  автор Тими Омоени

Стенограмма

Дрю Маклеллан: Отмеченный наградами специалист по внешнему интерфейсу, родом из Остина, но сейчас живет в Далласе, штат Техас, после временного пребывания в Нью-Йорке. За это время, работая в агентствах, она создавала сайты для таких клиентов, как Nintendo, WorldPride и Jerry Seinfeld. Сейчас она штатный инженер по внешнему интерфейсу в Netlify, где, помимо прочего, работает над созданием приложений, которые клиенты используют для управления своими услугами и развертываниями. Итак, мы знаем, что она опытный фронтенд-инженер, но знаете ли вы, что, живя в Нью-Йорке, она три года подряд работала помощником судьи по приготовлению чили. И это на самом деле правда. Мои потрясающие друзья, пожалуйста, поприветствуйте Лесли Кон-Вейн. Привет, Лесли. Как твои дела?

Лесли Кон-Вейн: Я в ударе.

Дрю: Я хотел поговорить с вами сегодня о том, как Netlify ест свою собачью еду, если использовать это очаровательное выражение, когда дело доходит до Jamstack. Я должен немного поместить это в контекст, сказав, что еще несколько месяцев назад мы работали вместе в одной команде в Netlify. И когда я туда попал, процесс разработки был мне совершенно чужд, даже после 20 лет работы разработчиком. Я подумал, что это было действительно увлекательно и стоило того, чтобы его немного изучить с более широкой аудиторией. Я, вероятно, должен указать, что мы говорим об этом, потому что это действительно интересное тематическое исследование, а не спонсируемая большая реклама Netlify. Каждый должен проверить Vercel. Но я думаю, что из обсуждения можно извлечь много ценных вещей, особенно с точки зрения Jamstack. Потому что Netlify действительно большой сторонник подхода Jamstack, и услуга как бы предлагается клиенту и построена вокруг этой идеи создания проектов Jamstack. Но и сам сервис построен по этим принципам. Не так ли?

Лесли: Это да. Многие люди думают об архитектуре Jamstack как о статических сайтах, но мы на самом деле тестируем, что означает создание приложения Jamstack с интерфейсом Netlify. Поскольку это приложение React, которое представляет собой полноценное приложение Jamstack, мы развертываем Netlify на Netlify, так что… Да, мы действительно пробуем его и раздвигаем границы возможного.

Дрю: Я думаю, что иногда бытует мнение, что Jamstack отлично подходит только для статических сайтов, как вы говорите, и аспект API появляется, если вы хотите отправить форму на адрес электронной почты, и вы можете просто сделать что-то простое, но вы таким образом можно создать целое веб-приложение. Но вы делаете это, не так ли?

Лесли: Да, абсолютно. Наше приложение, говоря конкретно о том, что вы видите, если войдете в систему на app.netlify.com, основано на… у нас есть внутренний REST API, но внешний интерфейс, как я уже сказал, это чистый Jamstack. Итак, у нас есть собственный этап сборки, мы наблюдаем за сборкой приложения в приложении и развертываем его в нашей собственной системе.

Дрю: Итак, когда задействован бэкэнд-процесс, и всегда будет какой-то уровень бэкэнд-процессов, вы знаете, сохранение данных или, в случае с Netlify, начинающийся с развертывания или чего-то еще, этот бэкэнд просто строится как серия API, которые затем могут использоваться интерфейсом?

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

Дрю: Думаю, меня удивило, когда я начал работать над приложением, насколько многого можно достичь во внешнем интерфейсе, особенно когда речь идет о взаимодействии с внешними API и прочим. Я знаю, что когда Netlify взаимодействует с вашим провайдером Git, поэтому он переходит на GitHub и получает список репозиториев, все это происходит между вашим браузером и GitHub. И помимо, может быть,… прохождения безсерверной функции, которая помещает некоторые секреты в запрос или что-то в этом роде, большая часть этого просто происходит в стиле Jamstack. Он не проходит через базовую серверную инфраструктуру типа Netlify. Итак, это довольно увлекательно. Это действительно намного больше, чем просто статический сайт с несколькими вызовами API для выполнения мелких задач. Это и есть настоящая основная функциональность, не так ли, которая реализуется в браузере?

Лесли: Абсолютно. Я думаю, это действительно расширяет представление о том, что такое фронтенд-разработчик, верно? И это то, что подталкивает меня, как фронтенд-инженера, к тому, чтобы быть лучше и больше думать о такого рода… уровне API, к которому я традиционно не был так близок. Я больше работаю над пользовательским интерфейсом, цветами и системами дизайна, так что это действительно… Я действительно обнаружил, что работа над масштабным приложением Jamstack подтолкнула меня к тому, чтобы стать лучшим разработчиком.

Дрю: Быть фронтенд-разработчиком не значит знать CSS от начала до конца, хотя это его часть. Это не знание HTML от начала до конца, но это часть его. Это также отклонение на эту территорию, которая традиционно была прерогативой бэкэнд-инженера, что довольно интересно. Использует ли Netlify новый рендеринг на стороне сервера для

Лесли: Не то чтобы я в курсе.

Дрю: Итак, все буквально сделано, как вы говорите, вы обслуживаете оболочку, а затем она заполняется запросами к различным конечным точкам API, чтобы как бы заполнить все это.

Лесли: Точно.

Дрю: И вы говорите, что это приложение React?

Лесли: Да. да. Реагировать. Сейчас мы используем React Redux, и прямо сейчас мы PostCSS, но мы также экспериментируем с нашей архитектурой CSS.

Дрю: Разве мы не все? Итак, вы создаете приложение в React, а затем развертываете его в Netlify?

Лесли: Да. Может быть, моя любимая часть всего этого процесса — это волшебство Deploy Previews, которое мы получаем через Netlify. Итак, что происходит, вы будете… вы работаете в GitHub, вы продвигаете свой PR. Итак, вы открываете свой PR в GitHub, и это автоматически создает сборку вашего Deploy Preview приложения. Таким образом, мы фактически используем Deploy Previews самого приложения для тестирования, чтобы убедиться, что все работает так, как должно. Мы запускаем наши тесты. Это то, что мы используем для ручной проверки во время проверки кода. Итак, у нас есть все это непрерывное развертывание, настроенное прямо из GitHub.

Лесли: И еще одна интересная вещь, которую мы настроили, это то, что у нас есть пара разных сайтов Netlify, которые загружаются из того же репозитория, где находится наше приложение. Итак, у нас есть как наше приложение, так и экземпляр Storybook, в котором есть своего рода компоненты пользовательского интерфейса для приложения. Итак, у нас есть само приложение, компоненты пользовательского интерфейса Storybook и, по сути, сайт Netlify, который показывает наш пользовательский интерфейс Storybook. А еще у нас есть третий сайт, на котором работает анализатор пакетов webpack. Итак, это визуальный пользовательский интерфейс, который дает вам древовидную карту, визуализацию всех пакетов приложений, и мы можем как бы оценить их размер, и это просто напоминание нам о том, чтобы перепроверить. Когда каждое развертывание приложения выходит, мы можем проверить и убедиться, что мы не делаем ничего странного с нашим размером пакета. Таким образом, все три этих сайта генерируются в одном запросе на извлечение приложения. Таким образом, вы получите ссылки для предварительного просмотра, по сути, ваших предварительных просмотров развертывания, как сборника рассказов приложения, так и профиля этого приложения, чтобы мы могли его проверить.

Дрю: А с Deploy Previews это, по сути, становится вашей промежуточной средой, не так ли?

Лесли: Точно. На самом деле мы не запускаем традиционную промежуточную среду, потому что мы действительно верим, что наши предварительные версии развертывания — это, по сути, то, что будет запущено, когда мы нажмем кнопку слияния и запустим официальную сборку нашей основной ветки в нашем основном приложении. Так что мне нравится, что мы можем полагаться на Deploy Previews как на промежуточную среду. Мы действительно верим, что это будет соответствовать производству. Мы создаем его со всеми производственными переменными, всем, что… переменные среды, все это создается в Deploy Preview. Итак, это очень похоже на ситуацию, в которой можно не беспокоиться. Пока ваш Deploy Preview работает, вы знаете, что приложение тоже будет работать.

Дрю: И я думаю, как организация, если ваш предварительный просмотр развертывания не соответствует тому, что будет запущено, то это проблема службы, которую Netlify хочет решить. Так что с этой точки зрения это действительно работает очень хорошо. Итак, вы ознакомились с предварительным просмотром развертывания, все выглядит отлично, PR объединяется. Что происходит тогда?

Лесли: Итак, поскольку Netlify запускает все наши непрерывные развертывания, по сути, у нас все подключено, так что любое слияние с нашей основной веткой автоматически запускает официальное производственное развертывание с приложением. Итак, как правило, если вы являетесь разработчиком, который объединил свой собственный PR, вы попадете в фактическое… вы должны убедиться, дважды проверьте свои вкладки, потому что, если у вас открыт предварительный просмотр приложения и приложение, вы должны убедиться… вы обычно хотите следовать в реальном приложении. Итак, вы должны проверить свою вкладку. Но, да, в приложении, которое вы обычно заходите, вы можете просмотреть журналы сборки для того слияния, которое вы только что запустили, так что все происходит автоматически. И затем, как только эти журналы сборки будут завершены и сайт заработает, все, что вам нужно сделать, это обновить окно браузера, и вы увидите, что все, что вы только что развернули, должно быть обновлено в приложении.

Дрю: Допустим, вы поймали проблему, как только она появилась, что вы тогда делаете?

Лесли: Это очень хороший вопрос. И, возможно, одна из моих любимых вещей в использовании Netlify еще до того, как я работал в Netlify, это было для меня чем-то вроде волшебства, потому что Netlify как бы запекает то, что мы называем откатами. Таким образом, практически каждое развертывание на Netlify… поскольку мы используем эту архитектуру Jamstack, каждое развертывание является атомарным. Итак, это означает, что у вас есть полная история каждого развертывания, которое вы когда-либо делали на сайте, и вы можете мгновенно вернуться к любому из них. Итак, если мы случайно выявляем ошибку или что-то сломано, первое, что мы обычно делаем, — фактически останавливаем эту непрерывную интеграцию. Итак, мы войдем, и в пользовательском интерфейсе Netlify будет всего одна кнопка, на которую вы скажете «Остановить автоматическую публикацию», и что она сделает, так это остановит это соединение с GitHub. Так что, если мой товарищ по команде вдруг тоже сливает свой PR, мы не собираемся повторно вводить баг, ничего подобного не произойдет.

Лесли: Итак, мы останавливаем все эти автоматические развертывания. А затем все, что мне нужно сделать, это вернуться к моему списку развертываний и найти последний работающий развертывание, нажать еще одну кнопку с надписью «Опубликовать это», и оно будет запущено. Итак, что это делает, так это снимает это давление, чтобы иметь возможность действительно вернуться, посмотреть на код, понять, что на самом деле произошло. Иногда это означает выполнение Git revert на вашей основной ветке и возвращение основной ветки туда, где она должна быть. А иногда это оперативное исправление или вы уходите в ветку, и вы исправите ее, и вам даже не нужно беспокоиться о возврате в Git. А затем, когда вы будете готовы вернуться, вы убедитесь, что все работает в предварительном просмотре развертывания приложения, и вы можете просто сбросить все это обратно. Итак, как только вы запустите эти автоматические развертывания, вы, по сути, снова в деле.

Дрю: Итак, я заметил здесь проблему.

Лесли: Ой-ой.

Дрю: Вы используете Netlify для развертывания изменений в приложении Netlify. Что делать, если ошибка, которую вы развернули, мешает вам выполнить откат? Что вы делаете тогда?

Лесли: Мне снятся кошмары. Нет. На самом деле, у нас есть пара способов справиться с этим. Таким образом, если мы отключим приложение и не сможем использовать пользовательский интерфейс для выполнения этого процесса, наши предварительные версии развертывания фактически будут работать с нашим производственным API. Итак, это означает, что даже если приложение не работает, у нас все еще есть эти атомарные развертывания. Таким образом, если у вас есть ссылка с GitHub, возможно, из старого или недавнего PR, и у вас есть этот URL-адрес предварительного просмотра развертывания, вы действительно можете получить доступ к предварительному просмотру развертывания приложения и внести любые необходимые изменения, вернуться и опубликовать более раннее развертывание. из предварительного просмотра развертывания. И это все еще затрагивает наш производственный API, так что это по-прежнему влияет на приложение, а затем оно снова заработает. Это похоже на смайлик взрывающегося мозга, но это один из способов сделать это. Мы также могли бы опубликовать более раннее развертывание из некоторых наших серверных систем. Мы могли бы попросить наших бэкэнд-инженеров опубликовать это для нас. Или вы всегда можете использовать Git, чтобы вернуться и попытаться поднять это, но это немного пугает, потому что вы не можете смотреть, что делаете.

Дрю: Думаю, тебе просто нужен очень ясный ум, чтобы справиться с этой ситуацией.

Лесли: Ага.

Дрю: Но, похоже, это полностью поправимо.

Лесли: Ага. Что ж, и как только вы опубликуете свое рабочее развертывание, все давление исчезнет. Это действительно самая приятная часть. И я нашел это, работая в агентствах. Возможность отката была действительно спасением… Это также избавляет вас от беспокойства по поводу публикации новых изменений. Если вы что-то сломаете, вам понадобится секунда, чтобы откатить это назад, что очень хорошо сочетается с моделью быстрого перемещения и извлечения вещей.

Дрю: Определенно. Я думаю, что обычно такой рабочий процесс работает лучше всего, когда вы имеете дело с действительно небольшими изменениями. Я имею в виду, что в идеале вы хотите создать ветку, внедрить небольшое изменение, поднять PR, а затем как можно быстрее вернуть все обратно. Очевидно, что это хорошо работает для настроек, исправлений ошибок и мелких вещей, но не так хорошо работает для работы над основными функциями, когда эта функция может занять недели или, может быть, даже месяцы от ее запуска до ее готовности к развертыванию. Как вы управляете таким процессом?

Лесли: Да, это отличный вопрос. Итак, недавно мы стали немного больше использовать флаги функций. Прежде чем я расскажу немного больше о том, как мы это делаем, я расскажу о том, что мы делали раньше. Итак, до того, как мы использовали флаги функций, я думаю, что все были знакомы с идеей долговременной ветки функций. Мы все их ненавидим, верно? Но мы будем работать над нашими меньшими связями с общественностью. Мы бы объединили каждую из них по отдельности, после проверки кода, в эту более длинную ветку функций. Таким образом, у вас будет просто вся ваша новая функция в одном месте, у вас может быть один Deploy Preview, с помощью которого вы сможете протестировать эту новую функцию. Иногда эта модель требовала скоординированного развертывания другими командами. Итак, когда мы были готовы сказать: «Окей, эта функциональная ветка, мы готовы ее объединить и запустить», иногда это означало: «Хорошо, вы должны убедиться, что серверная часть уже внедрила свои изменения». Работа API, которую мы делаем в нашей функции, готова к работе. Если на нашем сайте документации есть документы, которые должны быть опубликованы одновременно с функцией, вам придется координировать действия и нажимать кнопки одновременно.

Лесли: Эта модель… она работала для нас, но вы правы, возможно, она была не самой гладкой. На самом деле это довольно забавно, наш соучредитель и генеральный директор Netlify Мэтт Бильманн фактически запустил нашу функцию аналитики, используя этот процесс, на сцене Jamstack Conf London в прошлом году. Итак, он использовал нашу функцию развертывания блокировки, чтобы фактически взять Предварительный просмотр развертывания новой функции аналитики и опубликовать его вживую на сцене. Итак, это было довольно круто.

Лесли: Но, как ты сказал, это… у тебя немного меньше уверенности. В этом запросе на слияние все еще как бы скрыто. Это становится немного громоздким. Кто-то должен одобрить этот окончательный запрос на слияние, который обычно довольно велик. Это немного ошеломляет. Итак, в настоящее время мы в основном используем флаги функций. Мы используем сервис под названием LaunchDarkly, который позволяет нам в основном обернуть наш новый пользовательский интерфейс с этими флагами, чтобы мы могли постоянно объединять код, даже если пользовательский интерфейс не является тем, что мы хотим, чтобы клиенты видели. Итак, вы просто убедитесь, что в производственной среде флаг вашей функции отключен, мы можем развернуть код, объединить его, и никто… если вы обычный пользователь, вы не увидите этот новый пользовательский интерфейс.

Дрю: Итак, флаг функции в основном похож на переключатель в коде, который говорит: «Если эта функция включена, используйте этот новый код, в противном случае используйте этот старый код».

Лесли: Точно.

Дрю: Значит ли это, что вы получаете беспорядочную кодовую базу со всеми этими форками? Как ты с этим справляешься?

Лесли: Да, я думаю, что… любой, кто использует флаги функций, вероятно, привык к такого рода битвам, когда вы очищаете флаги функций? Как долго вы оставляете их там? Мы как бы приземлились примерно через две недели после выпуска важной функции, у нас есть напоминания. К счастью, LaunchDarkly недавно настроил функцию, которая будет уведомлять Slack. Итак, вы можете подключить его к Slack, и он просто скажет вам: «Эй, ваш флаг функции был… Вы работали в прямом эфире в течение двух недель. Пришло время убедиться, что вы убрали свой флаг в коде».

Лесли: Итак, мы пытаемся и довольно быстро очищаем его, но в промежутке между ними приятно знать, что флаг все еще там. Даже если вы выпустили эту функцию, это означает, что снова одним щелчком мыши вы можете войти и снять этот флажок, если есть ошибка, если что-то всплывает. Итак, мы предпочитаем оставлять их ненадолго, пока функция действительно готовится, пока люди привыкают к ней, чтобы убедиться, что нет никаких серьезных проблем. Но затем мы пытаемся вернуться к коду, и это небольшая очистка, так что это не идеальный процесс, но обычно удаление флага не занимает много времени, вы просто удаляете пару строк кода.

Дрю: Итак, я думаю, что самый простой подход к реализации флага функции может быть просто… как переменная конфигурации в вашем приложении, которая говорит: «Эта функция включена или выключена», но тогда вам нужен какой-то способ убедиться, что это включено для правильных людей и выключено для правильных людей. И я предполагаю, что именно здесь вступает в действие такой сервис, как LaunchDarkly, потому что он принимает это… Я имею в виду, что в основном то, что включает и выключает переменную, доходит до экстремального уровня, не так ли?

Лесли: Да. да. Это точно. Таким образом, есть способы, которыми мы могли бы, даже без LaunchDarkly, самостоятельно настроить переменную конфигурации, которой мы как бы управляем с нашей стороны. Одна из вещей, которые мне нравятся в LaunchDarkly, это то, что есть разные среды. Итак, что мы можем сделать, так это, по сути, включить флаг функции для наших предварительных просмотров развертывания. Таким образом, любой, кто просматривает внутри Netlify предварительный просмотр приложения, может получить доступ к новой функции, может протестировать ее, но опять же, как только она будет запущена в производство, этот флаг снят. Итак, очень мало… опять же, вам нужно как бы проверить свою вкладку и убедиться, что вы знаете, в каком сегменте вы находитесь, потому что вы не хотите удивлять себя и думать, что запустили что-то, что вы не сделали, вы должны быть немного осторожны там. Но, в целом, это работает довольно хорошо, и LaunchDarkly также позволяет вам выполнять эти выборочные развертывания. Таким образом, вы можете развернуть функцию для определенного процента вашей кодовой базы или для определенного сегмента пользователей, людей с определенным типом плана или определенного типа пользователей. Таким образом, это позволяет вам гораздо больше контролировать, кому вы как бы выпускаете.

Дрю: Ага. Я думаю, это может быть действительно мощно, особенно с новыми функциями или функциями, которые, как вы, возможно, ожидаете решить проблему. Может быть, вы улучшаете функцию, чтобы сделать ее более понятной, вы можете попробовать ее с 10% пользователей и посмотреть, испытывают ли они те же проблемы и…

Лесли: Точно. Это также отличный способ получить обратную связь, да.

Дрю: Я полагаю, что использование LaunchDarkly таким образом, а не развертывание собственного решения, является своего рода еще одним аспектом подхода Jamstack, не так ли? Это просто использование API, который дает вам эту функциональность, не беспокоясь о том, как вы реализуете это самостоятельно, как это разработать, как поддерживать и сохранить это, чтобы вы могли просто отдать это на аутсорсинг, скажем: «Хорошо, мы будет использовать этот API, а обо всем остальном позаботятся».

Лесли: Ага. Да, точно.

Дрю: Таким образом, этот подход позволяет вам вводить в производство небольшие кусочки новых функций, но они просто скрыты за флагом. А затем, когда все будет готово к работе, вы можете просто перевернуть флажок и снова быстро переключить его, если что-то пойдет не так.

Лесли: Да, именно так. Это делает наши запуски немного менее захватывающими. Раньше вы нажимали эти большие кнопки, и весь этот код сливался, и вы смотрели свои журналы сборки, и это был момент предвкушения. И теперь вы прыгаете на вызов Zoom, нажимаете одну кнопку, и он в прямом эфире.

Дрю: Ага. Я думаю, что последний запуск функции, я работал над Netlify, мы использовали этот подход. И это были недели работы для целой команды людей, и мы позвонили в Zoom, чтобы скоординировать релиз, и все подтвердили, что их части готовы. А потом я перевернул флаг функции и включил ее для всех пользователей, и все.

Лесли: Готово.

Дрю: Все закончилось через несколько минут, и это было действительно разочаровывающе.

Лесли: Да, это немного грустно.

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

Лесли: Точно. И если вам нужно откатить его, опять же, это так просто, это один щелчок. Это снимает часть этого давления, беспокойства.

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

Лесли: Ага. Итак, это область, над которой мы сейчас активно работаем в командах Netlify, работаем над решением, которое позволило бы нам, возможно, связать все с одним флагом в LaunchDarkly, который используют все наши системы. , все наши кодовые базы используют. Таким образом, в идеальном мире мы могли бы перевернуть флаг и сказать: «Хорошо, это переключение на новую конечную точку API, которая также используется во внешнем интерфейсе с этим новым пользовательским интерфейсом, который заключен в флаг функции, а также эту часть сайта документации, которая содержит новую информацию об этой новой функции». И вы переворачиваете этот один флаг, который влияет на все эти репозитории. Мы еще не совсем там. Мы работаем над этим, но я рад видеть, сможем ли мы все это координировать и работать.

Дрю: Netlify как сервис очень хорошо приспособлен для создания сайтов таким образом. Влияла ли работа, которую вы и ваша команда выполняете с использованием продукта, на разработку продукта?

Лесли: Я бы сказал, что это определенно так. Все всегда говорят, что вы не ваш пользователь, и я думаю, что в большинстве случаев это так, за исключением случаев, когда вы являетесь своим пользователем. Что забавно в Netlify, потому что я думаю, что большинство людей в команде внешнего интерфейса, в частности, люди, которые раньше использовали Netlify как продукт. И, конечно же, поскольку мы используем Netlify для развертывания Netlify, мы сталкиваемся с теми же проблемами, что и некоторые из наших пользователей. Таким образом, в некотором смысле, если мы столкнемся с проблемой, мы постараемся донести ее до остальных сотрудников компании. Мы упомянем об этом во время телефонного разговора с инженером или вызовем нашего технического директора и скажем: «Эй, это то, с чем мы боремся. Есть ли что-то, что мы могли бы встроить в продукт, что облегчило бы это для нас и для всех наших пользователей, которые развертывают то же самое, что и мы?» Таким образом, это своего рода уникальная позиция, но интересно наблюдать за тем, как разрабатывается дорожная карта продукта.

Дрю: Думаю, мало кто использует Netlify так же интенсивно, как сама Netlify.

Лесли: Ага. Да. Я думаю, это правильно. Я смотрю на Netlify как при его создании, так и при его развертывании, так что я хорошо с ним знаком.

Дрю: А потом на выходных ты работаешь над побочным проектом и снова оказываешься в Netlify.

Лесли: Ага. Это на самом деле очень верно. Да. да. Да, в самом деле.

Дрю: Есть ли у вас примеры того, как работа, проделанная командой, повлияла на направление продукта?

Лесли: Ага. Итак, совсем недавно мы запустили новый вид целевой панели для приложения, которое мы называем Обзором команды. Итак, раньше, когда вы входили в Netlify, вы попадали на страницу сайта, которая в основном представляла собой длинный список ваших сайтов. И мы хотели дать людям немного больше области управления полетами, где они могли бы увидеть много важной информации с первого взгляда, получить доступ к вещам, которые будут для них наиболее полезными. Итак, это была новая функция, которую мы создали. В начальной итерации мы пытаемся сделать это быстро, у нас есть небольшая карточка в этом пользовательском интерфейсе, которая ссылается на ваши последние сборки. Он показывает вам любую сборку всей вашей команды, которая должна отображаться на этой карточке.

Лесли: И поначалу мы фактически не связывали их со сборкой… с самим журналом отображения. Итак, это был просто список, где вы могли проверить это. Вы можете нажать на страницу сборки, чтобы получить похожее представление. Но я на самом деле работал над чем-то на выходных, над личным сайтом, и у меня был включен этот обзор команды, и я был раздражен, потому что я понял, что я вошел в Netlify, и я хотел пойти проверить эту сборку, которая происходит в моем проекте, и я не мог просто щелкнуть по нему и сразу перейти к нему. Мне пришлось щелкнуть на странице сборки, а затем щелкнуть еще раз. Итак, на следующий день на работе я вошел, добавил это изменение и связал эти сборки, потому что это меня беспокоило. Итак, это был один из примеров того, как с помощью продукта просто поняли, что есть очень небольшая возможность его улучшить. И мы взяли это.

Лесли: Но у нас есть и другие примеры. Наверное, чуть более эффектно. Во-первых, мы как бы добавили эту функцию обнаружения формы. Итак, немного предыстории, если вы не знакомы, формы Netlify — это функция в Netlify, которая позволяет вам создавать форму внешнего интерфейса. И Netlify как бы выполняет всю внутреннюю работу по управлению представлениями. Это похоже на вашу базу данных для вашей формы, которую вы создали на своем интерфейсе. Это означает, что вам не нужно писать какой-либо код на стороне сервера или много дополнительного кода JavaScript для управления отправкой форм. На самом деле любой сайт, который вы развернули в Netlify, когда ваша сборка происходит, наши боты сборки анализируют HTML вашего сайта во время развертывания, чтобы в основном определить, есть ли у вас форма Netlify, на которую Netlify нужно обратить внимание и управлять. И это обнаружение формы, которое ищет бот сборки, включено по умолчанию.

Лесли: Но это означает, что, как вы понимаете, это отнимает у вас немного времени на сборку, потому что ботам приходится идти и искать этот дополнительный шаг. Итак, само приложение Netlify, на самом деле, мы не используем, у нас сейчас нет форм Netlify в приложении. Итак, это шаг, который немного увеличивает время сборки, но это не обязательно должно происходить. Таким образом, Netlify фактически создала новую функцию, которая позволяет любому пользователю отключить обнаружение этой формы. Это означает, что вы можете отключить этот параметр в настройках своего сайта, боты сборки понимают, что им не нужно ничего искать, поэтому вы экономите немного дополнительного времени обработки в сборках.

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

Лесли: Точно.

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

Лесли: Ага. Точно. Итак, это было то, что мы также слышали от некоторых наших пользователей и клиентов, и мы тоже это заметили. Это было так: «Ну, нам не нужен этот дополнительный шаг в нашем собственном продукте. Итак, есть ли способ, что-то, что мы могли бы дать всем нашим пользователям, чтобы сделать жизнь каждого немного проще, сделать сборку каждого немного быстрее, если они не используют эту функцию?»

Дрю: Есть опасность… Я имею в виду, вы говорите, что вы не ваш пользователь, но с Netlify вы часто являетесь своим пользователем. Есть ли опасность, что при интенсивном использовании продукта вы можете упустить из виду пользователей, которые используют его очень мало, и все может стать слишком сложным и слишком продвинутым, и станет очень трудно получить началось с?

Лесли: Это отличный вопрос. Мы также действительно создали нашу функцию исследования пользователей в Netlify и нашу функцию обработки данных, и я думаю, что в целом мы доверяем им гораздо больше, чем моему неподтвержденному опыту использования и развертывания приложения. Но я думаю, что все эти данные объединяются, чтобы позволить нам лучше понять, кто использует Netlify, с каким типом пользователя мы разговариваем? Есть люди с разными потребностями. У нас есть люди в наших стартовых командах, которые управляют блогами и личными сайтами, а также у нас есть огромные предприятия, которые запускают большие маркетинговые кампании и большие веб-приложения, мало чем отличающиеся от самой Netlify. Так что интересно наблюдать за ростом пользовательской базы, думать обо всех этих вариантах использования и выяснять, как мы можем удовлетворить всех этих пользователей. И, конечно же, используя больше наших исследовательских функций, чтобы опираться на понимание того, кто эти пользователи, а не только на наш внутренний опыт.

Дрю: Расскажи мне, Лесли, о сервисе скриншотов, который есть у Netlify? Потому что я нашел это действительно интересным.

Лесли: Ага. В пользовательском интерфейсе у нас есть… когда вы развертываете сайт на Netlify, в пользовательском интерфейсе у нас есть небольшой снимок экрана, который показывает вам, как обычно выглядит домашняя страница сайта, который вы чувствовали. На самом деле забавно, что мы подняли эту тему, потому что не так давно я слушал Криса Койера в его выпуске Serverless, и он говорил о том, как они делают скриншоты в CodePen, что на самом деле не так уж отличается от того, как это делает Netlify. Но в основном мы запускаем Puppeteer, чтобы сделать снимок экрана пользовательского сайта, и способ, которым все это работает, заключается в том, что он настроен с помощью функции Netlify. Итак, это снова пример того, как мы тестируем наш собственный продукт. Итак, по сути, мы используем эту конечную точку, которая является функцией Netlify внутри нашего собственного приложения, чтобы вернуть URL-адрес этого изображения снимка экрана, который затем мы можем использовать в приложении.

Дрю: Значит, функции Netlify — это реализация Netlify бессерверных функций, не так ли? Где вы в основном просто помещаете файл JavaScript в указанную папку как часть вашего источника, а затем он становится доступным для выполнения как облачная функция.

Лесли: Да, именно так.

Дрю: Очень умно, не так ли?

Лесли: Ага. Это великолепно. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Да.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?