鬼谷子
鬼谷子
@capdiem PTAL
issue先关了，如果有问题再重新打开
这块儿还没有开始做
收到，我们将会在2.0启动后考虑这个需求，谢谢。
动态代理在我理解是我们在模仿WCF自动生成代理类。而这个过程在不断的优化。 目前我们有提供这个功能的雏形，即Caller。当然，现阶段我们只是埋点了在这里对HttpClient，Dapr Http，Dapr gRPC的快速适配，我们仍然需要自己写一个Client对服务端进行操作。 但像自动填充验证，序列化和反序列化对象等基础功能都完成了。 我们目前缺的是一个时机，如何用最小的代价动态生成Client。选择的技术有很多，但看起来都不太完美，要么太复杂不容易理解，要么限制很多。Rougamo这个项目我大概看过，等我们有空的话会对这个进行一个技术预研，如果ok的话，或许会通过它或者类似的机制完成自动生成Client的部分。 这也是我们对Caller的最终期待。 至于Http和gRPC确认不能同时开？
@tky753 > 我看ABP的动态代理是服务端开一个 api/abp/api-definition controller，可以向Client发送所有route的信息，Client据此生成动态代理。 我们之前考虑是直接用Open API就可以了，不需要自己造轮子。我们目前在使用Minimal APIs，也是支持Open API的，虽然支持上还稍微有些不足。 然后通过打一个特殊的特性或者接口的方式协助Client生成代理进行扫描。然后用Source Generator等生成Native Code Client。 你的意思是我们只需要解析一个特定的 API Definition，然后在IoC中自动注册一个远程服务接口的实现类去解析API Definition，创建接口到服务的路由是么？ 如果是这样的话，的确可以在没有更好的native code选择情况下作为备选，因为这样需要在服务端提供一个额外的服务来协助解析，相当于造了一个类似Open API的轮子。 > 我试了没有both 选项 这个我觉得可能是因为暂时没有做 gRPC 和 Http 的API Scope导致的吧。应该是担心你混用，但daprd和应用之间的通讯目前还不支持混用。
我看你说 Api Definition 我就明白了。我们当初是想通过约定优于配置的方式自动解析，而不需要额外的自定义。因为本来Client和Server都是自己的，没有必要自定义一个特殊的。除非它需要对外，但即便这样，Server也可以进行“单方法，双API”。 好处是简化了对于Open API造轮子这件事儿的额外成本。缺点目前我们的场景还没遇到，需要社区集思广益。 我希望我们能做一个更简单的东西，当然 AbpApiDefinitionController 我记下了。等推动Caller往最终形态重构的时候可能会把现有的实现路径都研究一下。 如果你对这件事情感兴趣，我们也欢迎你能参与进来。
@15168440402 PTAL