Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shutting this project down #43

Open
technoweenie opened this issue Jan 6, 2016 · 12 comments
Open

Shutting this project down #43

technoweenie opened this issue Jan 6, 2016 · 12 comments

Comments

@technoweenie
Copy link
Member

This project is incomplete, and isn't seeing any new work. I don't have any time to work on it, and unfortunately need to shut it down :( I'm not going to yank any gem versions, but I won't be replying to issues or pull requests from here on out.

You're probably better off with Faraday if you can't decide which of ruby's many http clients you want to use.

@georgeguimaraes
Copy link

Thank you for all your effort on hurley. <3

@christhekeele
Copy link

Should this lostisland/faraday#454 issue be closed then?

I just came back to this project, after having last heard about it through that issue, to start replacing my Faraday code, only to discover hurley had come and gone. :/

@aaronchi
Copy link

😢

@zekefast
Copy link

@technoweenie will you consider if somebody catch up this project? It seems from architecture point of view this project much better then Faraday.

@technoweenie
Copy link
Member Author

@zekefast I think I'd prefer you to fork and rename it. Hurley is kind of a dumb name anyway :)

@halostatue
Copy link

@technoweenie Do you have anything that would suggest the architectural direction you thought appropriate? My team at Kinetic Cafe has found Hurley to be useful over the last year and plan on forking and renaming, but we want to make sure we have an appropriate understanding before we start introducing our own ideas. @ravster would be our lead on this.

Thanks so much for this and Faraday both.

@zekefast
Copy link

zekefast commented Feb 3, 2016

@technoweenie Thank you for starting this and Faraday! As @halostatue mentioned it would be interesting to here you architectural plans about it if you had some. Thanks!

@halostatue, @ravster have you, guys, made some progress on this already? Please, point me where I can found you plans on this project. So I do not need to make one more fork of this.

@halostatue
Copy link

@zekefast we have not yet started this and probably won’t for a week or so. Our fork is currently at KineticCafe/hurley but we will be renaming it as @technoweenie has requested once we come up with a good name.

@technoweenie
Copy link
Member Author

The only thing I've written about Hurley outside of its code/README is lostisland/faraday#454. That outlines my initial goals. The big one was dropping the rack-inspired middleware system, into before and after callbacks on a Hurley::Client. I was also inspired by Go's HTTP client.

One really common Faraday question was how to test a built faraday stack. Since the stack is just an array of middleware, you'd have to know the adapter's exact array index in the stack. I think most people just create some factory method that takes a faraday adapter (net/http, typhoeus, etc).

I prefer Hurley's client callbacks to the rack middleware.

FWIW I really like Hurley, and may even help out on the renamed project. I just don't have the bandwidth to lead the project right now. Figured it'd be better to just put it out of its misery now before more people start depending on it in their projects.

@christhekeele
Copy link

I've been tinkering with a Faraday/Hurley inspired library for the past few months, finally sitting down and extracting it fully now.

It follows the direction Hurley was headed, but the implementation has a few extra design goals:

  • It represents all components of HTTP calls with plain-old ruby value objects. This makes it easy to add behavior the Ruby way, and translate between various low and high level HTTP adapters by having standard behaviour-less interim objects.
  • It uses dependency injection heavily, so that objects can be reused often and tested simply.
  • Internally it does mutation only on object initialization, to minimize potentially invalid states and be somewhat thread-safe without being clever. Public mutation methods return duped modified objects.
  • It extends the callback system with a 'pipeline' object that's a collection of before, around, and after callbacks, and wraps it up in an elegant little DSL.

I've about wrapped up the proof of concept, so once I document and push publicly I'll link to it here.

@zekefast
Copy link

zekefast commented Jun 7, 2016

@christhekeele, Your ideas looks same as mine. Did you released anything interesting? I really excited to take a look at it and provide feedback!

@christhekeele
Copy link

@zekefast It's preeeeeety beta still, since I no longer work the job I was building it for, so progress is now slower and rarer. But I have every intention of continuing to work on it, so if you don't mind the rough edges, and maybe error reporting (😄) or contributing (❤️) then check it out--it's called clientele!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants