You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
|
|
|
|
| 编号 | 作者 | 发表时间 | 变更时间 | 版本 | 状态 |
|
|
|
|
|
| ----- | ----- | ----- | ----- | ----- | ----- |
|
|
|
|
|
| 006| 北野 | 2022-11-23 | 2022-12-23 | v0.1 | 提议 |
|
|
|
|
|
|
|
|
|
|
### 关于paopao-ce的结构设计
|
|
|
|
|
![](.assets/06-01.png)
|
|
|
|
|
|
|
|
|
|
### 疑问
|
|
|
|
|
|
|
|
|
|
1. 为什么要引入[go-mir](https://github.com/alimy/mir)?
|
|
|
|
|
工欲善其事,必先利其器。为了RESTFul API的后端开发体验可以媲美gRPC,本人特意打造[go-mir](https://github.com/alimy/mir) v3版本来满足需求。[go-mir](https://github.com/alimy/mir)是一套使用golang自身语言生态实现的RESTFul API从接口定义到代码自动生成的脚手架辅助工具集,便捷的实现快速后端开发体验,颇有“程咬金的三板斧,简单抡着就完事”的韵味。而从[go-mir](https://github.com/alimy/mir)的官方文档参考也可以看出,其生成的代码也确实就将一个HTTP的请求/响应简单分成 `请求绑定`->`业务逻辑`->`结果渲染`三个步骤去完成,生成的代码结构简单清晰,与gRPC的生成代码有点类似。
|
|
|
|
|
1. 为什么要兼容RESTful服务与gRPC服务?
|
|
|
|
|
RESTful服务与gRPC服务各自有擅长的场景,在合适的场景使用最适合的技术去做相应的适配,这是paopao-ce秉持的代码开发原则之一。
|
|
|
|
|
|
|
|
|
|
### 更新记录
|
|
|
|
|
#### v0.0(2022-11-23) - 北野
|
|
|
|
|
* 初始文档, 先占个位置
|
|
|
|
|
#### v0.1(2022-12-23) - 北野
|
|
|
|
|
* 添加部分内容
|