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.
paopao-ce/docs/proposal/006-关于paopao-ce的结构设计.md

19 lines
1.4 KiB

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

| 编号 | 作者 | 发表时间 | 变更时间 | 版本 | 状态 |
| ----- | ----- | ----- | ----- | ----- | ----- |
| 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) - 北野
* 添加部分内容