像这种小更新(v1.0.0 --> v1.0.1), 也不一定要重新定义一个 api/path/v1.0.1

@rockyliang
其实方法(1),(2)最后都需要保存 2 套逻辑, 所以一定要做的事情是: factor out 共用逻辑，减少重复代码.
至于很多人说不能用(2), 其实也不一定, 因为很多小更新(v1.0.0 --> v1.0.1), 也不一定要新开个大版本号 (v1.0 -->v2.0)

看了下 package manager, xrepo:
https://github.com/xmake-io/xrepo
好像依赖的 library 是有 hash 值的?

@waruqi
希望 xmake 越搞越好啊.

要是能出个 C/C++ 的 package manager, 安装依赖跟 Go Mod, Rust Cargo 似的简单, 还能够以 hash(library) 来实现版本 lock, 那就厉害了 -- 只是我的 YY... 哈哈

@waruqi
今天刚好看到云风的 blog 下面, 一堆用户推荐用 xmake 代替 Ninja
不过云风因为 Lua5.1vs5.4，没有采用.
https://blog.codingnow.com/2021/05/make_to_ninja.html

@jim9606
JSON schema 的思想是好，但是实现略复杂，用起来感觉重
要是有个简化版的 JSON schema + 统一标准的各语言实现就好了

protobuf 是跨语言的，所以搞成这样. 都是语言太多整出来的麻烦.
你说的分库是 protobuf 各个语言生成器么? 多个库方便不同的 team 管理吧.

@0576coder 自己正经搞的话，应该是装个机器, 再在上面装上 FreeNAS

当然会有...
当有个人或者公司 定义且推广开一门新语言就行了.
能不能推广开，看这个人或者公司的能量有多大.
基于利益, 新崛起的强力公司很有意愿干这事儿.

面试和日常就是两回事，别纠结.
面试刷题慢慢变成了某种标准化考试 -- 当然也随机地考验你和面试官的眼缘.
虽然面试能帮你大厂，但是面试和在大厂打工其实就是挣个高点的工资而已.
都不用看得太重, 只认工资就行. 简单说就是 "面试耍猴玩, 工作拧螺丝".

@join
"其实大家都搞错了方向，cmake 难的不是 cmake 本身，而是编译依赖和项目构建本身就是个复杂的问题"

我觉得问题的本质是: "编译依赖和项目构建" 应该是"设计和维护编程语言工作的一部分", 但是很多语言由于历史原因(C, C++)，开始时没认真对待这个必要的工作, 导致后来需要疯狂补课.

更加现代的语言, 比如 Rust 之类，出来就有 Cargo

"简洁易学的配置语法，非 DSL"
支持这个思路, 用 Lua 挺好

@xuanbg 好的

@xuanbg "换成自己的轮子吧，用服务端存 Token 的虎符模式"
能说说哪些 Token 虎符模式 的轮子比较好么?

自己造轮子的话，我的理解是: backend 的所有 services 里面得有个专门的 authentication service, 这个 auth service 通过认证 user 的主 key (e.g. password) 给用户生成 token (with expiration time). 然后, user 试图连接任何 edge services 的时候 (edge services 是我临时取的名字, 算是所有在 server mesh 边界, 链接 client users 的那些 services), edge services 都会去认证 user message 附带的 token. edge service 可以每次都去 authentication service 认证 user token, 也可以 cache user tokens 到自己 service node 上, 当然如果允许 cache user tokens 的话, auth service 撤销(revoke) user tokens 的时候, auth service 必须通知有可能 cache 过相关 user tokens 的所有 edge service nodes.

JWT 的能力是很有限的, 参考这个帖子里的讨论

https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens

Truly stateless JWT authentication cannot be achieved for a typical, real world web app because stateless JWT does not have a way to provide immediate and secure support for the following important use cases:
User's account is deleted/blocked/suspended.
User's password is changed.
User's roles or permissions are changed.
User is logged out by admin.
Any other application critical data in the JWT token is changed by the site admin.
You cannot wait for token expiration in these cases. The token invalidation must occur immediately. Also, you cannot trust the client not to keep and use a copy of the old token, whether with malicious intent or not.

@IVeverKB DRF 有 token 认证的, 非 JWT token 那种

@timsensor
我比你大点, 以前也是做 C++的, 做 C++一般扩展语言的路线是 Python, Go.

你列出来这些方向都太小众了, 我帮你分析下，写点干货吧.

OpenGL? 去大厂做 3D engine rendering?? 没多少职位的.
现在很多游戏厂都是使用或者修改 Unity/Unreal. 很多时候会它们的 shader 编程就够用了. 做 Unreal 倒是需要 C++, 不过职位也不多. 一般不如用 C# 的 Unity 职位多.

区块链? 最多需要的是 Go, JavaScript (like Ethereum solidity)
https://coinmarketcap.com
你把上面的 top 50 区块链都看一遍, 拿着它们的名字去搜索 github.
你会发现如果是新出的链，一半以上是 Go (Ethereum, Chainlink, VeChain, THETA, Avalanche) 实现的, 偶有用 Rust (Polkadot) 甚至是 Haskell (Cardano). 其他的是 BitCoin 的 fork, 当然是 C++, 或者是 Ethereum 上的 token, 使用类似 JavaScript 的 Solidity.
毫无疑问, 搞区块链应该转 Go

游戏服务端? 这块应该是 C++, Java, Go, Rust 都行.
如果需要 real-time Action game 后端的话, 应该是 C++/Rust > Go > Java

再来看需求量最大的 web 后端, 现在是 Go VS Java
还是推荐转 Go. 因为 Java 历史 沉淀(包袱) 很大, 现在入场没什么优势了.

综上所述, 保留你 C++ 和 web 后端的经验, 转 Go, 顺便看看 Rust.

没有, 估计也不会有.
Go 跟 Java 完全不是一套思维.

不推荐用 jwt, 正经做产品的话, jwt 有点残疾.
比如不方便实时 revoke token, 比如你的用户改了主密码, 需要将所有关于他的 authenticating token 立刻作废. 这种情况 jwt 就处理不好.