c4710n

c4710n

Background

When implementing libraries which have to sent HTTP/HTTPS requests, we have to implement an HTTP client.

In most of time, people implement their own HTTP client with their preferred underlying library, such as: httpc, hackney, mint, finch, etc.

But, maybe that’s not the good way.

Doing so not only wastes the time but also makes the libraries inflexible. If using multiple libraries, and these libraries use different HTTP clients, we will have many different implementations of HTTP clients running at the same time.

What’s the big deal?

Using multiple implementations of HTTP clients in one project, not only consumes more resources but may also creates inconsistencies in usage patterns, complicates maintenance, observation and debugging, etc.

It would be good if we can have a unified HTTP implementation, and then each library author can use it. In the way:

  • every library author can add multiple HTTP-adapters support in short time.
  • every library user can choose their preferred HTTP client in a flexible way.

What to use?

After investigating existing HTTP implementations, I found elixir-tesla/tesla, which considers what I said above.

Tesla provides a very flexible way to configure adapters. Let’s say we want use hackney as the adapter.

  1. Set an adapter at module level in the module itself:
defmodule GitHubClient do
  use Tesla

  adapter Tesla.Adapter.Hackney, recv_timeout: 30_000

  # ...
end
  1. Set an adapter at module level in the config file:
config :tesla, GitHubClient, adapter: {Tesla.Adapter.Hackney, [recv_timeout: 30_000]}
  1. Set an adapter at app level in the config file (this is not supported for now, but I have created an PR for it):
config :tesla, :my_app, adapter: {Tesla.Adapter.Hackney, [recv_timeout: 30_000]}
  1. Set an adapter at global level in the config file:
config :tesla, adapter: {Tesla.Adapter.Hackney, [recv_timeout: 30_000]}

Last

Everyone can benefit from using Tesla:

  • every library author can add multiple HTTP-adapters support in short time.
  • every library user can choose their preferred HTTP client in a flexible way.

Consider using it when writing your next package. If you do, remember to include a badge in your README.md, like Tesla compatible.

[![Tesla compatible](https://img.shields.io/badge/Tesla%20compatible-6e4a7e?Color=white)](https://github.com/elixir-tesla/tesla)

That’s it. :wink:

Showing Posts 1 to 3

mruoss

mruoss

@whatyouhide also discussed this topic in his blog post “A Breakdown of HTTP Clients in Elixir”. Me personally, as a library author I’d rather use Req than Tesla. It also allows for custom HTTP adapters. The problem I have with Req (for libraries) is that its default adapter (Finch) is not an optional dependency which, in the case of libraries, would be desirable.

The “adapter behaviour” Andrea discusses in the blog post is a possible approach for libraries. But as a library author, I don’t want to give up on the conveniences I get from req (steps) or tesla (middlewares). I’m in a bit of a dilemma here… :slight_smile:

c4710n

c4710n OP

Previously, I think that req and finch are tightly bound. If, as he says, finch will also support multiple adapters and offer flexible configuration options, that would be terrific.

Thank you for refreshing my understanding. :wink:

Maybe, someday, it would be Req-compatible libraries.

mruoss

mruoss

Edit: sorry, misread your post

— All posts loaded —

Where Next? Top

Trending in Discussions Top

cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
wmnnd
Hey folks, I wanted to share with you a project I’ve been working on for a while: It’s an Open Source (AGPLv3) newsletter tool. Think Ma...
New
axelson
Hi there! :wave: @frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
alexslade
Fly’s CEO posted this recently - Turn And Face The Strange · The Fly Blog It says that Fly is going all-in on sprites, which is a worry ...
New
sntran
In my third year of college, around 2010, I found Erlang. A few years later, I found Elixir. I liked the ideas at once: many small proces...
New
Ganna
Hi everyone, I have 8 years of production experience with Erlang/OTP and I’m just starting to get to know Elixir. What would you learn f...
New
gtcode
I’ve been tinkering with Lynx (by José) via hold_ledger. I used AI to write the code, a separate specification, the tests, and the Lean p...
New

Other Trending Topics Top

dominicletz
Hey there, I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first. ...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
OndrejValenta
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly) AI dream has many faces, but general...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews