nofdev / nofdev-rpc Goto Github PK

目前 ServiceContext 会保留 http 协议 header 中所有以 Service-Context 为前缀的 key, 并一直传递下去, 比如 Service-Context-CallId, Service-Context-App 等. 而其他前缀的 header, 在向后调用时会被忽略掉无法透传.

而 ServiceContext 本身继承了 Hashmap, 所以要获取上下文的话, 可以调用 serviceContext.get('Service-Context-App')这样的方法, 设置和修改也可以使用 put 方法.
但是如果 key 不是已 Service-Context 为前缀的话, 透传就会出问题, 会被忽略掉.

现在的问题是, ServiceContext 的结构设计. 我希望业务方可以灵活的设置和修改某一个 key, 同时对 httpheader 友好.

现在有两种方案,

1. 目前所采用的, 以 key 的前缀为判断依据. {"Service-Context-App":{},"Service-Context-CallId":{}},缺点是业务方需要按约定 get,put
2. 统一用一个 key {"Service-Context":{"callId":{},"app":{}}}, 缺点是 get,put 方法需要特殊去实现, 也不符合 http 协议header 的惯例用法, 优点是对 key 不需要根据 http 协议特殊要求总长度不超就行

我个人倾向第一种

个人不太建议实现typescript to json idl，理由是typescript的数据类型太简化，不能准确的转换到强类型语言，而且类型规范也不能强制化，像如下代码：

getProfileForMe(categories: Array<Category>, promotionId: string): Promise<any>;

除非规定不允许使用any，否则上述代码再转换时不知返回类型。
再者，number的转换也不好明确目标类型。

Maybe, we should add a support for batch invoke and batch execute a service out of the box.

In the client-side. If there is a api method with AllowBatch annotation. You can invoke the method such as object.batchXxx(local, params...params) or object.batchXxx(remote, params...params).

The previous will create multiple connections concurrently and invoke the xxx method.

The after will create a connection and invoke the batchXxx method generated in server-side.

The batchXxx method in server-side is a method generated by framewok, and execute the xxx method concurrently.