@fastly/compute-js-static-publish — это инструмент для статической публикации на Fastly Compute. У вас есть папка со статическими файлами? Укажите на нее инструменту, и вы получите сервис Compute, который обслуживает их прямо с периферии, без необходимости использования исходного сервера.
Еще в 2022 году я писал о ранних версиях этого инструмента, когда он был на версии 2.0.0. Что ж, с тех пор многое изменилось! Теперь у нас версия 8, и самое главное изменение находится «под капотом»: вашим файлам больше не нужно находиться внутри вашего приложения. Давайте посмотрим, что нового, особенно если вы давно не следили за обновлениями.
Начало работы
Допустим, у вас есть файлы веб-сайта в каталоге с именем public. Введите следующую команду для создания шаблона приложения Compute (вам потребуется Node.js 20.11 or newer installed):
Это создает приложение Compute в каталоге с именем compute-js. Прежде чем делать что-то еще, вы можете протестировать его на локальном сервере разработки Fastly. Вам понадобится интерфейс командной строки Fastly (CLI), но учетная запись или сервис Fastly пока не требуются:
Перейдите по адресу http://127.0.0.1:7676, и вот ваш сайт, обслуживаемый из симулированного хранилища KV Store.
Вам нравится, как это выглядит? Чтобы запуститься в продакшн, вам понадобится учетная запись Fastly, а ваш API-токен Fastly должен быть установлен в переменной окружения FASTLY_API_TOKEN. Выполните следующие команды:
Первая команда развертывает приложение и создает KV Store, а вторая загружает ваши файлы. Вот и все! Теперь у вас есть веб-сайт, работающий на периферии, и вы не написали ни единой строки кода.
Куда делись все статические файлы?
Если вы читали публикацию за 2022 год, то можете помнить ответ на этот вопрос: все компилировалось в единый бинарный файл Wasm, который развертывался в Fastly. Это просто, но это означало, что весь ваш сайт должен был помещаться в ограничения по размеру пакета, а каждое изменение контента требовало новой сборки и развертывания. Версия 4 добавила другой вариант: хранение файлов в KV Store от Fastly и чтение их во время запроса. Некоторое время вы могли выбирать любой подход. Затем в версии 7 мы полностью отказались от встроенного варианта Wasm, поэтому теперь все работает через KV Store.
Вот что это вам дает. Файлы хранятся под ключом на основе хэша их содержимого, поэтому идентичные файлы сохраняются только один раз, даже в разных публикациях. Файлы размером более 20 МБ невидимо разбиваются на части и собираются обратно при чтении. И поскольку ваш контент не зашит внутрь приложения, лимит пакета в 50 МБ (позже увеличенный до 100 МБ), о котором я предупреждал в первой статье, больше не ограничивает размер вашего сайта, а публикация нового контента не требует развертывания нового бинарного файла Wasm. Вам нужно переразвертывать приложение только при изменении кода или конфигурации вашего приложения.
Версия 8 добавляет еще одно место, где могут храниться ваши файлы: Fastly Object Storage (или любое хранилище, совместимое с S3). Поскольку оно совместимо с S3, вы можете использовать собственное хранилище, и ваши файлы остаются целиком, а не разбиваются так, как KV Store разбивает файлы размером более 20 МБ. Затраты на хранение также обычно ниже при использовании Fastly Object Storage (актуальные тарифы смотрите на странице цен). Эта функция находится в стадии бета-тестирования, а KV Store по-прежнему является стандартным вариантом, поэтому вам ничего не нужно менять. Если вы хотите попробовать Object Storage, в репозитории проекта на GitHub есть подробная информация о настройке ваших учетных данных.
Коллекции: Публикация, Предпросмотр, Продвижение
Вот где разделение контента и приложения действительно приносит пользу: у вас может быть опубликовано более одной версии вашего сайта одновременно. Мы называем каждую версию коллекцией, которая представляет собой именованный набор файлов вместе с соответствующими настройками сервера. У вас могут быть живая версия (live), версия для тестирования (staging) и предварительный просмотр (preview-123), существующие бок о бок.
Допустим, вы хотите опубликовать тестовую версию, которая автоматически удалится через неделю:
И как только вам понравится результат, сделайте ее основной (live):
Срок действия истекших коллекций заканчивается, и они перестают обслуживаться, а команда clean удаляет все файлы, которые больше не используются ни одной из коллекций. Чтобы просмотреть коллекцию, ваше приложение выбирает активную коллекцию для каждого запроса, а инструмент поставляется со вспомогательными функциями для этого на основе имени хоста (например, preview-pr-123.example.com), файлов cookie, заголовка, пути URL или значения в Fastly Config Store. Представьте, что у каждого пулл-реквеста есть собственный URL предварительного просмотра!
Быстрее и эффективнее
Сжатие происходит при публикации, а не во время визита пользователя. По умолчанию текстовые файлы хранятся в вариантах Brotli и gzip наряду с оригиналом, и сервер выбирает наименьший вариант, который поддерживает браузер посетителя. Сервер также обрабатывает условные запросы, отвечая статусом 304 Not Modified, если у посетителя уже есть последняя копия.
Версия 8 также делает саму публикацию намного быстрее. Инструмент теперь значительно сокращает время, необходимое для проверки того, что уже находится в хранилище, пропускает неизмененные файлы, сканирует и сжимает файлы параллельно, а также загружает их в хранилище (KV Store или Object Storage) пакетами. Если вы предпочитаете немного увеличить файлы ради более быстрого сжатия, вы можете уменьшить качество Brotli в своей конфигурации публикации.
Появился также новый опциональный кэш ответов для работающего приложения. Включите его с помощью setResponseCache(), и целые ответы будут кэшироваться с помощью Core Cache API от Compute, поэтому повторные запросы полностью пропускают чтение из хранилища. Это также означает, что как только ответ закэширован, любая разница в задержке между бэкендами хранения влияет только на первый запрос. Ответы размером более 8 МБ по умолчанию обслуживаются напрямую из хранилища, хотя вы можете увеличить этот лимит с помощью maxBodySize. Публикация нового контента автоматически очищает кэш для этой коллекции. И если вам интересно, куда уходит время, setServerTimingRequestHeader() добавляет заголовок Server-Timing к запросам, которые запрашивают его, включая информацию о том, было ли попадание в кэш (cache hit) или промах (miss). Обе функции по умолчанию отключены.
А теперь — JavaScript-часть
До сих пор все, что я описывал, работает «из коробки», вообще без написания кода, и вы можете подумать, что инструмент можно было бы назвать просто Compute Static Publish. Но помните, он называется Compute JS Static Publish. Дело в том, что создаваемый проект представляет собой обычное приложение Fastly Compute, написанное на JavaScript, и именно здесь этот инструмент становится по-настоящему интересным. Если все, что вам нужно, — это обслуживать статические файлы, вам никогда не придется прикасаться к коду. Но когда вы захотите что-то добавить — это ваш код, так что дерзайте.
В центре созданного приложения находится класс PublisherServer, который сопоставляет входящие запросы с вашими опубликованными файлами и заботится об индексных файлах, страницах 404, резервных маршрутах для одностраничных приложений (SPA), сжатии и заголовках кэширования. Если вы помните обращение к объекту assets для получения содержимого файла в старые времена с этой библиотекой, то этого больше нет; PublisherServer — это то, как вы теперь работаете со своим контентом.
Когда PublisherServer не может обработать запрос, он возвращает null, что позволяет вам обернуть его собственной логикой. Например, вот статический сайт, у которого также есть небольшой эндпоинт API:
Отсюда вы можете дальше расширить приложение, добавив аутентификацию, перенаправления, A/B-тестирование или выбор коллекций. А если вам нужен программный доступ к статическим файлам, функция getMatchingAsset() предоставляет доступ к байтам файла или его метаданным, таким как тип содержимого, размер и хеш, чтобы вы могли самостоятельно отдавать файл или читать его содержимое в собственном коде.
И многое другое!
В коробке есть кое-что еще, что не поместилось в один пост! Вот несколько основных моментов, а подробности вы найдете в :
- Полноценный набор инструментов командной строки. Единственная команда из 2022 года превратилась в подкоманды в стиле git: publish-content, clean и collections (с командами list, promote, delete и update-expiration). Все, что вносит изменения, поддерживает параметр --dry-run, поэтому сначала можно посмотреть, что произойдет.
Полноценный набор инструментов командной строки. Единственная команда из 2022 года превратилась в подкоманды в стиле git: publish-content, clean и collections (с командами list, promote, delete и update-expiration). Все, что вносит изменения, поддерживает параметр --dry-run, поэтому сначала можно посмотреть, что произойдет.
- Автоматическая очистка кэша. После выполнения publish-content и collections delete версия 8 выполняет мягкую очистку (soft-purge) суррогатного ключа затрагиваемой коллекции, чтобы устаревшие закэшированные ответы не задерживались. Опции --fastly-service-id и --purge-environment позволяют контролировать, что именно подвергается очистке.
Автоматическая очистка кэша. После выполнения publish-content и collections delete версия 8 выполняет мягкую очистку (soft-purge) суррогатного ключа затрагиваемой коллекции, чтобы устаревшие закэшированные ответы не задерживались. Опции --fastly-service-id и --purge-environment позволяют контролировать, что именно подвергается очистке.
- Локальная разработка. В режиме KV Store флаг --local настраивает команды управления на работу с симулированным KV Store, поэтому вы можете опробовать весь рабочий процесс публикации без сервиса Fastly. В режиме Object Storage (S3) локальной симуляции нет, но вы все равно можете вести разработку локально: публикуйте данные в свой бакет, и локальный сервер разработки будет считывать контент напрямую из него. Используйте отдельный бакет или коллекцию для разработки, чтобы не менять то, что обслуживает продакшн.
Локальная разработка. В режиме KV Store флаг --local настраивает команды управления на работу с симулированным KV Store, поэтому вы можете опробовать весь рабочий процесс публикации без сервиса Fastly. В режиме Object Storage (S3) локальной симуляции нет, но вы все равно можете вести разработку локально: публикуйте данные в свой бакет, и локальный сервер разработки будет считывать контент напрямую из него. Используйте отдельный бакет или коллекцию для разработки, чтобы не менять то, что обслуживает продакшн.
- Тонкая настройка. Включайте или исключайте файлы, добавляйте или переопределяйте типы содержимого, выбирайте варианты сжатия для генерации и задавайте настройки сервера для каждой коллекции, такие как резервные варианты для SPA и пользовательские страницы 404.
Тонкая настройка. Включайте или исключайте файлы, добавляйте или переопределяйте типы содержимого, выбирайте варианты сжатия для генерации и задавайте настройки сервера для каждой коллекции, такие как резервные варианты для SPA и пользовательские страницы 404.
Обновление
Если вы используете версию 6 или более раннюю, запланируйте повторное создание каркаса приложения, так как версия 7 представляла собой масштабную переработку. В ней было прекращено встраивание файлов в бинарный файл Wasm, а также поддержка ассетов модулей. Если вы зависите от ассетов модулей, v6 branch по-прежнему доступна для вас.
Если вы используете версию 7 и работаете с KV Store, у нас хорошие новости: пересоздавать каркас приложения не нужно. Установите версию 8 в ваш каталог compute-js, убедитесь, что инструмент может найти токен API Fastly (установите переменную FASTLY_API_TOKEN или передайте --fastly-api-token, так как инструмент больше не обращается к учетным данным вашей сессии Fastly CLI), а затем пересоберите и разверните ваше приложение. Версия 8 продолжит обслуживать контент, который вы уже опубликовали. В руководстве по миграции описаны другие изменения, на которые стоит обратить внимание.
Готовы попробовать?
@fastly/compute-js-static-publish — это проект Fastly Labs, и мы будем рады узнать, что вы создадите с его помощью! Версия 8 доступна для использования в npm, поэтому переходите в репозиторий GitHub за полной документацией, чтобы опробовать ее, и сообщайте о проблемах в трекер, если столкнетесь с чем-то неожиданным.
