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

Ответ 1

Использование предварительно загруженного 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

Ответ 2

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

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

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

Например,

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

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

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

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

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

Динамическая SSR - это концепция, при которой будет запущен работающий сервер Node, что при каждом попадании в маршрут он будет динамически генерировать и сериализовать приложение, возвращая эту строку в браузер.

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

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

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

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

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

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

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

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

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

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

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

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

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

Открытие щедрости здесь.

Ответ 3

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

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

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

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

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

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