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

Convert Internals to Faraday to support middleware and instrumentation #208

Open
hexgnu opened this issue Jan 27, 2014 · 10 comments
Open

Convert Internals to Faraday to support middleware and instrumentation #208

hexgnu opened this issue Jan 27, 2014 · 10 comments

Comments

@hexgnu
Copy link
Owner

hexgnu commented Jan 27, 2014

Right now we have reimplemented things many many times. It'd be nice to convert all of the internals to faraday so that we can easily extend the linkedin gem.

@hundredwatt
Copy link
Collaborator

@hexgnu The Twitter gem is moving from Faraday to HTTP (https://twitter.com/sferik/status/426910345173929984). I checked out the HTTP gem over the weekend, the interface is slick, but the internals maybe a little immature.

Let's discuss on Thursday, though if Faraday is what's comfortable for both of us, we should go with that.

cc: @sferik

@sferik
Copy link
Collaborator

sferik commented Jan 27, 2014

The Twitter gem is moving from Faraday to HTTP

I should clarify…I’ve been working on a branch that swaps out Faraday for the HTTP gem, but it’s still experimental and far from being merged into master. I wouldn’t expect this change to happen any time soon, if ever. That said, the early results in that branch look promising.

the internals maybe [sic] a little immature

Yeah. The current version of the HTTP gem (0.5.0) is missing a bunch of stuff but it’s under very active development. I wouldn’t recommend switching until 0.6.0 or 1.0.0 is released. The HTTP gem doesn’t support middleware or swappable adapters like Faraday, so if your users depend on those features, I wouldn’t recommend switching at all. That said, after making the swap, tests run about 4X faster (4 seconds vs. 16 seconds), which is quite nice.

@hexgnu
Copy link
Owner Author

hexgnu commented Jan 27, 2014

awesome thanks @sferik for clarifying

@hundredwatt
Copy link
Collaborator

@sferik Thanks for clarifying, definitely not room in 140 characters for all that nuance :)

Sounds like we should use Faraday @hexgnu

@ryanatwork
Copy link
Collaborator

About 2 years ago in the v4 branch I started moving this gem to Faraday:

https://github.com/hexgnu/linkedin/blob/v4/lib/linked_in/connection.rb#L22

@hexgnu
Copy link
Owner Author

hexgnu commented Jan 27, 2014

Oh wow cool @ryanatwork I'll see if I can resurrect some of that

@RKushnir
Copy link

RKushnir commented Feb 3, 2014

@hexgnu Is this a matter of replacing oauth with oauth2 gem? Or some major rewrite? I have a pretty urgent need for caching, so I'm thinking about the best quick way to accomplish this. Maybe, you could tell what's the likelyhood that you switch to faraday in the nearest couple of weeks? Or do I better just go with some temporary solution(monkey-patching, reimplement my own subset of the gem etc.)? Thanks.

@hexgnu
Copy link
Owner Author

hexgnu commented Feb 3, 2014

@hundredwatt and I paired up on this pretty recently so I'd say this will be happening within the next couple of weeks. We've got a few test failures to fix but overall it went well.

Also I'll add in the ability to add your own middleware layer to faraday so you can cache responses.

Cheers, and stay tuned

@hexgnu
Copy link
Owner Author

hexgnu commented Feb 3, 2014

@RKushnir #212 currently in progress.

After this is in place you'll be able to

LinkedIn.middleware << FaradayMiddleware::Caching

Which would cache requests and responses.

@RKushnir
Copy link

RKushnir commented Feb 3, 2014

@hexgnu That is impressive! Thanks.

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

5 participants