还没有人说关键的技术问题, server video streaming 这种思路是不能解决网络延迟问题的.
要知道, 最好的 real-time game (FPS, ACT, MOBA) 都是 client 和 server 同时模拟游戏逻辑 (非 lock step),
然后 sync states, resolve state conflicts, 才能达到最低延迟效果.
要是像现在 "云游戏" 那样, input 发到 server, server streaming video 回来... 黄花菜都凉了...

@gz911122 回头 Vue3 出来后, 又新学一波新的 best practices, 好麻烦...

你们都不等着 Vue3 出来后再学么?
"你们"指的是业余前端, 比如日常是写后端的人

@wadezhao 我看漏了... >_<

@wadezhao
哥们你没认真看回复吧. 别搞啥 IDE 内置 VIM 了...
作为 VIM, emacs 都用过的人, 我负责任的告诉你, 如果你是 Mac, 用 emcas key binding 最自然.
Mac 在很多 App 里, 默认就支持 Ctrl + f/b/n/p/a/e 就是 右 /左 /下 /上 /home/end, 然后 alt+arrow 就是 skip by word
就是在浏览器里也支持, 你还折腾啥 IDE 内置 VIM ...!?

PS, 我装过 Karabiner, 记得以前是要设置 Karabiner 的, 现在好像是不用了

@murmur
对于还没出来的 Vue 3, 怎么评价? 会不会让 Vue 2 用户的学习成本暴增?

Django request 会对应到数据库的 transaction. 是数据库帮你搞定的, 基本只有数据库才是 stateful 的.

难道不该是 gRPC 配 Protocol Buffer, webSocket 配 JSON?

@Mithril
GraphQL 的问题是, 它定义了某些高级的可以演义的动态 '语义' 和 '逻辑'.
没有任何成熟的机制，可以保证这些特性被高效可靠地实现.
所以, 其实要做聚合多个 micro service 的查询 api, 直接用死死的 function call 一样的 API 反而简单可靠高效 -- 比如就用 RESTful 之类就行了.

@StarkWhite
我不觉得有什么很好的方案能解决效率问题，因为 GraphQL 要达到的黑魔法一样的效果，后端的支持必然会比较粗糙.

我们看观点，不看出处. 你引用的这段，看着真的挺 YY 的. 而且我没听说过, micro service 最好是要配套 GraphQL 的.

知乎帖子 <GraphQL 为何没有火起来?>
没有认证, 现在不能发 URL...

可以看看知乎这个帖子里 2018~2019 的讨论

"GraphQL 的每一个实体背后可能对应着不同的数据库甚至不同类型的存储集群，后端集群间的海量数据自由 join，基本还是无解的，只能搭专门的集群处理，这个不清楚 FB 是否有什么黑科技，我严重怀疑 FB 自己也没做到全业务查询"

"FB 自己也没有黑科技...最近在做广告数据整合，FB 的广告相关 API 基本是一步一个 bug， 基础的时间段 filter 都有问题。传统 restapi 我好歹还可以看文档知道到底支持哪些 API 请求，Facebook 的 graphql 经常会出现明明符合查询字段，返回的确实毫不相关数据的情况"

"这个事情到底由谁来做？ GraphQL 的利好主要是在于前端的开发效率，但落地却需要服务端的全力配合"

GraphQL 玩玩可以. 认真做个大系统? 算了吧.

然而人家 ElasticSearch 同时提供了 database 和 Query DSL -- 它复杂的 JSON API 其实已经是 DSL 了.
GraphQL 提供了什么? 一个看起来美妙的 Query DSL 和 ... ... ?

"GraphQL 和 ElasticSearch 的 Query 比较类似，优点不在于优化性能"
大家理解 GraphQL 暗含了多少查询性能的坑了没?

我还是那句话, 如果有天出现了成熟的 GraphQL Database,
专门做给 GraphQL 查询用的, GraphQL 可以一用,
但是, 本质上就是另外一个专门的 database with specific query APIs, 就像 ElasticSearch

不能理解"GraphQL 就是把 SQL 弄到前端去", 就是没理解 GraphQL 这个沙雕 idea 的本质.
这样说吧, 从广义上讲, 给前端提供个有一定表现力的 query DSL...
这个方案的隐形代价是很大的! 除非你后端专门为这个 query DSL 设计个特别的数据库.
不然没有魔法能保证你的查询效率, 你们支持 GraphQL 自己慢慢想吧...

本来 SQL 还有优化 SQL 就是一堆问题了,
现在好，来个更沙雕的 idea，把 SQL 弄到最前端去, 直接暴露在空气中随便弄...
好像所有的查询优化都可以魔法搬自动解决一样, 实在太脑残了

@linlance
Django 和 Rails 一般都推荐你用 PostgreSQL, 官配
PostgreSQL 真心比 MySQL 强多了

@dafengchui
其他的 service, 比如 nginx, 甚至是 docker, 其实也得用 systemd 监控.
systemd 里面那些 "杂乱" 的信息，你迟早得慢慢去理解...
如果想用编程的方法控制 systemd, 最好的 lib 在 golang community
coreos go-systemd

@dafengchui
我以前跟你一样的想法, 也是倾向于用 supervisor, 觉得干净整洁，只有我自己的 sevice 信息.
后来发觉用熟 systemd 是必须的, 因为现在它是 Linux 事实性的标准, 比 supervisor 稳定多了.
你后来会发现, 为了让 supervisor 稳定可靠, 最好是用 systemd 监控它...