proposal: component ref 配置注入

[ZLBer]

What would you like to be added:

1. component_ref统一实现起来较为混乱，我们可以拆分成pubsub_ref、config_ref等。

2. 以pubsub_ref为例，对于pubsub_ref的实现,我们需要支持如下配置：

"pubsub_ref": [{
	"store_name": "redis",
	"keys": [
		"*", //支持配置全部注入
		"parent1.son1", //支持层级获取配置,
		"parent1.son2"
	],
	"encoding_type": "json/yaml" //因为sub返回的是bytes类型，我们可以支持多种编码方式
}]

3. 在配置更新之后需要重新初始化，这期间需要禁止调用组件。现在有相关的实现吗？

Why is this needed:

[seeflood]

component_ref统一实现起来较为混乱，我们可以拆分成pubsub_ref、config_ref等。

The disadvantage of this design is that we have to add a new xxx_ref struct every time we add a new API.

Could you clarify the advantages of it over the componentRef design style? For example, the componentRef design is to category them using type :

      "componentRef": [
        {
          "type": "config_store",
          "name": "apollo",
          "metadata":{}
        },

[seeflood]

在配置更新之后需要重新初始化，这期间需要禁止调用组件。现在有相关的实现吗？

Could you explain the problem in details? I think we don't have to consider this problem if users use this component injection feature. All we have to do is to inject the config store component into some other component written by users.
Uses should invoke the component.Subscribe(xxx) themselves to watch the keys and do some updates

[ZLBer]

The disadvantage of this design is that we have to add a new xxx_ref struct every time we add a new API.

Could you clarify the advantages of it over the componentRef design style? For example, the componentRef design is to category them using type :

      "componentRef": [
        {
          "type": "config_store",
          "name": "apollo",
          "metadata":{}
        },

1.我的想法是，不同的组件有不同的调用方式和返回结果，拆分开更容易精细化配置一些。 2.关于这个组件注入理解，好像有些点不一样，我理解的不就是主要用来注入配置的吗?所以我们只要按照配置文件中的方式把配置注入到组件中的metadata字段中，然后调用init方法重新初始化组件。你的意思是，可以插入用户的逻辑 , 那该怎么调用用户的逻辑啊?

[seeflood]

@ZLBer

1. 那这样呢

{
  "pub_subs": {
    "demo": {
      "type": "redis",
      "metadata": {
        "redisHost": "localhost:6380",
        "redisPassword": ""
      },
      "componentRef": {
        "config_store": [
          {
            "name": "config_store_demo",
            "xxx": "yyy"
          }
        ],
        "secret_store": [
          {
            "name": "secret_store_demo",
            "aaa": "bbb"
          }
        ]
      },
      "secretRef": [
        {
          "name": "xxx",
          "key": "yyy"
        }
      ]
    }
  }
}

2. 晚上开会聊下? 用户自己写自己的pubsub组件，runtime 只负责注入一个config store 组件给这个pubsub组件，用户自己决定怎么用这个注入进去的组件

[ZLBer]

为什么不直接给一个接口，让其余组件可以获取到所有组件？这样都不用注入 - -

[seeflood]

@ZLBer Good point! We can design a "inter-component communication" mechanism in the future, if users need it. For example, we can design a "service bus" for all the components to communicate with each. But for now, it's not appropriate because :

• Users only need to invoke config store and secret components. They don't need to invoke other types of components
• Your proposal might leads to cyclic dependencies. For example, A component depends on B, while B also has a dependency on A. A better approach to solve the communication problem is to design a service bus mechanism. Or, we can design a "bean injection" mechanism like Spring which automatically detects the cyclic dependencies. Anyway, they are complex and let's start simple.

[ZLBer]

layotto自己的组件还好说，要是dapr的组件怎么开个口子注入进去 ？

[seeflood]

layotto自己的组件还好说，要是dapr的组件怎么开个口子注入进去 ？

这个之前有讨论过，组件注入是一种侵入性的方案，目标不是”透明“的让所有已有组件都获得动态配置下发的能力；只有新写的组件才能支持组件注入，已有的组件没这功能

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.