2 年前用过， 当时做很小的活动 h5 游戏(websocket)，感觉还可以。

everlane

如果更复杂的情况，

如果是基本业务代码相同，可以考虑做成 parent view 然后继承；
如果是业务代码共用，需要做部分处理，那么在类内做成 base func，用*kwarg 来做处理，

代码相对来说可能比较漂亮些；

另外作为 drf 吹（ django rest framework ），推荐你使用。

感觉有些乱来

view 的作用是处理 request response, 没必要这么引用

如果 A 和 B 有代码可以共用，那么就抽出来做个 Mxin 就可以，没必要交叉

随便改了下，类似这样
https://gist.github.com/chrisguox/4de1a0cc586055d776be818ed636cf6e

第一种办法
1 分别查询
2 用 chains 连接起来
3 如果是 drf，建个自定义 serializer 序列化

------

第二种
重新抽象 model，
看业务需求用 proxy 模式或者直接用字段表示不同的类型，再分别 filter 出去

@mashoushan1989

[更多公司介绍请点此]( http:https://ashma.info/2019/03/01/Q&A-of-hiring/?v2ex)

http:https://
是主题的链接加多了协议头

如果是 drf 那套的话，
login 的时候直接把 token 更新下就可以。


jwt 的过期和刷新的理念，当时用的时候觉得不太顺手，git 上面好像还有一个 issue 就是讨论这个问题。

content = "ad=0 cd=0 rcode=ok qdcount=1 ancount=0 nscount=0 arcount=1 src=232.190.252.222 dst=45.80.170.1 test test2"

1
直接字符串判断
rocde_is_ok = "rcode=ok"
rocde_is_ok in content

2

pairs = content.split(' ')

content_dict = {}
for name_value in pairs:
nv = name_value.split('=', 1)
if len(nv) != 2:
nv.append("")

key, value = nv
content_dict[key] = value

Patch /path/to/resource/<id>/

data :
{
"a" : "test",
"b": "test"
}

----
Patch /path/to/resource/<id>/

data :
{
"b" : "test",
"c": "test"
}


在渲染层再做业务的处理

self.website =
这行结尾多了一个逗号

CRUD

感觉 app 和 nginx 混在一起了。

你可以大概这么写：

先把 各自的 app 容器都写出来，然后将 sock 文件或者 端口号暴露给 nginx 容器。

然后再写个 nginx 容器，定义好路径，一一指向你要指向的 api 就可以。

@qianddoo1
请问在哪买呢

速途同归。

我入门是由 flask，后面开发用的是 django。

flask 比较自由，而且整体的理念是比较自由的，但初学者比较难摸到套路。
django 的话，reuse 的理念比较强，整体的框架还有理念都很好地让人们明白怎么去安排代码。

django 还有一个好处是 django rest framework，这个东西基本能够把 web 能够遇到的比较烦的东西简化成声明式编程。


如果是零基础，我其实是比较建议 flask，更建议狗书，慢慢累代码上来，对编程这个事其实更有帮助。