Define an API for HTTP clients about elixir-google-api

[ananthakumaran]

Any update on this issue?

Tesla seems to have updated the api, so one could pass the adapter options directly now Tesla.client(middleware, adapter). But this is still not exposed by GoogleApi.Gax.Connection.

We are currently working around the issue by configuring the adapter globally. But we really would like to avoid global config, as this means we can't use different adapter configs (like no proxy for internal services) for different client.

config :tesla,
  adapter: {Tesla.Adapter.Hackney, [pool: Client.BigQuery, proxy: {host, port}]}

[chingor13]

Thanks Jose for the great suggestion!

Defining the connection API seems like an easy step to take. We picked Tesla for it's extensibility and multipart request handling but we're not doing a great job of surfacing it. We'd also like to make Tesla an implementation detail of the default connections (but document how to extend it). Currently, Tesla structs bleed out into the developers' code.

[josevalim]

Great! I have also opened two issues on Tesla, in case you'd rather expose it: elixir-tesla/tesla#218 and elixir-tesla/tesla#219

[teamon]

DISCLAIMER: I'm obviously biased here

The way I've always imagined client libraries build around tesla is that they expose a way to pass a custom %Tesla.Client{} to add/change functionality (like fuse/timeout/retry/headers/adapter/etc).

If you need a dynamic client you could do something like:

# MyApi

def new(token, middleware \\ []) do
  Tesla.build_client([{Tesla.Middleware.Header, "Bearer #{token}"}] ++ middleware)
end

# app code
client = MyApi.new(token, my_custom_middleware)
MyApi.some_function(client)

So, instead of hiding tesla it is actually exposed as first-class citizen and out of the box compatible with 3rd party tesla extensions. For example, need caching? - plug in tesla_cache middleware into your custom client.

I agree tesla docs are not the best currently but we are working on them! ( elixir-tesla/tesla#228 )

[josevalim]

@teamon this would be a valid approach as long as everything in Tesla can be done at runtime. Middleware are fine. However, you can't configure adapters at runtime, which is the reason why I opened this issue and the ones in Tesla.

The only way to make the adapter customizable with the current Tesla version would be if Google API added a global compile time configuration.

The other limitation is that it is unclear how to customize the adapters in Tesla. So if I need to tune hackney, I need to figure out how to go all the way from Google API -> Tesla -> Hackney, and that's not easy. As long as one of those contracts are well defined (Google API -> HTTP client) or (Tesla -> HTTP client), then we should be good to go.

[teamon]

You can override adapter in runtime, but it's not pretty and it needs to be improved a lot.

iex(1)> Tesla.get("https://httpbin.org/ip")
{:ok, %Tesla.Env{status: 200, ...}}

iex(2)> client = Tesla.build_adapter(fn env -> IO.inspect("Custom adapter") end)

iex(3)> Tesla.get(client, "https://httpbin.org/ip")
"Custom adapter"
# no request has been made

(Adapter is just the last middleware that does not call Tesla.run)

Regarding adapter customization - docs docs docs + best practices/tips & tricks

[josevalim]

@teamon build_adapter has no documentation. So it is unclear if it is a private function that was accidentally public or something that is meant to be used. build_adapter also does not receive the client as argument, so I still unclear how to change the adapter of an existing client, which is likely what I would expect here.

In any case, the lack of documentation around those customizations are precisely what those issues are about. :) Given Tesla defaults to httpc, which I don't recommend for production usage, I would say replacing and customize adapters should be more prominently featured.

[teamon]

Yes, yes, and yes, all you say is (unfortunately) true.
Thanks for starting the discussion around it! I hope we can get it solved in the near future.

[jmnsf]

@ananthakumaran & others, you can specify a particular client for which the config applies. For example, for the DialogFlow client:

config :tesla, GoogleApi.Dialogflow.V2.Connection,
  adapter: {Tesla.Adapter.Hackney, [pool: :dialogflow]}

[tielur]

Currently found this issue when trying to define a new middleware for the Tesla client like adding the Tesla.Middleware.Timeout. Interested to see if that's possible in another way and/or the state of this issue.