Лучший шаблон для вызова AWS API от Elm SPA? - PullRequest
0 голосов
/ 16 октября 2018

Я разрабатываю приложение, следуя довольно близко Пример Feldman Elm SPA с API, размещенным на AWS API Gateway.Моя проблема заключается в следующем:

Мне нужно подписать вызовы API с помощью AWS API Signature v4 .Это менее тривиальная задача, чем я изначально думал в Elm:

  • Нет пакета сигнатур Elm AWS, поэтому я, естественно, посмотрел библиотеки JS для использования через порты.
  • Вариант 1: Используйте AWS Amplify API , который выполняет всю работу => Но затем, как обрабатывать результат наиболее подходящим для Elm способом (в идеале с RemoteData ).
  • Вариант 2. Используйте стороннюю библиотеку JS, чтобы просто подписать запрос, подделанный Elm Http.request , и отправить / обработать HTTP-запрос через Elm => Пока что я нашел только ошибочные реализации AWS Sigv4,В любом случае, я бы предпочел официальную реализацию.
  • В двух случаях я застрял с сообщением «Главный родитель / страница детей»: я могу отправить запрос 1) или 2) через порт от ребенка.Но тогда как ребенок может получить ответ на свой запрос?Действительно, все ответы отправляются в Elm через одну и ту же подписку на порт.Нужно ли «отмечать» исходящие запросы, а затем отправлять ответ на основе тега?Но это будет выглядеть ужасно и плохо масштабироваться.

Обратите внимание, что речь идет о шаблоне и архитектуре приложения.Это не основной вопрос о портах Elm (я уже успешно звонил в API от Elm).

Любые рекомендации или указатели приветствуются.Спасибо!

Дополнительная информация о моей настройке (после первого комментария)

Я следую Рекомендации AWS (сценарий № 3 Доступ к ресурсам с помощью API Gateway иЛямбда с пулом пользователей )

  • Пользователи интерфейсных приложений управляются:
    • Пулом пользователей Cognito (регистрация, вход и т. Д.) *
    • Cognito Identity Pool (сопоставьте пользователей с ролью IAM для доступа к ресурсам AWS, включая шлюз API)
  • Внутренний сервер не работает: функции API Gateway + Lambda
  • Шлюз API: интеграция с Lambda-прокси + Авторизация = IAM => для этого требуется подпись AWS
  • Я не использую ключи API, потому что:
    • Я не хочу предоставлять доступ ксерверная часть для неаутентифицированных пользователей
    • Мне нужно идентифицировать пользователя по заголовкам запросов
    • Я не хочу полагаться на долгосрочные секреты для аутентификации на стороне клиента
...