正文
前几天一直在评估在即将要开发的新系统上的数据接口规范选型。
- 第一种备选方案是，客户端需要什么样的数据服务端就提供什么样的数据，接口规范只定义网络请求发起时的
request body数据结构和网络请求从服务端回到客户端时的response body数据结构。数据不做冗余处理，比如（客户端需要 5 个字段，服务端从数据库就查出来 5 个字段）。 - 第二种备选方案是，沿用上个项目的 GraphQL 接口规范，定义清晰的模式（Schema），
request body和response body数据结构的最外层完全根据 GraphQL 的规范来。GraphQL 在项目的锤炼下，用起来已经很轻车熟路了，很多坑也知道在哪。 - 第三种备选方案是，使用去年 12 月份学习的 gRPC。学习的过程中发现，gRPC 有个明显的好处就是只需要在一个服务端定义结构体，最后可以生成多种客户端调用代码，非常的吸引人。
自动生成的 go 和 js 客户端文件
思来想去，还是决定选用第三种方案，不得不说，我确实喜欢 GraphQL，而且也有相应的项目经验。但 gRPC 对我的吸引力还是太大了，通过这次机会我不但能打磨自己这块技术，在技术栈里新添一项；而且不用在客户端服务端各自分别定义结构体代码能节省开发时间，显著提高开发效率。
琢磨完，便开干了。前阵子学习，这会也忘了好多，开始新一轮的回顾旧知识。
旧书重读
这次回顾旧知识，和最近一次回顾 Linux shell 脚本一样。我的英语只过了四级，其实阅读英文文档还是不够滑溜，但上次已经踩了好多坑了，不少关键的单词也做了笔记，而且在本地的开发环境里已经敲过代码了，这次再次读起来，基本上都明白是什么意思了。
这就是种老友重逢的感觉吧，使个眼色，便懂了。
最近一次的回顾里，写到了 gRPC for Web，当时也成功把前后端串起来了，但是安装环境忘记记录了。虽然这次从头再走了一遍，不过学习过一遍的优势还是有的，感觉路走过！这次花的时间比较少，挺顺利的就再次把前后端串通了。
软件开发者的技术的巩固一定要多敲代码，多实践才好。前期没有实操机会时，就静下心来积淀，如果每一次实际操作的时候都有种回顾旧知识的感觉该有多好——很不容易，尽力而为吧。
