Move interceptors from generated code into the transport layer

[timostamm]

gRPC clients via @grpc/grpc-js bring their own interceptors. Letting the user choose from multiple interceptor mechanisms available seems overcomplicated.

This could be solved by moving interceptors to the transport layer.

[be9]

@timostamm Do you plan to deprecate the existing interceptor interface and nudge users to switch to the native mechanism or just move it around?

P.S. I'm asking because I'm currently working on some interceptors for my company that conform to RpcInterceptor interface.

[timostamm]

The gRPC-web and Twirp transports use the fetch API without additional abstractions, so there is no native mechanism to switch to. The idea here is to keep RpcInterceptor as is, and just move the point where it is applied from the generated client to the transport.

    /**
     * MakeHat produces a hat of mysterious, randomly-selected color!
     *
     * @generated from protobuf rpc: MakeHat(spec.haberdasher.Size) returns (spec.haberdasher.Hat);
     */
    makeHat(input: Size, options?: RpcOptions): UnaryCall<Size, Hat> {
        const method = this.methods[0], opt = this._transport.mergeOptions(options);
        return stackIntercept<Size, Hat>("unary", this._transport, method, opt, input);
    }

It's about the stackIntercept() call in the last line.

[be9]

@timostamm thanks for clarification! 🙏