Hypothetical: Required Call Option

[moatra]

Aside: Found this library and love what it's doing. It's a much cleaner interface than trying to work with grpc-js directly. Thanks for the amazing work!

I'm toying around with the middleware concept that nice exposes, and I'm trying to implement a client middleware that always inserts a "request id" into the metadata to try and play nicely with a distributed tracing system. The request id is generated elsewhere in the codebase, so it needs to be passed in to the middleware and the middleware cannot arbitrarily generate one.

My initial thought was to have the middleware extend the type of the CallOptions with something like {request_id: string} and have the caller be responsible for wiring in the request id. However, it looks like the process of building the client to use this middleware forces any extension to be a partial. Indeed, even if it didn't, all the method types declare options to be optional. This seems to make it impossible to have a "required" option for requests that typescript will enforce

The other approach that strikes me is to make a middleware factory: On each request, the caller would pass in the request id to the middleware factory and then use that to build a dedicated client for handling that request. I typically shy away from trying to repeatedly rebuild clients as that can be quite a heavy operation, though.

Any suggestions how to possibly approach this?

[aikoven]

However, it looks like the process of building the client to use this middleware forces any extension to be a partial. Indeed, even if it didn't, all the method types declare options to be optional. This seems to make it impossible to have a "required" option for requests that typescript will enforce

Right. We could theoretically make it possible to have required options, but then we would have to make the options argument to be required based on whether there are any required options. This is technically possible (I guess) but it would seriously complicate the typings.

I typically shy away from trying to repeatedly rebuild clients as that can be quite a heavy operation, though.

Well, it probably is heavy right now, as it involves creating grpc-js client. Though I can't be sure about this without measuring. Also, if there's need, we could potentially optimize client creaton.

---

You may want to consider another option for distributed tracing: instead of forcing users to explicitly pass request_id to each call, you can make a middleware that adds it implicitly. But it should first somehow retrieve it from current context. For example, opentelemetry-js implements its Context using async_hooks. Btw, we have official support for OpenTelemetry that consists of server middleware that extracts trace info from headers and populates the Context, and client middleware that reads the Context and populates headers. Something similar could be done for other tracing systems. I would recommend async-local-storage as a ready-to-use async context implementation.

Aside: Found this library and love what it's doing. It's a much cleaner interface than trying to work with grpc-js directly. Thanks for the amazing work!

❤️