@dfkjgklfdjg 你的建议很好 谢谢

@janxin 确实... 从公司角度这个属于安全问题，如果直接公开肯定不好
不过我小小的希望一下可以当做内部技术测试，或者渠道白名单啥的。

一方面，解决商家系统和快团团系统的连接
一方面，可以为现在还在迭代的快团团开放平台提前做一些测试和用户反馈

@yohole 联系了 还在等待回复

@Exdui 内部使用 也不影响第三方运行 应该不犯法吧

@huolinmufeng xmszer

干 不会自驾怎么行动

+1

是啊 这个确实挺蛋疼的
安卓的什么权限设置只是对年轻人有用 而且很搞笑的是 设置起来还特别麻烦，然后第一次提示引导又搞得特别重

然后我给我爸妈本来就是配了安卓机，结果没几天就一堆乱七八糟的 App

一方面是安卓应用市场太乱了
一方面安卓安装方式太简单了
一方面各种 App 违规引导 爸妈根本就不懂啊


最后还是全部换成了 iOS

就我目前来说

我是想找个前端直接查询 sql 的方案

我的场景是，我在在做 DEMO 项目，然后遇到数据的存储。本来是用 indexedb 的，但是这玩意和 localstorage 一样的限制，所以不能满足更多需求
那么就需要一个持久化储存
然后持久化存储有了，但是前端并不能直接访问数据库，需要某个中间服务去处理，而且这个中间服务必须简单，不能花太多精力

然后这时候的方案就是


1. 直接传 sql ， 这个肯定不行，又慢又不安全
2. orm 写接口，加快了查询速度，但还是要写接口，不符合需求
3. graphql ，还是要写 schema...
4. apijson 只有 java ，我 TM...
5. nextjs ，另一种思路可以但是副作用更大


然后说一下 graphql ，他的场景主要是解决前端层的需求，更具体的是 BFF 层的需求，比如接口裁剪、组合。不是解决后端层的需求。后端其实并没有任何收益，说代码少写实际上并没有，因为你用普通的 orm 也能搞。
当然，有很多工具可以实现自定义生成 schema ，但还是不够快，而且费了太多功夫的。像这种情况下，我们肯定是不推荐硬写。就能实现但不是它该做的


那么剩下就是 apijson ，首先我一看到那个 github 项目页真的。真的是很糟糕
我感觉就是个 80 后程序员硬写出来的东西，而且毫无审美
更加意外的是居然还有那么多产品在用？ 当然这也说明国内真的很多公司水得一比

因为如果你真的有技术人员，或者真的有选型的能力，那绝对不可能选择 apijson ，怎么敢用在生产环境上？？？？
这就和前端的 uniapp 一样

虽然火，但是他真的又菜又没有创新。受众人群就是非程序员或者水平菜得不行的程序员
当然还有一批 80 后的程序员，就真的和社会脱节了，这个东西才是他们能认知的东西


然后目前来说，像我这个场景下，graphql 还是无奈的优选

最简单的方法就是 graphql + 自动生成 schema 然后放在云函数就可以跑了
再麻烦一点就是 graphql + orm + 云函数，然后如果表结构更新，记得更新云函数就行

@atian25 怎么实现的

是自动创建跳转的 index.html 页面吗

免费证书真的能省下一大笔钱，特别是泛域名的情况，一个域名一年好几千
正常使用下理论上没什么特别大的区别

无非就是每 3 个月定时更新一下，问题也不是很大

还是蛮推荐是使用免费域名证书的

这种就是传统思维下的历史成本
不愿意抛弃已有的认知去学习新的东西

------



当然，你用已有的知识去学习新东西是可行，但前提你得懂什么叫『抽象化』什么叫『融会贯通』（当然这个词选得不好）

大概例子就是，比如你已经 [精通] 一门乐器，那你再学习另外一种 [同类型] 的乐器时，那你以往的知识就是有帮助的

或者如果你掌握都是 [通用] 的 [方法论] ，那你学习什么都用得上。比如如何快速阅读一本书

否则你只会被你以往的经验束缚，并且可能走错方向



-----


当然额外的说明

像这种很 [通用] [现代] 的技术，或者 [新] 的技术方案，入门门槛难道会变得更难？
如果更难，那不就退步了？


或者说，如果你让一个没接触的人去学习，你会发现他学习非常的快

估计是上面有要求
如果你提交多一点领导也好看一下
拿到老板面前也好说

@guanyin8cnq12 什么意思 就是还是要有线桥接是吗 只不过可以实现自由切换

只能说以前受限于用户环境兼容，包括现在也是
实现对接 grpc 本身很简单，就是基于 http/2 传输
但是基础环境跑不起来，还得考虑降级等操作，那这部分肯定费时费力
那么就需要大厂来搞和实现

所以需要一点时间慢慢来，这就和短视频和网络关系一样，你网络没升级，短视频肯定不行

国内微服务框架

阿里 dubbo-go
头条 kitex
腾讯 tars-go
b 站 kratos

我们最后选择了 kratos，原因
- dubbo-go 感觉被名字局限了，毕竟是 go 版的 dubbo，而不是 go 版的 spring 。当然 dubbo-go 也是朝着更多功能扩展，但感觉还是怪怪的，期待再独立一个项目出来。但是毕竟阿里还是 Java 为主，Java 生态无敌
- 腾讯，每次都让人有种格格不入的感觉，但是确实这里做的最『未来』的，整体性很强。还有一个原因虽然和 tars 没关系，但是微信开发团队真的非常糟糕给腾讯名号蒙羞
- 头条，没什么感觉也没什么推广
- b 站，有概念感、业务实践、也喜欢毛剑老师。唯一缺点就是 git 社区客服戾气太重，有点玩不起的感觉，不知道是不是 b 站人员，可能是最近生活不顺利啥的。


然后为什么要框架，其实如果你只是写『脚本』那完全不需要
但是如果你需要架构层面，那肯定需要这类框架，rpc 框架现在基本都是往 go 框架发展

为什么选国内框架
- 中文太重要了

不知道是你们公司架构的问题还是你理解的问题（因为初期的表现确实就是个数据库增删改查的接口封装）

一般架构思想其实很简单，就是

原来都是单体应用，维护麻烦，崩得也很彻底

维护麻烦怎么办？拆应用呗，1 个单体应用拆成 5 个业务应用，每个业务应用还可以不同人维护，这样不就解决了。


---------------

我们知道了用拆可以解决问题，那理论上拆得越多问题解决越彻底，当然这肯定有副作用（需要自己权衡）


--------------

而你遇到的问题其实在于怎么拆？

如果仅仅只是把数据库的读写拆出来，那这个肯定是很无语的，因为根本没有解决问题

你有其他语言基础 理论上学习其他语言应该没什么问题 你需要的可能是实践是吧

实践的直接去极客时间或者 b 站看就行，其实内容不多（除非你要连微服务一起看了），几个小时就可以了（当然大部分视频都是废话或者广告）

然后目前我们公司实践下来，最后还是 kratos 生态一把梭

毕竟
1. 是 b 站的，有真实大量业务实践
2. 是国内的，无压力
3. 负责人很有趣


不过 go 的工具生态真的很糟糕就是了，像我们以前用 java 和 nodejs，java 是全，nodejs 是快

go 现在连个真正的 orm 工具都没有，框架更惨，还在 cli 生成文件的阶段

搞得比较 JavaScript 更像脚本语言 很无语