Как загрузить предварительно обработанный файл на S3 и получить к нему доступ при начальной загрузке нашей веб-страницы?

Использование предварительно обработанного HTML аналогично загрузке статического веб-сайта. Предполагая, что у вас установлен и настроен aws cli (используя aws configure), вы можете запустить следующую команду в каталоге, чтобы загрузить файл в корзину s3.

Это загрузит/обновит только те файлы, которые изменились по сравнению с существующими файлами корзины.

aws s3 sync my_local_dir s3://my_s3_bucket_name

Кроме того, если вы хотите установить кеш, вы можете добавить следующую опцию

aws s3 sync my_local_dir s3://my_s3_bucket_name --cache-control max-age=604800

Angular Universal можно использовать как для динамического SSR (рендеринг на стороне сервера), так и для статического предварительного рендеринга.

Динамический SSR (рендеринг на стороне сервера) не может быть реализован при размещении статических файлов, таком как AWS S3. Ему нужен механизм Javascript на стороне сервера (nodejs) для предварительного рендеринга страницы перед передачей ее клиентскому браузеру; Amazon S3 просто не имеет никаких возможностей, кроме обслуживания некоторых статических файлов.

С другой стороны, для статического предварительного рендеринга с помощью angular universal можно использовать AWS S3, так как это все статические файлы html/js/css. Однако есть одна загвоздка: каждый раз, когда содержимое статического файла изменяется, вы должны запускать процесс сборки/CI-CD, чтобы результирующие статические файлы были развернуты в корзине S3. Если вас это устраивает, это ничем не отличается от развертывания любых других статических сайтов на S3.

Например,

aws s3 sync ./dist/<your_awesome_ng_project> s3://<your_awesome_bucket_name>/ --delete.

Вы можете сослаться на эту конфигурацию круга CI, где я создаю угловой проект и развертываю его в корзине S3 https://github.com/jaisonpjohn/dbeaver-password-retriever-ng/blob/master/.circleci/config.yml

Подробнее о динамическом SSR (рендеринг на стороне сервера) и статическом предварительном рендеринге

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

Динамический SSR (рендеринг на стороне сервера) и статический предварительный рендеринг

Dynamic SSR – это концепция, согласно которой будет развернут сервер Node, который при каждом попадании в Route будет динамически генерировать и сериализовать приложение, возвращая эту строку в браузер.

Статическая предварительная отрисовка — это когда мы хотим предварительно отобразить список маршрутов и создать статические файлы (например, index.html, about-us.html и т. д.), а затем использовать сервер наш выбор обслуживать эти файлы позже.

Итак, как мы узнаем, какой из них выбрать и когда?

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

Вот моменты, которые вы должны рассмотреть, прежде чем решить, какой маршрут вам нужно выбрать.

Когда использовать статический предварительный рендеринг:

• Само ваше приложение довольно статично. (или, по крайней мере, маршруты, которые вы пытаетесь предварительно отрендерить) Например: домашняя страница | о нас | свяжитесь с нами

• Очень динамичные части вашего сайта (и те, которые находятся за барьером входа/авторизации) могут указывать на обычную версию вашего приложения, отображаемую на стороне клиента (CSR), и Angular может нормально загружаться.

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

Когда использовать динамическую SSR:

• Ваше приложение (и маршруты, которые вам нужны для SSR) очень динамичны.
• У вас есть список «популярных продуктов» | «живые данные» | и т. д., которые необходимо правильно заполнить для каждого рендеринга на стороне сервера.
• Структура вашего приложения визуализируется на основе файлов JSON или CMS, где все может измениться в любой момент.

Как правило, большинству приложений требуется статический предварительный рендеринг (поскольку любые маршруты за стеной аутентификации не получают большой/никакой выгоды от использования SSR, поскольку одной из основных целей является выигрыш в поисковой оптимизации и улучшение воспринимаемая производительность.Помните, что вы всегда можете иметь определенные аспекты вашего приложения, которые не отображаются во время SSR, и эти динамические части заполняются во время CSR!

Аналогичный вопрос (этот вопрос касается другого статического файлового сервера nginx вместо S3): https://github.com/angular/universal/issues/554

Кстати, Angular Universal теперь является частью основного проекта ng

Этот ответ немного запоздал, я не знаю, получили ли вы свой ответ или нет. Но я все равно добавляю его сюда, чтобы помочь другим пользователям SO.

Открытие баунти здесь.

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

1. Не отправляйте сканеры на реальный сервер, иначе это повлияет на наш анализ.
2. Зачем беспокоить наши серверы поисковыми роботами, которым нужны ТОЛЬКО статические данные.
3. Самое главное, БОЛЬШИНСТВО движков не могут отображать теги Angular. В основном они не выполняют javascript на странице перед отображением результатов поиска. Если мы этого не сделаем; результаты поиска для нашего веб-сайта будут выглядеть ужасно.

Как мы это сделали: На нашем nginx; мы настроили правило, если юзер-агентом является любой из поисковых систем запрос передачи на сервер пре-рендеринга (независимый сервер), имеющий https://github.com/prerender/prerender установлен.

Самое главное, на этом сервере предварительного рендеринга был настроен плагин s3HtmlCache. Этот плагин сначала проверяет, доступна ли страница в S3; если нет, он создает страницу во время выполнения -> сохраняет в s3 -> отправляет клиенту.

Итак, чтобы решить вашу проблему: в вашем nginx; просто передайте ВСЕ запросы на сервер пре-рендеринга.

Дайте мне знать, если у вас возникнут какие-либо проблемы. Я реализовал это, и я знаю, что это сработает наверняка. Всего наилучшего.