You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2021. It is now read-only.
The bundle only works with guzzle clients which are tagged.
This makes integration difficult or impossible when you have a service that wraps private guzzle clients created "in code".
It's not always easy to move the guzzle client to the service layer because their initialization options cannot be changed afterwards by the service using it, which means initialization options must also be exposed in the service layer and cannot be kept encapsulated in the wrapping service. You may also have even more complex use-cases with middlewares using sub clients (ex: guzzle-jwt-middleware).
Would it be possible to provide some kind of factory or configuration builder that would help "instrument" client created in code ? I've scanned through the code and it seems that adding the middlewares to the client stack would be the only thing required. Is that correct ?
You can actually already do that. The middleware are exposed as services, which can actually be injected in other services. So you could actually get the references to the various middleware you want to use, and that should be it.
To do that, you would only need to inject the stopwatch, history and logger middleware (csa_guzzle.middleware.stopwatch, csa_guzzle.middleware.history, csa_guzzle.middleware.logger). Of course, you would need to take care of the priorities of the different middleware in order to load them in the right order :)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The bundle only works with guzzle clients which are tagged.
This makes integration difficult or impossible when you have a service that wraps private guzzle clients created "in code".
It's not always easy to move the guzzle client to the service layer because their initialization options cannot be changed afterwards by the service using it, which means initialization options must also be exposed in the service layer and cannot be kept encapsulated in the wrapping service. You may also have even more complex use-cases with middlewares using sub clients (ex: guzzle-jwt-middleware).
Would it be possible to provide some kind of factory or configuration builder that would help "instrument" client created in code ? I've scanned through the code and it seems that adding the middlewares to the client stack would be the only thing required. Is that correct ?
Ideally something like this would be great:
The text was updated successfully, but these errors were encountered: