layotto api 向前兼容 dapr 代码 about layotto HOT 9 CLOSED

@wenxuwan

from layotto.

Hi @cyb0225,
Thanks for opening an issue! 🎉

from layotto.

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

from layotto.

#959

from layotto.

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

from layotto.

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

from layotto.

包括我在 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的依赖踢掉了，很鸡肋。

from layotto.

包括我在 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，把他依赖下了。

from layotto.

包括我在 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里面，不再这样强行兼容了。后期有需求兼容再做

from layotto.