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

994 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 代码出一个后台页面了,大概是这个样子:




后来觉得 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