Sanic 源码阅读 - 基于 0.1.2

@xiaozizayang 根据一般源码解析的书，他们多是注释跟说明结合，你要有注释，同时要有说明这段代码如何被调用的说明。
比如一个请求的生命周期是怎么样的，加一个流程图说明这样子就更好了，对你对其他人都好。
增加跟其他框架的对比就可以知道这个框架的优势。到底是框架厉害，还是有水分呢？粗糙地使用 asyncio+uvloop 嫩股本你达到 benchmark 的水平呢。这些可能更有意义。
毕竟在读者看来，我压根就不知道你的 on_函数什么时候被调用。比如 http://tengine.taobao.org/book/这样的结构就甚好了

xiaozizayang

2017-12-21 11:54:46 +08:00

你说得有道理我也是说明和和注释相结合我是这样写的我把源码注释好了放在另外一个项目里我在文章中列出框架的执行路线，每个路线的函数的作用，若想知道这个函数具体代码以及代码的具体解释，这里我就会把我注释好的代码地址放在旁边，读者可以一边看我写的注释，一边追踪框架的运行路线

xiaozizayang

2017-12-21 11:55:35 +08:00

@neoblackcap

ManjusakaL

2018-01-08 16:26:31 +08:00

Sanic 现在看起来真的有点原地炸裂。。

xiaozizayang

2018-01-08 19:22:21 +08:00 via Android

@ManjusakaL 何出此言

ManjusakaL

2018-01-08 20:25:13 +08:00

@xiaozizayang
之前写过一篇文章
现在仔细看的话，第一不支持 ASGI/WSGI 想部署只能用它自己实现的 Gunicorn Worker，生产环境下经常玄学问题。
第二，就是内部耦合严重，写插件做扩展真是伤心事
第三，就还有一些细节的东西吧

ManjusakaL

2018-01-08 20:25:29 +08:00

http@s ://zhuanlan.zhihu.com/p/32518153

xiaozizayang

2018-01-09 09:26:04 +08:00

@ManjusakaL 1.我司有些服务将 flask 替换成 sanic 了不过都是接口服务感觉还可以压测同等条件下 sanic 比 falsk 快关于部署 docker 下直接裸跑没毛病，2.我只针对 requets 以及 response 的请求前后做些处理简单封装下就好并没有需求对处理过程进行重新的需求，可能不理解你的感受，看你文章中的关于 json 的 pr，何不针对错误封装个 response_handle()，出错就替换成你的 json dumps，3.你说的装饰器的那个其他问题，我觉得那个没毛病，你编写的函数默认其实就是一个装饰器包裹起来的异步函数 sanic 只看返回的函数，这样我觉得还灵活点

xiaozizayang

2018-01-09 09:27:19 +08:00

@ManjusakaL 我用 sanic 比较早不得不承认是有问题的记得年中那段时间还有安全问题等它慢慢完善吧