Serverless Framework 如何为 AppSync 启用服务端缓存并用 flush-cache 命令清除缓存【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless如果你的 AppSync GraphQL API 存在重复请求打满数据源、或数据更新后仍返回旧结果的问题可以在 Serverless Framework 中通过appSync.caching配置启用 AppSync 的服务端数据缓存之后再用sls appsync flush-cache命令随时手动清空缓存。AppSync 集成已内置于 Framework无需安装任何插件原有的appSync配置会被直接沿用。本文适用于provider.name为aws、serverless.yml中已定义appSync块的服务前提是该服务已能正常部署。启用服务端缓存配置appSync.caching在服务目录的serverless.yml中appSync块下添加caching子配置即可开启缓存。文档给出的最小配置如下appSync: name: my-api caching: behavior: PER_RESOLVER_CACHING type: SMALL ttl: 3600 atRestEncryption: false transitEncryption: false各属性的含义与默认值来源caching.mdbehavior缓存行为只能取FULL_REQUEST_CACHING按整个请求缓存或PER_RESOLVER_CACHING按 resolver 缓存typeRedis 实例规格可选SMALL、MEDIUM、LARGE、XLARGE、LARGE_2X、LARGE_4X、LARGE_8X、LARGE_12X默认SMALLttl缓存默认有效期秒默认3600最大3600enabled布尔值是否启用缓存只要存在caching定义默认即为trueatRestEncryption/transitEncryption布尔值分别控制静态加密与传输加密默认均为false。也就是说caching块一旦出现缓存就默认开启如需关闭显式写enabled: false。可选分支按 resolver 细化缓存全局behavior设为PER_RESOLVER_CACHING时可以在单个 resolver 上进一步自定义 TTL 和缓存键来源resolvers.md 的 Caching 一节appSync: resolvers: Query.user: dataSource: myDataSource caching: ttl: 60 keys: - $context.arguments.id直接写caching: true表示使用全局ttl、不指定keys写成对象时可覆盖该 resolver 的ttl秒并提供keys数组作为缓存键。这只影响单个 resolver 的缓存策略与后文整库清除缓存的flush-cache命令互不冲突。部署使配置生效缓存配置随 CloudFormation 栈下发修改appSync.caching后需要部署服务使配置生效sls deploy部署成功后API 的 Redis 缓存实例才会按type、ttl、加密等配置创建或更新。用 flush-cache 命令清除缓存当源数据发生变化、希望立即丢弃已缓存的结果时在服务目录下执行来源commands.mdsls appsync flush-cache该命令的用途是当你的 API 使用服务端缓存时清空该 API 的缓存。从实现看appsync/index.js它会先从已部署的栈中读取 AppSync API ID再调用 AWS AppSync 的flushApiCache接口成功后在终端输出Cache flushed successfully因此这条命令有两个明确前提服务已通过sls deploy部署过栈中存在可解析的 API IDAPI 启用了服务端缓存即存在appSync.caching配置未启用缓存的 API 不存在可清除的缓存。验证与后续排查成功判定命令返回Cache flushed successfully即表示flushApiCache调用成功控制台核对如果需要在 AWS 控制台查看该 API 的缓存状态可运行sls appsync console它会打开一个新浏览器标签页跳转到该 API 的 AppSync 控制台页面辅助命令排查缓存行为时sls appsync logs支持--filter、--startTime、--tail等选项可以查看该 API 的日志sls appsync get-introspection可导出 schema 用于确认 resolver 结构。限制与注意事项ttl上限就是3600秒不能配置更长的全局缓存有效期需要更短的生命周期时用 resolver 级别的caching.ttl覆盖type只能从文档列出的八种规格中选取写其他值没有依据flush-cache作用于整条 API 的缓存没有按 resolver 或按字段部分清除的选项缓存的加密atRestEncryption、transitEncryption默认关闭如果合规要求传输或存储加密需要在caching块中显式置为true后再部署。更多 AppSync 配置项认证、API Keys、数据源、自定义域名等见 AppSync 文档目录。【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Serverless Framework 如何为 AppSync 启用服务端缓存并用 flush-cache 命令清除缓存【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless如果你的 AppSync GraphQL API 存在重复请求打满数据源、或数据更新后仍返回旧结果的问题可以在 Serverless Framework 中通过appSync.caching配置启用 AppSync 的服务端数据缓存之后再用sls appsync flush-cache命令随时手动清空缓存。AppSync 集成已内置于 Framework无需安装任何插件原有的appSync配置会被直接沿用。本文适用于provider.name为aws、serverless.yml中已定义appSync块的服务前提是该服务已能正常部署。启用服务端缓存配置appSync.caching在服务目录的serverless.yml中appSync块下添加caching子配置即可开启缓存。文档给出的最小配置如下appSync: name: my-api caching: behavior: PER_RESOLVER_CACHING type: SMALL ttl: 3600 atRestEncryption: false transitEncryption: false各属性的含义与默认值来源caching.mdbehavior缓存行为只能取FULL_REQUEST_CACHING按整个请求缓存或PER_RESOLVER_CACHING按 resolver 缓存typeRedis 实例规格可选SMALL、MEDIUM、LARGE、XLARGE、LARGE_2X、LARGE_4X、LARGE_8X、LARGE_12X默认SMALLttl缓存默认有效期秒默认3600最大3600enabled布尔值是否启用缓存只要存在caching定义默认即为trueatRestEncryption/transitEncryption布尔值分别控制静态加密与传输加密默认均为false。也就是说caching块一旦出现缓存就默认开启如需关闭显式写enabled: false。可选分支按 resolver 细化缓存全局behavior设为PER_RESOLVER_CACHING时可以在单个 resolver 上进一步自定义 TTL 和缓存键来源resolvers.md 的 Caching 一节appSync: resolvers: Query.user: dataSource: myDataSource caching: ttl: 60 keys: - $context.arguments.id直接写caching: true表示使用全局ttl、不指定keys写成对象时可覆盖该 resolver 的ttl秒并提供keys数组作为缓存键。这只影响单个 resolver 的缓存策略与后文整库清除缓存的flush-cache命令互不冲突。部署使配置生效缓存配置随 CloudFormation 栈下发修改appSync.caching后需要部署服务使配置生效sls deploy部署成功后API 的 Redis 缓存实例才会按type、ttl、加密等配置创建或更新。用 flush-cache 命令清除缓存当源数据发生变化、希望立即丢弃已缓存的结果时在服务目录下执行来源commands.mdsls appsync flush-cache该命令的用途是当你的 API 使用服务端缓存时清空该 API 的缓存。从实现看appsync/index.js它会先从已部署的栈中读取 AppSync API ID再调用 AWS AppSync 的flushApiCache接口成功后在终端输出Cache flushed successfully因此这条命令有两个明确前提服务已通过sls deploy部署过栈中存在可解析的 API IDAPI 启用了服务端缓存即存在appSync.caching配置未启用缓存的 API 不存在可清除的缓存。验证与后续排查成功判定命令返回Cache flushed successfully即表示flushApiCache调用成功控制台核对如果需要在 AWS 控制台查看该 API 的缓存状态可运行sls appsync console它会打开一个新浏览器标签页跳转到该 API 的 AppSync 控制台页面辅助命令排查缓存行为时sls appsync logs支持--filter、--startTime、--tail等选项可以查看该 API 的日志sls appsync get-introspection可导出 schema 用于确认 resolver 结构。限制与注意事项ttl上限就是3600秒不能配置更长的全局缓存有效期需要更短的生命周期时用 resolver 级别的caching.ttl覆盖type只能从文档列出的八种规格中选取写其他值没有依据flush-cache作用于整条 API 的缓存没有按 resolver 或按字段部分清除的选项缓存的加密atRestEncryption、transitEncryption默认关闭如果合规要求传输或存储加密需要在caching块中显式置为true后再部署。更多 AppSync 配置项认证、API Keys、数据源、自定义域名等见 AppSync 文档目录。【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考