Replacing Faraday with Hurley

[technoweenie]

Though Faraday has been pretty solid for awhile, it has a number of big issues.

• Requests are made with an array of rack-like middleware and/or adapters. This makes it cumbersome to swap adapters out.
• Url handling has weird edge case issues.
• Adapters are of varying quality, and depend on specific Faraday releases.

I tried fixing this a couple years ago (#207), but eventually gave up due to the complexity in migrating from Faraday v0.9 to the mythical Faraday v1.0.

Instead, I sat down this last week and wrote Hurley, a major refresh of the Faraday code base.

• No more rack internals.
• A Hurley::Client can swap out connections without changing its properties.
• Optional support for Addressable::URI.
• Zero 3rd party runtime dependencies.
• Url handling is improved, with a clear API for changing it.
• Built-in automatic redirection following.

What about Faraday?

It hasn't seen much activity since v0.9's release. Hurley is what Faraday v1.0 would have been. Being a separate library means it can be loaded alongside Faraday during a gentle code migration.

So, only bug fixes for now (unless someone else wants to take the reins). I'm hoping to get Faraday-related projects such as Sawyer and Octokit upgraded to Hurley soon.

WTF is Faraday and Hurley?

Dumb LOST nerd lore :) Daniel Faraday is a scientist with brain damage that goes back in time and gets shot by his mother years before he was born. Hurley Reyes is brought to the island by Jacob, and eventually inherits and runs the island for many years.

Comments?

I know this is a big change. It's not ideal, but I think better than letting Faraday rot in its current state.

[sferik]

👍

[jfelchner]

I don't see why these code changes couldn't have been made in faraday? A 1.0 release would have allowed breaking backward compatibility. Now we have another gem which is extremely similar that people have to deal with? Am I missing something?

[mislav]

@technoweenie Would you be willing to write some sort of migration guide from Faraday 0.9 to Hurley? Then we could update our README by linking to it. Such guide could be hosted on Hurley repo, for example.

Having maintained Faraday for a long time, I'm a bit 😢 that Faraday will never see a 1.0, but I'm also proud of the work we did making the 0.8 and 0.9 series useful, stable, and a top HTTP client for a while. Good work everyone 👍

[technoweenie]

@jfelchner It's mainly to allow a slow migration off of Faraday. If you had an app using Faraday v0.9 AND Octokit, you wouldn't be able to update just Octokit to Faraday v1.0. You'd be forced to make a site-wide upgrade for everything.

@mislav: That sounds like a great idea, once we start using Hurley internally :)

[jfelchner]

@technoweenie I see. Thank you for explaining your reasoning!

[christhekeele]

This should probably be closed (re: lostisland/hurley/issues/43) but another issue opened up about documenting this project's own future. Has there been any thought in this direction over the last 6+ months I can start outfitting the issue description with?

[pengwynn]

RIP Hurley lostisland/hurley#43

[christhekeele]

😢 I hardly knew ye.

So where does this put Faraday today, with a year-old open issue that the project is dying and 4 years of PRs and plans for v1.0? Mostly curious about what the support/development story will be like looking ahead for the next few months.

[mislav]

@christhekeele I'm still casually maintaining Faraday and, in my opinion, this library is pretty stable. I might start thinking about a v1.0, but the ambitions for the big one-point-oh would be modest in comparison with our original goals.

From my perspective, the v1.0 should mostly focus on current usability problems of Faraday (i.e. eradicating ways that developers can shoot themselves in the foot using Faraday) and dropping any features that we don't want to support in the long run.

Please add your thoughts/ideas here: #202

As always, I welcome maintenance help by means of bug reports, triaging issues, and refining ideas. Faraday is definitely not "dying". A library not iterating as fast as before just means that it's stable.

[christhekeele]

Sorry–accidentally imported the "dying" adjective mentally from the hurley issue.

Of course I acknowledge the difference between stability and heat-death, but this issue's been open in my mind as well as on this repo over the last year, since I depend on Faraday extensively at work. Just wanted to make 100% sure this issue wasn't still an accurate description of the project state.

Thanks for keeping Faraday going, I'll be sure to read through #202 and keep an eye on all the activity on it as I revisit and update the API parts of my project.