Deprecate `FaradayMiddleware::Instrumentation` in favor of `Faraday::Request::Instrumentation`?

[ivy]

I noticed Faraday already has a Faraday::Request::Instrumentation middleware that's almost exactly like FaradayMiddleware::Instrumentation. The only difference seems to be that the middleware from Faraday core allows configuring the :instrumenter class if for some reason ActiveSupport::Notifications is inadequate.

[olleolleolle]

👋 Good idea! One way to do it softly could be to change the documentation about the middleware in this gem. Your description of the situation helps people learn about both.

The middleware shipped with this gem will not be gaining new features, I believe, as we desire to reduce the "collection" and go towards "an ecology" of middlewares and adapters. The Awesome Faraday repo is a step in that direction - telling users about what's out there, and letting them tell the world about their things (as opposed to hoping the the Faraday team invents and maintains the middlewares of their dreams).

[iMacTia]

I agree with @olleolleolle, the long-term plan is to split this library into multiple smaller gems, one for each middleware. And the main reason is that right now it's a bit of a nightmare to manage dependencies. We already have a template repo to facilitate this, however works on this are on hold to give priority to the Faraday 2.0 release.

Once we get there, the middleware here will simply not be ported, so for now it should be enough to document this or note it somewhere to make people aware of the one bundled with Faraday.