是否考虑实现类似ABP VNext的基于HTTP的RPC调用

[tky753]

ABP对服务间调用进行了封装，用动态代理实现了RPC调用。
这是它的文档，动态代理
它是基于HTTP封装的，感觉用的非常爽，
远程调用和本地resolve 一个service，用法完全一致，比grpc还要方便（grpc还要想法子传递proto文件）。
而且对内对外不需要定义两套。
而且abp vnext从7.0开始正式支持dapr了（其实现在的版本已经有preview可以拿来用了），我看这个rpc调用也有dapr的实现方式了。
你们是否会考虑也整一个？

grpc我看了一下dapr的文档，好像同一个服务不支持同时开http和grpc，这个限制太坑了，
所以我在想，能不能在http的基础上搞一个rpc调用？

[doddgu]

动态代理在我理解是我们在模仿WCF自动生成代理类。而这个过程在不断的优化。
目前我们有提供这个功能的雏形，即Caller。当然，现阶段我们只是埋点了在这里对HttpClient，Dapr Http，Dapr gRPC的快速适配，我们仍然需要自己写一个Client对服务端进行操作。
但像自动填充验证，序列化和反序列化对象等基础功能都完成了。

我们目前缺的是一个时机，如何用最小的代价动态生成Client。选择的技术有很多，但看起来都不太完美，要么太复杂不容易理解，要么限制很多。Rougamo这个项目我大概看过，等我们有空的话会对这个进行一个技术预研，如果ok的话，或许会通过它或者类似的机制完成自动生成Client的部分。

这也是我们对Caller的最终期待。

至于Http和gRPC确认不能同时开？

[tky753]

@doddgu 我看ABP的动态代理是服务端开一个 api/abp/api-definition controller，可以向Client发送所有route的信息，Client据此生成动态代理。
dapr client可以同时调用Http或者grpc
dapr server启用Http或者gRPC，对应一个 dapr run 的选项，看文档是这样的：

我试了没有both 选项 文档链接

[doddgu]

@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和应用之间的通讯目前还不支持混用。

[tky753]

接上文，
就算dapr sidecar它支持both选项，asp.net core程序中一个端口想要同时支持 grpc 和 http，也是很蛋疼的，必须要启用TLS，底层我不太懂，据说是需要TLS做http1.1和http2之间的 ALPN negotiation，我一个内部微服务启用这玩意儿做啥？而且这玩意儿开起来还有点费劲，反正我是整了一下午没成功。

你可以clone一下abp vnext源码，搜索这个类：AbpApiDefinitionController，看看它传递了哪些controll，action定义参数。我看连 controller 实现的 interface都一起传了，然后客户端resolve那个interface来进行RPC调用

[doddgu]

我看你说 Api Definition 我就明白了。我们当初是想通过约定优于配置的方式自动解析，而不需要额外的自定义。因为本来Client和Server都是自己的，没有必要自定义一个特殊的。除非它需要对外，但即便这样，Server也可以进行“单方法，双API”。

好处是简化了对于Open API造轮子这件事儿的额外成本。缺点目前我们的场景还没遇到，需要社区集思广益。

我希望我们能做一个更简单的东西，当然 AbpApiDefinitionController 我记下了。等推动Caller往最终形态重构的时候可能会把现有的实现路径都研究一下。

如果你对这件事情感兴趣，我们也欢迎你能参与进来。

[hrx521]

我也支持这个提案。常常有这样的场景，后端的服务做好后，客户端有浏览器以http调用后端，有时还有一部分客户端是wpf或winForm这种应用，也想调用同样的后端服务，这时用httpClient来调用后端webapi就费劲了，而且性能也不如rpc好。所以特别希望在这种场景下wpf或winForm客户端应用能借助某种后台服务自动生成的代理进行像调用本地服务一样的方式来用。