Category: python

  • Flask已死,Fastapi才是未来[转]

    Flask是一个在Python开发者心目中十分重要的项目,如果你是一个Web开发者,我相信你一定用过Flask,但是可能没有用过FastAPI。这个和国外相比可能会更明显一点,我觉得主要是因为国内已经没有多少人在写技术文章推荐,教大家分辨趋势或者主流,而一些老手即便知道它们的优缺点可能也懒得写对比文章,结果造成很多新人不了解怎么选,只能看一些老的文章、大V或者书籍的推荐作为选择的依据。 但是如果你有兴趣,你可以考证2点: 最近1-2年,Python相关的知名新项目中只要有Web的,基本都使用FastAPI。 今天(2023年12月18日)在Github上,FastAPI的star数(66k)已经超过了Flask(65.2)。 接着看一下Python官方的开发者调查中Web框架占比的变化: 可以看到19年FastAPI甚至不是一个选项,而22年已经占到25%的比率。这个开发者调查需要年中才会统计出上一年的,所以2023年的得明天第三季度才能知道,我预计FastAPI可以达到35%左右。 需要注意这个占比数据包含了现有系统,所以Django和Flask不容易跌得很快,但是趋势是很明显的。 我们知道Web框架这个领域是很高产的,基本每年都有新的框架诞生,大部分框架昙花一现,但有的框架却能够长青。FastAPI诞生于2018年底,在2019年年底左右开始崭露头角,那么为什么它可以在短短的5年里让关注度超过在2010年底诞生的Flask呢?接着我们顺着时间线捋捋Python Web框架和相关解决方案的发展来理解吧。 Web框架(插件、工具)发展史 FastAPI作者是一个非常关注Python生态发展的开发者,延伸阅读链接2是一篇作者写的,详细的介绍了FastAPI出各个库中的借鉴或者启发的细节,而发展史这部分我也参考了这篇文章。大家应该看看原文,里面包含了为什么会出现FastAPI以及作者的一些设计哲学。 Django Django是Python社区里最早做到统治级别的Web框架,当时知名的Instagram就是用它构建的。它的特点是大而全,各种web开发需要用到的细节它基本都有相关的模块,尤其和关系数据库、管理功能等方面耦合度非常高。对于熟悉的老手,这是一个生产级别的框架,但即便有完整的文档,对于初学者非常不友好,学习曲线中后期很陡峭,它的复杂度和定制成本非常高。 其实我这篇文章,也可以叫做「Django和Flask之死」,但是在框架应用场景角度来说Flask和FastAPI对比更合适,而Django直接和FastAPI相比有一些差别。在一些商业场景(例如CMS)Django依然是首选,而Flask(甚至FastAPI)看起来更像个「玩具」,所以Django短时间不会被取代(Flask这些年不是也是没取代的了嘛)。 Django REST Framework(DRF) Django主旨是为了在后端生成 HTML,而不是创建现代前端(如 React、Vue.js )或与其通信的其他系统使用的 API。所以FastAPI其实和Django REST Framework直接对标,它们主要场景都是构建 Web API,但是名字上也可以看出来,DRF还是依托于Django框架,所以缺点一样。 Flask Flask是一个「微」框架(Micro framework),和Django截然相反,它仅保留小部分的核心,还为了解耦把功能拆分成几个库(如Jinja2,Werkzeug等),所以开发者有足够的自由,你可以很容易写出相关功能的第三方插件。它里面的蓝图、上下文、装饰器表示路由、信号等等设计在当时是非常先进的,再加上文档写的很完整,可以说对新手极为友好。 Flask REST Frameworks 由于Flask的简单性,它非常适合构建API,不过由于Flask什么也不带,我们需要专门的REST框架。所以相继出现了 flask-restful 、Flask-RESTPlus、flask-api等框架,另外在Rest服务中,会需要数据验证、解析和规范等需要,也出现了Marshmallow、Webargs和APISpec,一直到Flask-apispec。但是整个发展过程中没有出现一个足够好的能够对标DRF的Flask REST Framework。 而到这个阶段,Flask的缺点其实也暴露了。 Flask本来的优点是灵活性和极简主义,但这意味着很多很多组件需要自己造,这个要不然需要公司够大专门有开发者开发和维护,要不然得个人能力极强,否则插件很难达到生产级别,这就造成Flask的第三方插件质量层次不齐,且无法保证长期维护。就像我上面说的那些库,现在来看,其中已经很多不再维护了。 所以即便是今天,你想用Flask构建一个API服务,还是要东拼西凑各个组件,其中某些组件有些没及时更新的地方要自己动手解决,这对于老手来说还好,对于新人来说很痛苦,尤其是你想要应用现在最新的实践方案和理念,只能望而兴叹。 Asyncio生态 从Python3.5开始,asyncio已经是未来的趋势了。所以开始出现了一些原生支持asyncio的Web框架,如aiohttp、Starlette和sanic。 这个时候Flask并不想接受改变,社区迟迟的不加入aio的支持,另外Flask原作者也去写rust了,把项目交给了2个维护者(现在只剩一个人了)。 而用于构架API服务的项目例如apistar,molten。它们都给FastAPI的带来了设计灵感。 FastAPI 接着就是诞生FastAPI了。作者本来也是想找到一个好的解决方案,但是以上种种都是自己的问题或者说局限性,所以作者就造了这个轮子。 FastAPI为什么能成为统治者 这篇文章的核心部分啦,这些理由也是为什么FastAPI会替代Flask的原因。 异步设计 在Flask的那个时代,代码执行是单线程、同步的,这意味着要依次处理请求,前一个请求完成前,其他请求消耗在等待 I/O 操作上。而asyncio是最好的解决方案,它让I/O成为异步操作,无需等待任务完成即可获取任务结果并继续处理其他任务请求。 而FastAPI天生支持并发和异步代码,代码写对了就可以在效率上达到极致,所以它被认为是目前最快的Python框架,效率和NodeJS或Go接近。当速度和性能至关重要时,FastAPI 是最佳选择。 使用Pydantic做用户数据验证 […]