Live data from Hacker News

Mint, a new HTTP library for Elixir

elixir-lang.org

11–20 of 58 posts

Re: Mint, a new HTTP library for Elixir

#12
post #2

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)

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."

Re: Mint, a new HTTP library for Elixir

#13
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.

Re: Mint, a new HTTP library for Elixir

#16

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.

Ouch, this is not a server library but a client! We updated the title of the blog post since it wasn't clear, not sure if we can update it here as well :\ Sorry for the confusion!

Re: Mint, a new HTTP library for Elixir

#17

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…

> 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.

Re: Mint, a new HTTP library for Elixir

#18

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.

Phoenix is just some additional libraries around Plug. The reason it’s so popular is that there’s almost no performance hit compared to using raw plug unlike a lot of other frameworks.

Re: Mint, a new HTTP library for Elixir

#20

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

The main thing is a processless architecture that lets you easily build architectures that are fine-tailored for your use case. You might build a process that holds many connection structs, or a use the connections directly in say a GenStage producer/consumer, or things like those. The idea is that you now have the building blocks to build whatever fits your thing :)
Post reply on HN