Развертывание для хостинга firebase от функции firebase

Возможно ли развертывание статических активов от функции firebase до хостинга firebase?

Случай использования: блог со статическими html файлами. Содержимое блога и метаинформация будут храниться в базе данных (контент как уценка). При публикации или обновлении запускается функция firebase, которая анализирует уценку и генерирует статический html файл для сообщения в блоге и развертывает его на хосте Firebase. После развертывания функция сохранит прямой URL-адрес в базе данных.

Будет ли этот рабочий процесс возможным? В текущей документации я ничего не могу найти о развертывании из функций.

В качестве обходного пути я мог представить себе установку с помощью travis-ci. Функция запускает восстановление на travis, travis создает статические активы и разворачивает их на хостинг firebase, но это кажется огромным накладным расходами.

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

Ответ 1

Я хотел бы сделать это в течение длительного времени, и кажется, что с недавно представленной Firebase Functions Hosting Integration... мы все еще не можем делать то, что хотим. Но мы можем приблизиться!

Если вы прочитаете сообщение выше, вы можете увидеть, как мы теперь можем отредактировать firebase.json перенаправить URL-адреса (ы), чтобы указать на функцию firebase, которая может построить страницу из уценки, хранящейся в firebase, и служить этому для клиента.

Дело в том, что это происходит при каждом запросе GET для каждой страницы. Это глупо (для большей части статической страницы, как обычный блог). Мы хотим, чтобы статические страницы были мгновенно доступны, не ожидая, что функции сгенерируют что-нибудь (хотя это происходит очень быстро). Мы можем смягчить это, установив заголовок Cache-Control на произвольно большое число с объектом response, как в

res.set('Cache-Control', 'public, max-age=600, s-maxage=31536000');

Что скажет браузеру кэшировать результат в течение 10 минут, но CDN будет кэшировать его в течение года. Это почти решает проблему отсутствия предварительно рендерированных, мгновенно доступных страниц для всех, кроме первого удара, что повлечет за собой стоимость рендеринга. Кроме того, CDN может вытеснить ваш кешированный контент, если он определит, что недостаточно трафика, чтобы гарантировать его хранение.

Подходите ближе.

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

Измените URL-адрес сообщения. Это, вероятно, плохая идея, так как она запишет любой SEO и сломает ссылки на страницу, которая уже находится в дикой природе.

Возможно, существует способ заставить CDN обновиться, возможно, добавив ваш процесс публикации публикации в блоге, включив в запрос javascript GET запрос с чем-то нечетным в заголовке запроса, или, может быть, есть способ сделать это с функцией firebase в любое время, когда сообщение обновляется. Вот где я застрял.

Firebase использует Google Cloud Platform CDN, который включает механизм недействительность кэша, но я не знаю, что это легко доступно из функций - и даже если это так, он по-прежнему не решает выходить из кэша.

Лично я, вероятно, буду использовать настройку, которую я описал с предельным возрастом кэша CDN промежуточной длины. Это превосходит мой текущий подход отправки меток к клиенту и рендеринга локально с использованием (отличного) showdown.js, который по-прежнему очень быстрый, но требует JavaScript-клиент и несколько циклов процессора.

Надеюсь, у кого-то будет решение для этого (или кто-то из firebase может проскользнуть, нажав на хостинг из функций в следующую версию:)). Я обновлю свой ответ, если я его пригворю.

Ответ 2

Я еще не полностью исследовал это, но мне интересно, это то, что вы ищете:

https://gist.github.com/puf/e00c34dd82b35c56e91adbc3a9b1c412

мерзкий клон https://gist.github.com/e00c34dd82b35c56e91adbc3a9b1c412.git firebase-hosting-deploy-file cd firebase-hosting-deploy-file npm установить

выполняя пробный запуск, убедитесь, что вы ничего не делаете, вы пожалеете узел deployFile.js contentsite/index.html

сделать удаление для реального узла deployFile.js contentsite/index.html commit

Ответ 3

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

Я обновлю этот ответ с помощью кода функции и учебника после некоторых тестов.