需求 1：spug ，排队啥的应该不行
需求 2：有点够呛，QQ 的话几个 onebot 的框架还好，但容易被风控，irc tg 可能好些
需求 3：直接编译保证不了环境一致，drone 挺好的

好久不见……我也开始找工作了，没想到刷到你的

R.I.P 完全用 VIM 开发过一年。感谢这个项目。虽然现在不会再回去这样用了

建议 PVE 套娃，PVE 比 exsi 简单多了

@AmberJiang 是我经常去的地方

@chashao pyqt 我个人看法是，对许可协议有疑虑

@liuser666 考虑一下 miniblink ，能解决 electron 大的问题

2021 年了，别再 vim 了吧

还是太闲了。现在一个项目的生命周期撑死两三个月，完成需求就行了。it works

因为好用。说实话出来那两年 TS 很菜，当年我也看过然后骂骂咧咧走了，后来今非昔比

还是不行，我前两天 vue router 切页动画翻车了

骚操作

@youngce

原来还有这种操作，那这样说的话这个方向是没问题的。

我不太了解 Django，刚看这文档的话，他是不是不支持各种算符啊？好像这篇文档只有这些：

'^' Starts-with search.
'=' Exact matches.
'@' Full-text search. (Currently only supported Django's PostgreSQL backend.)
'$' Regex search.

@youngce

DRF 不能处理条件查询、order 等内容

可能我文档没有说清楚，这个库的 CRUD 可以提供一些查询条件，类似 graphql，但是易用性上要好得多。

比如说：
```
# 查询 2020 年 1 月 1 日之后的文章：
http http://localhost:9999/api/topic/list?time.ge=1577808000

# 创建新文章
http -f POST "http://localhost:9999/api/topic/create" title="Hello Again" content="Content changed" time=1578729600

# 修改 id 为 1 的文章
http -f POST "http://localhost:9999/api/topic/update?id=1" title="Hello Again" content="Content changed"
```

@so1n 原来如此。至少先 work 起来了，而且文档也写的不错。

@popil1987

因为觉得多数操作重复，所以进行了封装。直接捅到 API 那一层。

@WildCat

我在这块选的方案更接近于 Data Mapper 。不过主要花费精力还是在 json 转查询和拦截器上。

@LeeReamond 个人微不足道的意见是这个回复出发点不合适。因为文章主题是复杂的，所以回复哲学永远是具体，你这个评论又强行抽象回去了。掷地有声的大段文本乍一听让人很兴奋，结果看了一下你的回复内容，问了一下自己，说的是什么？答案是没有具体内容，所以回到了上述的“具体”问题。

---

没意义的话我就当没看到。想听听你对 graphql 有什么高见？

还不错，明天试试。这个应该是把封装函数的 request 吃掉然后做各种操作吧？

读了一遍文档，初步印象中唯一一个槽点是`Body.i()` 中的 `.i()` 有点摸不着头脑。

说起来 fastapi 那个 query 校验真是僵硬的不行；还有文档生成不支持自定义不说，居然会把 pydantic 手动修改的一些 schema 列移除掉，就很奇怪

@iceteacover golang 写 web 的话感觉和 js 的 koa，或者是 python 的 flask 差不多，应该没 Java 那么系统化。轮子倒也不用怎么弄