来自AWS无服务器反应应用程序的多个安全休息电话

Question

I am developing app using react-reduce, appsync graphql and database as dynamoDB. so it's like below

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

Now requirement wise there is a situation where i need to call multiple SSL certificate based REST API to get data, once data is fetched from REST API then get other data from DB ..merge those data and show it to UI.

for eg user data i need to display in UI, so database has 50% data for that user and rest of the data i need to fetch from multiple web service call.

few options i have in mind or i have explored so far to address this situation. eg

(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

this option UI don't have to merge data, what ever is coming from pipeline resolver, UI can display.

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

In option:2 UI has to get data from REST and DB and then merge and display.

(Option:3)

Option:3, i am not sure how feasible it is. As of now i came up with above options. looking for right approach or best practices for such situation.

Answer 1

So ideally when building out a GraphQL gateway in AppSync, the idea should be that the UI developer doesn't have to think about the mechanics of where data comes from, rather they just work with the high-level entities particular to the application. There are some scenarios where this isn't as optimal, but it's something to strive for.

If the result of a REST API call only maps to a single field, you can attach a nested resolver just to that field, even if there's a resolver at a higher level that's getting data from DynamoDB. However if that REST call returns values for multiple fields, or depends on data from the other REST calls, then a pipeline resolver makes sense here.

You merge the data from multiple steps in a pipeline resolver is to take the output of each function call and add it to the $context.stash in the function response mapping template, which is a Map that is persisted throughout each function call in the pipeline resolver. Then in the Pipeline Resolver's response mapping template, you can read from the stash and assemple the data you want to return for that type in your schema.

Another benefit of GraphQL in this case that when the client UI doesn't need a particular field in an object, say that omitted field is found in a database that's slow to return, you don't have to actually call that database in the query resolver, as the client defines only the data it needs.