Appsync vs Apollo GraphQl性能

发布于 2025-02-01 22:36:54 字数 781 浏览 4 评论 0原文

AWS提出了为Appsync创建LAMBDA解析器的理由,该解析器将执行不同的操作。由于单个查询可能会导致对多个操作的调用,因此AppSync将多次调用Lambda解析器。我认为每个调用将有助于该请求的总体延迟。与Apollo或Express GraphQl Server的无服务器实现相比(GraphQl Server和在单个Lambda函数中运行的解析器)的实现。

参考。 https://docs.aws.amazon.com/ appsync/最新/devguide/tutorial-lambda-resolvers.html

exports.handler = (event, context, callback) => {
    switch(event.field) {
        case "operation_1": {/* ... */}
        case "operation_2": {/* ... */}
        case "operation_3": {/* ... */}
        ...
        default: {/* ... */}
    }
};

AWS makes a case to create a lambda resolver for AppSync that will perform different operations. Since a single query may result in calls to multiple operations, AppSync will invoke the lambda resolver multiple times. I think each invocation will contribute to the overall latency for the request. How does this compare to serverless implementation of Apollo or Express GraphQL Server (GraphQL Server and Resolvers running inside a single lambda function).

Ref. https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-lambda-resolvers.html

exports.handler = (event, context, callback) => {
    switch(event.field) {
        case "operation_1": {/* ... */}
        case "operation_2": {/* ... */}
        case "operation_3": {/* ... */}
        ...
        default: {/* ... */}
    }
};

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文