Windfarer
Windfarer
可不可以有BatchSend和BatchGet
用单个请求拼成batch，和直接调batch，性能是有差别的 > > 可不可以有BatchSend和BatchGet > > @Windfarer 接口应该不包含把，实现的时候自己加上。接口保证最小粒度。
延续2楼老铁的思路，即task和job（下文简称为“任务”）的调度基于外部系统进行，我们的项目结构设计仅专注于如何整洁地组织启动时的逻辑。 ## 任务特点 1. 任务不需要kratos.App实例上的生命周期管理（如Start,Stop和服务注册注销等）（有部分应用信息仍然需要） 2. 任务的定义类似接口定义，CLI调用某个任务（某个API），传入某些参数（请求参数），但是可能不要求返回值 3. 任务不需要server层进行的接口注册逻辑（不需要提供HTTP或gRPC接口） 4. 具体的业务在biz层的use case实例中，对于底层数据持久化或者外部数据调用实现在data层的repo中，这些部分结构定义良好，可以沿用或复用 5. task是跑一次就结束退出，job是持续在线进行处理（如消息队列的消费者） ## 设计 基于以上特点，我们可以使用proto来定义任务的接口（任务名和参数），编写一个新的protoc插件来进行代码生成，生成的代码主要用来处理任务名和参数的解析，维护任务的生命周期，进行相应的处理。 对于配置/参数的区分，我们认为配置文件是较稳定的，可以继续按照原来的形式进行加载和解析，而参数（命令行参数）可能在每次run的时候需要传入不同的参数，因此进行独立的定义和解析。 最终整个任务相关的代码在项目中将被分为四部分： 1. Manager实例，用于管理任务的应用信息和生命周期（相当于原来的kratos.App） 2. 通过protoc生成的任务定义代码，提供方法名映射和命令行参数解析等 3. task层代码，进行基本的业务逻辑组装，相当于原来的service 4. 底层业务代码，即biz和data与之前保持一致 ## 命令行界面 ```...
In additional, unit tests are required
https://github.com/google/gnostic
> why antd ? there are more prettier UI's available :) > https://www.vue-tailwind.com/ > https://vuetifyjs.com/en/ > https://vuesax.com/ Because our team is more familiar with react and antd.
> you can custom ResponseEncoder like this: https://mp.weixin.qq.com/s/4ocdoAVXXKTvJ3U65YXltw I know, but IMO this may be a frequently used function, we should make it to be a built-in feature of the...
rebase main branch to make the ci work
registry is noun and register is verb, maybe you should name it as re-register?