Add RpcOptions to Client-Stub constructor?

[awltr]

Add RpcOptions to Client-Stub constructor?

[mikberg]

I ran into this recently when tracing down memory leaks in our GraphQL server, where memory use appeared to be linearly increasing with the number of requests. We were creating new GrpcTransports for every request in order to attach authorization information to them.

I ended up writing a function to wrap the transport for each incoming request context:

// Wrap some existing RpcTransport to provide default call options.
const transportWithDefaults = (
  t: RpcTransport,
  callOpts: Partial<RpcOptions>
): RpcTransport => {
  return {
    mergeOptions: options => t.mergeOptions(options),
    unary: (method, input, options) =>
      t.unary(method, input, mergeRpcOptions(callOpts, options)),
    serverStreaming: (method, input, options) =>
      t.serverStreaming(method, input, mergeRpcOptions(callOpts, options)),
    clientStreaming: (method, options) =>
      t.clientStreaming(method, mergeRpcOptions(callOpts, options)),
    duplex: (method, options) =>
      t.duplex(method, mergeRpcOptions(callOpts, options)),
  };
};

Usage:

const transport = new GrpcTransport({ ... });

// for each incoming request – client creation is cheap
const myClient = new MyClient(transportWithDefaults(transport, {
  meta: {
    authorization: 'Bearer somevalue',
  }
}));

[timostamm]

From the manual:

First, protobuf-ts generates the following interface:

export interface IHaberdasherClient {
   makeHat(request: Size, options?: RpcOptions): UnaryCall<Size, Hat>;
}

As you can see, a method with a "lowerCamelCase" name is generated. It takes
two arguments:

1. "request" - this is the input type of your RPC. The message to send
   to the server.
2. "options" - RpcOptions for this call. Options can include
   authentication information, for example.

Have you tried this? Are you looking for something else?

[awltr]

RpcOptions can be specified either when creating the RpcTransport or directly with the call

This would be the second option via call, right? I'm looking for an option to add default metadata to every call of a client. This can be achieved with RpcTransport but as said, I want to reuse the RpcTransport-Instance. So it would be great, to pass options to the Client-Stub as second parameter, e.g.

const client = new HaberdasherClient(transport, {
  meta: {
    // add general meta data, e.g. bearer token of request scope
  }
})

[timostamm]

I see. That's not possible. Would certainly be nice for some use cases, but it would also complicate code gen for clients.

Interceptors might be an option for your use case:
https://github.com/timostamm/protobuf-ts/blob/main/MANUAL.md#rpc-options
https://github.com/timostamm/protobuf-ts/blob/main/packages/runtime-rpc/src/rpc-interceptor.ts

[awltr]

Then I would add this as a feature request. Maybe it will get some other people's support.

In the architecture of micro services, you have actually very often an incoming request on one side and an outgoing request on the other. The incoming request has a context such as the token of the client that originally made the request - this is what I mean with request scope. Creating one RcpTransport per incoming request just doesn't seem right to me, as already said there is still a lot of initialization going on (see here and here). Channel overwrite may be an option - that's also a bit cumbersome but I'll probably do this for now.

[awltr]

@mikberg I already thought about something similiar, but wanted to keep the complexity low so I decided to just pass the options to every rpc for now. But that actually looks simpler than I thought, maybe I'll take it over. Thanks.

@timostamm It looks like you're currently working on other projects addressing the same purpose - protobuf-es and connect-es. Maybe you can put this requirement into your considerations there. Since I don't think it will be accepted in this project, I will close this issue. Thanks.