Allow injection of proxy configuration, instead of environment variables.

[zamnuts]

PR #1243 introduced proxy support via environment variables, specifically process.env. See https://github.com/grpc/grpc-node/blob/%40grpc/grpc-js%400.7.0/packages/grpc-js/src/http_proxy.ts#L45-L56

Sole reliance on environment variables (global scope), while a common occurrence, violates the Dependency Inversion principle by tightly coupling the location of the proxy configuration. In practice, this means that the inclusion of a proxy configuration cannot readily support the following use cases:

• Reading from a filesystem; e.g. kubernetes secrets mount, or kubernetes init container pattern (using emptydir for config loading)
• Application layer integration with a configuration management system and/or secrets vault; e.g. SDK use of GCP Secret Manager or HashiCorp Vault/Consul.

These use cases also apply to the scenario where an authenticated proxy is used and the credentials (secrets) would/should not be present in environment variables.

Solution

Allow dependency injection of a proxy configuration, via one or both of:

1. proxy as part of grpc.Client#options, I don't think noProxy would be required since the Client is bound to a single URI
2. proxy and noProxy, possibly, as part of grcp.loadPackageDefinition or similar where it has a more global effect across the grpc library.

Possible workaround

A workaround is to read the proxy configuration via one of the two previously mentioned use cases and set them directly on process.env before the @grpc/grpc-js module is loaded (required). It is important that it happens prior to requiring given that the proxy options are determined at module load time and not at the time of proto instantiation nor client creation.

[CMCDragonkai]

This looks really useful for our usecase, which is to dynamically create a NAT-busting tunnel that GRPC connections have to go over (via TURN or hole punching).

[CMCDragonkai]

A workaround is to read the proxy configuration via one of the two previously mentioned use cases and set them directly on process.env before the @grpc/grpc-js module is loaded (required). It is important that it happens prior to requiring given that the proxy options are determined at module load time and not at the time of proto instantiation nor client creation.

Is it possible to dynamically require and then change the proxy configuration, and then dynamically require again where the proxy configuration will be reset to the new proxy configuration?

[murgatroid99]

Is it possible to dynamically require and then change the proxy configuration, and then dynamically require again where the proxy configuration will be reset to the new proxy configuration?

No, that currently does not work.

[jbgomond]

It would be a very good feature ! I'm doing a per client proxy configuration in the C++ version of GRPC and I was looking into doing the same in NodeJS 👍

I'm in a situation where I have multiple proxies depending on where the GRPC service is located ... and so I need to use a different proxy for each client.