WEB后端：现有框架模式是否已经过时？未来又会如何？

1,018 views
Skip to first unread message

fy

unread,
Jun 27, 2017, 1:13:48 PM6/27/17
to pyth...@googlegroups.com
在 2015、2016 两年前端的狂飙突进之后，工具链已经成熟、本轮框架大战也基本落下帷幕的前后端分离、单页应用的趋势已成定局。我想在这个过程最不适应的大概就是ROR还有Django这样的重型框架了。我也很难想象两年前的自己还一度羡慕 rails4 的单页动态加载（turbolinks）。

而事实上，直至今天虽然我手上的前端技术栈发生了很多变化，后端仍然是 tornado + peewee/sqlalchemy 的老一套，靠着自己写的一个脚手架 fpage 疯狂续命。（https://github.com/fy0/fpage 这个项目已经服役了很久而且至今仍在用，只是现在一般创建完项目直接就把template删除掉），很久没更新因为大致也没什么可改的了。

估计 flask 的情形大致也类似吧。

但是最近写项目的时候总是觉得很不爽，曾经的后端是MVC三层，现在V移除了，剩下MC两层，我慢慢也觉得C层显得多余了。

现在逻辑基本上都在前端写了，那后端留下什么呢？我认为在 Model 层上面加上权限控制、条件查询、数据校验以及分页功能就完全足够了。

我设想极端情况下开发者直接写了 Model 之后就可以自动生成对应的各种 API 而且是拥有一切权限，这样可以快速完成初始原型。后面逐渐再加各种数据校验和限制等等。

一个探索性的想法，不知道现在有没有现成的库做了这方面的工作呢？
如果没有的话，我打算自己做一个demo看看效果，底层 http 库初定 aiohttp （性能更好的同时不再打算兼容python2），不知道有没有更好的选择。

--
我的github: http://github.com/fy0



peng yu

unread,
Jun 27, 2017, 1:28:37 PM6/27/17
to pyth...@googlegroups.com
转go啊。。开发效率高，水平scale

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

fy

unread,
Jun 27, 2017, 1:32:03 PM6/27/17
to pyth...@googlegroups.com
> 转go啊。。开发效率高，水平scale

go 能解决上面这个问题？
--
我的github: http://github.com/fy0



peng yu

unread,
Jun 27, 2017, 1:48:49 PM6/27/17
to pyth...@googlegroups.com
现在上规模的架构都是走微服务了

chao huang

unread,
Jun 27, 2017, 3:22:53 PM6/27/17
to pyth...@googlegroups.com
postgrest满足一切需求。

MuSheng Chen

unread,
Jun 27, 2017, 9:15:56 PM6/27/17
to pyth...@googlegroups.com
"我设想极端情况下开发者直接写了 Model 之后就可以自动生成对应的各种 API 而且是拥有一切权限，这样可以快速完成初始原型。后面逐渐再加各种数据校验和限制等等。"

这点可以看下odoo，你绝对值得拥有，用它的后端就行了，其它的忽略它吧，还有就是只支持python2。

Stephen Zhang

unread,
Jun 27, 2017, 9:50:46 PM6/27/17
to pyth...@googlegroups.com
这个分析蛮有意思的。

我在想，前后端分离，原本的目的是让前后端的开发人员可以解耦，前端开发人员只关注前端技术，后端开发人员只关注后端技术。我对“前端”原本的理解就是HTML、CSS（以及操作HTML、CSS的JS）之类，也就是MVC里面的V。

但是，实际情况是，现在前端也开始做业务逻辑了。所以，前端已经不是简单的V了，这导致对前端开发者的技术栈要求有了提升，以前只需要会HTML、CSS就够了，现在不行，现在需要能写业务逻辑的JS。在写业务逻辑上，我认为对技能的要求，前端和后端是没有区别的。

对于这种前端技术栈方面微妙的变化，我很好奇背后的原因是什么。是因为前端技术人员能力提升了？还是因为有许多后端开发者转做前端了？又或者是其他原因，比如客户端的性能在不断提升，所以许多业务逻辑都放到客户端做，从而减轻服务器的负担？

不过，不管是哪种原因，我认为虽然前后端的框架的界限开始变得很明显，但是技术技能的界限却变得更模糊了。前后端开发者的区别，似乎只是所用的语言不一样，（编程）能力上的差别越来越小。

说到这里，我觉得，也许 RESTful 就是在设定一个前后端的界限。后端负责数据逻辑，前端负责业务逻辑。就是说，后端的视角是资源，是描述资源的数据，前端的视角是操作这些资源的逻辑。因此，我觉得，RESTful 也许就是其中一个你说的“做了这方面工作的现成的库（思路）”。

不知道我的理解是否跟你的想法一致。

2017-06-28 1:13 GMT+08:00 fy <fy0...@gmail.com>:

bigzhu

unread,
Jun 27, 2017, 10:44:01 PM6/27/17
to pyth...@googlegroups.com
回归正常的开发模式而已.

传统的 BS 开发, 用一种语言(PHP java python ruby .....), 通过字符串拼接成另一种语言(html css js), 再显示交互, 本来就是种很不合理的变态模式.

10 年前的 flash/flex, 早就是前后端分离了, 只不过不是运行在浏览器, 而是跑在 flash 客户端上的程序, 能力上绝对比现在的"前端" 要强, 只是硬生生给各大厂商弄死了......

现在做 SPA 开发, 用 python 也多是写写 CRUD, 做一些权限和安全上的控制, 业务逻辑大都放在前端了, 后端的这些 API 写起来, 是有点雷同和体力活的感觉, 自已也用 tornado 想写个可配置的通用 API, 但很难保证灵活性的同时又省去麻烦且好维护. 最后还是放弃了.

有人写了postgrest可以从表生成可 CRUD 的 API, 可权限控制上做的很可怕. 用下来还不如直接用 python 写 API 的方式方便.

上面说的用 odoo 的 API, 还是个不错的思路呢. 不过这货实在太庞大, 太慢了, 学起来不容易吧?
--

fy

unread,
Jun 27, 2017, 10:59:57 PM6/27/17
to pyth...@googlegroups.com
实际上我觉得 RESTful 的改变也有限，即使是从2011、2012年就开始说 restful，但是今天绝大多数还是 get/post 加逻辑的API服务器吧？

所以可能 restful 没有真正解决问题，只是换了一种命名接口的形式，对老web语言可能推动了变革，但像是 python / ruby 这种大概也不会比之前在用的方式更好。只是把写在这里的代码改到了那里而已。

PostgREST 感觉很6，虽然我确实是 postgreSQL 的用户，但我也希望 model 更为向上层，更抽象一些，这个深度耦合的模式还是太僵了。


我的github: http://github.com/fy0



MuSheng Chen

unread,
Jun 27, 2017, 11:05:14 PM6/27/17
to pyth...@googlegroups.com
只用odoo的api的话很简单，只写model就行了，权限可以慢慢加规则。
由于绑定太多所谓解决方案，安装东西有点多，但也点不了太多空间，如果你不用那些功能的话，对速度也没影响。

Yunfan Jiang

unread,
Jun 27, 2017, 11:06:13 PM6/27/17
to pyth...@googlegroups.com
确实如此  甚至连M和C也并不需要了 比如graphql 再比如aws lambda  后端大概要退后到各种redis/postgresql这个层面的开发了
不过还有个十年缓冲期吧

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
Name: yunfan
Site: http://geek42.info/
Interest:
  - Lang: [forth, clojure, c, python, lua]
  - software: [nginx, redis]
  - abstract: [vm, tiny, cloud, html5]
  - history
  - science-fiction
  - music: [new-age, vangelis, yanni]

黄其泽

unread,
Jun 27, 2017, 11:08:57 PM6/27/17
to pyth...@googlegroups.com
我觉得两个重要原因让前端JS的规模越来越大：

1. 用户对一个好的界面的要求提升了。一个输入是否合法的判断、排个序都要发送请求到后端才能搞定的页面，卡顿感肯定会让用户不满。
2. 专业化让程序更有时间折腾自己所在的领域。



在 2017年6月28日 上午9:50，Stephen Zhang <steph...@gmail.com>写道：



--
Python及Qt相关Blog：http://hgoldfish.com/

MuSheng Chen

unread,
Jun 27, 2017, 11:10:26 PM6/27/17
to pyth...@googlegroups.com
mc都不需要了？有人有过powerbuilder/delphi/c++builer么？Embarcadero欢迎你。

fy

unread,
Jun 27, 2017, 11:28:57 PM6/27/17
to pyth...@googlegroups.com
> mc都不需要了？有人有过powerbuilder/delphi/c++builer么？Embarcadero欢迎你。

这不是上古开发工具吗？我还是 delphi 入门呢，那时候还是borland旗下。但也跟mvc不相干吧，难道近年有什么新姿势？
我的github: http://github.com/fy0



panfei

unread,
Jun 28, 2017, 12:13:29 AM6/28/17
to 华蟒用户组
做前后端分离开发，如果后续部署也是分离的，现在Django基于Cookie认证就不能适应新情况了，需要自己实现一套。世界在不断变化～～
不学习，不知道

YS.Zou

unread,
Jun 28, 2017, 12:50:28 AM6/28/17
to pyth...@googlegroups.com
在 2017年6月28日 上午1:13，fy <fy0...@gmail.com>写道：
但是最近写项目的时候总是觉得很不爽，曾经的后端是MVC三层，现在V移除了，剩下MC两层，我慢慢也觉得C层显得多余了。

首先，我觉得 C 是省不了的，一方面是后端的，“数据” + “服务” 的现实情况，与 Rest 中的 “资源” ，经常差异还是很大的，而这些差异就需要 C 去处理。另一方面，对 “资源” 的操作本身是不固定的，远不止 “增删改查” 这么简单，这也需要 C 去处理。当然，你要说这些事我就要放在 M 中去做，那么也是一回事。

其实 V 这一层，在 “前后端协作” 方面有时是有关键作用的，只是，理解并控制好 “ html / css / javascript / json 不过是可以动态生成的字符串” 这一点，对很多人要求太高而已。

更说远一点，从，交互，体验这些方面来说， Web 跟桌面客户端的水准，还差得远得多。现在整个前端，工具，工程，这些领域连当初 Flash 的水准都达不到，更不用说 VisualStudio  这种怪物，某些方面要突破，方向我觉得还是前后端放在一起考虑才可能。

 

现在逻辑基本上都在前端写了，那后端留下什么呢？我认为在 Model 层上面加上权限控制、条件查询、数据校验以及分页功能就完全足够了。

当然不够吧，首先，权限控制什么的，不是 M 层的事。嗯，我个人的观点， M 层是状态无关的，而权限控制显示受限于 “当前用户”，“当前会话” 这些状态信息，我会放在 C 层做。

其次，后端的实际情况，在角色划分中，数据层面，现在更多的是 Model + Service ，后端服务给出是 “资源”，但是前期的包装整合还是有很多工作的。（Service 就不是 rest 那么简单了嘛， 状态，事务，retry，各种协议 事多了）
 

我设想极端情况下开发者直接写了 Model 之后就可以自动生成对应的各种 API 而且是拥有一切权限，这样可以快速完成初始原型。后面逐渐再加各种数据校验和限制等等。

一个探索性的想法，不知道现在有没有现成的库做了这方面的工作呢？


我做过这样的事：

我自己做后端的话，是 Tornado + SQLAlchemy ，简单情况下，一个 “资源” 可以对应 SQLAlchemy 的一个 Model ，按 Restful  的做法，我给一个资源定义 6 + 1 个预定义的方法： create delete update read list option + meta （使用 HTTP 的 GET POST DELETE UPDATE 那套东西来做 rest 我并不认同哈）

这里面的，  read list option + meta 几乎是可以通过简单配置类的代码就可以完成的，但是 create delete update 还是要写具体的实现。

具体来说，我有一个 RestHandler 的基类（示例代码在最后），在做具体资源时，只需要：

class MyResourceHandler(RestHandler):
    def get_query(self):
        q = self.session.query(Model).filter(Model.status.in_(Model.STATUS_NORMAL))
        if 'id' in self.p: q = q.filter(Model.id == self.p.id)
       return q

这些， read list 方法就可以用了。

对应的 URL 配置是：

    ('/api/my-resource(/[^/]*?)?', MyResourceHandler),

使用时，就是 /api/my-resource/read , /api/my-resource/list 这种了，反正是一套规则。

最开始的时候，我还会有一个 meta 方法，它返回的东西大概是：

    META = {
        'name': u'文章',
        'baseUrl': SELF + '/ec/article',
        'help': '',
        'waterMark': '',
        'field': [
            {'id': 'id', 'name': u'主键ID', 'type': 'input', 'asPrimary': True},
            {'id': 'title', 'name': u'标题', 'type': 'input'},
            {'id': 'content', 'name': u'内容', 'type': 'richtext'},
            {'id': 'topic', 'name': u'专题', 'type': 'select-ajax', 'option': SELF + '/ec/topic/option'},
            {'id': 'create', 'name': u'创建时间', 'type': 'date'},
            {'id': 'user', 'name': u'用户', 'type': 'select-ajax', 'option': SELF + '/ec/user/option'},
            {'id': 'status', 'name': u'是否已删除', 'type': 'checkbox'},
            {'id': 'count', 'name': u'生成几篇', 'type': 'input'},
            {'id': 'topic_title', 'name': u'专题名', 'type': 'input'},
            {'id': 'img', 'name': u'配图(满比例5:4)', 'type': 'image', 'width': '120'},
            {'id': 'intro', 'name': u'摘要', 'type': 'textarea'},
            {'id': 'is_favorite', 'name': u'当前用户是否关注', 'type': 'checkbox'},
            {'id': 'author', 'name': u'作者名', 'type': 'input'},
            {'id': 'html', 'name': u'HTML代码', 'type': 'textarea'},
        ],
        'filter': ['title', 'topic'],
        'action': [
            {'id': 'random', 'name': u'随机生成每个话题下的文章', 'type': 'general-extra', 'params': ['count'] },
            {'id': 'random_comment', 'name': u'生成评论', 'type': 'target-extra', 'params': ['count']},
            {'id': 'favorite', 'name': u'收藏', 'type': 'target'},
            {'id': 'set_html', 'name': u'设置HTML内容', 'type': 'target-extra', 'params': ['html']},
        ],
        'disableDelete': False,
        'disableCreate': False,
        'createDisplay': ['title', 'author', 'create', 'topic', 'user', 'img', 'intro', 'content'],
        'updateDisplay': ['title', 'author', 'topic', 'img', 'intro', 'content'],
        'listDisplay': ['id', 'user', 'title', 'author', 'topic_title', 'create', 'img', 'intro', 'status'],
        'defer': ['content'],
        'listLink': ['title'],
    }


通过对 “列位” 的配置，对过滤器，额外方法等的定义与声明，前端就可以 0 代码出一个后台页面了，大概是这个样子：

http://os8q5ytom.bkt.clouddn.com/29f49c81ac294cecb9e45bb31bff6927.jpg



后来觉得 META 信息后端维护太麻烦，就不要了，前端自己维护就好了。

当然，这套东西，得到 “原型” 级别的后台页面可以，但是，哪怕需要一点点更好的交互体验，都很麻烦。所以，我后来就不管 meta 什么，页面都放前端一个一个做就好了。 /resource/action 这套规则下，统一的资源服务是确定的，前端对应的组件包装也很容易，即使一个一个做对应的页面，也是分分钟钟的事，还不怕改。因为页面本来就是分开的，任何对前端交互的需求，想做就做。

最后，后端其实只要能提供足够的“元”信息，所有页面，都通过前端可视化配置完成，是很容易做的（后端维护这套元数据，也通过前端的同样一套可视化工具完成）。而我现在遇到最大的问题就是，当你在一个前后端分离的团队，前端做前端的事，后端大部分完全不懂前端，连统一的 rest 风格都是奢望的情况下，更别想后端有对资源“元”信息如何提供服务的概念啦。 这也回到我最开始说的：

> 某些方面要突破，方向我觉得还是前后端放在一起考虑才可能。



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

RestHandler 大概的样子：

class RestHandler(BaseHandler):
    SUPPORTED_METHODS = ('GET', 'POST')

    DEFAULT_PAGE = 1
    DEFAULT_PER_PAGE = 10
    MAX_PER_PAGE = 100
    TEMPLATE = None

    def get_query(self): raise Exception('not implemented')
    def get_option_query(self): raise Exception('not implemented')
    def create(self): raise Exception('not implemented') 
    def delete(self): raise Exception('not implemented')
    def update(self): raise Exception('not implemented')
    def is_post_method(self, action): return action in {'create', 'update', 'delete'}
    def get_template_args(self): return {}
    def permission(self): self.finish({'code': -1, 'msg': u'没有权限'})
    def prepare(self): super(RestHandler, self).prepare(); self.permission()
    def list_filter(self, q): return q
    def list_defer(self): return []

    @tornado.web.asynchronous
    def get(self, action):
        if not action:
            self.render(self.TEMPLATE, **self.get_template_args()) if self.TEMPLATE else self.send_error(404)
            return

        action = action[1:]
        if self.is_post_method(action): self.send_error(403)
        else: getattr(self, action)()


    @tornado.web.asynchronous
    def post(self, action):
        if not action: self.send_error(404); return
        action = action[1:]
        getattr(self, action)()


    def get_page_and_per_page(self):
        ... 
        return page, per_page

    def list(self):
        ...
        p = {
            'count': count,
            'page': page,
            'perPage': per_page,
            'isCount': is_count,
            'itemList': obj
        }
        self.finish({'code': 0, 'data': p})


    def read(self):
        ...
        self.finish({'code': 0, 'data': obj.dict()})


    def option(self):
        ...
        self.finish({'code': 0, 'data': p})






--
进出自由才是游戏者的生存之道。

http://www.zouyesheng.com

beck917

unread,
Jun 28, 2017, 12:59:20 AM6/28/17
to pyth...@googlegroups.com
cookie可以的,别自己实现

任何http客户端,都有完整的cookie实现

panfei

unread,
Jun 28, 2017, 1:57:21 AM6/28/17
to 华蟒用户组
主要是绕过浏览器的同源策略，并不是说要自己写程序去访问后端接口。

jianxiao jiang

unread,
Jun 28, 2017, 3:10:05 AM6/28/17
to pyth...@googlegroups.com
bottle这样的就够用了, 我们的erp现在代码已经超10万行, web就几百行代码, 主要作用就是将请求转换为restful服务. 后面都是应用服务器层面的事情了

性能的问题更多的在于调用层次, 一上手就用django这样的我认为是有害的, 调用层次太多, 举个例子

sqlalchemy orm- sqlalchemy sql expression - raw sql  就是典型的三个层次, 性能差距很大, 比方说很多人用golang 写raw sql, 然后大呼, 性能出色, 其实就是....

再打个比方说, django的自动事务管理, 这肯定是会有性能问题的, 连接应该尽早释放, 事务时间应该尽可能的短, 但如果一开始依赖这种机制, 后面改就麻烦了

所以我一看到使用django, 但又要强调请求数的公司, 就会自动的回避

chao huang

unread,
Jun 28, 2017, 9:54:24 AM6/28/17
to pyth...@googlegroups.com
MVC模型的如果继续简化，要么保留C，要么保留V和M。在mobile first的年代，V最重要，不能动。
就像楼主说的权限控制、条件查询、数据校验以及分页功能，如果M层可以实现，那就可以简单的拿掉C了，剩下V和M。

Stduolc X

unread,
Jun 28, 2017, 9:42:43 PM6/28/17
to python-cn(华蟒用户组,CPyUG 邮件列表)
django怎么会不适应.老哥你想多了吧.用用 django rest framework再加上guardian 或者自己写权限处理的部分.只会更好用.毕竟App的模式,而且原生做了mvc分层.要随便去掉view层还是很方便的.去掉ctrl层也不是不行.

在 2017年6月28日星期三 UTC+8上午1:13:48，fy写道：

Stduolc X

unread,
Jun 28, 2017, 9:46:02 PM6/28/17
to python-cn(华蟒用户组,CPyUG 邮件列表)
直接自动扫描model,注册api.相加什么,新建个model.api就有了.就用了django的restframework. 
  def get_model_serializer(model_class):                                                                                                                                                     
      tmp_name = re.split('\W', str(model_class))                                                                                                                                            
      tmp_name = tmp_name[-3]                                                                                                                                                                
      serializer_name = tmp_name + 'Serializer'                                                                                                                                              
                                                                                                                                                                                             
      class Meta:                                                                                                                                                                            
          model = model_class                                                                                                                                                                
          fields = get_model_fields(model_class)                                                                                                                                             
                                                                                                                                                                                             
      serializer = class_factory(serializer_name, [],                                                                                                                                        
                                 OpsApiSerializer,                                                                                                                                           
                                 **{'Meta': Meta})                                                                                                                                           
      locals()[serializer_name] = serializer                                                                                                                                                 
      return locals()[serializer_name]                                                                                                                                                       
                                                                                                                                                                                             
                                                                                                                                                                                             
  def get_model_view_set(model_class):                                                                                                                                                       
      tmp_name = re.split('\W', str(model_class))                                                                                                                                            
      tmp_name = tmp_name[-3]                                                                                                                                                                
      fields_name = get_model_fields(model_class)                                                                                                                                            
      query_view_set_name = tmp_name + 'ViewSet'                                                                                                                                             
      queryset = model_class.objects.all()                                                                                                                                                   
      serializer_class = get_model_serializer(model_class)                                                                                                                                   
      query_view_set = class_factory(query_view_set_name, [], OpsApiBaseViewSet,                                                                                                             
                                     **{'queryset': queryset,                                                                                                                                
                                        'serializer_class': serializer_class,                                                                                                                
                                        'lookup_field': 'id',                                                                                                                                
                                        'lookup_fields': fields_name,                                                                                                                        
                                        'model': model_class})                                                                                                                               
      return query_view_set                                                                                                                                                                  
                                                                                                                                                                                             
                                                                                                                                                                                             
  def set_model_api(model_class):                                                                                                                                                            
      model_set = get_model_view_set(model_class)                                                                                                                                            
      tmp_name = re.split('\W', str(model_class))                                                                                                                                            
      tmp_name = tmp_name[-3]                                                                                                                                                                
      router.register('{0}'.format(tmp_name), model_set, tmp_name.lower())                                                                                                                   
                                                                                                                                                                                             
                                                                                                                                                                                             
  def register_url():                                                                                                                                                                        
      models = load_models()                                                                                                                                                                 
      map(set_model_api, models)                                                                                                                                                             
                                                                                                                                                                                             
  register_url()

peng yu

unread,
Jun 28, 2017, 9:49:30 PM6/28/17
to pyth...@googlegroups.com
django本身是MVT吧

Peng Dai

unread,
Jun 28, 2017, 11:18:04 PM6/28/17
to python-cn(华蟒用户组,CPyUG 邮件列表)
我觉得很大一部分原因是为了把实现经可能后推。java模式里经常会强调建立接口，把具体实现后推，来做的比较好的结偶和扩展性。前后端分离和部分业务逻辑推到前端也有这方面的考虑。

YS.Zou

unread,
Jun 29, 2017, 1:20:57 AM6/29/17
to pyth...@googlegroups.com
在 2017年6月28日 上午9:50，Stephen Zhang <steph...@gmail.com>写道：
对于这种前端技术栈方面微妙的变化，我很好奇背后的原因是什么。是因为前端技术人员能力提升了？还是因为有许多后端开发者转做前端了？又或者是其他原因，比如客户端的性能在不断提升，所以许多业务逻辑都放到客户端做，从而减轻服务器的负担？

1. 前端领域，因为 nodejs 的原因，有了很多配套的预处理工具，也有了像 es6 这些有新能力的“语言”，还有像 angularjs / react  这些新的框架。结果就是，前端对整个环境的控制能力有了非常大的提升。换句话说，5年前你要做一个“复杂”的页面，开发可能需要花 5 分力，维护它需要花 8 分力。现在开发花 3 分力，维护花 2 分力。总结就是前端生产力提升了。

2. 浏览器进化。兼容性这类问题，现在已经不太为前端领域关注了，相反，浏览器提供了什么新的特性，给前端带了什么新的可能性（比如 AR ，地理位置，本地存储），成为更流行的话题。这跟以前只考虑怎么把页面做出来，还是有很大不同的。总结就是，前端有新的可能性了。

3. 招人难，前端这块还能细分出去，那么如果可能，随带就招几个专职前端也能给业务带来好处啊。总结就是，能招到干活的人。

4. 前后端分工方面，如果以前是用“编译语言”的技术的，前后端搞在一起，效率太低。那些技术不像 Python ，要改页面，刷新一下就完事。想想，就改个页面至少要花几秒到几十秒重新编译部分项目，太让人绝望了。但是，前后端完全分离，就完全没有这个问题了。但是如果你本来就是 Python 这种，还能一人前后端都做的话，那么实际上前后端分离是会大大降低开发效率的（但是对维护方面有好处）。总结就是，提升团队开发效率。


上面几点是共同作用的哈。

> 不过，不管是哪种原因，我认为虽然前后端的框架的界限开始变得很明显，但是技术技能的界限却变得更模糊了。前后端开发者的区别，似乎只是所用的语言不一样，（编程）能力上的差别越来越小。

你想多了。不信的话，你随便拉几个前端问问，看有几个能把 HTTP 协议说清楚，有几个会写 SQL ，有几个能熟练使用正则表达式，有几个能把字节和字符概念分清楚的。再多说一点，前端项目的结构（这也是人设计的话），你试试看能不能从身边找出来一个项目，虽然技术在不断变化，但是它的项目结构过了 5 年还不过时的，还能照样顺利维护的。（整个前端领域，好像除了 jQuery 就没有在时间上经得住考验的吧，但是现在很多用新框架的人却在排斥 jQuery ，呵呵）

客观讲，前端环境因为资源性质各异（html, css, js），还全是异步调用（连模块加载都要异步），js 语言本来又挫又弱，要统一整合好，难度确实是更大。但是当你面对一个觉得 js 这个语言牛逼得不得了的人时，说什么都是徒劳的。










--
进出自由才是游戏者的生存之道。

http://www.zouyesheng.com

fy

unread,
Jun 29, 2017, 3:05:10 AM6/29/17
to pyth...@googlegroups.com
> django本身是MVT吧

没错，不过两种是一回事。我自己日常也是用的MVT(model view template)，为了大家好理解说MVC
--
我的github: http://github.com/fy0



fy

unread,
Jun 29, 2017, 3:20:19 AM6/29/17
to pyth...@googlegroups.com
> 4. 前后端分工方面，如果以前是用“编译语言”的技术的，前后端搞在一起，效率太低。那些技术不像 Python ，要改页面，刷新一下就完事。想想，就改个页面至少要花几秒到几十秒重新编译部分项目，太让人绝望了。但是，前后端完全分离，就完全没有这个问题了。但是如果你本来就是 Python 这种，还能一人前后端都做的话，那么实际上前后端分离是会大大降低开发效率的（但是对维护方面有好处）。总结就是，提升团队开发效率。

我也觉得这个很蛋疼，不仅要在两个shell中分别开前后端，然后改两下前端，改两下后端。十分痛苦，但是前端的工具链太好又无法舍弃。后来改为先写后端API，写完写tests，跑通之后就可以不管后端狂写前端，效率提升很多。但仍然免不了来回切换。

所以我也希望能从后端这部分解放出来。


--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
我的github: http://github.com/fy0



YS.Zou

unread,
Jun 29, 2017, 3:48:00 AM6/29/17
to pyth...@googlegroups.com

在 2017年6月29日 下午3:19，fy <fy0...@gmail.com>写道：
我也觉得这个很蛋疼，不仅要在两个shell中分别开前后端，然后改两下前端，改两下后端。十分痛苦，但是前端的工具链太好又无法舍弃。后来改为先写后端API，写完写tests，跑通之后就可以不管后端狂写前端，效率提升很多。但仍然免不了来回切换。

是这样的。因为全是服务没有前端应用场景，验证的事只能交给测试用例，其实想想，这也算是一个额外的收益了。
否则，有页面的话，验证的事因为有前端应用，测试用例能省就省了。


--
进出自由才是游戏者的生存之道。

http://www.zouyesheng.com

阮明辉

unread,
Jun 29, 2017, 8:34:55 AM6/29/17
to python-cn
最主要的原因应该是app的普及吧  服务器的api同时要兼顾web端和app端

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
Thanks & Regards,
ezioruan = {
        'email':'qiaoq...@gamil.com',
        'interests':{ 'Python',  'Linux' 'game'},
        'location':'南京',
        'website':'http://ezioandnanjing.appspot.com/',
        'note':'功名利禄身外物,知足常乐总逍遥'
        }

YS.Zou

unread,
Jun 29, 2017, 9:47:49 AM6/29/17
to pyth...@googlegroups.com

在 2017年6月29日 下午8:34，阮明辉 <qiaoq...@gmail.com>写道：
最主要的原因应该是app的普及吧  服务器的api同时要兼顾web端和app端

不是的， 我们所有项目都是前后端分开的，但是，即使个别项目有多端的需求，服务可能还是多套的（当然在非 HTTP 层，后端的代码可能是一套）。

至于为什么会这样，我觉得跟项目有产品经理们的参与是分不开的。算了，不黑他们了。


--
进出自由才是游戏者的生存之道。

http://www.zouyesheng.com

vicalloy

unread,
Jun 29, 2017, 9:17:50 PM6/29/17
to pyth...@googlegroups.com
很早之前看过ROR的文档，在ROR里需要返回HTML还是JSON是在URL里指定的。
但就我对Django的使用经验，REST和普通的WEB要想完全公用一套代码实际上还是有难度的。
目前看到的一些传统的WEB应用的REST API实现基本上都是同WEB页面的实现独立的。

我觉得前后端分离主要还是方便协作以及测试。
另外web技术发展到现在，单页面应用越来越成熟，也没法完全用传统的方法来实现。

Ken

unread,
Jun 29, 2017, 10:31:38 PM6/29/17
to pyth...@googlegroups.com
>> 但是最近写项目的时候总是觉得很不爽，曾经的后端是MVC三层，现在V移除了，剩下MC两层，我慢慢也觉得C层显得多余了。
V 和 C 的确没有明显的分界线，千人千面，团队内难以明确统一标准，甚至有人会在 Model 写点逻辑，这样代码共用程度好一点。我(大胆的)以为控制失当的 MVC 害人不浅，所以划分功能还要看使用的框架和业务和团队来定，能让团队明确执行的就是好方法，能控制工程质量的就是好方法。我写的代码一般就2层, Model + View，如果需要跨模块共用，直接用 Model，或者在 Model 上加一个子类，封装功能，连 cache 也在这个子类里。

>> 现在逻辑基本上都在前端写了，那后端留下什么呢？
SPA 应用的确风靡好久了，前提是得有好的前端架构师，否则工程质量堪比多页面。如果是 SPA，我以为服务器端有个好的 REST 接口，支持最小完整的增删改查，我们有个实际工程给每个Model就一行代码:

rest.create_api(models.Series)

框架是 Flask, flask_restless + sqlalchemy, 当然中间有个 cache 层，这样代码就很少很少了。少并不代表后端没有价值了，反而正是后端的价值。

>> 一个探索性的想法，不知道现在有没有现成的库做了这方面的工作呢？
肯定有，Flask 就是如此，当然得有其他库辅助才可以。Django 天下一统，自然 Flask 被忽略也是正常。

Django 和 Flask 是两个思维极端的产物。Django 是封闭大而全，但是很多事情都做不到最好。我罗列一下
  • 曾今有人给 Django 加上 SQLAlchemy，但是作者多少年了就是没有采用，在邮件组里说没有必要。
  • 没有人不吐槽 Django 的模版吧，连 +1 都做不了，如此简单的模版，性能应该领先吧，事实不是这样，好多独立的库都能超越这货。
  • 其强大的 Admin 的确可以很容易做出一个后台，但是根据业务定制简直苦不堪言。

Flask 秉承小而精，组合强大插件然后强大。当然作者能力也是一个因素，itsdangerous, markupsafe, click 几个库也是惊艳异常。让每个组件在社区环境下独立发展，大部分都能脱离 Flask 都有广泛用途。


我举个实际例子，公司有个庞大的后台(编辑人员、管理人员使用)，有内容管理、各种配置、统计，菜单项有上百。我们采用了 flask_admin + sqlalchmey 能解决部分不需要太多定制的页面，用 template 定制前端、后端 view 处理，能很好组合进 flask_admin。在这个架构之前有过好多尝试，乐呵大家一下：

  • PHP 页面堆，两个框架加各种轮子飞了几年就不多说
  • Django admin，一个18年经验的 Pythoner 指导，用 Python 类输出 HTML，各种分栏眼花缭乱，一个新人A写一个业务花了一周，最后还不干了。
  • Django xadmin 配置，国人的轮子，成熟度很高，一个10年Pythoner主导开发，为了各种定制，把xadmin代码都翻烂了，其他人难以帮忙。
  • 轮到 Angular SPA 上场了，3年JS工程师主导，新人A配合，一个5张表的业务写了一个月，等我去看时服务器有60个接口，前端有数千行JS加HTML若干。第二个尝试换了个写了18年PHP的工程师主导，一个月下去出了几千行代码，还不稳定，业务要求都达不到。这个业务后来换 flask_admin和HTML，总共1K代码全部搞定。
  • flask_admin + html 下一个.Net转过来的程序员2月搞定大部分业务。

并不是要嘲笑这些人，我对每次尝试的人都心怀感激，至少我能知道这个团队搞不定这个方案。


换语言是个更大的坑，每种语言用好了都能最低成本解决问题。
我换语言的考虑如下：
  • 公司最好只养一个语言的团队，不会出现大部分都使用 PHP，然后因为算法再搞一个 Python 团队。我不相信有全栈工程师每个领域都能做到最好，大部分这类‘大神’也是皮毛师傅，并不能做到业界顶尖。团队大了也不会出现明争暗斗。
  • 至少该语言能很快招到人，且素质不会低于平均水准，招个数据结构都不懂的程序员是自找麻烦。
  • 每个业务不是语言、框架、人能保证成功的，保证成功的是过程控制、单元测试、自动化部署、测试流程。没有单元测试说得天花乱坠是没有用的，某次更新可能就挂掉全部业务，让公司遭受严重损失。
  • 团队能掌控的方案才是好方案，某个人的特殊能力是绝对风险。
  • 花哨的、新的技术需要对应的人来掌控。譬如异步程序(go-lang)很难写。

数年没有写过这么多文字了，欢迎砖头。(个中提到的人请不要对号入座，我对大家心怀感激)。





在 2017年6月28日 上午1:13，fy <fy0...@gmail.com>写道：
在 2015、2016 两年前端的狂飙突进之后，工具链已经成熟、本轮框架大战也基本落下帷幕的前后端分离、单页应用的趋势已成定局。我想在这个过程最不适应的大概就是ROR还有Django这样的重型框架了。我也很难想象两年前的自己还一度羡慕 rails4 的单页动态加载（turbolinks）。

而事实上，直至今天虽然我手上的前端技术栈发生了很多变化，后端仍然是 tornado + peewee/sqlalchemy 的老一套，靠着自己写的一个脚手架 fpage 疯狂续命。（https://github.com/fy0/fpage 这个项目已经服役了很久而且至今仍在用，只是现在一般创建完项目直接就把template删除掉），很久没更新因为大致也没什么可改的了。

估计 flask 的情形大致也类似吧。

但是最近写项目的时候总是觉得很不爽，曾经的后端是MVC三层，现在V移除了，剩下MC两层，我慢慢也觉得C层显得多余了。

现在逻辑基本上都在前端写了，那后端留下什么呢？我认为在 Model 层上面加上权限控制、条件查询、数据校验以及分页功能就完全足够了。

我设想极端情况下开发者直接写了 Model 之后就可以自动生成对应的各种 API 而且是拥有一切权限，这样可以快速完成初始原型。后面逐渐再加各种数据校验和限制等等。

一个探索性的想法，不知道现在有没有现成的库做了这方面的工作呢？
如果没有的话，我打算自己做一个demo看看效果，底层 http 库初定 aiohttp （性能更好的同时不再打算兼容python2），不知道有没有更好的选择。

--
我的github: http://github.com/fy0



piglei

unread,
Jun 29, 2017, 11:03:02 PM6/29/17
to pyth...@googlegroups.com
大家讨论的观点都很多了，我刚好最近也在接触这块，顺手安利两个东西：

- webpack：配合一大堆 loader，直接写 ES6 代码，让我重新爱上写 JS
- vuejs：革新了我在 jQuery、Backbone.js 时代对交互开发的理解，提升生产力
- DRF：对 HTTP API 的开发抽象不一定适合你的项目，但是绝对值得了解


est

unread,
Jul 2, 2017, 4:27:03 AM7/2/17
to pyth...@googlegroups.com
sql 自带 view，权限管理，sql 就是微服务。json protobuf 什么的都是异端。


timger™

unread,
Jul 2, 2017, 4:43:39 AM7/2/17
to pyth...@googlegroups.com
我一直觉得 ,如果数据库足够牛逼了 是否架构会简单很多,比如谷歌的 F1
我们还需要这么多分布式架构吗?

est <electr...@gmail.com>于2017年7月2日周日 下午4:26写道：
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
--
timger

YS.Zou

unread,
Jul 2, 2017, 1:13:36 PM7/2/17
to pyth...@googlegroups.com

在 2017年7月2日 下午4:26，est <electr...@gmail.com>写道：
sql 自带 view，权限管理，sql 就是微服务。json protobuf 什么的都是异端。

PG 还可以用各种语言写存储过程，现在就差一个 http 代理了？


--
进出自由才是游戏者的生存之道。

http://www.zouyesheng.com

beck917

unread,
Jul 3, 2017, 4:45:51 AM7/3/17
to pyth...@googlegroups.com
讨论这个的结果就是...

大家都失业了,js全包了

--

luzi

unread,
Jul 3, 2017, 9:36:29 AM7/3/17
to pyth...@googlegroups.com

你是说作一个每天只有100人访问的网站吗？

bosby j

unread,
Jul 3, 2017, 10:06:56 AM7/3/17
to pyth...@googlegroups.com
100人访问也是个小型系统啦，小公司内部用着妥妥的。

Stduolc X

unread,
Jul 5, 2017, 9:40:13 AM7/5/17
to python-cn(华蟒用户组,CPyUG 邮件列表)
influxdb 就是json化的rest服务。

在 2017年7月2日星期日 UTC+8下午4:27:03，est写道：

panfei

unread,
Jul 5, 2017, 1:08:15 PM7/5/17
to 华蟒用户组
Elasticsearch应该也可以看成同样的东西。与kibana这个纯前端的一结合中间不需要后端专门处理逻辑。简单和可预见的情形可以适应，但是复杂的情形还是需要中间有个后端服务来处理（当然也可以取到数据后在前端处理，但是前端的性能是个需要考量的点，前端最好只做渲染显示的工作；再者后端可选的模块比较丰富、稳定）。
不学习，不知道

Mengyang Li

unread,
Jul 5, 2017, 6:25:15 PM7/5/17
to pyth...@googlegroups.com
couchdb?
>>>>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>>>>>> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>>>>>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>>>
>>>>>
>>>>> --
>>>>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>>>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>>>> ---
>>>>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>>>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>>>>> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>>>>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>>
>>>>
>>>> --
>>>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>>> ---
>>>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>>>> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>>>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>
>>>
>> --
>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> ---
>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>
>
>
>
> --
> 不学习，不知道
>
> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。



--
Best regards,
ᶘ ᵒᴥᵒᶅ
Mengyang Li

fy

unread,
Jul 5, 2017, 9:18:24 PM7/5/17
to pyth...@googlegroups.com
前几天想了一个大概，正在慢慢磨
内嵌图片 1


couchdb?
>>>>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>>>>>> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>>>>>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>>>
>>>>>
>>>>> --
>>>>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>>>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>>>> ---
>>>>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>>>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>>>>> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>>>>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>>
>>>>
>>>> --
>>>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>>>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>>>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>>>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>>>> ---
>>>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>>>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>>>> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>>>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>>>
>>>
>> --
>> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
>> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
>> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
>> ---
>> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
>> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。

>> 要查看更多选项，请访问https://groups.google.com/d/optout。
>
>
>
>
> --
> 不学习，不知道
>
> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。



--
Best regards,
ᶘ ᵒᴥᵒᶅ
Mengyang Li
--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。



--
我的github: http://github.com/fy0



Ken

unread,
Jul 6, 2017, 12:26:34 AM7/6/17
to pyth...@googlegroups.com

Guo Jing

unread,
Jul 6, 2017, 12:46:17 AM7/6/17
to python-cn(华蟒用户组,CPyUG 邮件列表)
最近我也在考虑这个问题，我们现在的选型基本上就是后面用 es 做高可用存储了，中间用什么语言不重要，基本上透传，前端可以处理大部分逻辑。至于权限控制什么的，找一个 nginx + lua 来写也不是不行了。

当然招人会有一些问题，不过中间这一层是用 Python 还是 Java 还是 Go 不重要了。本身 es 的性能也不错。所以后端要做的事情真正的减少了。

但我觉得有一个好的地方是，真正的能力不仅仅是一些数据处理（C 的能力），而是一些数据抽象的能力，这个对任何一种程序员的发展都好。还有，程序员有更多机会站在其他位置，如产品业务。

est

unread,
Jul 6, 2017, 4:40:24 AM7/6/17
to pyth...@googlegroups.com
的确如此。现在后端api基本就是包装db的api + 权限认证 这一块了。

叶俊青

unread,
Mar 15, 2018, 2:12:34 AM3/15/18
to python-cn(华蟒用户组,CPyUG 邮件列表)
我是一个运维，虽然会写一些前端的代码（js还好，比较讨厌写html和css），但还是尽量避免写前端代码，于是，在做一个数据维护相关功能的时候（增删改查）设计了一套通用的增删改查系统
对于一个表数据的维护功能，只需要在后台配置一下相关的sql模板就可以创建一个新的页面，对于单表，只需要写select语句，delete insert update都可以在后台配置表名和主键名称 自动生成sql，也可以自定义复杂一点的sql
同时实现了权限管理，感觉和楼主的想法差不多

在 2017年6月28日星期三 UTC+8上午1:13:48，fy写道：
在 2015、2016 两年前端的狂飙突进之后，工具链已经成熟、本轮框架大战也基本落下帷幕的前后端分离、单页应用的趋势已成定局。我想在这个过程最不适应的大概就是ROR还有Django这样的重型框架了。我也很难想象两年前的自己还一度羡慕 rails4 的单页动态加载（turbolinks）。

Zoom.Quiet

unread,
Mar 15, 2018, 3:40:27 AM3/15/18
to CPyUG~华蠎用户组
此坟挖的够狠...
的确: encode/apistar: A smart Web API framework, designed for Python 3. 🌟
https://github.com/encode/apistar
现在都是自动化接口生成了...
> --
> 邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
> 规则: http://code.google.com/p/cpyug/wiki/PythonCn
> 详情: http://code.google.com/p/cpyug/wiki/CpyUg
> 严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
> ---
> 您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。



--
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!

fy

unread,
Mar 19, 2018, 5:31:52 AM3/19/18
to pyth...@googlegroups.com
是老坟了啊！正文中提到的探索项目，我本来以为会在2017年搞定的，至今还是不稳定的状态。


目前实现的部分包括：常规CRUD、分页、外键和软外键查询、基于用户的权限控制、Session等等……

对应的驱动号称是peewee + asyncpg，实际上目前只有 peewee 正确工作。


实际的编写过程中造了一个实验性的项目（一个社区程序，vue.js + python后端）

表权限的例子在这里：


View的例子：


对应Model：



前端用起来这个画风：





总之业余时间也有限，花了不少时间在里面。

目前不仅没文档，遇到事情也是逢山修路遇水搭桥的状态。



> 要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
> 要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
> 要查看更多选项，请访问https://groups.google.com/d/optout。



--
life is pathetic, go Pythonic! 人生苦短, Python当歌!
俺: http://zoomquiet.io
授: http://creativecommons.org/licenses/by-sa/2.5/cn/
怒: 冗余不做,日子甭过!备份不做,十恶不赦!
KM keep growing environment culture which promoting organization learning!
--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。



--
我的github: http://github.com/fy0



Tian

unread,
Apr 9, 2018, 10:53:10 AM4/9/18
to pyth...@googlegroups.com
我们做企业内部应用的。并不打算走向SPA的方式（不能说死，也可能少数地方会用）。现在的前端项目感觉侵入性太强，一搞就是一整套全得按他的来（这是题外话，不是我们不选择SPA的理由）

从企业应用这端来看是希望尽可能多的业务逻辑收缩到后端，除去V， C都不太应该有业务逻辑，剩下M一层放业务逻辑是不太够的。smart ui 在DDD中属于反模式

Linker

unread,
Apr 16, 2018, 7:06:19 AM4/16/18
to pyth...@googlegroups.com
就前端技术发展来说,最大的趋势是,游戏引擎化.
不论React还是vue,本质上都是使得前端更像是一个游戏,而不是传统的网页了.
如果考了wasm的发展,这个趋势就更加的明显了.
websocket替代http/ajax,使得http退化成static file service,也是一个趋势.

最终,浏览器发展成为一个新的操作系统.



2017-06-28 1:13 GMT+08:00 fy <fy0...@gmail.com>:
在 2015、2016 两年前端的狂飙突进之后，工具链已经成熟、本轮框架大战也基本落下帷幕的前后端分离、单页应用的趋势已成定局。我想在这个过程最不适应的大概就是ROR还有Django这样的重型框架了。我也很难想象两年前的自己还一度羡慕 rails4 的单页动态加载（turbolinks）。

而事实上，直至今天虽然我手上的前端技术栈发生了很多变化，后端仍然是 tornado + peewee/sqlalchemy 的老一套，靠着自己写的一个脚手架 fpage 疯狂续命。（https://github.com/fy0/fpage 这个项目已经服役了很久而且至今仍在用，只是现在一般创建完项目直接就把template删除掉），很久没更新因为大致也没什么可改的了。

估计 flask 的情形大致也类似吧。

但是最近写项目的时候总是觉得很不爽，曾经的后端是MVC三层，现在V移除了，剩下MC两层，我慢慢也觉得C层显得多余了。

现在逻辑基本上都在前端写了，那后端留下什么呢？我认为在 Model 层上面加上权限控制、条件查询、数据校验以及分页功能就完全足够了。

我设想极端情况下开发者直接写了 Model 之后就可以自动生成对应的各种 API 而且是拥有一切权限，这样可以快速完成初始原型。后面逐渐再加各种数据校验和限制等等。

一个探索性的想法，不知道现在有没有现成的库做了这方面的工作呢？
如果没有的话，我打算自己做一个demo看看效果，底层 http 库初定 aiohttp （性能更好的同时不再打算兼容python2），不知道有没有更好的选择。

--
我的github: http://github.com/fy0



--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
Regards,
Linker Lin
linker...@gmail.com

fy

unread,
Apr 20, 2018, 2:27:24 AM4/20/18
to pyth...@googlegroups.com
> 我们做企业内部应用的。并不打算走向SPA的方式（不能说死，也可能少数地方会用）。现在的前端项目感觉侵入性太强，一搞就是一整套全得按他的来（这是题外话，不是我们不选择SPA的理由）

> 从企业应用这端来看是希望尽可能多的业务逻辑收缩到后端，除去V， C都不太应该有业务逻辑，剩下M一层放业务逻辑是不太够的。smart ui 在DDD中属于反模式

这其实是一种对后端的绑架。

当年做传统后端的时候，就不得不考虑css整合压缩，js打包混淆，资源部署，移动端/服务端API等等问题。

后来前端工具部分解决这些问题的时候，一开始还不觉得优势很大。但前端是热门领域，后面各路公司和开发者拼命堆资源，越做越好，最终觉得收益大于更换体系的成本了，也无力用Python来重新实现一遍这些工具链，所以就只有追着大势所趋、所谓潮流了。

可能企业应用其实更重服务而甚于交互吧，但是大的趋势是相反的。

我的github: http://github.com/fy0



chenh...@gmail.com

unread,
Apr 20, 2018, 10:27:00 AM4/20/18
to python-cn(华蟒用户组,CPyUG 邮件列表)
反正最后都会回来的.
model还有graphql呢.
前端还在ssr呢.
总体上来说就是一个操作接口和显示层的分离.
至于显示层,你喜欢jinja还是js.数据结构你是rpc还是函数调用.看情况呗.

在 2018年4月20日星期五 UTC+1上午7:27:24，fy写道：

依云

unread,
Apr 22, 2018, 11:47:33 AM4/22/18
to pyth...@googlegroups.com
On Mon, Apr 16, 2018 at 07:05:30PM +0800, Linker wrote:
> 就前端技术发展来说,最大的趋势是,游戏引擎化.
> 不论React还是vue,本质上都是使得前端更像是一个游戏,而不是传统的网页了.
> 如果考了wasm的发展,这个趋势就更加的明显了.
> websocket替代http/ajax,使得http退化成static file service,也是一个趋势.
>
> 最终,浏览器发展成为一个新的操作系统.

让我想起这个视频了：
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
The Birth & Death of JavaScript

--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
https://blog.lilydjwg.me/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

Linker

unread,
Apr 22, 2018, 12:05:55 PM4/22/18
to pyth...@googlegroups.com
@依云 很有趣的视频～

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了 Google 网上论坛的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。

管策

unread,
Apr 23, 2018, 1:20:17 AM4/23/18
to pyth...@googlegroups.com
我现在主要用 JS/TS/NodeJS，随着社区的发展，凡是可以用 JS/TypeScript移植的都会移植过来。

目前 JS 生态中缺像 Django 这样的成熟框架，这种缺失在开发最小可行性产品时影响会有点，但也不是特别大。而且现在的确是稍微有点规模，就会考虑拆成微服务，语言也不重要。

其他像科学计算、机器学习库都在开始往 JS 生态引入。

运维我现在基本是用 Docker，基本不用 python。



您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
管策
君子博学而日参省乎己，则知明而行无过矣。

chenh...@gmail.com

unread,
Apr 23, 2018, 1:36:11 PM4/23/18
to python-cn(华蟒用户组,CPyUG 邮件列表)
科学计算可见将来还是c++/python的。。。。js要补的生态还是不少的。
说是在引入不过目前也就tf.js和mx.js跑在asm.js上。。
实际情况还是复杂的多的。等各种js库都能充分利用wasm吧。

在 2018年4月23日星期一 UTC+1上午6:20:17，ithinco写道：

bosby j

unread,
Apr 24, 2018, 10:16:44 AM4/24/18
to pyth...@googlegroups.com
js写起来没python舒服。es6时代之前，写个大型的库还是很麻烦的。

Yunfan Jiang

unread,
Apr 24, 2018, 10:05:29 PM4/24/18
to pyth...@googlegroups.com
es6 => ... => esN => .. => pythonN
Name: yunfan
Site: http://geek42.info/
Interest:
  - Lang: [forth, clojure, c, python, lua]
  - software: [nginx, redis]
  - abstract: [vm, tiny, cloud, html5]
  - history
  - science-fiction
  - music: [new-age, vangelis, yanni]

郁夫

unread,
May 3, 2018, 8:57:21 PM5/3/18
to python-cn
Delphi 转 Python，主要是从C/S 转向了 B/S 。

在 2017年6月28日 上午11:10，MuSheng Chen <sheng...@gmail.com>写道：
mc都不需要了？有人有过powerbuilder/delphi/c++builer么？Embarcadero欢迎你。

2017-06-28 11:05 GMT+08:00 Yunfan Jiang <jyf...@gmail.com>:
确实如此  甚至连M和C也并不需要了 比如graphql 再比如aws lambda  后端大概要退后到各种redis/postgresql这个层面的开发了
不过还有个十年缓冲期吧

在 2017年6月28日 上午1:13，fy <fy0...@gmail.com>写道：
在 2015、2016 两年前端的狂飙突进之后，工具链已经成熟、本轮框架大战也基本落下帷幕的前后端分离、单页应用的趋势已成定局。我想在这个过程最不适应的大概就是ROR还有Django这样的重型框架了。我也很难想象两年前的自己还一度羡慕 rails4 的单页动态加载（turbolinks）。

而事实上，直至今天虽然我手上的前端技术栈发生了很多变化，后端仍然是 tornado + peewee/sqlalchemy 的老一套，靠着自己写的一个脚手架 fpage 疯狂续命。（https://github.com/fy0/fpage 这个项目已经服役了很久而且至今仍在用，只是现在一般创建完项目直接就把template删除掉），很久没更新因为大致也没什么可改的了。

估计 flask 的情形大致也类似吧。

但是最近写项目的时候总是觉得很不爽，曾经的后端是MVC三层，现在V移除了，剩下MC两层，我慢慢也觉得C层显得多余了。

现在逻辑基本上都在前端写了，那后端留下什么呢？我认为在 Model 层上面加上权限控制、条件查询、数据校验以及分页功能就完全足够了。

我设想极端情况下开发者直接写了 Model 之后就可以自动生成对应的各种 API 而且是拥有一切权限，这样可以快速完成初始原型。后面逐渐再加各种数据校验和限制等等。

一个探索性的想法，不知道现在有没有现成的库做了这方面的工作呢？
如果没有的话，我打算自己做一个demo看看效果，底层 http 库初定 aiohttp （性能更好的同时不再打算兼容python2），不知道有没有更好的选择。

--
我的github: http://github.com/fy0






--
××××××××××××××××××××××××
西安——深圳——上海
××××××××××××××××××××××××

郁夫

unread,
May 3, 2018, 9:19:34 PM5/3/18
to python-cn
Docker 和 python 有替代性？

icebird

unread,
May 3, 2018, 9:58:42 PM5/3/18
to Python.cn@google
十几年从事前端的人员来回复一下这个问题。

首先第一个问题，mvc是否过时？答案当然是否定的。前端由于各种原因，现在激进的想要把所有业务逻辑工作全部包揽，但事实上这是不可能的事情，至少对于数据加密和服务端的验证是不可能被取缔的，大数据的计算整合也必须在服务端进行，前端所能作的业务逻辑方面的工作其实是一些对安全性要求不高的部分，所以C绝不可能从服务端移除，而且前端直接连接restful api的做法安全隐患极大，未来肯定会有越来越丰富的中间逻辑层对数据层的api进行封装加工。至于v的部分，确实有很大一部分工作由于js框架的狂野发展而不再需要由服务端进行template的处理，但现在出现一个很有趣的趋势是为了seo和加载运行效率，又开始进行首屏数据服务端渲染的工作了。

其次，单页应用是否适用于所有场景？答案也是否定的。现在的前端有时一个页面的大小可以达到10M甚至20M的夸张程度，或许对于宽带和pc端来说问题不大，但对于移动端，它消耗的流量和耗电程度事实上已经超过了当年被乔布斯疯狂诟病的flash。几乎可以肯定的事情是，在未来肯定会想办法把这些离谱的东西重新拆开。到时在什么页面依赖哪些程序，恐怕还是得需要服务端进行处理。至于这个服务端使用的是node.js还是python或者是java/php，会出现什么样的新框架，那得看未来的发展。

其实这里有个最重要的问题，开发人员在面临这场变革的时候究竟需要做什么准备？从我在前端经历的这一场变革来看，更重要的是对基础语言的熟悉和掌握，以便无论出现什么样新的框架和技术，都能够快速掌握并应用于工作中。有了这样的基础，面对的变革不论是发展成什么样子，技术上都不会落于人后了。

郁夫 <szx...@gmail.com> 于2018年5月4日周五 上午9:19写道：
Docker 和 python 有替代性？

@依云 很有趣的视频～

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。
--
Regards,
Linker Lin
linker...@gmail.com

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。

要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
管策
君子博学而日参省乎己，则知明而行无过矣。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
××××××××××××××××××××××××
西安——深圳——上海
××××××××××××××××××××××××

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

fy

unread,
May 6, 2018, 3:41:18 AM5/6/18
to pyth...@googlegroups.com
> 前端直接连接restful api的做法安全隐患极大

我觉得这个能否展开说一下，在我看来restful把安全问题解决的很好，远比cookies方案好。cookies方案由于json接口很难加token进行二次校验，但是不加始终会有跨域提交的风险。但是restful中的access_token参数就很好地解决了这个问题，除非把用户自己把access_token丢了，但如果这个能丢，cookies肯定也没了。

> 在出现一个很有趣的趋势是为了seo和加载运行效率，又开始进行首屏数据服务端渲染的工作了。

服务端渲染貌似并不影响编码的方式，只是一些额外配置。但是工具链相对于传统MVC是全方位的进步了，我觉得这并不能说明传统方式的优越，而正相反说明了传统方式少数几个优越的地方也在被人积极地进行超越了。

> 现在的前端有时一个页面的大小可以达到10M甚至20M的夸张程度，或许对于宽带和pc端来说问题不大，但对于移动端，它消耗的流量和耗电程度事实上已经超过了当年被乔布斯疯狂诟病的flash。几乎可以肯定的事情是，在未来肯定会想办法把这些离谱的东西重新拆开。到时在什么页面依赖哪些程序，恐怕还是得需要服务端进行处理。

这个也不是很赞同，10MB、20MB我觉得只能是轻量级的页游了。大部分SPA页面不算图片能达到3MB我觉得就恐怖如斯了。事实上打包工具链也在进一步进步，你说的那个按需加载实际上很早就有了，自动模块拆分也是有的……


其实去年的时候我还不太确定，但现在可以看出趋势，大家确实是都在向着自动化CURD的道路上走。只不过不同的一点是，与我想的一个框架整合全部直接对接数据库不同，一部分项目是拆成了API服务 + 鉴权服务，以接口为单位进行权限校验。这看起来就没那么激进了。


icebird <iceb...@gmail.com> 于2018年5月4日周五 上午9:58写道：
十几年从事前端的人员来回复一下这个问题。

首先第一个问题，mvc是否过时？答案当然是否定的。前端由于各种原因，现在激进的想要把所有业务逻辑工作全部包揽，但事实上这是不可能的事情，至少对于数据加密和服务端的验证是不可能被取缔的，大数据的计算整合也必须在服务端进行，前端所能作的业务逻辑方面的工作其实是一些对安全性要求不高的部分，所以C绝不可能从服务端移除，而且前端直接连接restful api的做法安全隐患极大，未来肯定会有越来越丰富的中间逻辑层对数据层的api进行封装加工。至于v的部分，确实有很大一部分工作由于js框架的狂野发展而不再需要由服务端进行template的处理，但现在出现一个很有趣的趋势是为了seo和加载运行效率，又开始进行首屏数据服务端渲染的工作了。

其次，单页应用是否适用于所有场景？答案也是否定的。现在的前端有时一个页面的大小可以达到10M甚至20M的夸张程度，或许对于宽带和pc端来说问题不大，但对于移动端，它消耗的流量和耗电程度事实上已经超过了当年被乔布斯疯狂诟病的flash。几乎可以肯定的事情是，在未来肯定会想办法把这些离谱的东西重新拆开。到时在什么页面依赖哪些程序，恐怕还是得需要服务端进行处理。至于这个服务端使用的是node.js还是python或者是java/php，会出现什么样的新框架，那得看未来的发展。

其实这里有个最重要的问题，开发人员在面临这场变革的时候究竟需要做什么准备？从我在前端经历的这一场变革来看，更重要的是对基础语言的熟悉和掌握，以便无论出现什么样新的框架和技术，都能够快速掌握并应用于工作中。有了这样的基础，面对的变革不论是发展成什么样子，技术上都不会落于人后了。

郁夫 <szx...@gmail.com> 于2018年5月4日周五 上午9:19写道：
Docker 和 python 有替代性？

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。


--
我的github: http://github.com/fy0



Linker

unread,
May 6, 2018, 10:16:06 AM5/6/18
to pyth...@googlegroups.com
10MB大小的前端,长远看倒不是问题.


Docker 和 python 有替代性？

@依云 很有趣的视频～

要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要向此群组发帖，请发送电子邮件至 pyth...@googlegroups.com。
要查看更多选项，请访问 https://groups.google.com/d/optout。
--
Regards,
Linker Lin
linker...@gmail.com

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。

要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
管策
君子博学而日参省乎己，则知明而行无过矣。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
××××××××××××××××××××××××
西安——深圳——上海
××××××××××××××××××××××××

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

Linker

unread,
May 6, 2018, 10:17:51 AM5/6/18
to pyth...@googlegroups.com
我觉得,趋势可能是 发展一种通用的对象同步协议.
客户端/浏览器和服务器的通讯,只描述一件事:  一个对象的生老病死.


2018-05-06 15:40 GMT+08:00 fy <fy0...@gmail.com>:
> 前端直接连接restful api的做法安全隐患极大

我觉得这个能否展开说一下，在我看来restful把安全问题解决的很好，远比cookies方案好。cookies方案由于json接口很难加token进行二次校验，但是不加始终会有跨域提交的风险。但是restful中的access_token参数就很好地解决了这个问题，除非把用户自己把access_token丢了，但如果这个能丢，cookies肯定也没了。

> 在出现一个很有趣的趋势是为了seo和加载运行效率，又开始进行首屏数据服务端渲染的工作了。

服务端渲染貌似并不影响编码的方式，只是一些额外配置。但是工具链相对于传统MVC是全方位的进步了，我觉得这并不能说明传统方式的优越，而正相反说明了传统方式少数几个优越的地方也在被人积极地进行超越了。

> 现在的前端有时一个页面的大小可以达到10M甚至20M的夸张程度，或许对于宽带和pc端来说问题不大，但对于移动端，它消耗的流量和耗电程度事实上已经超过了当年被乔布斯疯狂诟病的flash。几乎可以肯定的事情是，在未来肯定会想办法把这些离谱的东西重新拆开。到时在什么页面依赖哪些程序，恐怕还是得需要服务端进行处理。

这个也不是很赞同，10MB、20MB我觉得只能是轻量级的页游了。大部分SPA页面不算图片能达到3MB我觉得就恐怖如斯了。事实上打包工具链也在进一步进步，你说的那个按需加载实际上很早就有了，自动模块拆分也是有的……


其实去年的时候我还不太确定，但现在可以看出趋势，大家确实是都在向着自动化CURD的道路上走。只不过不同的一点是，与我想的一个框架整合全部直接对接数据库不同，一部分项目是拆成了API服务 + 鉴权服务，以接口为单位进行权限校验。这看起来就没那么激进了。


icebird <iceb...@gmail.com> 于2018年5月4日周五 上午9:58写道：
十几年从事前端的人员来回复一下这个问题。

首先第一个问题，mvc是否过时？答案当然是否定的。前端由于各种原因，现在激进的想要把所有业务逻辑工作全部包揽，但事实上这是不可能的事情，至少对于数据加密和服务端的验证是不可能被取缔的，大数据的计算整合也必须在服务端进行，前端所能作的业务逻辑方面的工作其实是一些对安全性要求不高的部分，所以C绝不可能从服务端移除，而且前端直接连接restful api的做法安全隐患极大，未来肯定会有越来越丰富的中间逻辑层对数据层的api进行封装加工。至于v的部分，确实有很大一部分工作由于js框架的狂野发展而不再需要由服务端进行template的处理，但现在出现一个很有趣的趋势是为了seo和加载运行效率，又开始进行首屏数据服务端渲染的工作了。

其次，单页应用是否适用于所有场景？答案也是否定的。现在的前端有时一个页面的大小可以达到10M甚至20M的夸张程度，或许对于宽带和pc端来说问题不大，但对于移动端，它消耗的流量和耗电程度事实上已经超过了当年被乔布斯疯狂诟病的flash。几乎可以肯定的事情是，在未来肯定会想办法把这些离谱的东西重新拆开。到时在什么页面依赖哪些程序，恐怕还是得需要服务端进行处理。至于这个服务端使用的是node.js还是python或者是java/php，会出现什么样的新框架，那得看未来的发展。

其实这里有个最重要的问题，开发人员在面临这场变革的时候究竟需要做什么准备？从我在前端经历的这一场变革来看，更重要的是对基础语言的熟悉和掌握，以便无论出现什么样新的框架和技术，都能够快速掌握并应用于工作中。有了这样的基础，面对的变革不论是发展成什么样子，技术上都不会落于人后了。

郁夫 <szx...@gmail.com> 于2018年5月4日周五 上午9:19写道：
Docker 和 python 有替代性？

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。


--
我的github: http://github.com/fy0



--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

icebirds

unread,
May 7, 2018, 8:51:02 AM5/7/18
to pyth...@googlegroups.com
首先说一下restful，这玩意的各种auth方案看似完善，但对前端的底层暴露的越多，就越容易被hack。restful服务端对数据合法性的校验更多的是依赖auth，却不去做逻辑是否合理的校验便直接入库。几乎是随便什么人在登录后开起来控制台看一会，写几行代码就能把他希望的数据插进数据库甚至修改掉，现在这个问题虽然还比较少，但未来就难说了。从业务角度来说，纯粹的restful是十分不靠谱的。

首屏服务器数据渲染并不表示未来会返回古老的一切都要靠服务端v层的方式。我说这个只是回答前面的问题，并不是说服务端将来就只是做做数据库对应，或者某个数据库干脆直接给出各表的crud就可以的。基于安全和业务需要，服务端业务逻辑会永远存在。但更多的会是针对数据的统合校验处理和高性能通信的逻辑。

至于代码大小的问题，我提出来的意思并非整个应用10m很小，我说的是一页。纯粹的一个页面就有10M之多，如果全站整合起来成为一个单页应用的话，不算数据很可能一个就达到上百m之巨，之前我们在做一个react的应用的时候，图快和开发效率，各种乱七八糟的库引用了一堆后，最后生成代码就不知不觉暴增到60多MB，而这60多MB的代码对客户端的内存和cpu压力十分恐怖。这正是当年flash被疯狂诟病的一点。而现在的前端开发，真实性能和美术资源尚未达到当年flash的巅峰，便已经出现了这种情况，事实上很多站的功能用所谓的单页应用就是一个十分不靠谱的事情。按需加载和各页面合理的模块拆分也绝不是现有的技术体系能够做到自动完成的。另外，我说的不是页游。页游几年前就已经暴增到10M以上了。

现在的架构体系上，自动化CURD和前端之间，事实上是把原来服务端的业务逻辑模块全部扔给了前端来写，目前在尚没有出现大规模前端注入漏洞利用的时候，还可以认为这没问题，但未来很多业务逻辑必定还要被交给服务端执行。事实上我们现在很多时候在没有办法的情况下都是使用node来完成这个需求的。不是没有这个需求，只是前端一旦提出部分api需要进行业务逻辑处理，提供与数据库不同的通信api，就会被服务器开发以不符合restful的理由驳回。

restful作为数据层，是一个十分优美的方案，它几乎完美解决了困扰业界多年的大型分布式数据存储和迁移方案。因为对数据库进行扩展或者切分时，根本无须修改业务逻辑层，但非要用restful来换掉整个后端的功能，那被换掉的很可能是后端程序员。因为curd是相对比较容易被自动化的。一旦这玩意的自动化完成，那么除了少数对数据分布进行的程序员外，其他死盯着这玩意不放的会被无情淘汰。

回到对这个邮件最初问题的讨论，其实现在后端被迫引发的变革，大谈什么restful everyting，绝对是一个误区。传统的MVC搅和在一个应用里的情况肯定是不适用了。但如果把视角放大，你会发现其实原来的M变成了现在的restful服务，其实更加复杂了，而V几乎完全交给了前端来处理，事实上本来这个东西就应该这么处理，前端获得了更强大和灵活的界面处理能力，事实上V也变的更复杂了。但C呢？难道这部分消失了？还是全部扔给前端，理性点分析，M和V都越来越复杂，C根本不可能反而变的简化甚至无端消失，这一部分在不久之后就会随着开发的需要被重新提出来，但它会被拆分成两部分，一部分交给前端，另一部分仍然留在服务器端，而留在服务器端的这部分，现在的后端程序员们不做的话，所谓的大前端、全栈开发就真的会到来。虽然这俩概念目前在实际操作上还有一些扯淡。

【说说我的结论】这一轮变革首先是从前端开始的，而node.js的出现让前端开发人员有了涉足后端业务逻辑的可能。未来是js开发人员大规模侵占曾经后端开发人员的领土，还是原来的后端开发细分成数据服务开发和业务服务层开发，现在不得而知。唯一确定的是数据库的业务逻辑层绝对不可能消失。反而会在把纠缠在一起的mvc拆分成几个应用层之后，这个业务逻辑层会在减负后逐渐变的更加复杂。

发自网易邮箱大师

peng yu

unread,
May 7, 2018, 10:23:15 AM5/7/18
to pyth...@googlegroups.com
我记得之前看到一个很有意思的比喻，对比REST 和 gRPC
REST就好像收款的二维码，gRPC就好像收款的pos机... 实践来看，其实REST/二维码已经能处理大部分业务了



要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。


--
我的github: http://github.com/fy0



--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+unsubscribe@googlegroups.com。
要发帖到此群组，请发送电子邮件至python-cn@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。

管策

unread,
May 9, 2018, 8:55:35 PM5/9/18
to pyth...@googlegroups.com
不好意思，icebirds 你的团队可能需要一个靠谱的前端。

“图快和开发效率，各种乱七八糟的库引用了一堆后，最后生成代码就不知不觉暴增到60多MB”，大型项目难道不需要做优化？自己没用好，来说工具有问题……

比如 webpack 的 tree shaking，很多时候不是直接就能用的

还有比如按需加载、延迟加载、代码分割等等优化手段


要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。


--
我的github: http://github.com/fy0



--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

--
邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
规则: http://code.google.com/p/cpyug/wiki/PythonCn
详情: http://code.google.com/p/cpyug/wiki/CpyUg
严正: 理解列表! 智慧提问! http://wiki.woodpecker.org.cn/moin/AskForHelp
---
您收到此邮件是因为您订阅了Google网上论坛上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
要发帖到此群组，请发送电子邮件至pyth...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。


--
管策
君子博学而日参省乎己，则知明而行无过矣。
Reply all
Reply to author
Forward
0 new messages