Is it me or are we running out of names for things?
They’ve already announced a change to CockroachHTTP
Mint, a new HTTP library for Elixir
41–50 of 58 posts
Re: Mint, a new HTTP library for Elixir
#42I 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!
Re: Mint, a new HTTP library for Elixir
#43What does Mint provide over, say, HTTPoison? Still can't quite grok what it's offers.
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.
Re: Mint, a new HTTP library for Elixir
#44I'm sure that won't be difficult to google.
Re: Mint, a new HTTP library for Elixir
#45While 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…
At least the naming is distinct within the Elixir ecosystem. It has always bothered me how close HTTPoison and HTTPotion are to one another.
not to mention that the dominant JSON parser used to be called Poison.
Re: Mint, a new HTTP library for Elixir
#46People 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.
No it doesn't. All you have to do is search and you get relevant results. Look through your library list, it's pretty common for the names to only make sense in context.
actually, if you need it fast, you can just duckduckgo "mint !hexpm"
Re: Mint, a new HTTP library for Elixir
#47looking 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.
Re: Mint, a new HTTP library for Elixir
#48Fantastic! 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://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!
Re: Mint, a new HTTP library for Elixir
#49I'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.
Re: Mint, a new HTTP library for Elixir
#50A 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.
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.
Maybe we should package it together as PlugBoy?