一起养成写作习惯！这是我参加「日新计划 4 月更文挑战」的第28天，点击查看活动概况。
FastApi相关总结
先说说感想
上一篇写到了迁移Flask到FastApi的注意事项，其实直到现在我都还不算真实运用过FastApi，也许我也没有资格写这种点评类的文章。不过我仍是想说点感想:
-
FastApi的一些材料还不是很成熟，不如Flask和Django的材料那么多。
所以，
不主张没有Flask或许Django或许其他web结构运用经历的用户第一时间上手FastApi。由于遇到问题会比较难处理，能查到的材料相对有限。但有问题可以试试去官网查找，一般都会有处理方案。 -
FastApi归于比较约束的结构，在某些当地操控得比较死，比方接口参数那里。下面我会提到。
也有烦恼
其实我今日抽空在研讨@permission装修器的替代方案，之前是经过修正接口的参数，经过装修器注入参数到kwargs的办法，获取到用户信息。
可是现在有个问题是，FastApi严格操控了你的接口参数，假如改变接口的参数，FastApi内部会直接跑出参数过错的反常。这就很让人苦恼，所以我开端研讨其他的办法:
-
完成login_required并不一定需要
装修器业界完成
判别用户是否登录的办法，包含FastApi引荐的也都是: 用中间件结合Request上下文来完成的。一直以来都是我野路子了，详细的做法我这里就不详说了，大约意思是一个HTTP恳求分为很多个阶段。画个草图:
在这些过程中，会遇到很多个Context，比方咱们的登录状态就应该放到恳求之前去做。假如校验经过，则调用下一个context，失利则直接回来RESPONSE。
用Flask类比的话就是@app.after_request()和@app.before_request()，这个都是我印象中的，我没有深化去运用到。放到FastApi里边就是以middleware的方式。
可是我不考虑这种做法，第一是太局限了，基本上会给许多接口都加上登录的约束，第二是没有对详细的用户权限进行整合，比方有的接口我希望管理员访问，有的接口希望普通用户就能访问。这种情况下，我仍是打算选用别的办法。
- Depends
其实在之前蓝图模块就有看到过这货，只不过不太清楚他是干嘛的。其实它完成的功能和上面的差不多，也是可以调整接口恳求的参数。
Depends会去帮你处理恳求参数里的信息，基本上它是这么用的:
这就是，我要的滑板鞋!现在问题就可以拆解为，读取request headers里的token字段，然后判别token是否过期等等。最终转换成用户信息，return出来~期间遇到反常，就回来对应的反常即可。
最终的用法
遇到参数问题
Depends承受的其实是一个函数，说是函数，可是它是根据目标是否完成了__call__办法来判别的，Depends适当所以在恳求履行之前调用了Depends里边传递的办法，所以咱们编写一个Permission类，完成__call__即可。
-
__init__办法
初始化把role的权限值赋给self.role
-
__call__办法
逻辑和之前的permission相似，先判别token是否为空，这边封装了2个exception，分别是认证失利和权限失利。
反常代码，承继了HTTPException。由于FastApi供给了全局监听Exception的办法，便利你处理自定义的反常，所以这就是咱们封装自定义反常的原因。
封装好的反常，经过@pity.exception_handler操控反常详细的输出，当是PermissionException或AuthException的时候输出对应的内容。
同步代码堵塞问题
当FastApi遇到同步代码（io堵塞，比方恳求其他人的接口，特慢那种），会堵塞整个服务，所以主张我们尽可能地运用异步库比方用aiohttp替换requests等，我们可以做个实验测验一下，运用time.sleep来模拟同步操作即可。接着就是可以多开几个worker，堵塞1个没关系，还有其他的worker在处理事情。
总结
来个首尾呼应吧，其实写到这里，我自己都一脸懵逼。这也就是我发现FastApi的一大问题，并不是它有问题，而是我有问题！有的东西我并不会用，没有的东西，还得自己写！所以也就对应了我之前说，为什么不主张我们没有基础的去挑战这个结构，这个结构它是20级的boss，新手村出来的伙计仍是先别打了！
后续虽仍是持续运用这个结构，但对于他共同的当地我就不深化去研讨了，尽管自己写插件这种方式很能训练人，可是那自己写插件我要你这个结构干啥呢？所以适宜的当地用适宜的武器，不能大炮打蚊子，也不能杀鸡用牛刀。
