Tesla - a flexible HTTP client library for Elixir

Tesla is an HTTP client that leverages middleware to streamline HTTP requests and responses over a common interface for various adapters.

It simplifies HTTP communication by providing a flexible and composable middleware stack. Developers can easily build custom API clients by stacking middleware components that handle tasks like authentication, logging, and retries. Tesla supports multiple HTTP adapters such as Mint, Finch, Hackney, etc.

Tesla is ideal for developers who need a flexible and efficient HTTP client. Its ability to swap out HTTP adapters and create custom middleware pipelines empowers you to make different architectural decisions and build tools tailored to your application’s needs with minimal effort.

Inspired by Faraday from Ruby.


Please check Tesla’s latest documentation update at Tesla — tesla v1.12.2.

I would appreciate any feedback about it. I need a different perspective to make sure the documentation covers most personas. The In-Module documentation is still WIP; I focused on guides and the getting started experience.

7 Likes

Tesla v1.13 introduces Tesla.Test module and direct integration with Mox You can read more about How-To at Test Using Mox with Tesla — tesla v1.13.0

6 Likes

We have a cool logo!

3 Likes

I’ve been using Req mostly. How would you compare Req to Tesla?

I use both; it all depends.

Req is excellent for getting something working very fast. At the same time, I use Tesla for predictable SDKs since Tesla barely includes anything by default, and Tesla has been around and used in production quite a bit.

You can check the built-in steps/middleware and the defaults you like; to me, they are the same, just different starting points.

1 Like

Sharing here for visibility, I need folks opinions about chore: add warning message to Tesla.Builder by yordis · Pull Request #621 · elixir-tesla/tesla · GitHub

References

For me Tesla.Middlewear.Logger is great for debugging as you can log the whole request/response. I believe the architecture of Req makes this difficult as there is no way to hook into the entire communication cycle.

I also find that the Tesla Middlewear model is simpler than Req’s, which requires more boilerplate and is a bit harder to get your head around, at least that was my impression from writing equivalent middlewear for both clients:

Tesla:

    def call(%Tesla.Env{method: :get, url: url} = env, next, options) do
      timeout = Keyword.get(options || [], :debounce_timeout)

      case Boing.debounce(url, timeout) do
        :ok -> Tesla.run(env, next)
        {:error, debounced: ^url} -> {:error, debounced: url}
      end
    end

Req:

    defmodule DebouncedException do
      defexception [:url]

      @impl Exception
      def message(%__MODULE__{url: url}), do: "Debounced: #{url}"
    end

    def attach(%Req.Request{} = request, options \\ []) do
      request
      |> Req.Request.register_options([:debounce_timeout])
      |> Req.Request.merge_options(options)
      |> Req.Request.append_request_steps(debounce: &debounce_step/1)
    end

    defp debounce_step(%Req.Request{method: :get, url: url} = request) do
      timeout = request.options[:debounce_timeout]

      case Boing.debounce(URI.to_string(url), timeout) do
        :ok -> request
        {:error, debounced: url} -> {request, DebouncedException.exception(url: url)}
      end
    end