本文目录导航：
从Flask到FastApi
上次咱们曾经拿到了FastApi体验卡，并且搭建了一个demo服务。说好的要开局学 FastApi ，那怎样能从入门到丢弃呢？
所以我稍稍看了一下文档，理了一下他外面的途径。
所以这篇文章可以算是私货吧，由官方文档加上团体了解组成。
我计划先完善比拟关键的性能，剩下的到用到的时刻再 切换 就行了。
为了繁难大家能从Flask无缝切换到 FastApi ，我也经过必定的通常，联合自己的名目特地编写了这篇文章，或者有些中央没有思考到，宿愿大家见谅。文章有点点长，可以不用一口吻看完~留着前面啃也可以！
咱们之前会给Flask的 app （pity）初始化一特性能:
其实性能 还有 一种用法，就是间接引入Config类，应用Config.字段去失掉性能项，所以咱们在原名目外面取性能的方法都要修正。
Flask 允许跨域 很繁难，引入CORS，将app套出来即可。
其实FastApi也不难，其中官方就有对应的例子:
经过引入FastApi自己封装好的CORSMiddleware，即可到达一样的成果。
首先导入uvicorn库，而后经上来运转对应的 app ，我经常提到的app，其实是一个FastApi的实例的概念。
只管我给他取名叫 pity ，但是我有时刻也会叫他 app ，宿愿不要给大家带来困扰。
留意，我这边run方法接受了4个参数，host和port就不多说了，dddd。
reload呢，就是热降级的意思。
至于app=main:pity，main代表的是这个文件的名字: ，pity也就是app的名字。
main:pity 即代表以后要启动的是main外面的pity。
至于为什么要这么复杂，归根结底还是这个 reload 参数，为了能热降级，它须要这些消息，不然会报错:
所以，都是被逼的。
其实这个不太属于这块内容，由于有的人甚至没有用到这个模块。
用sqlalchemy的同窗可以跳过哦！
其实处置方法呢，就是换成sqlalchemy。
所以咱们须要依照sqlalchemy的格局去编写ORM。
可以看到我这边读取链接URL，是经过Config来间接失掉的。
结构函数可不变，Use类承袭的对象就是models/ init 外面的base类，须要留意的是: sqlalchemy须要 tablename 这样一个字段，所以咱们须要给它加上， 它不会自动生成，不加就报错 。
其余中央基本上没有差异。
以 注册用户 为例，改写方法是去掉以前的 _by() ，改为 (User)_by() ，其余的时刻差距不大。
留意为什么要用，由于with口头终了之后会智能调用 exit （），也就是会智能 封锁session 。
FastApi呢，和Pydantic启动了强强联合，只管这一块我还摸得不是很清楚，不过我临时可以用起来了。
先看下旧版本的， 人肉校验器 :
新版本的话，等于说是把参数校验和业务逻辑 解耦 了，参数校验放到另外的中央去编写，接口外面只担任处置业务逻辑即可。
新版本接口:
一切的外围都在于这个 UserDto
可以看到，咱们为UserDto类指定了4个字段，由于都是 必填项 ，所以未加上自动值，假设咱们须要email是 非必填 的，则要改成:
接着就是详细的校验方法了，由于咱们的校验规定很繁难，所以对 一切字段 都是采取的一个方法:field_not_empty
意思是字段不能为空字符串，否则抛出ParamsError，留意这个 ParamsError 是我自定义的失误类型，它承袭了ValueError。
但是这个字段呢，是pydantic帮助校验好的，所以咱们须要减少这么一个方法:
这个方法是针对恳求参数校验失败的处置，相似于一个hook，只要恳求参数校验失败了，才会走到这个步骤。
只管外面失误消息多，但是咱们只取第一条失误消息，不然数据多了展现不繁难。
接着咱们定义了一个失误字典，目前允许 missing , params （自己封装的),not_allowed (参数类型不分歧)
这样就成功了参数的校验了！
在http恳求里，接口分类是很关键的事件，所以蓝图这块咱们不能跳过，咱们粗略讲一下。
其实flask外面咱们也只是用来给url分组，那咱们这里也成功一样的事件就好了。
APIRouter约等于Blueprint，创立一个APIRouter实例，prefix即url的前缀。
编写接口的时刻从改为/get即可，变动不大。
由于我这里只变革了user下的router，所以其余的未include出去。
(2022年10月)新名目选用django还是fastapi?
在选用新名目的框架时，思考诸多起因，包含名目需求、团队相熟度、社区允许以及常年保养性。
关于指导者而言，通常介绍经常使用成熟的框架，以确保名目的稳固性和可裁减性。
因此，假设我是指导者，我会优先思考经常使用 Django 或 Flask。
这两款框架领有丰盛的处置计划和资源，能够满足多样的开发需求，为团队提供强有力的技术允许。
FastAPI 作为一个相对较新的框架，以其繁复高效的设计和注解 API 模式，吸引了泛滥开发者。
但是，值得留意的是，FastAPI 的某些性能可以经过 Django 的 ninja 库成功，例如极速的 API 开发。
这象征着在某些场景下，经常使用 Django 依然能够成功 FastAPI 的长处，同时享用 Django 更成熟的生态系统。
面向简历编程时，选用 FastAPI 或者是一个吸引雇主留意的选择，尤其是关于寻求展现自己经常使用现代技术才干的开发者。
FastAPI 的特性，如基于 OpenAPI 的智能生成文档和更繁复的代码格调，能够在面试中给面试官留下深入印象。
不过，假设名目需求触及到异步编程，Django 4.0 也提供了经过 ASGI（异步主机网关接口）来允许异步性能的才干，这雷同是一个吸引点。
综上所述，选用 Django 还是 FastAPI 并非相对，取决于名目详细需求、团队技艺、常年保养思考以及团体偏好。
无论是 Django 还是 FastAPI，选用适宜的技术栈都是为了更好地服务于名目自身，确保高效、稳固地成功指标。
在决策环节中，充沛思考这些起因，能够协助团队做出最适宜名目的框架选用。
django、flask、fastapi,python后端哪个更好?
Django因其片面的工具集，为开发者提供了方便，但性能方面并非最佳。
关于性能敏感的运行，或者不可到达现实形态。
这种工具集的就义，体如今性能上，关于谋求高性能的名目或者不太实用。
但是，Django在构建资讯类网站时展现的便利性，使得其在特定场景下依然表现杰出。
假设名目需求与Django的原生性能符合，那么其长处就显得尤为显著。
在复杂业务后盾搭建时，假设Admin Form性能无余，裁减老本相对较高，或者须要更多定制化上班。
Flask代表了组件松懈、设计繁复的格调。
它的设计初衷是提供尽或者中立的环境，让各个组件正交合成，这种思绪与Spring框架相似。
Flask的Pythonic格调和轻量化使其在CSDN AI团队中失掉运行。
Flask对业务代码的侵入较轻，但在性能方面预期不要太高。
关于寻求繁难、灵敏框架的名目，Flask是一个不错的选用。
FastAPI是协程技术在现代框架中的一种表现，充沛应用了Python 3.6及以上版本的异步特性，对现代互联网运维和架构技术提供了良好允许。
FastAPI和Tornado相比，无通常上的性能表现相似，均可到达每秒10k以上的QPS，属于高性能运行框架。
但是，施展协程框架的性能须要开发者熟练把握协程技术，并确保业务逻辑适配异步并发，这在通常中往往较为艰巨。
通常中，即使有少量经常使用Tornado或FastAPI的团队，其运行性能往往并不现实。
在找上班时，倡导开发者不要过于依赖特定框架，而应学习Flask和FastAPI等现代框架，同时把握Java、Go、Javascript等其余技术栈，提高自己的竞争力。
这不只能顺应极速变动的技术环境，还能拓宽处置复杂业务疑问的思绪。
关于开发者而言，灵敏多变的常识结构是常年开展和优化找上班的竞争力的关键。
