Add interceptor capabilities to ConnectRouter

[fubhy]

Is your feature request related to a problem? Please describe.
It's currently not easily possible to implement generic middlewares for service methods. This makes it rather tedious to enhance connect services with generic logic across multiple methods.

Describe the solution you'd like
I'd like to be able to implement interceptors / middlewares for my service methods or groups of service methods (Connect for Node.js). The recently introduced ConnectRouter appears to be a good candidate to register these.

These interceptors should have the ability to augment the HandlerContext. Ideally, this should be done with TypeScript in mind ... That said, I'm not a big fan of blanket type augmentation as used in e.g. Express, etc. for this problem. Maybe there's a better way.

Describe alternatives you've considered
We are currently "intercepting" requests inconveniently by wrapping all service methods with higher order functions. To keep things simple and because that's the extent of our requirements currently, we've only implemented this pattern for unary requests. So this is only a temporary workaround at the moment.

Additional context
Implementing interceptors would allow the development of generic, community provided interceptor modules. E.g. for integrations with OpenTelemetry (metrics & tracing): #523.

Other possible use cases:

• Automatic request (& response) validation (protoc-gen-validate)
• AuthN & AuthZ
• Rate limiting
• Caching

These could all be nicely paired with proto options based code generation.

The ConnectRouter is currently only handling POST requests. That means that, in its current form, it wouldn't be the right place to also handle things like OPTIONS requests (CORS). I don't know whether (and how) "fixing" that is within the scope of this issue. However, I can definitely see value in being able to handle CORS at service method granularity... So maybe there's room for that here somehow?

[timostamm]

Related to augmenting the HandlerContext, the following feature requests should be considered in the design:

• Cannot get fastify context in request handler. #708
• Provide express' req/res.locals inside HandlerContext #586
• Serve handler from cloudflare workers #550 (comment)
• Difficulty Accessing Authenticated User Object from Passport Middleware #818

Ideally, we really want context properties to be type-safe 🙂

Since the context is part of service implementation signatures, it's also important that it's possible to stub or mock them with createHandlerContext() with a user-friendly API.

[srikrsna-buf]

You can now try out this feature using the next release of connect: npm i @connectrpc/connect@next. The docs for the next release are hosted here