昨晚FastAPI提交了一个commit给项目加了OpenAPI依赖关系的基准测试。代码改动不大但背后的意图值得聊聊。具体来说这个测试评估的是在复杂的依赖链下生成OpenAPI Schema需要多长时间。测试方式很简单——构建一个包含多层嵌套依赖的FastAPI应用然后测量生成OpenAPI文档的性能开销。乍一看这不就是个普通的性能测试吗。但仔细想想为什么直到现在才有人关注这个依赖链的隐形成本用过FastAPI的都知道它的核心卖点之一就是自动生成OpenAPI文档。你写个路由函数加个类型注解FastAPI自动帮你搞定API文档。开发者体验确实好。但随着项目变大依赖关系变得越来越复杂的时候问题出现了。怎么说呢一个典型的场景是这样的你在一个中型项目里定义了UserService它依赖DatabaseSessionDatabaseSession又依赖ConfigManagerConfigManager又依赖SecretResolver……每一层依赖在生成API文档时都需要被解析。如果这个依赖链有10层OpenAPI Schema生成的时间就不是O(1)而是随着依赖深度线性增长。我看到这个commit的测试脚本里构建了一个包含多个嵌套依赖的FastAPI应用。说实话这个测试场景非常贴近真实项目——只要项目里用了依赖注入FastAPI的Depends随着业务增长依赖层级就会越来越深。不是开发者故意写得复杂而是业务本来就是这样一层套一层的。翻了下GitHub Issue区发现确实有开发者报过这个问题项目到了几百个路由的规模后每次修改代码后重载开发服务器等待OpenAPI文档重新生成的时间越来越长。有人专门拉了个分支做性能分析发现在某些极端情况下生成OpenAPI Schema的耗时能达到秒级。盯着那个Issue的讨论看了好一会——这不只是FastAPI的问题任何依赖注入框架在复杂场景下都会遇到类似的性能瓶颈。为什么现在才开始关注有意思的是FastAPI从2018年发布到现在性能和自动文档生成一直是它的招牌功能。但过去大家关注的重点是运行时的性能——路由匹配快不快、请求处理耗时不耗时。很少有人关注开发时的性能——启动应用、生成文档这些环节的耗时。但项目规模摆在那。一个只有10个路由的小项目和500个路由的大项目启动时间的差距不是线性增长的。因为不仅路由多了每个路由背后的依赖关系也会指数级复杂化。这也是很多框架的通病。在小项目阶段测试不出问题到大项目阶段才发现当初的设计决策带来了性能隐患。FastAPI的依赖注入现在是通过Python类型系统和泛型来实现的这种方案的灵活性无可挑剔但在性能上——说实话——不是最优的。如果未来要优化要么是缓存依赖解析结果要么是惰性生成Schema要么是彻底重写解析引擎。对开发者的实际影响这个基准测试的出现意味着FastAPI的开发团队开始正视这个问题了。对正在用FastAPI做中大型项目的团队来说有几个可以提前做的一是关注路由数量的临界点。如果你的项目路由超过200个而且大量使用了链式依赖注入可以自己跑一下启动耗时测试看看OpenAPI生成是否已经成为开发效率的瓶颈。二是有个临时方案可以试生产环境下可以禁用Swagger UI的自动加载或者把文档生成改成按需触发而不是每次启动都重新生成。我见过有人这么改启动时间从8秒降到了1秒。但真正麻烦的是——最核心的问题其实不是FastAPI自身怎么优化而是Python类型系统在做依赖注入方案设计时的固有限制。Python的泛型支持是在3.5之后才逐步完善的FastAPI用类型注解来做依赖注入本质上是把运行时的能力建立在编译时的信息之上。这个方案在简单场景很好用但一旦依赖图复杂了解析开销就变得不可忽视。那问题来了如果要支持复杂的企业级项目FastAPI要不要引入更复杂的依赖注入机制如果要引入它就不再是快速开发API那么简单了。这个取舍才是真正需要思考的问题。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
昨晚FastAPI提交了一个commit给项目加了OpenAPI依赖关系的基准测试。代码改动不大但背后的意图值得聊聊。具体来说这个测试评估的是在复杂的依赖链下生成OpenAPI Schema需要多长时间。测试方式很简单——构建一个包含多层嵌套依赖的FastAPI应用然后测量生成OpenAPI文档的性能开销。乍一看这不就是个普通的性能测试吗。但仔细想想为什么直到现在才有人关注这个依赖链的隐形成本用过FastAPI的都知道它的核心卖点之一就是自动生成OpenAPI文档。你写个路由函数加个类型注解FastAPI自动帮你搞定API文档。开发者体验确实好。但随着项目变大依赖关系变得越来越复杂的时候问题出现了。怎么说呢一个典型的场景是这样的你在一个中型项目里定义了UserService它依赖DatabaseSessionDatabaseSession又依赖ConfigManagerConfigManager又依赖SecretResolver……每一层依赖在生成API文档时都需要被解析。如果这个依赖链有10层OpenAPI Schema生成的时间就不是O(1)而是随着依赖深度线性增长。我看到这个commit的测试脚本里构建了一个包含多个嵌套依赖的FastAPI应用。说实话这个测试场景非常贴近真实项目——只要项目里用了依赖注入FastAPI的Depends随着业务增长依赖层级就会越来越深。不是开发者故意写得复杂而是业务本来就是这样一层套一层的。翻了下GitHub Issue区发现确实有开发者报过这个问题项目到了几百个路由的规模后每次修改代码后重载开发服务器等待OpenAPI文档重新生成的时间越来越长。有人专门拉了个分支做性能分析发现在某些极端情况下生成OpenAPI Schema的耗时能达到秒级。盯着那个Issue的讨论看了好一会——这不只是FastAPI的问题任何依赖注入框架在复杂场景下都会遇到类似的性能瓶颈。为什么现在才开始关注有意思的是FastAPI从2018年发布到现在性能和自动文档生成一直是它的招牌功能。但过去大家关注的重点是运行时的性能——路由匹配快不快、请求处理耗时不耗时。很少有人关注开发时的性能——启动应用、生成文档这些环节的耗时。但项目规模摆在那。一个只有10个路由的小项目和500个路由的大项目启动时间的差距不是线性增长的。因为不仅路由多了每个路由背后的依赖关系也会指数级复杂化。这也是很多框架的通病。在小项目阶段测试不出问题到大项目阶段才发现当初的设计决策带来了性能隐患。FastAPI的依赖注入现在是通过Python类型系统和泛型来实现的这种方案的灵活性无可挑剔但在性能上——说实话——不是最优的。如果未来要优化要么是缓存依赖解析结果要么是惰性生成Schema要么是彻底重写解析引擎。对开发者的实际影响这个基准测试的出现意味着FastAPI的开发团队开始正视这个问题了。对正在用FastAPI做中大型项目的团队来说有几个可以提前做的一是关注路由数量的临界点。如果你的项目路由超过200个而且大量使用了链式依赖注入可以自己跑一下启动耗时测试看看OpenAPI生成是否已经成为开发效率的瓶颈。二是有个临时方案可以试生产环境下可以禁用Swagger UI的自动加载或者把文档生成改成按需触发而不是每次启动都重新生成。我见过有人这么改启动时间从8秒降到了1秒。但真正麻烦的是——最核心的问题其实不是FastAPI自身怎么优化而是Python类型系统在做依赖注入方案设计时的固有限制。Python的泛型支持是在3.5之后才逐步完善的FastAPI用类型注解来做依赖注入本质上是把运行时的能力建立在编译时的信息之上。这个方案在简单场景很好用但一旦依赖图复杂了解析开销就变得不可忽视。那问题来了如果要支持复杂的企业级项目FastAPI要不要引入更复杂的依赖注入机制如果要引入它就不再是快速开发API那么简单了。这个取舍才是真正需要思考的问题。关于维基框架维基框架关注企业应用开发中的长期维护问题。在实际项目中业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素因此我们希望提供一套更容易扩展和维护的基础框架。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
