说下我对这 python 这几种 web 模型的理解吧：

首先是 http server + wsgi server(container) + wsgi application 这种传统模型吧：
http server 指的是类似于 nginx 或 apache 的服务
wsgi server 指的是类似 gunicorn 和 uwsgi 这样的服务
wsgi application 指的是 flask django 这样的基于 wsgi 接口的框架运行起来的实例
最初这种模型只是为了方便 web 框架的开发者，不需要每个框架层面都去实现一遍 http server ，就增加了一个 WSGI 中间层协议，框架只要实现这个协议的客户端就可以，然后用 wsgi server 去实现 http 协议的解析并去调用客户端(wsgi application)。

为了方便开发，每个框架都内置了一个简易的 wsgi server ，为什么还要用专门的 wsgi server 呢？
wsgi 除了解析 http 协议以及 http 端口侦听外，还负责了流量转发以及 wsgi application 进程管理的功能。一般 wsgi 框架内置的 wsgi server 都是一个单进程，一次只能处理一个请求。而目的通用的 wsgi server(gunicorn, uwsgi)都至少支持 pre fork 模型，这种模型会起一个 master 来侦听请求，并启动多个 slave(每个 slave 是一个 wsgi application)， master 负责把请求转发到空闲的 slave 上。除了这种传统的基于进程的 pre fork 同步模型，不同的 wsgi server 也会支持一些其它模型，有基于线程的同步模型，也有基于 asyncio 的异步模型。

这种模型下怎样写异步代码呢？
1. 直接用传统的异步编程(进程，线程，协程)，虽然有些 wsgi server 支持 asynio 模型，但是这也需要用户所写的代码做相应的支持。这就导致了如果我们在 wsgi application 的时候不能随便使用线程和异步 IO ，如果用了就需要配置 wsgi server 使其支持我们自己的写法。因此为了使得我们缩写的 application 能部署在任意的 wsgi server(container)中，我们就只能写同步代码了。
2. 使用分布式异步编程，使用类似 celery 的方式，将需要异步处理的东西发送到 worker 去处理。

既然有了 wsgi server ，为什么还要有一个 http server 呢？
主要是因为 wsgi server 支持的并发量比较低，一般会用一个专门的 http server 来做一层缓冲，避免并发量过大时直接服务挂掉。


python 传统的这种 wsgi 模型，主要是为了方便框架开发者只需要专注框架层面，而非 http 处理层面。但这样却增加了服务部署的复杂度，需要同时部署和配置 http server 和 wsgi server ，如果想支持异步还要部署 worker ，而使用 tornado 或 go 开发的应用因为自己实现了高效 http 处理的应用只需要部署自己就可以了。


接下来是 tornado 和 twisted 这种模型：
这种模型和上面的传统模型处于一个时期，这种模型和 nodejs 差不多，都是基于回调的模型，适用于高 IO 低 CPU 的场景。这种模型自己实现了一个基于回调 http server(event loop)，每一个请求都被注册成一个异步函数来处理，然后主循环来不断的循环这些函数。这样就和 pre fork 模型有了区别， pre fork 模型中每一个 slave 都是一个 wsgi application ，一个 wsgi application 都只能处理一个请求，而回调模型只有一个线程，不仅极大的减少了内存的分配还减小了进城以及线程间的切换开销，从而可以支持高 IO 并发。但是这种模型也有很明显的缺点，就是一旦应用程序有大量的 CPU 计算，就会让这个线程堵住，所有的请求都会收到影响，如果应用在处理一个请求时崩溃，所有的请求也都会收到影响。


接下来时 aiohttp/sanic 这种模型：
这种模型和 tornada 模型的改进，但实质上是一样的，因为回调的写法不易读也容易出错，于是将回调的写法改成了同步的写法。这种模型和 koa2 和 go net/http 查不多， asyncio 提供了类似 go coroutine 的功能和写法，而 aiohttp 则提供了类似 go 中的 net/http 的 http 处理库。

看上去这些 view 并没有什么真正的业务逻辑，都是 model 驱动的普通的 CRUD ，这样的情况直接用 Django 的 generic views 就行不需要自己写 view 内容。

1

@DesignerSkyline youyongsong#gmail.com 求一枚，谢谢！

pattern match

youyongsong

@lycos 9.9 一个

3M 8210

怎么没人提CloudMagic Mail呢，这么良心的手机APP，自带代理不用考虑被墙的问题了，而且推送还快。

楼主你这个算是scaffolding或generator吗?可以考虑用结合cookiecutter(https://github.com/audreyr/cookiecutter)这样的工具来搞，cookiecutter是《two scoops of django》作者写的非常好用，作者还用cookiecutter写了一个django的template叫cookiecutter-django(https://github.com/pydanny/cookiecutter-django)楼主可以看一下啊。我觉得generator这种东西，每个人喜欢的最佳实践还有使用的工具链都不完全相同，应该每个人或团队都有一个自己习惯的generator。

@donghouhe 可以看一下数码荔枝做的两款GIF软件的评测： https://www.v2ex.com/t/189618#reply20

再具体一点应该是用ModelForm, https://docs.djangoproject.com/en/1.8/topics/forms/modelforms/ ,话说楼主连django的核心部件之一Form都不知道就写程序真的好吗。

「React (web端)」

Incredible http://blog.leapoahead.com/incredible/ 一个用Node webkit开发的七牛的图形客户端，好像目前只支持mac