如何将域名解析度aws_使用信息上下文的aws appsync条件解析器

如何将域名解析度aws

AWS AppSync (AWS AppSync)

AppSync is a managed GraphQL service offered by Amazon Web Services and can be used to build scalable enterprise APIs. A typical AppSync solution consists of small resolvers that can be combined to access various data sources such as databases, HTTP APIs or AWS Lambda.

AppSync是Amazon Web Services提供的托管GraphQL服务，可用于构建可扩展的企业API。 典型的AppSync解决方案由小型解析器组成，可以将其组合以访问各种数据源，例如数据库，HTTP API或AWS Lambda。

介绍 (Introduction)

In this example, I will be talking about using AWS AppSync with AWS Lambda data sources and one of the challenges I have come across while developing enterprise scale solutions with these technologies.

在此示例中，我将讨论将AWS AppSync与AWS Lambda数据源一起使用，以及在使用这些技术开发企业级解决方案时遇到的挑战之一。

Each Lambda resolver you have in a particular request triggers an invocation. The problem comes with having nested resolvers where you only request data from the nested Lambda rather than the parent Lambda. As a result you will cause several invocations, incur cost and resource for the first Lambda without needing to.

您在特定请求中拥有的每个Lambda解析器都会触发一个调用。 问题来自于嵌套的解析器，您只从嵌套的Lambda而不是父Lambda请求数据。 结果，您将导致多次调用，而不必为第一个Lambda花费成本和资源。

If you’re running enterprise serverless it is important to consider the architecture to reduce the amount of compute where possible and lower the risk of hitting limits imposed by AWS.

如果您运行的是无服务器的企业服务器，那么就必须考虑该架构，以尽可能减少计算量，并降低违反AWS限制的风险。

Thankfully, AWS released an AppSync update in Feb 2020 giving us access to the context info object so we can mitigate this issue. Read more here.

值得庆幸的是，AWS在2020年2月发布了AppSync更新，使我们能够访问上下文信息对象，从而可以缓解此问题。 在这里阅读更多。

让我们潜入吧！ 💥 (Let’s dive in! 💥)

Say you have a GraphQL endpoint and schema to retrieve a typical blog post:

假设您有一个GraphQL端点和架构来检索典型的博客文章：

type Post{
  id: ID!
  title: String!
  content: String!
  image: ImageData!
}type ImageData{
  id: ID!
  postId: ID!
  path: String!
  tags: String
}type Query{
  getPost(id: ID!): Post!
}

Using GraphQL, your query could look like:

使用GraphQL，您的查询可能类似于：

query GetPost{
  getPost(id: $id){
    title
    content
    image{
      path
      tags
    }
  }
}

Suppose in our setup we keep the image data separate from the post data, now each entity will have its own AppSync resolver that links off to a Lambda function and effectively running the above query invokes two Lambdas; getPostLambda and getImageDataLambda. Each of the resolvers request functions look something like:

假设在我们的设置中，我们将图像数据与发布数据分开，现在每个实体将拥有自己的AppSync解析器，该解析器链接到Lambda函数，并且有效运行上述查询会调用两个Lambda。 getPostLambda和getImageDataLambda 。 每个解析程序的请求函数如下所示：

{
"version": "2017-02-28",
"operation": "Invoke",
  "payload": {
    "postId": "$ctx.args.id",
    "requestId": "$ctx.stash.requestId",
   }
}

现在… (Now…)

90% of the time that’s great! the getPostLambda retrieves title and content from a data store or external service and the getImageDataLambda returns the image data from another.

90％的时间很棒！ getPostLambda从数据存储或外部服务中检索标题和内容，而getImageDataLambda从另一个数据库返回图像数据。

Suppose we use the power of GraphQL a little bit further, and only request the image data i.e.

假设我们进一步使用GraphQL的功能，并且仅请求图像数据，即

query GetPost{
  getPost(id: $id){
    image{
      path
      tags
    }
  }
}

After running the above query, we’ll see two Lambda invokations and importantly, the getPostLambda gets executed and returns with a bunch of data that we do not need… Oh dear!

运行上面的查询后，我们将看到两次Lambda调用，重要的是，getPostLambda将被执行并返回一堆我们不需要的数据……噢，亲爱的！

修复； Context.Info✅ (The fix; Context.Info ✅)

We can skip the first lambda execution by inspecting the Context Info which contains information about the GraphQL request that has been made.

我们可以通过检查上下文信息来跳过第一个lambda执行，该上下文信息包含有关已发出的GraphQL请求的信息。

Inside the Info object we can inspect the “selectionSetList” property that gives us the fields that the user/query has requested. We can then take that list and use one of the inbuilt AppSync utility functions to determine whether we need fetch data from the data store or just simply return the Id for the following nested resolver(s):

在Info对象中，我们可以检查“ selectionSetList”属性，该属性为我们提供了用户/查询已请求的字段。 然后，我们可以获取该列表，并使用内置的AppSync实用程序功能之一来确定是需要从数据存储区中获取数据，还是仅返回以下嵌套的解析器的ID：

#set( $postProperties = ['title', 'content'])#set( $invokeLambda = $util.list.copyAndRetainAll($ctx.info.selectionSetList, $postProperties).size() > 0 )                                            
#if( $invokeLambda )
  {
  "version": "2017-02-28",
  "operation": "Invoke",
    "payload": {
      "postId": "$ctx.args.id",
      "requestId": "$ctx.stash.requestId",
     }
  }
#else
  #return({                                                    
    "id": "$ctx.args.id"  
  })
#end

And there you have it, a conditional resolver that only invokes the getPostLambda if the user requests one or more fields on “post”, otherwise save cost, time and resources by simply returning the post id to the following resolver.

在那里，有条件条件解析器仅在用户请求“ post”上的一个或多个字段时才调用getPostLambda，否则只需将post id返回到以下解析器即可节省成本，时间和资源。

✏️ Find more infomation on the AppSync Context Object here: https://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html

✏️在此处找到有关AppSync上下文对象的更多信息： https ://docs.aws.amazon.com/appsync/latest/devguide/resolver-context-reference.html

Hope this helps! 🚀

希望这可以帮助！ 🚀

Reach me on linkedIn here: https://www.linkedin.com/in/robertbulmer/

在以下链接上与我联系： https ： //www.linkedin.com/in/robertbulmer/

翻译自: https://medium.com/swlh/aws-appsync-conditional-resolvers-using-the-info-context-e2a89c5477d4

如何将域名解析度aws