Tesla Adapter #57
Tesla Adapter #57
Conversation
There was a problem hiding this comment.
when I saw Tesla some days ago, I immediately thought it could solve a limitation of Dayron: we could allow users to plug middlewares to add custom headers to a request, or handling the response json before it's converted to a struct. And it could be done without the need of writing a custom Adapter. Do you think there is path to allow that with the TeslaAdapter?
| end) | ||
| end | ||
|
|
||
| defp build_hackney_options(opts) do |
There was a problem hiding this comment.
@jwarlander any reason to go low level and building hackney options instead of trying Tesla Dynamic Middlewares to include custom headers and params?
There was a problem hiding this comment.
It should definitely be possible to allow for custom middlewares; perhaps using application config? I could also see it as an option on the repo itself, something like:
defmodule MyApp.RestRepo do
use Dayron.Repo, otp_app: :myapp, adapter_opts: [middlewares: [
{Tesla.Middleware.Headers, %{"Authorization" => "token: " <> token }}
]
end However, what do you think about me raising a separate pull request for that, on top of the initial working adapter for Tesla?
As far as the current implementation goes, one could imagine just pushing headers into the options in the main client code, and having middleware perform the rest of the option translation.. Strictly speaking though, I'm not sure if it would make a big difference - I see middlewares mostly as an excellent way to support optional / new behavior, and translating the Dayron options to something that's suitable for Tesla's underlying Hackney adapter isn't really optional :)
There was a problem hiding this comment.
I should note though that the response translation ended up as a middleware module because I could find no good way to hook into the Tesla client itself.. then I ended up working outside of the client anyway, and implementing the tesla_call/2 function that could as easily do that part, so I'll admit it's inconsistent ;)
It would probably be pretty nice to split out option handling and response translation both into separate middlewares, put them in their own source files, and clean up the client module. I'll play around with it and see where it goes!
Based off of the HTTPoison adapter. Work in progress.