многократный безопасный вызов rest из бессерверного приложения react aws

#amazon-web-services #aws-lambda #aws-api-gateway #aws-appsync

#amazon-веб-сервисы #aws-lambda #aws-api-gateway #aws-appsync

Вопрос:

Я разрабатываю приложение, используя react-reduce, appsync graphql и базу данных в качестве DynamoDB. итак, это выглядит следующим образом

 React <--> GraphQL <-> (AppSync) <--> resolver <--> DynamoDB
  

Теперь, исходя из требований, возникает ситуация, когда мне нужно вызвать REST API на основе нескольких SSL-сертификатов для получения данных, после извлечения данных из REST API затем получить другие данные из DB .. объединить эти данные и показать их в пользовательском интерфейсе.

например, данные пользователя мне нужно отобразить в пользовательском интерфейсе, чтобы в базе данных было 50% данных для этого пользователя, а остальные данные мне нужно извлечь из нескольких вызовов веб-службы.

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

 (Option:1) react <--> graphQL <--> AppSync <--> Pipeline Resolver (which will call one by one rest API call and then final resolver call will be DynamoDB) <--> REST API amp; DynamoDb
  

https://docs.aws.amazon.com/appsync/latest/devguide/pipeline-resolvers.html

при этом пользовательскому интерфейсу не нужно объединять данные, пользовательский интерфейс может отображать все, что поступает из конвейерного преобразователя.

 (Option:2) react -- single Lambda Function (for all necessary REST API call), Next GraphQL call -- AppSync -- DynamoDB
  

В варианте: 2 Пользовательский интерфейс должен получать данные из REST и базы данных, а затем объединять и отображать.

 (Option:3)
  

введите описание изображения здесь

Вариант: 3, я не уверен, насколько это осуществимо. На данный момент я разработал вышеуказанные варианты. ищу правильный подход или лучшие практики для такой ситуации.

Ответ №1:

Таким образом, в идеале при создании шлюза GraphQL в AppSync идея должна заключаться в том, что разработчику пользовательского интерфейса не нужно думать о механизме поступления данных, скорее они просто работают с высокоуровневыми объектами, специфичными для приложения. В некоторых сценариях это не так оптимально, но к этому стоит стремиться.

Если результат вызова REST API сопоставляется только одному полю, вы можете прикрепить вложенный преобразователь только к этому полю, даже если есть преобразователь более высокого уровня, который получает данные из DynamoDB. Однако, если этот вызов REST возвращает значения для нескольких полей или зависит от данных из других вызовов REST, тогда здесь имеет смысл использовать конвейерный распознаватель.

Объединение данных с нескольких этапов в конвейерном преобразователе заключается в том, чтобы получать выходные данные каждого вызова функции и добавлять их в $context.stash в шаблоне сопоставления ответов функции, который представляет собой карту, которая сохраняется на протяжении каждого вызова функции в конвейерном преобразователе. Затем в шаблоне сопоставления ответов конвейерного преобразователя вы можете считывать данные из хранилища и собирать данные, которые вы хотите вернуть для этого типа в вашей схеме.

Еще одно преимущество GraphQL в этом случае заключается в том, что, когда клиентскому пользовательскому интерфейсу не требуется определенное поле в объекте, скажем, это пропущенное поле найдено в базе данных, возврат которой происходит медленно, вам не нужно вызывать эту базу данных в распознавателе запросов, поскольку клиент определяет только те данные, которые ему нужны.

Комментарии:

1. Спасибо за ваше предложение