Skip to content
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

Allow defining API key/secret/passphrase/url dynamically #1

Closed
rylwin opened this issue Oct 27, 2017 · 3 comments
Closed

Allow defining API key/secret/passphrase/url dynamically #1

rylwin opened this issue Oct 27, 2017 · 3 comments

Comments

@rylwin
Copy link
Contributor

rylwin commented Oct 27, 2017

I have a use-case where I want to manage multiple GDAX accounts at once. My understanding of how Mix.Config works and the way ex_gdax uses it, that it would be difficult to achieve executing API calls for multiple accounts (but if I'm missing an easy way to do this, please let me know!).

Would there be any interest in a PR that adds the ability to specify the config per request? If so, I'd be happy to work on this.

p.s. thanks for this project! It gave me a great jump start on my own project 👍

@bnhansn
Copy link
Owner

bnhansn commented Oct 28, 2017

With the current approach of ex_gdax reading the api keys from system env vars or config.exs, I cannot think of a way off the top of my head to manage two different accounts inside the same application. I will put some thought into this but if you want to put together a PR I'd be happy to take a look!

@rylwin
Copy link
Contributor Author

rylwin commented Oct 28, 2017

One idea I have to achieve this is by adding a Config struct, then adding an additional, optional config parameter to all of the ExGdax.Private functions. If the optional config param is not provided, then we would default to the config.exs/environment variables. This would have the benefit of being backwards compatible while allowing specifying the config per request.

I've partially implemented this approach in rylwin@08da55f. If you like the concept, I can finish implementing the change for the remaining ExGdax.Private functions and the corresponding defdelegates, then open a proper PR.

Happy to go a different direction, too. Looking forward to your thoughts!

@rupurt
Copy link
Contributor

rupurt commented Nov 22, 2017

@rylwin I've also been thinking about how to achieve this. I can't really think of another approach besides passing something into a function. One idea I had which is similar to yours was to pass around the app name instead of the config e.g.

# config/config.exs
config :ex_gdax, app_one_api_key: "...", app_one_api_secret: "...", ...
config :ex_gdax, app_two_api_key: "...", app_two_api_secret: "...", ...

# lib/ex_gdax.ex
defdelegate list_accounts(app_name \\ nil), to: ExGdax.Private, as: :list_accounts

# lib/ex_gdax/config.ex
# ...
def api_key, do: from_env(:ex_gdax, :api_key)
def api_key(app_name), do: from_env(:ex_gdax, "#{app_name}_api_key" |> String.to_atom)

# Config usage
Config.api_key # default
Config.api_key(app_name) # For app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants