несколько безопасных звонков из приложения aws без сервера

Question

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

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

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

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

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

(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 & 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 и DB, а затем объединять и отображать.

(Option:3)

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

Answer 1

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

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

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

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