The proposal and the PR are now updated with the new API:
https://github.com/grpc/proposal/pull/14
https://github.com/grpc/grpc/pull/9842


On Friday, February 24, 2017 at 4:16:20 PM UTC-8, [email protected] wrote:
>
> Looking at this more closely, I think a more flexible outbound/inbound 
> interceptor API will cover the use cases I mentioned without a separate 
> batch-handling API. I'll work on updating the proposal.
>
> On Friday, February 24, 2017 at 9:25:13 AM UTC-8, [email protected] wrote:
>>
>> I agree with hiding the grpc.Call API. I'm concerned about the usability 
>> of the inbound/outbound interceptor API for use cases like caching. When we 
>> need to change how operations are batched or we want to short circuit the 
>> remaining interceptor stack, a purely operation-specific API is awkward and 
>> difficult to reason about.
>>
>> Would you consider an abstraction over the grpc.Call API like this?
>>
>> {
>>     interceptCall: function(callConstructor, options) {
>>         var call = callConstructor(options);
>>         return (new 
>> InterceptingCallBuilder(call)).withInterceptBatch(function(batch, next, 
>> responder) {
>>             var cachedResponse = _getCachedResponse(batch);
>>             if (cachedResponse) {
>>                 var response = (new 
>> ResponseBuilder).withMessage(cachedResponse).withStatus(grpc.status.OK).build();
>>                 responder(null, response);
>>             } else {
>>                 next(batch);
>>             }
>>         }).build();
>>     }
>> }
>>
>> `batch` in this example would wrap the internal client_batch with some 
>> accessor methods: `hasMetadata`, `getMetadata`, etc.  The returned call's 
>> `interceptBatch` would have access to (and the ability to mutate) the full 
>> batch and could short circuit the remaining interceptor stack without 
>> exposing the internal API.
>>
>>
>> On Thursday, February 23, 2017 at 1:20:38 PM UTC-8, Michael Lumish wrote:
>>>
>>> I do not like the idea of directly exposing the internal grpc.Call API. 
>>> It is internal for a reason, and it is not currently guaranteed to be 
>>> stable. I would strongly prefer that the "outbound interceptor" and 
>>> "inbound interceptor" APIs be the fundamental building blocks of this 
>>> interceptor API.
>>>
>>> On Thursday, February 23, 2017 at 1:01:45 PM UTC-8, Michael Lumish wrote:
>>>>
>>>> A proposal for a client interceptor API for the Node.js library has 
>>>> been created here: https://github.com/grpc/proposal/pull/14.
>>>>
>>>> Please keep discussion about it on this thread.
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/878bc96d-f6a7-4504-b106-6654b70de7d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to