
Mint, a new HTTP library for Elixir - jparise
https://elixir-lang.org/blog/2019/02/25/mint-a-new-http-library-for-elixir/
======
gamache
Fantastic! Congrats on the release, Eric and Andrea!

For Elixir devs who want a higher-level interface to Mint, check out Mojito:
[https://hexdocs.pm/mojito/Mojito.html](https://hexdocs.pm/mojito/Mojito.html)
[https://github.com/appcues/mojito](https://github.com/appcues/mojito)

It builds on Mint to offer one-off requests, connection pooling, and a
generally friendlier interface than playing telephone with a TCP socket. :)
Play around and let me know how it goes!

------
ramchip
I like that Mint keeps dependencies to a minimum. I wanted to use the Gun
client in the past, but couldn’t because Gun and Cowboy would depend on
different versions of Cowlib (this is less of a problem now that Cowboy 2 is
well supported in Phoenix). Instead I used HTTPoison, but the way it wraps
Hackney makes it a bit annoying to understand and debug, and the pooling can
cause problem.

Mint looks lower level, but with a clean, well-documented API which should be
a great building block in the future. Congrats Eric and Andrea!

------
skrebbel
It took me a while to figure out whether this is an HTTP client library or a
server library. Turns out it is the former. Nice! I like that it's in-process.
I wish more Elixir libraries would default to such a design.

(EDIT: I had accidentally written "latter" instead of "former" above, causing
a bunch of people to correct me, thanks for that)

~~~
derefr
I've noticed that the distinction between server and client is much less
apparent in HTTP2 libraries than it was in HTTP1 libraries. It doesn't seem
like Mint follows this philosophy, but many HTTP2 libraries (even ones that
also support HTTP1) are both server and client libraries.

Presumably this is because HTTP2 is sort of two protocol layers stuck
together—a session layer and an application layer—and at the session layer,
HTTP2 just has identical "peers" rather than any concept of client/server.
(Theoretically either side of an HTTP2 connection could open a session to the
other side and send a message! It's just the semantics of the HTTP-mimicking
application layer that stop this. If you read the RFC, all the session
stuff—frames et al—are specified in terms of "peers", and it's only when the
spec starts talking about HTTP request-response that we see "clients" and
"servers" mentioned.)

Since implementing the session layer is most of the work of implementing an
HTTP2 client/server, and the session layer is just about "peers", once you've
implemented it for a client (or server), you can reuse it to implement a
server (or client) mostly "for free."

------
eternal_virgin
While I have qualms about the name since this is like the 20th Mint I've heard
of now, I'm incredibly excited as to what this has to offer. The control over
the underlying process is key to creating beautifully asynchronous
applications, and it gives me a lot of node-got vibes in terms of how easy it
is to use.

And thank god, HTTPS support built in... it never ceases to amaze me why some
HTTP libs don't have TLS as a given.

~~~
ams6110
> it never ceases to amaze me why some HTTP libs don't have TLS as a given

Separation of concerns. TLS termination is something that can be done
separately, and at scale you want to separate it anyway.

~~~
carlosdp
For a server, sure, but for a client?

~~~
ams6110
Admittedly, I missed that. I thought this was a server lib.

------
mrdoops
I'm liking the trend of designing runtime-behaviour agnostic libraries in
Elixir. We get such powerful runtime capabilities with OTP, but indulged in
the wrong context our cool OTP processes can be imposing assumptions onto our
users.

I'd like to see some kind of generic HTTP contract or REST-API client builder
library next so we can have swappable HTTP adapters (e.g. Mint/Hackney). I
don't want to depend on a library like HTTPoison or Tesla directly when making
a client, instead just generic Request/Response structs or protocols. That way
an internal project can use a single HTTP adapter across all REST integrations
rather than whatever the library author chose to use.

------
Dirlewanger
What does Mint provide over, say, HTTPoison? Still can't quite grok what it's
offers.

~~~
supernintendo
Requests made with HTTPoison are passed to the library’s own connection pool
whereas requests made with Mint are handled in the same process. While
HTTPoison is great for most use cases, Mint is a promising solution for anyone
who has specific control flow requirements.

I’m interested in this for some of the uglier API integrations I maintain
where an ordered chain of requests must be made with no guarantee of delivery
and responses that involve a considerable amount of in-memory processing
(large XML bodies to be exact). Having control over my process architecture is
preferable to leaving it up to the HTTP library’s connection pool in these
cases.

~~~
0xADEADBEE
Thank you so much for a concise answer to the exact question I had.

------
kt315_
What is the advantage over Gun?
([https://ninenines.eu/docs/en/gun/1.3/manual/](https://ninenines.eu/docs/en/gun/1.3/manual/))

~~~
whatyouhide
[https://news.ycombinator.com/item?id=19248319](https://news.ycombinator.com/item?id=19248319)

~~~
kt315_
I think Gun has very similar philosophy, e.g. it is connection oriented and
does not impose pooling and such.

~~~
ericmj
Gun starts a process for each connection. The main idea for Mint was to not do
this so that users can choose their own process structure.

~~~
kt315_
With Gun it is also possible to create a specialized process structure albeit
with more heavyweight processes behind each connection. Mint provides
lightweight (possibly more efficient?) abstraction to achieve similar results.
Thanks Eric and Andrea!

------
etxm
I wish a solid HTTP client and JSON library was a part of the std lib. I feel
like all of my apps have HTTPotion, HTTPoison, Poison, and Jason as
dependencies.

------
sysashi
this library was renamed from xhttp to mint and new name is much more
refreshing :)

I'm excited to try out this library (or something built on top of it)! In my
day to day work I use hackney, it's an awesome lib, but sometimes I struggle
with documentation.

------
KhoomeiK
A lightweight serverside Elixir framework like this is exactly what I was
looking for earlier this week. Phoenix is really clunky in my opinion and
pretty foreign (Ruby/Rails-like) coming from a lightweight Flask/Express/Go
background.

~~~
mmartinson
I'd recommend using plug + cowboy for your web layer and if you prefer to do
away with some of the more prescriptive parts of phoenix.

~~~
darkmarmot
Maybe we should package it together as PlugBoy?

------
dnautics
looking at the library, one of the exciting things (for me) is the existence
of stream_request_body. AFAICT there isn't an obvious way to do this in any of
the other libraries.

------
alexgaribay
Admins: Can we get the title updated to the actual article's page title to
avoid some confusion?

"Mint, a new HTTP client for Elixir"

------
chooseaname
Is it me or are we running out of names for things?

~~~
smacktoward
Nonsense, there's still plenty of available names out there.

In unrelated news, be sure to check out my new project
Asbhrjfuugwxcgxedzkyhbwf!

~~~
bryanrasmussen
Why would you name your project after my password!?

~~~
smacktoward
"I've got the same combination on my luggage!"
[https://www.youtube.com/watch?v=_JNGI1dI-e8](https://www.youtube.com/watch?v=_JNGI1dI-e8)

------
ProAm
People are the worst at naming products. Why call it Mint when there is
already an insanely popular Mint.com financial software. It makes
Googling/searching for product relevancy near impossible. It's like try to
search for Firefox on Android vs Firefox on a desktop information.

~~~
ryeguy
No it doesn't. All you have to do is search <language> <package> and you get
relevant results. Look through your library list, it's pretty common for the
names to only make sense in context.

~~~
dnautics
actually, if you need it fast, you can just duckduckgo "mint !hexpm"

~~~
elcritch
That’s handy!

~~~
dnautics
Yes sorry I should have also mentioned that it only really saves time if you
have ddg as your default searchbar engine!

