Как я могу использовать AWS CloudFront и API Gateway одновременно для одного домена?
Я помещаю эти статические ресурсы своего веб-сайта на S3 и настраиваю CloudFront для их распространения. По сути, они содержат контент, который потребуется пользователям для любого запроса GET на моем сайте, по существующим путям, то есть со списком ошибок.
У меня также есть некоторые запросы POST, которые мне нужно обработать. Отправка форм, отправка писем, уведомлений, взаимодействие с базой данных.
Как я могу настроить Lambda (или API Gateway) бок о бок с CloudFront для одного домена, чтобы CloudFront обрабатывал запросы GET, а API Gateway обрабатывал запросы с телом или запросами POST. Или я могу как-нибудь сделать это по индивидуальному URL?
Я запускаю несколько веб-приложений точно в соответствии с предложенным вами дизайном и извлек gofaas , образовательное приложение Go и Lambda, чтобы поделиться этими методами.
Вам нужно два. отдельные домены, например www.gofaas.net для S3 + CloudFront и api.gofaas.net для API Gateway + Lambda.
Затем вы можете позволить своему статическому сайту взаимодействовать с API с помощью конфигурации CORS API Gateway и некоторого кода JavaScript:
fetch(`https://api.gofaas.net/work`, {
method: "POST",
mode: "cors",
headers: {
"Accept": "application/json",
...
},
body: JSON.stringify(...)
})
.then(function(response) {
return response.json();
})
.then(function (json) {
// use response
})
.catch(function (err) {
console.log("fetch error", err);
});
Вот несколько руководств по настройке всего этого:
Вы можете создать лямбда-функцию, настроить шлюз API, а затем настроить CloudFront для пересылки определенных путей (например, / rest / *) на шлюз API и обслуживания всего остального из корзины S3.
Вот полное руководство, показывающее, как это сделать: https://www.codeengine.com/articles/process-form-aws-api-gateway-lambda/
С точки зрения подключения "что-то" должно отвечать на ваши запросы (GET, POST, PUT, все). Прежде всего, у вас есть TCP соединение, и "что-то" должно убедиться, что оно понимает уровень 7 и имеет смысл из байтов, которые посылает клиент. Только на этом этапе можно обрабатывать GET-запросы иначе, чем POST-запросы или один URL, чем другой. Поэтому, в конце концов, вам нужен сервис, способный понимать и маршрутизировать HTTP. Это могут сделать следующие службы: CloudFront ЭЛБ/ЭЛБ Шлюз API (ограничение будет позже)
API Шлюз использует CloudFront внутри (не давая вам возможности реально что-либо настроить на уровне CloudFront) - это означает, что нет способа запустить CloudFront и Шлюз API бок о бок, так как в конце концов это означает, что вы запускаете CloudFront с CloudFront бок о бок.
CloudFront дает возможность выбирать различное происхождение на основе шаблонов - но в качестве источника можно выбрать только S3 или ELB/ALB, а не функции Lambda (кроме функции Lambda@Edge).
ALB/ELB может использовать только EC2 экземпляры в качестве бэкэнда - здесь нет ни Lambda, ни S3.
Единственные способы, которые я могу придумать, как сделать то, что вы хотите:
- Вы используете API Gateway и направляете определенный "актив" - путь к функции Lambda, которая делает своего рода обратный прокси для S3 (таким образом, пропуская статические активы через лямбда) - будьте осведомлены о затратах на Lambda здесь!
- Вы можете сделать то же самое, но вместо того, чтобы пропускать актив через Lambda, просто генерируйте подписанный URL внутри Lambda и перенаправляйте его непосредственно на S3 для обслуживания (это может быть более выгодно с точки зрения затрат)
- Используя различные поддомены для ваших активов по сравнению с остальной частью вашего приложения - Это очень распространенная закономерность, поскольку можно легко разделить на уровне DNS и использовать различные сервисы для различных случаев использования (CloudFront для активов и API Gateway для нестатических частей)
Так что мой звонок будет последним вариантом - но это означает, что вам нужно указать клиентам/браузерам отдельный поддомен для всех статических активов (или для всех POST запросов).
Звучит так, как будто вы хотите взглянуть на такие технологии, как AngularJS или React, чтобы построить действительно API-ориентированное приложение в браузере. При таком подходе вы запускаете реальный API, который обрабатывает все "динамические" запросы с помощью шлюза API и доставляет само приложение из S3 в качестве статического актива. Может быть, взглянув на них, вы сможете найти свой путь - даже если вы их не используете, архитектурный шаблон на то, как построить такие вещи - это то, о чём вы просите imho.
.У меня такая же настройка. Статические ресурсы на S3, функции Lambda обслуживаются через шлюз API, и у них одно и то же доменное имя.
Я использую шлюз API, который уже использует CloudFront и предоставляет некоторые его функции, такие как кэширование. Затем я настраиваю URI, которые сопоставляются со статическими активами. В API Gateway ресурс может быть функцией Lambda, функцией AWS, макетом или другим URL-адресом. У меня они указывают на мои URL-адреса S3.
URI-адреса также могут быть настроены для поиска подпути, например / assets / * .