layotto api 向前兼容 dapr 代码

[cyb0225]

Your question

pkg/grpc/dapr 下的代码为理解为旧版本 dapr 开放给各种 sdk 的 grpc 服务
pkg/grpc/default_api 我理解为 layotto 开放给各种 sdk 的 grpc 服务
目前我们的做法是将 dapr api 的部分复制过来使用，后来我看了一下代码，实际上我们在 default_api 中使用的也是 dapr_api interface 的接口，没有去使用它的私有方法，所以我在想当初为什么没有直接引用 dapr 的主库，采取了复制代码，避免 dapr 接口变更吗？

其次，我在 default_api 中发现了很多与 dapr_api 相同的代码段，查看他们的使用方法也是与 dapr_api 类似的。

layotto/pkg/grpc/dapr/dapr_api_pubsub.go

Line 119 in 1694e7a

func (d *daprGrpcAPI) startSubscribing() error {

layotto/pkg/grpc/default_api/api_pubsub.go

Line 51 in 1694e7a

func (a *api) startSubscribing() error {

idea

目前我的设想是采用引用 dapr 主库的方式，将 daprAPI 注入到 layottoAPI 中。当 layotto api 实现 pubsub 等方法时，将参数完全透传给 daprAPI，由 daprAPI 完成逻辑处理。
后续更新 dapr 版本的时候，我们只需要 layotto api 的 proto 方法参数与 dapr api 的参数方法对齐即可。

[cyb0225]

@wenxuwan

[github-actions]

Hi @cyb0225,
Thanks for opening an issue! 🎉

[cyb0225]

包括我在 goland 对比了一下 dapr_api_pubsub.go 和 api_pubsub.go 这两个文件，发现大部分代码是一样的。我的理解是后面我们会修改 dapr 的逻辑处理，但是这样 component 更新上去后，我们必须更新 layotto api 的逻辑重新兼容 dapr，才能保证 dapr 组件的复用，否则肯定会产生行为不一致的情况。
所以我觉得如果要服复用 dapr 的组件，就很难我们自己去修改 dapr 的内部逻辑，不然每次更新 dapr 版本，layotto 的 api 就要想办法去对齐。
或者我们想扩展自己对于这些组件的一些功能和规范，那我们其实后续实现起来语义也很难跟 dapr 兼容，也无法复用 dapr 的 component 了。那样我觉得就没必要去兼容 dapr 了。

[cyb0225]

#959

[cyb0225]

晚上试了一下发现 dapr component 的依赖都很难升上去，因为 layotto component 和 dapr component 的 go mod 有比较多重复的依赖，且 dapr 升上去之后，dapr 这些依赖的版本也更高了，layotto component 就出现很多依赖组件 break change 的报错。如果我们把 dapr 升上去，layotto component 的部分逻辑也得改。

[cyb0225]

dapr 实现 pluggable component 功能时 component 仓库的版本也是略高于我们现在 layotto 引入的 dapr component 版本

[wenxuwan]

包括我在 goland 对比了一下 dapr_api_pubsub.go 和 api_pubsub.go 这两个文件，发现大部分代码是一样的。我的理解是后面我们会修改 dapr 的逻辑处理，但是这样 component 更新上去后，我们必须更新 layotto api 的逻辑重新兼容 dapr，才能保证 dapr 组件的复用，否则肯定会产生行为不一致的情况。 所以我觉得如果要服复用 dapr 的组件，就很难我们自己去修改 dapr 的内部逻辑，不然每次更新 dapr 版本，layotto 的 api 就要想办法去对齐。 或者我们想扩展自己对于这些组件的一些功能和规范，那我们其实后续实现起来语义也很难跟 dapr 兼容，也无法复用 dapr 的 component 了。那样我觉得就没必要去兼容 dapr 了。

的确是很多重复的代码，一开始Layotto是和Dapr并行的，所以很多代码是从dapr那边拷贝过来的，这就是default_api的由来，再到后面就是想能否兼容Dapr的sdk调用，就有了grpc/dapr的由来。所以先不用做调整了，pluggabel component可以直接在Layotto里面实现，先不用去升级dapr的依赖。后面看看把dapr的依赖踢掉了，很鸡肋。

[cyb0225]

包括我在 goland 对比了一下 dapr_api_pubsub.go 和 api_pubsub.go 这两个文件，发现大部分代码是一样的。我的理解是后面我们会修改 dapr 的逻辑处理，但是这样 component 更新上去后，我们必须更新 layotto api 的逻辑重新兼容 dapr，才能保证 dapr 组件的复用，否则肯定会产生行为不一致的情况。 所以我觉得如果要服复用 dapr 的组件，就很难我们自己去修改 dapr 的内部逻辑，不然每次更新 dapr 版本，layotto 的 api 就要想办法去对齐。 或者我们想扩展自己对于这些组件的一些功能和规范，那我们其实后续实现起来语义也很难跟 dapr 兼容，也无法复用 dapr 的 component 了。那样我觉得就没必要去兼容 dapr 了。

的确是很多重复的代码，一开始Layotto是和Dapr并行的，所以很多代码是从dapr那边拷贝过来的，这就是default_api的由来，再到后面就是想能否兼容Dapr的sdk调用，就有了grpc/dapr的由来。所以先不用做调整了，pluggabel component可以直接在Layotto里面实现，先不用去升级dapr的依赖。后面看看把dapr的依赖踢掉了，很鸡肋。

对的，后来我又试了一下删掉 layotto component 中的代码，仅升级 layotto runtime 中的 dapr component 版本，发现还是很难升上去，layotto runtime 里面也有 pubsub 等 dapr component 的内存 mock 需要兼容，且 dapr runtime 初始化的形式也变化很大。感觉这个 dapr 依赖的作用不是很大，后面可以想办法把他旧版本的 component 实现和接口定义直接 copy 到 layotto，把他依赖下了。

[wenxuwan]

包括我在 goland 对比了一下 dapr_api_pubsub.go 和 api_pubsub.go 这两个文件，发现大部分代码是一样的。我的理解是后面我们会修改 dapr 的逻辑处理，但是这样 component 更新上去后，我们必须更新 layotto api 的逻辑重新兼容 dapr，才能保证 dapr 组件的复用，否则肯定会产生行为不一致的情况。 所以我觉得如果要服复用 dapr 的组件，就很难我们自己去修改 dapr 的内部逻辑，不然每次更新 dapr 版本，layotto 的 api 就要想办法去对齐。 或者我们想扩展自己对于这些组件的一些功能和规范，那我们其实后续实现起来语义也很难跟 dapr 兼容，也无法复用 dapr 的 component 了。那样我觉得就没必要去兼容 dapr 了。

的确是很多重复的代码，一开始Layotto是和Dapr并行的，所以很多代码是从dapr那边拷贝过来的，这就是default_api的由来，再到后面就是想能否兼容Dapr的sdk调用，就有了grpc/dapr的由来。所以先不用做调整了，pluggabel component可以直接在Layotto里面实现，先不用去升级dapr的依赖。后面看看把dapr的依赖踢掉了，很鸡肋。

对的，后来我又试了一下删掉 layotto component 中的代码，仅升级 layotto runtime 中的 dapr component 版本，发现还是很难升上去，layotto runtime 里面也有 pubsub 等 dapr component 的内存 mock 需要兼容，且 dapr runtime 初始化的形式也变化很大。感觉这个 dapr 依赖的作用不是很大，后面可以想办法把他旧版本的 component 实现和接口定义直接 copy 到 layotto，把他依赖下了。

嗯嗯，后面看看找机会把它下了，pluggabel component我们直接在layotto里面实现就好，把引用dapr了，如果哪天dapr有一些接口能力我们要用，就直接复制到layotto里面，不再这样强行兼容了。后期有需求兼容再做