Ошибка Amplify JS, когда подписка Appsyn c выставляется через API-шлюз - PullRequest
Новая
       33

Ошибка Amplify JS, когда подписка Appsyn c выставляется через API-шлюз

0 голосов
/ 20 апреля 2020

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

  1. Поддержка плана использования
  2. Возможность монетизации.

Насколько я понял, Appsyn c - это GrapQL + Apollo реализация сервера. Представленный API поддерживает запрос POST. И даже запрос на подписку также является почтовым запросом с URL-адресом Websocket MQTT (AWS IoT) в качестве ответа. (Например, ниже) 

{
  "extensions": {
    "subscription": {
      "mqttConnections": [
        {
          "url": "wss://something-ats.iot.ap-northeast-1.amazonaws.com/mqtt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=...",
          "topics": [
            ".../.../subscribeToVehicleLocation/..."
          ],
          "client": "..."
        }
      ],
      "newSubscriptions": {
        "subscribeToVehicleLocation": {
          "topic": ".../../subscribeToVehicleLocation/..",
          "expireTime": null
        }
      }
    }
  },
  "data": {
    "subscribeToVehicleLocation": null
  }
}

Если это так, можем ли мы предоставить конечную точку Appsyn через API-шлюз (метод POST)?

Для простоты я попытался использовать HTTP API в API-шлюзе.

  • Хорошо работал для Запрос & Мутирование Запрос.

  • Но для Подписаться запрос, я получаю исключение рукопожатия. (Ошибка подключения: ошибка установления соединения в моем angular проекте усиления)

    1. Это правильный способ выставить Appsyn c через API-шлюз? Или я должен использовать сервис AWS (в API Gateway) для вызова Appsyn c?

    2. Как я могу устранить эту ошибку квитирования Websocket Connection в Angular Amplify Project?

PS :

Ранее я мог подписаться на данные, используя оригинальный URL-адрес Appsyn c (используя Amplify JS в Angular 7). С URL-адресом API-шлюза я получаю это исключение WS Handshake (с Amplify). 

WebSocket connection to 'wss://....execute-api.ap-northeast-1.amazonaws.com/graphql?header=...&payload=e30=' failed: Error during WebSocket handshake: Unexpected response code: 400

in AWSAppSyncRealTimeProvider.js:603

Обновление 24-04-2020

Я был возможность вызывать Appsyn c через AWS Сервисный вызов в API-шлюзе с указанными ниже настройками.

Но, тем не менее, у меня ошибка веб-сокета в Amplify

Конфигурация API-шлюза

AWS API Gateway invoking AWS Service Appsync

Доверительные отношения для роли IAM 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "appsync.amazonaws.com",
          "apigateway.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Разрешение роли IAM

AWSAppSyncInvokeFullAccess

Ответы [ 2 ]

0 голосов
/ 24 апреля 2020

Получив мнения экспертов, я наконец-то отказался от плана разоблачения Appsync через API-Gateway.

Appsyn c & API-Gateway принадлежит к той же иерархии в AWS Stack. Не было хорошей идеей выставлять Appsyn c через API-шлюз, поскольку конечная точка Appsyn c все еще была бы опубликована c (ведущая в черный ход).

Ниже приведены мои решения ( с учетом Appsync) для

  1. Область монетизации : сбор журналов Appsyn c metrics/trace и вычисление использования API на основе Cognito UserId или Apikey.

  2. План использования / Квота : Установите Lambda Datasource (в средстве распознавания конвейера), увеличивающее количество обращений в кэше Redis (с ключом в качестве Apikey и значением в качестве количества обращений пользовательский TTL, скажем, 1 день)

0 голосов
/ 21 апреля 2020

Я не думаю, что вы можете установить соединение так, как вы себе представляли.

В AppSyn c запросы и мутации доставляются с использованием обычных HTTP-соединений (REST). С другой стороны, подписки основаны на веб-сокетах. Оба протокола основаны на TCP, но серверы и клиенты обрабатывают их по-разному (браузеры и sdk, например, усиливают).

AWS Шлюз API поддерживает WebSockets , но использует другую конфигурацию.

Вы сказали нам, что настроили шлюз API для использования HTTP API для простоты. В этом случае это не будет работать, потому что конечная точка, созданная вами внутри API Gateway, не готова выполнить рукопожатие websocket с клиентом (Amplify).

Чтобы принять и контролировать рукопожатие, вы должны создать API как Websocket API. Но дело в том, что с помощью этого API вы не можете просто переадресовать свой вызов в AppSyn c. Вам потребуется развернуть компонент для реализации управления подключением, как ожидается Реализация API-шлюза Web Gateway .

Первой идеей будет лямбда-функция, но затем возникает вопрос: как вы будете контролировать и сохранять соединение через веб-сокет от вашего Lambda до API AppSyn c. Вы не можете рассчитывать на то, что Lambda сделает это.

Я могу представить себе следующую реализацию для работы над вашим делом (но я не думаю, что это будет хорошая реализация):

  1. Реализация API WebSocket в AWS Шлюз API
  2. Развертывание компонента для управления бэкэндом API WebSocket (это должно быть внутри экземпляра или контейнера)
  3. Из этого компонента вы используйте ampify для подключения к конечной точке веб-сокета в AppSyn c.
  4. В компоненте, каждый раз, когда вы получаете запрос от AppSyn c на указанное c подключение веб-сокета, вы вызываете AWS URL-адрес обратного вызова шлюза API для API WebSocket и переадресация ответа.

В итоге, с этим решением вам нужно будет воспроизвести элемент управления соединением, предоставляемый AppSyn c из коробки, помимо наличия другой части инфраструктуры для обеспечения сантехники, которая уже предоставляется AppSyn c из коробки.

...