-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TNT-46700 Add proxy configuration #116
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ericfichtel Oveall looks good, just a couple minor comments
}) | ||
const options = { headers }; | ||
|
||
if (config.proxyAgent != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest simplifying a bit
if (config.proxyAgent != null) { | |
if (config.proxyAgent) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for consistency let's use isDefined
please.
if(isDefined(config.proxyAgent)) {
/** | ||
* Proxy Agent to specify a proxy for the fetch implementation | ||
*/ | ||
proxyAgent: ProxyAgent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably also be nullable
proxyAgent: ProxyAgent; | |
proxyAgent?: ProxyAgent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to add undici
as a dependency and use this ProxyAgent
object? What is the benefit? It is a standard? I wonder if we can define a basic proxy of our own in target tools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
undici fetch is expecting an undici
Dispatcher in fetch.options.dispatcher
, which is the recommended solution for adding a proxy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dispatcher
extends node's events.EventEmitter
, so it could be possible to omit the undici dependency through extending that, but that seems like it would be out of the scope of this ticket
}); | ||
} | ||
|
||
// proxy test for Node 18.2+ users |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest having this one uncommented, and the ones for older Node versions commented out
@@ -10,7 +10,10 @@ | |||
"author": "", | |||
"license": "Apache-2.0", | |||
"dependencies": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably also add "@mutagen-d/node-proxy-server"
to dependencies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if it is necessary to include the local proxy server file in the repo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why we need to introduce proxyAgent to the SDK. It seems enough that our users have full control to implement this based on what they pass in for fetchImpl
. What am I missing? Why is it worth adding these dependencies and complexity rather than just documenting how it can be done with fetchImpl
?
}) | ||
const options = { headers }; | ||
|
||
if (config.proxyAgent != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for consistency let's use isDefined
please.
if(isDefined(config.proxyAgent)) {
/** | ||
* Proxy Agent to specify a proxy for the fetch implementation | ||
*/ | ||
proxyAgent: ProxyAgent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to add undici
as a dependency and use this ProxyAgent
object? What is the benefit? It is a standard? I wonder if we can define a basic proxy of our own in target tools.
@jasonwaters The idea is to make it simple for customers to configure a proxy, similarly to what we already have in the Java SDK with a simple configuration, instead of requiring fetchApi to be overriden, which is not that straightforward. |
@jasonwaters @ericfichtel In case we decide to support ProxyAgent, we can list |
Yes I think we should simply document how to do this by passing in a fetch implementation with a proxy configured. We added proxy functionality to Java SDK because it was not possible to pull off in another way. But I think it better to be less prescriptive in JavaScript and simply expect a fetch implementation to be passed in -- configured with or without a proxy. Maximum freedom for users. |
looks good @ericfichtel ! |
Description
Adding a new option to the SDK config:
proxyAgent: ProxyAgent
This
ProxyAgent
from the undici library, which now contains the default nodefetch
implementation starting with node 18.2, allows SDK users to configure a Proxy for the SDK fetch calls. The user implementation of this will vary due to the change in the default node implementation. For node 16.8+ users, the proxy agent is passed into theoptions
argument as adispatcher
during fetch calls. This functionality will not work out of the box for versions of node older than 16.8, as undici fetch does not support node versions older than that. I will outline implementation options for specific versions in the testing section.Related Issue
Ticket: TNT-46700
Motivation and Context
How Has This Been Tested?
I manually tested this by setting up a local proxy, instantiating a
TargetClient
with different Node versions, and checking if a connection to the proxy was made duringgetOffers
calls. Here is how I was able to do that with different node versions:proxyAgent
in theTargetClient
optionsundici.fetch
in addition to specifying theproxyAgent
. That is becauseundici.fetch
is not the default fetch for node for these versions.node-fetch
andhttp-proxy-agent
. If we go with the approach in this PR, I will do further research on how to get a proxy to work for these versions and document the solution.node-fetch
andhttp-proxy-agent
by passing in a custom fetchApi to theTargetClient
options.The setup for each of these can be found in
packages/target-nodejs-sdk/demo/proxy-test/proxy_demo.js
.Due to the difference in implementation of
fetch
between different node versions, unit testing this would require a lot of creativity or discontinuing support for Node 14.Screenshots (if appropriate):
Types of changes
Checklist: