用惯了 django 改用 flask 有感

[marco25]

django 就像 mac

• 完成度高，开箱即用
• 但是因为开箱即用，有时并不会去了解太底层的东西
• 自带或者第三方的 package 的质量都不错，admin 秒 flask-admin 好几条街
• 文档极其好

flask 就像 linux

• 理论上可以自己自由搭配需要的 package，但是如果要全部达到 django 自带模块的功能或者标准，估计需要海量时间，就像要把 linux 配置的长得像 mac，只要花时间还是能做到的
• 由于需要定制的东西比较多，所以逼着你了解他底层的机制，就像学 linux 难免要了解一些硬件或者 os 的底层机制
• 文档过于简单（这个缺点 linux 好像没有）

[est]

flask 吹过头了。

[echo1937]

我把 Django 看作是 Python Web 开发的一种最佳实践的集合。

[Abbeyok]

各有所爱吧，反正我用 flask 用着挺好

[Takamine]

如果是为了把 Linux 配置成 Mac 却还选用 Linux 的话，不是自己想要重新造轮子就是闲出屁了。:doge:

[whoami9894]

没怎么用过 Django，不过感觉 flask 的周边 package 大多都是开箱即用，没太大硬伤

[lynskylate]

django+drf crud 开发效率实在太高了，flask 自定义起来更方便，代码写的实在太巧妙了。

[janus77]

我怎么两年前听说的是这样的说法：flask 开箱即用简单需求，django 适合复杂大型系统
？？？

[kxiaong]

刚把公司之前的一个 flask 老项目用 django 重写。

用 flask，ORM 就是绕不开的一个坑。sqlalchemy 虽然强大，却隐藏了不少坑。 除非经验丰富，否则用 sqlalchemy 就是找虐。

最喜欢的还是 django 的 ORM， 开箱即用，简单明了。框架约束多，可以保证新手不留烂坑。

高手可能有自己的想法，但是 python 本身就足够灵活，在框架选择上，还是尽可能保守一些更好。

[rainmakeroly]

记得好像 Flask 的文档应该算是比较详细的了 。

[troywinter]

曾经用 flask 写过两年的 production 级服务，自己组织了代码的分层架构，用装饰器实现相应的依赖注入，实现了 clean architecture 的六边形架构，对 sqlalchemy 也做了各种封装，感觉对于定制需求很多的人来说很合适。

自己定制可以实现更好的正交性，和 DDD 相结合，各个模块之间可以更合理的组织，曾经公司新来的同事再看到我写的项目之后都会很惊喜，认为我组织的项目结构很好的反应了业务的关系，让他们很好接手（ PS 这几个同事是 Django 背景）。

了解底层机制无可厚非，这也是 flask 在设计时想要做的，我认为不懂 wsgi 这些 web 框架原理的是不合格的开发者，这些都是一年经验就能掌握的，相反的，如果框架做的大而臃肿，用户使用时不能理解设计的理念，api 设计没有正交关系，我觉得这并不好。另外，文档过于简单的话，我没体会到，本来就很小的框架，看文档我觉得所有 api 都讲解的很详细，除非你指那些扩展。

说到文档，记得有个笑话，The Django Documentation has more words than the Bible, and I know a whole lot of them by heart. 对不起，我大学四年 Bible 都没学完，Django 的文档实在看不完。

[marco25]

@troywinter @rainmakeroly flask 文档确实还 ok，但是和 django 比对新手的友好程度上还差不少。我碰 django 的时候连 http 基本的概念还不大清楚，也能完整地一步步跑起来。django 的文档不像文档，像是小说:-)所以你说的 more than bible 也是不夸张的。。。

[newdongyuwei]

做 web 开发追求生产效率就得上 full stack 的开发框架，用 flask 是自虐。sqlalchemy 也是渣渣。

[c00WKmdje2wZLrSI]

很小的项目的时候用 flask 倒是很爽，一个文件就解决了

[coolair]

@troywinter #10 很想学习学习你的依赖注入、六边形架构和对 sqlalchemy 的封装，有空写篇长博客介绍介绍吗？感谢。

[NoirStrike]

django admin 太香了...

[tonnycao]

@troywinter 可以分享一下架构吗？

[qq976739120]

系统稍微复杂点,django 的 orm 就不是优势了,很多时候都是各个库里做个简单查询,数据都是各种地方拼凑起来的,web 框架和 orm 做的并不多,那些 if else 用什么语言用什么框架写都一样,但是如果是个刚起步的小项目,django 的确帮你做好了很多优秀的封装,撸就完事了,而且 django 的文档真的业界标杆.

[Outliver0]

奔向 asgi

[cnanyi]

django admin 撸后台神器， 基本的 CRUD 包括 UI 都有了， 增加一些自定义功能也都有对应的方法，太香了

[rogwan]

@kxiaong SQLalchemy 会有哪些坑？

@newdongyuwei SQLalchemy 什么地方比较渣？

[37Y37]

站 Django，不得不说实在太好用了

[dzm]

做 web django ORM 和 admin 的配合几乎为所欲为,现成的东西太多了.

[mengzhuo]

bottle 表示这 flask 要叫爷爷

[crackhopper]

flask 比较玩具，底层并不代表优势（你咋不用系统 socket 编程？）。django 用的多了，仍然需要很深入了解，因为有对应组件的源码，所以反而更方便深入。其他方面就不多说了，简单来说，flask 适合做 demo，做产品级别应用并不省力气反而麻烦比较多。

[rogwan]

@mengzhuo 早先是 flask 的作者 A.R.提议 bottle 改，瓶子没鸟他，A.R.就自己搞了个 flask （烧瓶），烧瓶看上去是烧掉瓶子的意思

[matrix1010]

复杂的项目还是要上 Django, 有问题看源码就行。而且就算是 Django 也需要很多 package 支持，我最近就写了一个用来 cache/memoize 的: https://github.com/Yiling-J/django-cacheme

[mywaiting]

Ruby 圈有句话叫 You will end up reinventing Rails, in a horrible way. via /t/297504

用到 Python 上就是 You will end up reinventing Django, in a horrible way.

[lycbug666]

@troywinter #10 是否能分享一下?

[yanzixuan]

其实初学者真不建议 flask，因为 django 的规范能让你养成很多好习惯。

[janxin]

新人上手推荐 Django 吧，规范化对新人的规范作用很大，否则写出来的项目很容易就惨不忍睹了。而且从资料丰富度上 Django 还是最完善的。

对于老手，flask 充分给予了你定制的可能性，身负屠龙技，万物可屠龙

[dongxiaozhuo]

@rogwan 猜测其他楼层说的 sqlalchemy 的坑可能包含但不限于 orm session、复杂 sql 的问题。

sqlalchemy 如果使用 orm 操作数据库时默认使用事务，并且会引入一个 sqlalchemy session 的概念，与 db 的 connection 有区别，sqlalchemy 的文档推荐在 web 框架中做到 request context 级别的管理。如果直接 flask + sqlalchemy，如果没有手动回收 session，会出现过多事务未提交的错误，重启应用能释放这些未提交的事务。flask-sqlalchemy 使用 flask 的 app context 机制做了 orm session 在 request context 级别的回收。

复杂 sql 的问题，不管是 orm 层还是 core 层（ sql ）都会显的特别难受。复杂场景下，只能通过代码规范来限制 sql 拼接在代码不同层级的扩散。

---

关于本帖重点讨论的 Django 和 Flask 都只是轻量级的使用过，这两点好处自然不必说了。说说最近处理的问题。

最近一次处理 Django 的问题是，Django 的配置问题，Django 使用 import module 的方式获取变量，遇到了架构中使用了配置中心下发配置的情况，就显得非常尴尬。

最近一次处理 Flask 的问题是，从 Flask 迁移到其他框架时，业务代码中使用到的全局变量 g，结合业务的使用起来，迁移到其他框架 or 语言时，就要再造一次全局安全的 g 或者转换业务的实现形式。


这两个问题都是框架特有的使用方式与业务场景的绑定导致的问题，
---
个人理解：适当的使用框架但是不要被框架绑定了。

[tiedan]

用 django 如果业务流量大的话，记得换掉 django 自带的数据库连接池换成 sqlalchemy 的

[Hopetree]

小服务（个位数接口）使用 flask 比较好，在公司经常用 flask 搭建一些小服务，就提供单个功能，一个文件就搞定了，这并不是说 flask 不适合大型项目，只是说 flask 相较于 django 来说更便捷。如果涉及后台和用户管理的，flask 想想就麻烦，而 django 已经帮你弄好了

[lolizeppelin]

django/flask 都没用过

照楼上说法,比 flask 更轻量的 pecan 之类别活了

[rogwan]

> 如果直接 flask + sqlalchemy，如果没有手动回收 session，会出现过多事务未提交的错误，重启应用能释放这些未提交的事务。

@dongxiaozhuo 这里是不是理解反了？（源码中自动在每一次请求上下文之后，会自动 remove 啊）

----------------------------

@app.teardown_appcontext
def shutdown_session(response_or_exc):
if app.config['SQLALCHEMY_COMMIT_ON_TEARDOWN']:
if response_or_exc is None:
self.session.commit()

self.session.remove()
return response_or_exc

[dongxiaozhuo]

@rogwan 你发的这段代码时 flask-sqlalchemy 这个库里面做的事情，如果直接使用 flask 配合 sqlalchemy 就不会处理这一部分。

[rogwan]

@dongxiaozhuo 我没注意看你分别写的是 flask + sqlalchemy 和 flask-sqlalchemy -:)

[zhuangzhuang1988]

django 好。

[troywinter]

@coolair
@lycbug666

之前一直没有整理这块的架构，等我写好了分享一下，哈哈

其实总体思想就是 web 框架层，业务层和持久化层分开，不互相依赖使得它们可以轻易被替换，因为开发过程中我用了 TDD，所以每个模块必须是 decoupled，不然没法测试，然后其他的模块会有一些想 policy engine 负责对实际运营需求有不同的 policy，还有一些对接第三方服务，使得它们都可以轻易测试。

对于上面提到的 sqlalchemy 的问题，我觉得按照文档来就行了，文档提供了比较好的方向性的指点，比如 session 是 request 级的，不会被共享，我的方法是用 decorator 创建 session，诸如到 controller 中，其它的依赖注入比较类似，动态语言里真的好舒服。

[charlie21]

反正都是 API caller，用啥都一样。自己写一个 flask 用阿

[impl]

不是还有个叫 tornado 的，没人用了现在？

[encro]

flask,laravel,gin,vue 等等，核心思想是粘合剂，所以灵活、起步容易、约束少，适合人少的小型项目，或者有则良好开发水平和自我约束能力团队的中大型项目。
django,yii,ror,springboot,angular 等等，核心思想是最佳实践+约定，所以起步难，开发效率高，约束多，适合中大型团队，因为写代码都是一个样子的。
从维护性，学习编程思想，个人提高上来说，建议团队上后者，个人项目上前者后者都行。

[ClericPy]

走 asgi starlette 以后腰不酸腿不疼

[Luxurious]

@impl 有啊, 俺公司的一个标注平台就是 tornado

[belingud]

@tiedan 能否请教一下原因？

[lowman]

@rainmakeroly 你是我见到过的第一个说 flask 文档消息的................

[sazima]

我用的 django rest framework 的时候, 把 setting 文件里的 admin session auth user 什么的全注释掉了.

[frostming]

如果我选择 django, 仅因为两种原因：DRF, djang admin

除此之外，这两种因素并不重要时，我会选 flask

[linlance]

哎，楼主说的很对啊。
Flask 在开发小东西的时候很好用，但是一个用户权限设置，就麻烦透了。。。
其他都得自己搭建，半天出不了东西，着急，
目前正在从头看 django 了。。。