顺便问了下 claude ,很多项目 404 了,而且有些都停更了。 更多的是基于 node.js 的,比如 directus ,Strapi 之类。 比较有趣的是,claude 的回答说 directus 是基于 php 的,问了他是什么时候的数据,说是 2020 年的。也就是说 ai 可能会将老旧的数据作为默认呈现给你,如果提问的时候不限定一个时间戳的话,插曲就这点,回到正题。
倒不是说 node.js 的不行,反正基本都提供 REST 和 GraphQL ,用还是一样用,主要是二开这有认识的 go 程序员合作十年以上了,所以不想突然换技术栈。node.js 也会但主流还是 go ,最后如果实在没有主流并长期维护星数高的开源项目,可能还是会用 node.js 。
没什么太多需求,主要用于 youtube 这类视频站的制作。有完整的二开文档就好。以后想所有项目都基于 headlesscms ,然后业务逐步从 wp 这类开箱即用的转移过来。毕竟请个前端是一个季度的事情,请个后端可是一辈子的事情,后端是养不起的。
1
panlatent 197 天前 via Android
偏个题,虽然 cms 这件事用 go 肯定没问题,但会不会有点折磨?
|
2
ota OP node.js 肯定更顺滑,前端可以一把梭,但问题也出在我这边没有这类专攻的。有也是外包的,信任问题是第一。自己人专攻的是 go ,大部分业务也都是 go 写的。
现在业务处于中期阶段,尝试自己写 go 的一整套系统,纠错成本太高,虽然有问题立马可以解决,但不适合新人加入,只能提供 api 调用进行配合,程序员他自己也有其他事情要干(比如交易所量化这些,更能来钱),也不能常驻。所以小成本+信任度,让我只能选 go 为基础的 headless 更为便利。既可以不用独立开发,得到开源社区的维护,又能单独二开保证代码的独立性不至于让人带走(之前合作过的一个外包就拿走了项目代码自己另起炉灶了) |
3
BeautifulSoap 197 天前 via Android
@panlatent 没问题的。写通过 api 提供 cms 功能的项目,难度不在语言本身或框架,而在怎么写 sql 。通用 cms 存储的文章结构是完全无法提前预测的,导致你也没办法提前设计表结构。只能用其他办法来把关系型数据库当 NoSQL 来用,写到后来基本就是和 sql 斗智斗勇了(各种 join 之类的),项目代码本身没特别的复杂度和影响书写体验的地方。如果不用 rds 的话那这种 cms 就基本没任何难度了
|
4
capgrey 197 天前
|