Skip to content

add profile client #136

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

Merged
merged 1 commit into from
Apr 3, 2017
Merged

add profile client #136

merged 1 commit into from
Apr 3, 2017

Conversation

fbourigault
Copy link
Contributor

@fbourigault fbourigault commented Apr 1, 2017

Q A
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Related tickets Partially #108, Partially #93, Partially #135
Documentation N/A
License MIT

What's in this PR?

This add tracking of request target url and method. I choose to decorate the Client at the lowest possible level (i.e not the PluginClient, but the inner one) to be able to catch what goes in and out the Client and avoid false informations because of the registered plugins.

Technically, when the profiling is enabled, each client factory is decorated with a ProfileClientFactory which returns the original client decorated with a ProfileClient.

This is what I suggested for #135

Why?

Those new collected informations are required to write a better profiler.

To Do

  • Unit tests
  • Update changelog

@Nyholm Nyholm self-requested a review April 1, 2017 21:57
Copy link
Member

@Nyholm Nyholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this PR!

*/
public function __construct($client, Collector $collector)
{
if ($client instanceof HttpAsyncClient && $client instanceof HttpClient) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can remove all this logic by using the FlexibleHttpClient

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I use it directly without testing anything or should I use a condition to juste use FlexibleHttpClient when only one of both interface is implemented?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved this logic to the ProfileClientFactory and now FlexibleHttpClient is used.

public function __construct($factory, Collector $collector)
{
if (!$factory instanceof ClientFactory && !is_callable($factory)) {
throw new \RuntimeException(sprintf('Second argument to PluginClientFactory::createPluginClient must be a "%s" or a callable.', ClientFactory::class));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First argument...

use Http\Client\HttpClient;
use Psr\Http\Message\RequestInterface;

class ProfileClient implements HttpClient, HttpAsyncClient
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a class comment that explains the purpose of this new client.

@fbourigault
Copy link
Contributor Author

fbourigault commented Apr 2, 2017

I added the ProfileClientTest.

@fbourigault
Copy link
Contributor Author

I would do extensive tests about my code but how can I create a client using a callable instead of a factory with the bundle?

Copy link
Collaborator

@dbu dbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great, thanks! i only added some comments on phpdoc and code clarity.

re callable: maybe this could help? http://stackoverflow.com/questions/29792862/how-can-i-inject-callable-into-symfon2-dependency-injection-container-service - i assume you can do the same but configure a class as factory class.

that said, not sure if you need a callable - you can also set a service to a fixture class or something, if you need that instead.

*/
public function __construct($client, Collector $collector)
{
if (!$client instanceof HttpClient || !$client instanceof HttpAsyncClient) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would write this as if (!($client instanceof HttpClient && $client instanceof HttpAsyncClient)) { to make it more explicit. (just rewriting the expression, the logic is the same)

private $collector;

/**
* @param HttpClient|HttpAsyncClient $client
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this indicates that the client can be either, which is not correct. it needs to implement both. no idea if there even is a syntax for that, but the description should say that.

use Psr\Http\Message\RequestInterface;

/**
* The ProfileClient decorates any HttpClient (or HttpAsyncClient) to gather target url and response status code.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

description is not accurate, it decorates a FlexibleClient or something else implementing both interfaces

{
$client = is_callable($this->factory) ? $this->factory($config) : $this->factory->createClient($config);

if (!$client instanceof HttpClient || !$client instanceof HttpAsyncClient) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same remark as above, i think !(instanceof && instanceof) would be easier to read

}
}

interface ClientInterface extends HttpClient, HttpAsyncClient
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or just mock flexible client? not sure whats better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FlexibleHttpClient is final!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does that prevent from doing $this->createMock(FlexiblehttpClient::class) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

argh, thats quite stupid. ok then this is fine.

Copy link
Contributor Author

@fbourigault fbourigault Apr 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the drawback of the final keyword. But this case is special as we have to Mock both HttpClient and HttpAsyncClient interface.

Should this interface moved in an other package (in the tests section)?

EDIT: having this interface here makes it not autoloadable which is good!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah i think its right to have it here. its not something that anybody should rely on.

@fbourigault
Copy link
Contributor Author

From my POV, this is ready :)

Copy link
Member

@Nyholm Nyholm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great. Im happy with this PR.

Good work and good review by David!

@Nyholm Nyholm merged commit 6c8dc49 into php-http:master Apr 3, 2017
@fbourigault fbourigault deleted the profile-client branch April 3, 2017 12:59
private $collector;

/**
* @param HttpClient|HttpAsyncClient $client The client to profile. Client must implement both HttpClient and
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about introducing a new interface extending both interfaces and type hinting against that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That may be convenient but it does not comply with the Interface Segregation principle.

I know we talked about this before and decided not to, but I cannot find that thread atm.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

@greg0ire greg0ire Apr 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ISP states not to make big interfaces, so that people don't need to implement all of the methods inside. In your case, they still can choose to implement either inherited interface, so ISP wouldn't be violated here IMO. And if you do need both methods, it looks like the best bay to express that need.

Copy link

@greg0ire greg0ire Apr 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, I don't understand what inversion of control has to do with this, but I trust you have your (maybe fairly complicated) reasons. Plus, I wasn't aware there were other capabilities, and if an interface is introduced for every combination, this could get quite messy… the real thing to fix here might be php itself , to add the possibility to type hint against several interfaces :P

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More about this here

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

Successfully merging this pull request may close these issues.

4 participants