Основы JAMstack: что, что и как

Нам нравится раздвигать границы в Интернете, поэтому мы решили попробовать что-то новое. Вы, наверное, слышали о JAMstack — новом веб-стеке, основанном на JavaScript, API и разметке, — но что это значит для вашего рабочего процесса и когда это имеет смысл в ваших проектах?

В рамках нашего членства в Smashing мы еженедельно проводим Smashing TV , серию вебинаров в прямом эфире. Ничего лишнего — только практические вебинары с действенными вопросами и ответами, которые проводят уважаемые специалисты отрасли. Действительно, расписание Smashing TV уже выглядит довольно плотным, и оно бесплатно для участников Smashing Members вместе с записями — очевидно .

Мы любезно попросили Фила Хоксворта провести вебинар, объясняющий, что на самом деле означает JAMStack и когда это имеет смысл, а также как это влияет на инструментарий и интерфейсную архитектуру. Также доступен часовой вебинар. Мы очень рады приветствовать Фила в качестве соведущего на предстоящей конференции SmashingConf в Торонто (25-26 июня) и на JAMStack_conf в Лондоне, которую мы также организуем 9-10 июля в этом году. Итак, приступим!

Фил Хоксворт: Отлично, хорошо, тогда давайте приступим к делу. Просто в качестве очень быстрого приветствия, я имею в виду, что я уже поздоровался, Скотт хорошо представил меня. Но да, сейчас я работаю в Netlify, работаю там в команде разработчиков. Мы надеемся, что у нас будет достаточно времени для вопросов и ответов, но, как упомянул Скотт, если у вас нет возможности задать вопросы там, или если вы просто предпочитаете, вы можете отправить их прямо мне в Твиттере, так что мой адрес Твиттера меня зовут Фил Хоксворт, так что в любое время вы можете задавать мне вопросы о JAMstack или вообще о чем угодно в Twitter.

Фил Хоксворт: Но сегодня я хочу начать с того, что немного вернусь в прошлое к этой цитате, которая очень, очень сильно находит во мне отклик. Это цитата замечательного Аарона Шварца, который, конечно же, так много сделал для Creative Commons и открытого Интернета, и он написал это в своем блоге еще в 2002 году, и он сказал: Установка сервера AOL, Postgres и Oracle». Сервер AOL, мне пришлось искать, чтобы напомнить себе, что в то время это был веб-сервер с открытым исходным кодом.

Фил Хоксворт: Но мне это очень близко. Я также не хочу поддерживать инфраструктуру, чтобы поддерживать жизнь блога, и это то, о чем он говорил. И это было в этом сообщении в его собственном блоге, и оно было озаглавлено «Выпекать, не жарить». Он выбрал термин, который начал использовать кто-то, кто недавно создал CMS, и он как бы популяризировал этот термин о выпечке (выпекать, не жарить); то, о чем он говорит, — это предварительный рендеринг, а не рендеринг по запросу, то есть запекание контента заранее, а не обжаривание его по запросу, когда люди приходят и просят об этом — переводя вещи из времени запроса в своего рода время сборки.

Фил Хоксворт: И когда мы говорим о предварительном рендеринге и рендеринге, мы имеем в виду создание разметки. Иногда я чувствую себя немного застенчивым, говоря о серверном рендеринге, изоморфном рендеринге или множестве подобных модных терминов; Несколько лет назад меня вызвали на конференцию Frontiers Conference в Амстердаме, когда я говорил о рендеринге на сервере, и кто-то сказал мне: «Вы имеете в виду генерацию HTML? Просто что-то, что выводит HTML?» И это, конечно, то, что я имею в виду.

Фил Хоксворт: Но все это в значительной степени способствует упрощению стека. Когда мы думаем о стеке, из которого мы обслуживаем веб-сайты; Я все пытаюсь упростить вещи, я очень заинтересован в том, чтобы упростить стек. И это как бы сердце этой штуки под названием «JAMstack», и я хочу попытаться немного объяснить это. «JAM» в JAMstack означает JavaScript, API и разметку. Но на самом деле этого недостаточно, чтобы помочь нам понять, что это значит — что же это на самом деле означает?

Фил Хоксворт: Ну, что я хочу попробовать и сделать в течение следующих получаса или около того, так это то, что я хочу расширить это определение и дать более подробное описание того, что такое JAMstack. Я хочу немного поговорить о влиянии и последствиях JAMstack, и, вы знаете, подумать о том, что это может нам дать, и почему мы можем его выбрать. Попутно я попытаюсь упомянуть некоторые инструменты и сервисы, которые будут вам полезны, и, надеюсь, в завершение я приведу некоторые ресурсы, с которыми вы, возможно, захотите покопаться, и, возможно, упомяну некоторые первые шаги, которые помогут вам в пути.

Фил Хоксворт: Итак, это план на следующие полчаса. Но я хочу как бы вернуться к этому понятию об упрощении стека, потому что, надеюсь, люди, которые присоединятся к этому или придут посмотреть это видео позже, может быть, у вас есть представление о том, что такое JAMstack, или может быть, это совершенно новый термин, и вам просто любопытно. Но, в конечном счете, уже есть много стеков. Существует множество способов доставки веб-сайта. Такое ощущение, что мы очень долго строили различные типы инфраструктуры, будь то стек LAMP или стек MAMP, или — я не знаю — стек MEAN. Здесь их куча, проплывающая по экрану. Их очень и очень много.

Фил Хоксворт: Так с какой стати нам нужен еще один? Что ж, JAMstack, как я уже упоминал, это JavaScript/API/Markup, но если мы попытаемся быть немного более описательным, JAMstack предназначен для современной архитектуры, помогающей создавать быстрые и безопасные сайты и динамические приложения с помощью JavaScript/ API и предварительно обработанная разметка, обслуживаемые без веб-серверов, и это последний пункт, который, в некотором роде, выделяет его и, возможно, делает его немного более, своего рода, интересным и необычным.

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

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

Фил Хоксворт: И эти серверы будут выполнять некоторую логику, чтобы сказать: «Хорошо, вот наш шаблон, нам нужно заполнить его некоторыми данными». Мы можем получить наши данные с одного из нескольких серверов баз данных, которые будут выполнять некоторую логику для поиска некоторых данных, возвращать их на веб-сервер, создавать представление, которое мы затем передаем обратно через балансировщик нагрузки. Возможно, попутно вызывая CDN, сохраняя некоторые активы в CDN, и я должен уточнить, что CDN — это сеть доставки контента, поэтому сеть машин, распределенных по Интернету, чтобы попытаться получить услугу запроса как можно ближе. пользователю и добавлять такие вещи, как кеширование.

Фил Хоксворт: Таким образом, мы могли бы спрятать там некоторые активы и, в конечном счете, вернуть представление в браузер, в глаза пользователю, который затем получит доступ к сайту, который мы создали. Так что, очевидно, это либо чрезмерное упрощение, либо очень общий взгляд на то, как мы можем обслуживать запрос в традиционном стеке. Если мы сравним это с JAMstack, который обслуживает вещи немного по-другому, это может выглядеть так.

Фил Хоксворт: Итак, снова тот же сценарий, мы начинаем в веб-браузере. Мы отправляем запрос на просмотр страницы, а эта страница уже находится в CDN. Оттуда он обслуживается статически, поэтому он возвращается пользователю в браузер, и все готово. Так что, очевидно, это очень упрощенный вид, но сразу же вы можете начать видеть различия здесь с точки зрения сложности. С точки зрения мест, которые нам нужны для управления кодом, глубокого кода, всех этих разных вещей. Итак, для меня одним из основных атрибутов JAMstack является то, что это означает, что вы создаете сайт, который можно обслуживать непосредственно из CDN или даже со статического файлового сервера. CDN — это то, что мы могли бы захотеть внедрить для обработки нагрузки, но, в конечном счете, это можно было бы обслуживать напрямую с любого типа статического файлового сервера, типа статической инфраструктуры хостинга.

Фил Хоксворт: JAMstack как бы дает возможность уменьшить сложность. Просто сравнив те две части диаграммы, к которым мы вернемся несколько раз в течение следующих получаса, вы увидите, что это возможность уменьшить сложность и снизить риск. Итак, это означает, что мы можем начать пользоваться некоторыми преимуществами обслуживания статических ресурсов, и я собираюсь поговорить о них чуть позже. Но вы можете посмотреть на это и подумать: «Ну, отлично, но разве это не просто новое название для статических веб-сайтов?» Это разумная вещь, чтобы выровнять меня, когда я говорю: «Мы собираемся обслуживать вещи статически».

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

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

Фил Хоксворт: Как вы помните, стек LAMP состоит из веб-сервера apache, предназначенного для выполнения таких задач, как маршрутизация HCP и обслуживание статических ресурсов. PHP для некоторой предварительной обработки, так что красивая обработка гипертекста; применяя логику, возможно, создавая представления для шаблонов и того, что у вас есть. И имеет некоторый доступ к вашим данным через мой NISQL, а затем LINUX — это операционная система, которая стоит за всем этим, поддерживает все это в дышащем состоянии. Мы можем концептуально объединить это в виде веб-сервера. И у нас может быть много таких серверов, вроде как сидящих вместе, чтобы обслуживать веб-сайт.

Фил Хоксворт: Это своего рода традиционный взгляд на стек LAMP, и если мы сравним его со стеком JAM, то здесь есть критическое изменение. Здесь мы фактически поднимаемся на более высокий уровень, вместо того чтобы думать об операционной системе и о том, как мы запускаем логику для доставки веб-сайта. Здесь мы делаем предположение, что будем обслуживать эти вещи статически. Итак, мы выполняем маршрутизацию ACP и обслуживание активов со статического сервера. Это можно разумно сделать. С годами мы очень хорошо научились в этом, создавая способы доставки статических веб-сайтов или статических ресурсов.

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

Фил Хоксворт: Когда дело доходит до доступа к данным, это происходит, возможно, через внешние API, вызовы через JavaScript к этим внешним API для получения доступа к серверу, или мы можем рассматривать API как API браузера, способные взаимодействовать с JavaScript. с возможностями прямо в вашем браузере.

Фил Хоксворт: В любом случае, ключ к JAMstack заключается в том, что мы говорим о вещах, которые предварительно визуализируются: они обслуживаются статически, а затем, возможно, постепенно улучшаются в браузере, чтобы использовать браузерные API, JavaScripts. , а что у вас.

Фил Хоксворт: Итак, давайте просто проведем небольшое сравнение. Опять же, я просто хочу повторить, что JAMstack перешел на уровень выше для браузера. И если мы посмотрим на две стороны этой диаграммы, со стеком LAMP слева и стеком JAM справа, вы даже можете подумать, что, ну, даже когда мы строили вещи со стеком LAMP, мы все еще вывод разметки. Мы все еще выводим JavaScript. Возможно, мы все еще имеем доступ к API. Таким образом, JAMstack во многом похож на подмножество того, что мы создавали раньше.

Фил Хоксворт: Раньше я иногда говорил о JAMstack как о гарантированном стеке, потому что он обеспечивает набор инструментов и технологий, необходимых для создания сайта. Но, в любом случае, это значительно упрощенный способ доставки сайта, который как бы избавляет от необходимости выполнять действия и выполнять логику на сервере во время запроса.

Фил Хоксворт: Итак, это может сделать многое. Это может как бы упростить развертывание, и снова я буду время от времени возвращаться к этой диаграмме. Если мы подумаем о том, как мы развертываем наш код и наш сайт, для каждого развертывания, с самого первого, на протяжении всего жизненного цикла разработки, на протяжении всей жизни веб-сайта. В традиционном стеке нам, возможно, придется изменить логику и содержимое для каждого блока на этой диаграмме.

Фил Хоксворт: Принимая во внимание, что в JAMstack, когда мы говорим о развертывании, мы говорим о доставке вещей в CDN, доставке вещей на статический сервер, и это то, что влечет за собой развертывание. Сборка, та логика, которая запускает сборку, может работать где угодно. Это не обязательно должно работать в той же среде, в которой размещен веб-сервер. На самом деле это не так! Он запускает ключ к JAMstack. Мы разделяем то, что происходит во время запроса, обслуживая эти статические активы, и то, что происходит во время сборки, что может быть вашей логикой, которую вы запускаете для сборки, а затем для развертывания.

Фил Хоксворт: Таким образом, такое разделение является ключевым моментом, и я собираюсь вернуться к этому позже. У нас очень хорошо получается обслуживать статические файлы, и передача данных в CDN или передача данных в файловую систему (файловый сервер) — это то, в чем мы видели огромный прогресс за последние несколько лет. В настоящее время существует множество инструментов и процессов, которые могут помочь нам сделать это действительно хорошо. Просто чтобы назвать несколько сервисов, которые могут хорошо обслуживать статические активы и предоставлять рабочие процессы для переноса вашей сборки в эту среду, они являются обычными подозреваемыми, которых вы можете представить себе крупными поставщиками облачной инфраструктуры, такими как Azure, AWS и Google Cloud.

Фил Хоксворт: Но есть и другие. Итак, верхний справа — это сервис под названием Surge, который существует уже несколько лет. Это позволяет вам запускать команду в вашей среде сборки и развертывать ваши активы в их среде хостинга. Netlify, следующий по счету, — это то место, где я работаю, и мы делаем одно и то же, но у нас также разная автоматизация. Я мог бы заняться этим в другой раз. И тот, что внизу, еще один сайт со статической средой хостинга, который называется Now.

Фил Хоксворт: Итак, существует множество различных вариантов для этого, и все эти пространства предоставляют различные инструменты для максимально быстрого доступа к CDN. Развертывание ваших сайтов самым простым способом, который мы можем. И у всех у них есть что-то общее в том, что они строятся на принципе запуска чего-то локально. Я часто думаю о генераторе статических сайтов как о чем-то, что мы можем запустить в сборке, и когда мы его запускаем, он берет такие вещи, как контент и шаблоны и, возможно, данные из разных сервисов, и выводит что-то, что можно обслуживать статически.

Фил Хоксворт: Мы можем просмотреть это локально на нашем статическом сервере. Что-то, что довольно просто сделать в любой локальной среде разработки, а затем процесс развертывания, который доставляет это в среду хостинга и, в идеале, в CDN, чтобы получить, своего рода, масштабирование. Итак, заложив такую ​​основу, я хочу развеять некоторые распространенные заблуждения, когда речь идет о сайтах JAMstack. И я не сделал себе никаких одолжений, открыв это, описывая сайты JAMstack как JavaScript, API и разметку. Потому что распространенное заблуждение состоит в том, что каждый сайт JAMstack должен состоять из JavaScript, API и разметки, но мы упустили из виду то, что нам не нужно использовать все три — каждый из них, своего рода, , необязательный. Мы можем использовать их столько, сколько захотим. Точно так же сайт стека LAMP не обязательно должен обращаться к базе данных. Итак, в прошлом я создавал вещи, которые обслуживаются сервером apache, на машине с Linux, и я использовал PHP, но я не обращался к базе данных и не стал бы переименовывать стек. обязательно для того.

Фил Хоксворт: Итак, если мы подумаем о том, что такое сайт JAMstack, то это может быть множество разных вещей. Это может быть что-то, созданное с помощью генератора статических сайтов, такого как Jekyll, извлекающего контент из файлов YAML для создания сайта без JavaScript, вообще не обращающегося к API, и мы обслуживаем его на чем-то, например, GitHub Pages. Или это будет сайт JAMstack. Или, может быть, мы используем генератор статических сайтов, такой как Gatsby, который находится скорее в среде Ruby для Jekyll, теперь это генератор статических сайтов JavaScript, встроенный в экосистему React.

Фил Хоксворт: Это может быть повторное извлечение контента и организация файлов Markdown. Это может быть обогащено вызовами API-интерфейсов GraphQL. Это может быть что-то в браузере, например, гидратация JavaScript для заполнения шаблонов прямо в браузере. И это может быть подано на Amazon S3. Это сайт JAMStack? Да, абсолютно!

Фил Хоксворт: Перейдем к другому генератору статических сайтов, Hugo, созданному с помощью Go! Опять же, мы можем организовывать контент в файлах Markdown, добавляя взаимодействия в браузере с помощью JavaScript. Может быть, не вызывать какие-либо внешние API и, возможно, размещать их в Google Cloud. Это JAMstack? Абсолютно! Видите ли, я строю тему здесь. Использование чего-то вроде Nuxt, еще одного генератора статических сайтов, который теперь встроен в экосистему View. Может быть, это подтягивание содержимого из разных соседних файлов? Опять же, мы можем использовать взаимодействие JavaScript в браузере, возможно, вызывая API для таких вещей, как электронная коммерция, обслуживая другой статический сайт. Другая инфраструктура хостинга, такая как Netlify, это JAMstack? Да это так!

Фил Хоксворт: Но мы могли бы даже перейти, знаете ли, и на этот край шкалы. И подумайте о прогрессивном веб-приложении ручной работы, которое мы создали вручную, вручную, на JavaScript, который мы создали сами. Мы упаковываем его с помощью webpack. Возможно, мы используем веб-токены JavaScript и обращаемся к API-интерфейсам для аутентификации, взаимодействуем с различными API-интерфейсами браузера и размещаем их в Azure. Да, это тоже JAMstack!

Фил Хоксворт: И, вы знаете, все эти и многие другие вещи можно считать JAMstack, потому что все они имеют один общий атрибут, и ни один из них не обслуживается исходным сервером. Ни один из них не должен обращаться к серверу, который выполняет логику во время запроса. Они обслуживаются как статические активы, а затем дополняются JavaScript и вызовами API.

Фил Хоксворт: Итак, еще раз, я просто хочу повторить, что JAMstack означает, что его можно обслуживать непосредственно из CDN. Итак, я хочу просто назвать некоторые последствия и последствия этого, потому что зачем нам это делать? Что ж, первое понятие связано с безопасностью, и здесь у нас значительно уменьшена площадь поверхности для атаки. Если мы подумаем (снова вернемся к этой старой диаграмме), где нам, возможно, придется иметь дело с атакой, мы должны защитить такие вещи, как балансировщик нагрузки, веб-серверы, серверы баз данных. Все эти вещи, мы должны убедиться, что они не могут быть взломаны какой-либо атакой и, конечно же, CDN.

Фил Хоксворт: Чем больше кусочков мы сможем извлечь из этой головоломки, тем меньше мест можно будет атаковать и тем меньше мест нам придется защищать. Наличие нескольких движущихся частей для атаки действительно очень ценно. В Netlify мы управляем своими собственными CDN, поэтому мы можем позволить себе роскошь отслеживать трафик, который проходит через них, и хотя все сайты, размещенные на Netlify, все сайты JAMstack, которые вы можете себе представить, ни один из них иметь на них страницу администратора WordPress, потому что она полностью отделена. Там нет администратора WordPress, но мы видим огромный объем трафика, ищем такие вещи, как WP Admin, ищем пути, ищем векторы атак.

Фил Хоксворт: Мне очень нравятся некоторые вещи, которые сделал Кент С. Доддс. Я не знаю, знакомы ли вы с сообществом React, вы, вероятно, уже сталкивались с Кентом С. Доддсом в прошлом. Он не использует WordPress, но по-прежнему направляет этот URL-адрес WPAdmin. Я думаю, что он использовал это для видео Rick Roll на YouTube. Он определенно троллил людей, которые искали его. Но дело в том, что таким образом отделяя вещи и, как бы, перемещая происходящие события, выстраивая время из того, что происходит во время запроса, мы можем просто резко уменьшить наше воздействие. У нас нет движущихся частей во время запроса. Все движущиеся части полностью разъединены во время сборки. Потенциально на совсем, ну обязательно на совсем другой инфраструктуре.

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

Фил Хоксворт: Это что-то вроде шага к псевдостатичности. Точно так же в серверах баз данных мы хотим добавить уровни кэширования в запросы cache-com. Даже при низком балансе весь CDN можно рассматривать как кеш. Но в традиционном стеке нам нужно выяснить, как управлять этим кешем, потому что не все будет кэшировано. Итак, есть какая-то логика. Что нужно динамически заполнять, а что можно кэшировать. А в модели JAMstack все кешируется. Все кэшируется с момента выполнения развертывания, поэтому мы можем думать об этом совершенно по-другому.

Фил Хоксворт: Это тоже намекает на масштабирование. А по масштабу, я говорю о том, как мы справляемся с большими нагрузками трафика? Традиционные стеки начнут добавлять инфраструктуру для масштабирования. Так что да, кешировать. Мы начинаем внедрять наш традиционный стек. Это поможет — в какой-то степени. Что обычно происходит, чтобы справиться с большими нагрузками трафика, мы начинаем расширять инфраструктуру и начинаем добавлять больше серверов, больше частей для обработки этих запросов, затраты на эти вещи и оценка нагрузки — это большие накладные расходы, и это может быть головной болью для тех, кто занимается технической архитектурой. Это, безусловно, было для меня, поэтому я начал гораздо больше склоняться к подходу JAMstack, когда я просто знаю, что все обслуживается из CDN, который по умолчанию предназначен для управления масштабом, для управления производительностью прямо из ворот. .

Фил Хоксворт: Итак, я также хочу отметить опыт разработчиков и его влияние. Теперь опыт разработчиков никогда не должен рассматриваться как нечто, превосходящее опыт пользователей, но я считаю, что хороший опыт разработчиков может уменьшить трения, может позволить разработчикам гораздо лучше работать над созданием отличного пользовательского опыта!

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

Фил Хоксворт: Это действительно четко определенная проблемная область, потому что в конечном итоге вы пытаетесь создать что-то, что можно обслуживать непосредственно из CDN. Вы хотите что-то предварительно отрендерить, используя любые инструменты, которые вам нравятся: будь то генератор статических сайтов, встроенный в Ruby, Python, JavaScript, Go или PHP, у вас есть свобода выбора. Таким образом, это может создать для вас гораздо более приятную среду для работы. А также это дает возможность обрести реальную уверенность разработчика, потому что реальным атрибутом сайтов JAMstack является то, что их гораздо проще обслуживать как неизменяемое и атомарное развертывание.

Фил Хоксворт: И я хочу ненадолго отвлечься от слайдов, чтобы описать, что это значит, потому что неизменяемое развертывание и атомарное развертывание могут… (это может звучать немного похоже на маркетинговую речь), но что я собираюсь сделать, так это зайти в свой браузер. Теперь… вообще-то, я собираюсь вернуться на секунду. Позволь мне… просто сделать это.

Фил Хоксворт: Вот и мы. Это будет проще. Прыжок прямо на страницу. Теперь, Скотт, ты скажешь мне, Скотт, если ты не видишь мой браузер, я надеюсь. Теперь предположим, что все могут видеть мой браузер.

Скотт: Все выглядит хорошо.

Фил Хоксворт: Отлично! Большое спасибо!

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

Фил Хоксворт: Здесь я смотрю на развертывание, которое произошло на моем собственном веб-сайте. Я дам вам удовольствие. Вот как это выглядит. Это просто блог, он не выглядит чем-то особенно примечательным или захватывающим. Это статически сгенерированный блог, но у меня есть здесь каждое развертывание, которое когда-либо происходило, живет вечно, потому что это набор статических ресурсов, которые обслуживаются из CDN. Теперь я мог бы вернуться настолько далеко назад, насколько позволяет моя история, и пойти и посмотреть на это место, каким оно было… когда это было? Это был август 2016 года. И благодаря тому, что это набор статических ресурсов, мы можем разместить это на своем собственном URL-адресе, который будет жить вечно, и если бы я даже захотел, я мог бы решить войти и опубликовать это. развертывание.

Фил Хоксворт: Итак, теперь любой, кто просматривает мой веб-сайт, если я вернусь на свой веб-сайт здесь, если я обновлю эту страницу, теперь она будет обслуживаться непосредственно из CDN с активами, которые были там раньше. Теперь я снова могу ориентироваться. Вот, видите. Послушайте, я говорил об этом, я использовал эти ужасные термины, такие как изоморфный рендеринг, и говорил о JAMstack еще в 2016 году. Итак, теперь это то, что обслуживается в прямом эфире на моем сайте. Опять же, потому что есть взаимные развертывания, которые просто живут вечно. Я собираюсь просто положить свое, вроде, душевное спокойствие, я собираюсь — это первая страница? Да. Я собираюсь вернуться к моему последнему развертыванию. Мне придется снова закрыться и вернуться в реальный мир. Дай мне просто убедиться, что все в порядке.

Фил Хоксворт: Хорошо! Здорово! Итак, теперь я возвращаюсь к обслуживанию моей предыдущей версии или моей последней версии сайта. Я вернусь к основному докладу. Итак, это возможно, потому что вещи неизменны и атомарны. Атомарная часть этого означает, опять же, что развертывание полностью локализовано. Таким образом, вы никогда не дойдете до того момента, когда некоторые ресурсы будут доступны на веб-сервере, а некоторые — нет. Только когда все в контексте и все готово, мы переключаем обслуживание сайта на новую версию. Опять же, это то, что вы можете сделать намного проще, если вы создаете что-то в виде сайта JAMstack, который работает непосредственно с CDN в качестве набора ресурсов.

Фил Хоксворт: Я заметил, что мой таймер сбрасывается после перехода назад и вперед от основного доклада, поэтому я думаю, что у меня осталось около шести или семи минут. Скажи мне, Скотт, если…

Скотт: Итак, да, минут десять мы еще в порядке.

Фил Хоксворт: Десять минут? Хорошо, замечательно!

Скотт: Не торопись.

Фил Хоксворт: Спасибо, должно быть хорошо!

Фил Хоксворт: Итак, если немного переключиться и поговорить об API и сервисах (поскольку API — это часть JAMstack), сервисы, которые мы тогда сможем использовать, — это в основном JAMstack. Вы знаете, мы можем использовать сервисы, которые мы создали сами, или мы можем использовать купленные сервисы. Есть много разных поставщиков, которые могут что-то сделать для нас, и это потому, что это их опыт. С помощью API мы можем извлекать контент из систем управления контентом как услугу, и для этого есть множество различных поставщиков, которые специализируются на предоставлении отличного опыта управления контентом, а затем раскрывают контент через API, так что вы привыкли способен их втянуть.

Фил Хоксворт: Точно так же существуют разные способы обслуживания активов. Такие люди, как Cloudary, отлично справляются с этой задачей, выполняя оптимизацию изображений, размещая активы непосредственно на ваших сайтах, опять же, через API. Или как насчет электронной коммерции? Вы знаете, есть такие места, как Stripe или Snipcart, которые могут предоставить нам API, так что нам не нужно самим создавать эти сервисы и вникать в очень сложные проблемы, возникающие при попытке создать механизм электронной коммерции. Точно так же идентификация от таких людей, как Auth0, которые используют Oauth. Доступно множество сервисов, и мы можем использовать их через API, либо в браузере, либо во время сборки, а иногда и то и другое вместе.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Всем привет. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Верно? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Фил Хоксворт: Мне очень нравится, потому что термин JAMstack может вводить в заблуждение, потому что он пытается охватить так много разных вещей, и суть, которую я пытался, я, наверное, много раз забивал на этом слайде, заключается в том, что он может быть любым. вещей. Это так широко, но ключ заключается в предварительном рендеринге и статическом размещении ядра сайтов. Нам очень легко ввязаться в религиозные войны по поводу того, где должен быть сайт React. Это должно быть приложение React, чтобы быть сайтом JAMstack, или это приложение React, поэтому оно не может быть JAMstack. Но, на самом деле, суть в том, используете ли вы JavaScript или нет, вызываете ли вы API или нет, выполняете ли вы предварительный рендеринг и загружаете вещи на статический хост, который может быть очень производительным, — это ядро ​​JAMstack.

Виталий: Да, абсолютно.

Фил Хоксворт: Нам очень повезло, что браузеры становятся намного более функциональными, и API, которые есть в самих браузерах, также могут позволить нам делать гораздо больше. Таким образом, это еще больше открывает двери, но это не означает, что все, что мы создаем как сайт JAMstack, должно использовать все. В зависимости от того, что мы пытаемся предоставить, именно так мы должны начать выбирать инструменты, с которыми мы играем, чтобы развертывать эти вещи.

Виталий: Абсолютно. У нас здесь Доран. Доран, кажется, я знаю, Доран. У меня такое чувство, что я знаю Дорана. Он спрашивает: «Вы ожидаете, что безсерверные технологии будут стремиться к полной интеграции с JAMstack с [неразборчиво 00:44:36]? То, что упоминается как A в JAM.

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

Фил Хоксворт: Суть в том, что да, мы создаем вещи без серверов. Мы не хотим управлять этими серверами, и бессерверные функции или функции как услуга идеально подходят для этого. Таким образом, в тех случаях, когда вам нужен API, к которому вы хотите сделать запрос, вам действительно нецелесообразно делать этот запрос непосредственно из браузера. Так, например, если у вас есть секреты или ключи в этом запросе, вы можете не захотеть, чтобы эти запросы — эта информация — когда-либо раскрывались в клиенте. Но мы, безусловно, можем проксировать эти вещи, и, как правило, традиционно, то, что нам нужно сделать, это раскрутить сервер, иметь некоторую инфраструктуру, которая фактически делала немного больше, чем обработка запросов, добавление к ней аутентификации безопасности и передача этих запросов на , проксируя их обратно.

Фил Хоксворт: Бессерверные функции идеально подходят для этого. Они абсолютно идеальны для этого. Итак, я иногда думаю о бессерверных функциях или функциях службы почти как об аварийном люке, где вам просто нужна некоторая логика на сервере, но вы не хотите создавать всю инфраструктуру. И вы можете делать с этим все больше и больше, и формировать конвейеры разработки, рабочие процессы разработки, функции как услуга. Разработчикам JavaScript становится все доступнее создавать такие вещи. Так что, да, я действительно думаю, что эти две вещи очень хорошо сочетаются друг с другом.

Виталий: Хорошо, это очень исчерпывающий ответ. На самом деле, я совсем недавно присутствовал на выступлении, где фронтенд-инженер из Amazon рассказывал о бессерверных функциях и функциях Lamda, которые они используют, — меня почти не было. Он всегда говорил о Docker, и Kubernetes, и обо всем этом, Devox World, я сидел и думал: «Как он там оказался. Я не понимаю, что происходит!» Я понятия не имел, что происходит.

Фил Хоксворт: Точно, но дело в том, что раньше это было… я был… я признал, что ничего не понимаю в этом мире, но у меня не было никакого желания, так как это была совсем другая дисциплина. . И эта дисциплина по-прежнему очень важна. Вы знаете, люди, которые проектируют инфраструктуру — это по-прежнему очень важно. Но сейчас мне просто кажется, что я искушаюсь. Как человек с опытом разработки интерфейса, как разработчик JavaScript, я гораздо больше склоняюсь к тому, чтобы захотеть поиграть в этом мире, потому что инструменты становятся как бы ближе ко мне.

Фил Хоксворт: Гораздо более вероятно, что я смогу использовать некоторые из этих вещей и доставлять их безопасно, а не просто в качестве собственного эксперимента, в котором я раньше колебался. Итак, мне кажется, что мы становимся более влиятельными как веб-разработчики, что меня очень радует.

Виталий: Типа Могучих Рейнджеров, да?

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

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

Фил Хоксворт: Я думаю, что это, вероятно, Святой Грааль для генераторов статических сайтов и такого рода моделей, потому что, безусловно, вы определили, вероятно, самое большое препятствие, которое необходимо преодолеть. Или самый большой потолок, в который вы врезаетесь. И это веб-сайты, которые имеют много, десятки тысяч, сотни тысяч или миллионы URL-адресов — представление о том, что сборка может стать очень длинной. Возможность определить, какие URL-адреса изменятся на основе изменения кода, является сложной задачей. Это не непреодолимо, но это большая проблема. Понять, что представляет собой граф зависимостей на всем вашем сайте, а затем разумно развернуть его — это действительно сложно.

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

Фил Хоксворт: Но для меня это не идеально. Это не совсем идеальный сценарий. Один из подходов, который я немного изучил, просто в качестве доказательства концепции, заключается в том, чтобы подумать о том, как вы делаете вещи, например, разумно используете 404. Так, например, большой вариант использования очень больших вывесок, возможно, новостных сайтов, заключается в том, что когда им нужен URL-адрес, когда происходит экстренная новость, они должны быть первыми, чтобы развернуть его там. Им нужно получить URL там. Такие вещи, как BBC News, вы увидите, что новость появится на веб-сайте, а затем сверхурочно они будут добавлять к ней постепенно, но важно попасть туда первым. Таким образом, сборка, которая занимает 10 минут, 20 минут, что бы это ни было, может быть проблемой.

Фил Хоксворт: Но, если их содержимое абстрагировано и, возможно, использовалось для вызова из API. Я упомянул абстрактные системы управления контентом, такие как Contentful, Sanity и многие другие. Все, что имеет API контента, изменяется в этой структуре контента, что запускает сборку, и мы выполним запуск, но другая вещь, которая может случиться, это то, что, ну, если вы опубликуете свой URL-адрес для этого, а затем опубликуете этот URL-адрес , даже если сборка не запустилась, если кто-то перехватит этот URL-адрес, если первая остановка на его 404 вместо того, чтобы сказать «У нас его нет», на самом деле напрямую обратиться к этому API, тогда вы можете сказать , «Ну, сборка еще не закончила заполнять это, но я могу сделать это в клиенте». Я могу перейти непосредственно к API, получить его, заполнить в клиенте.

Виталий: Хм, интересно.

Фил Хоксворт: Так что, даже пока идет сборка, вы можете начать заполнять эти вещи. И затем, как только сборка будет завершена, конечно, она не попадет в 404. Вы попадете на эту статически работающую страницу. Итак, есть методы и стратегии для решения этой проблемы, но, тем не менее, это очень длинный и бессвязный ответ, извините, но мой вывод таков: да, это вызов. Скрестим пальцы, мы получим лучшие стратегии.

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

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

Фил Хоксворт: Итак, на данный момент этот ландшафт немного взрослеет. Я имею в виду, некоторые из этих примеров, я думаю, что я в очень удачном положении, я работаю где-то, что я в роли, которую я играю с игрушками, придумываю интересные способы их использования и начинаю экспериментировать. с ними. Итак, эти доказательства концепций — это своего рода вещи, с которыми я экспериментирую и пытаюсь решить эти проблемы. Но, как я упоминал ранее, тематическое исследование, которое было показано на конференции JAMstack в Нью-Йорке, и, конечно же, подобные мероприятия, мы начинаем видеть лучшие практики или отраслевые практики и отраслевые подходы, о которых говорят на подобных мероприятиях. событий. И, конечно же, я хочу видеть больше и работать над большим количеством тематических исследований, чтобы попасть в такие места, как Smashing Magazines, чтобы мы могли с большей готовностью делиться этой информацией.

Фил Хоксворт: Я думаю, что крупные компании и корпоративное пространство постепенно внедряют JAMstack, в разных местах, разными способами, но мир все еще склоняется к этому, поэтому я думаю, что каждый раз, когда компания принимает его и делится своими опыт, мы все извлекаем уроки из этого. Но я действительно хочу, чтобы все больше и больше таких тематических исследований публиковалось, чтобы мы могли опираться, в частности, на то, как преодолеваются подобные проблемы.

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

Фил Хоксворт: Какой вопрос. Я имею в виду, если бы мы не говорили об инкрементных сборках, это было бы...

Виталий: Да. Теперь уже слишком поздно. Эта карта уже прошла. Нам нужно что-то еще.

Фил Хоксворт: Итак…

Виталий: Я имею в виду, как на платформе, если вы посмотрите на заднюю платформу, там происходит так много всего интересного. У нас есть Houdini, у нас есть веб-компоненты и все такое, поскольку вы можете изменить весь ландшафт всех нужных компонентов. С другой стороны, у нас есть весь этот волшебный, причудливый мир с SS NGS, и, конечно, очевидно, у нас также есть одностраничные приложения и все такое. Что вас больше всего волнует?

Фил Хоксворт: Я собираюсь быть тупым, потому что происходит так много всего, это интересно, и есть так много новых возможностей, которые вы можете использовать в браузере. То, что меня действительно волнует, это люди, демонстрирующие сдержанность (смеется) и, как я уже сказал, скучный ответ, но я люблю видеть отличные исполнения, которые делаются сдержанно, вдумчиво — о широкой аудитории. Это действительно весело и приятно строить с помощью самой блестящей новой библиотеки JavaScript или нового API браузера, который делает, я не знаю, возможности скретчинга и обнюхивания в браузере, в которых мы отчаянно нуждаемся, в любой день.

Фил Хоксворт: Но мне действительно нравится видеть вещи, которые, как я знаю, будут работать во многих, многих местах. Они будут действительно производительными, будут сочувствовать существующим браузерам — не только на столах генеральных директоров и технических директоров, которые получили шикарные игрушки, но и у людей, у которых есть устройства с гораздо меньшим энергопотреблением, или они У меня сложные сетевые условия и тому подобное. Мне нравится видеть интересный опыт и богатый опыт, представленный таким образом, который вызывает симпатию к платформе и своего рода сострадание к более широкой аудитории, потому что я думаю, что Интернет простирается намного дальше, чем мы, разработчики, которые создают вещи для него. . И меня вдохновляет то, что я вижу интересные вещи, сделанные способами, которые охватывают больше людей.

Фил Хоксворт: Вероятно, это не тот ответ, который вы обязательно должны были получить—

Виталий: О, хороший конец. Большое спасибо. Нет, это идеально, это действительно так. Хорошо, я чувствовал, что все прошло хорошо! Большое спасибо за то, что вы с нами! Я раздаю Скотту!

Фил Хоксворт: Отлично!

Виталий: Я здесь только для того, чтобы играть в вопросы и ответы. Так что большое спасибо, Фил! Я все еще здесь, но Скотт, теперь сцена твоя! Может быть, вы можете поделиться с нами тем, что будет дальше на Smashing TV?

Скотт: Да, но сначала, Фил, я не могу дождаться, чтобы увидеть, как работает реализация API-интерфейса. Звучит очень интересно. И, Виталий, JAMstackify уже занят.

Виталий: (подавленно) Сняли?! Можем ли мы купить его?

Скотт: Нет, он существует!

Виталий: Ну, уже поздно. Я всегда опаздываю.

Фил Хоксворт: Это по-своему захватывающе.

Виталий: Это история моей жизни. Я всегда опаздываю.

Скотт: Следующие участники, я думаю, в четверг, 13-го, у нас есть мой старый папа, Зак Лезерман, говорящий о том, о чем он говорит лучше всего, а именно о шрифтах. Итак, он говорит о пяти Y реализации шрифтов. И потом, я также очень заинтересован в том, что у нас будет 19-го числа, это редактирование видео с помощью JavaScript и CSS с Евой Фариа. Итак, следите за обновлениями для обоих из них.

Скотт: Итак, это снова в следующий четверг с Заком Лезерманом, а затем 19-го числа с Евой, которая будет говорить о редактировании видео в JavaScript и CSS. Итак, на этой ноте, Фил, я больше не могу тебя видеть, ты все еще здесь?

Фил Хоксворт: Я здесь!

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

Виталий: Большое спасибо всем остальным!

Виталий: Да, кстати, еще одно! Возможно, Фил упомянул об этом, но у нас также есть конференция JAMstack в Лондоне в июле. Так что на это тоже стоит обратить внимание. Но я подписываюсь и иду за своим салатом! Не уверен, что ты…

Скотт: Хорошо, всем до свидания!

Виталий: Ладно, всем пока.

Это упаковка!

Мы от всего сердца благодарим участников Smashing Members за их постоянную и любезную поддержку — и нам не терпится провести больше вебинаров в будущем.

Кроме того, Фил будет ведущим на SmashingConf Toronto 2019 на следующей неделе и на JAMstack_conf — мы тоже будем рады видеть вас там!

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