Service Subscriber: Lazy Performance

so this is what I've done intuitively

services.yaml

services:
        Mars\Command\DoCloudCommand:
            tags:
                - { name: 'container.service_subscriber', key: 'cloud', id: 'messenger.transport.cloud' }

Command class:

public static function getSubscribedServices()
{
    return [
        'cloud' => ServiceLocatorArgument::class
    ];
}

and it works.

Can you shed more light on it and maybe direct me to some documentation covering this edge case please?

Hey Francisc !

Excellent question - and nice job finding the solution! So, there are 2 separate things going on... and I don't want to confuse them.

1) Pretend for a moment that we're not using a service subscriber, because the first "thing going on" has nothing to do with service subscribers. In Symfony's container, there are many services. It depends on your app, but let's pretend that there are 200 services. The majority of these services are not "meant" for you to use directly. I mean, you can use them directly, but Symfony makes it "not very easy". Specifically, if Symfony "wants" you to use a service, it configures an "autowiring alias" for it. For example, Symfony DOES want you to use the logger service directly. So it creates an alias from Psr\Log\LoggerInterface to logger so that you can type-hint Logger and get that service. But Symfony doesn't do this for all services in the container. If you have 200 services in the container, probably only about 50 of them have "autowiring aliases". You can use those other 150 services if you want to, but you need to do more work. Specifically, you need to manually "wire" them into a service. Usually, that would look like this:

services:
    My\Cool\Service:
        bind:
            $someArgumentName: '@some_service_id'

In this case, I'm pretending that this some_service_id service is a service that I want to access, but it does not have an autowiring alias. So, I configure it specifically on the service: Symfony will know to pass this service to my $someArgumentName argument (you could also use arguments instead of bind - they are equivalent in most cases.

2) The above description is the really important piece to all of this. Now let's talk about service subscribers :). By default, they work via autowiring: your getSubscribedServices method returns an array of autowiring type-hints that you want to be included in your service locator. If you use a interface/class that doesn't have an autowireable alias, it won't work. That's what's happening with the transports. It's not that common to need to interact with transport service directly. And so, autowiring alias are not made available. This is why it didn't work originally. Your solution above (which is correct) is how you explicitly configure a service inside a service locator when it doesn't have an autowireable alias.

Phew! I hope that helps! The big picture is that you're trying to reference services that are not autowireable. You could also make them autowireable with global binds:

services:
    _defaults:
        # ...
        bind:
            # now you can autowire the cloud transport by using the TransportInterface type-hint AND naming the argument cloudTransport:
            # public function __construct(TransportInterface $cloudTransport)
            Symfony\Component\Messenger\Transport\TransportInterface $cloudTransport: '@messenger.transport.cloud'

Let me know if that demystifies it! Fun stuff!

Cheers!

Hey Beis

It's quite simple. Psr\Container\ContainerInterface is more low level Interface which describes basic PSR Container, however Symfony\Component\DependencyInjection\ContainerInterface is more complex and of course it extends Psr\Container\ContainerInterface. If you not sure which one to use for autowire you could choose one from Psr\. In Symfony both interfaces are aliases to server_container and you will get the same object, only IDE autocompletion will be different a little.

Cheers!

Hey Jose carlos C.

I'm not sure I'm following what you want to achieve. What you mean with "create an interface of each service or class". Have you read about compiler pass?

Cheers!

Hey, Yes I think that's the solution I'm gonna investigate what's going on.

Thanks

Finally I found it here https://symfonycasts.com/sc..., of course I didn't know the concept and I didn't know how to search. I'm going to try if I have any questions in linked video.

Thanks so much

Good find Jose carlos C.!

The tagging / compiler pass system is super advanced (not necessarily super hard, just not *that* commonly needed) but super power and cool. There is also a shortcut syntax if you want to automatically "inject" all classes with a certain "tag" into one of your services - https://symfony.com/blog/ne...

If you combine that with the "autoconfigure" feature, then you could make it so that ever class with a certain interface automatically gets passed to one of your services. Totally doable - the Symfony core does it all the time. Let us know if you have questions (maybe you already have and I haven't checked yet!).

Cheers!

Hey @Sidi-LEKHAIFA ,

We're happy to hear it was useful to you :)

Cheers!

Hey Jayson,

Thank you for this tip ;) More information about it you can find in Symfony docs: https://symfony.com/doc/cur...

Cheers!

Hey Ryan,

Thanks for sharing it with others Windows users ;)

Cheers!

Hey Lijana Z.

That's a good question. It depends, if you have a dependency of a service which opens a DB connection or communicates to a email server, then, for sure you will want it to be lazy. I always do this trick, it's quite fast and simple to implement :)

Cheers!

yea, maybe on those cases, but I do not know, if I use dependencies which open DB connection, unless of those dependency depencies do this. Connectioin should be opened in constructor as I understand for this to be a problem but I do not do this.

Are there some symfony classes openening DB connections on instantiation which I should think about?

I believe an Entity Repository opens up a DB connection upon instantiation but I'm not totally sure

Any update on that? It is happening to me. It is happening to me when die on the MarkdownHelper constructor. This helper is used as a filter. On the video, error does not appears, and title is shown...

I saw a question below. I was using wrong ContainerInterface. That's the correct one:
use Psr\Container\ContainerInterface;

hey Beis

Awesome that you found what's wrong! If you will have some issues in feature stay in touch!

Cheers!

Hey Eugem

Check where you are fetching the service `MarkdownHelper` from the container and instead try using Dependency Injection or implement a ServiceContainer

Cheers!

Hey AndTheGodsMadeLove

Thank you for your king words :)

About your question. You are correct, almost everything inside the "src/" directory is autowired and autoconfigured (if you didn't change your "services.yaml" file). The MarkdownHelper class lives inside the service directory only for highlighting the concept of services, but yes, it would fit better inside "Helper" directory

Cheers!

Hey Dominik!

Sorry, it's me again.

Ha! It's no problem of course :)

I can't understand the part of that video when we implement "getSubscribedServices" method from interface. I don't see point when we call that implemented method.

Excellent question. And you're right: we NEVER call this method. Instead, when Symfony is building its container, it "notices" that we implement this interface and IT calls this method. It uses that information to create a "mini container" for us that it passes as the first argument to the method. This method basically provides configuration that is used by Symfony's core.

In constructor we type hint interface "ContainerInterface" not a class. In my knowledge (still not good enough) we use interfaces to defined head of methods and during interface implementation we have to define body of that implemented methods. So how come we can type hint interface and use not implemented method? Did I miss something from previous tutorials?

Another good question :). If you dump($container) in the constructor, you will find that the object has a Symfony\Component\DependencyInjection\ServiceLocator class - which is a normal, concrete class (not an interface). So, you're 100% correct that you will always work with concrete classes. But, this ServiceLocator class DOES implement this ContainerInterface. So then, if we are passed a ServiceLocator object, you might wonder: why not use the ServiceLocator class in the type-hint for the argument instead of ContainerInterface? The answer is that, in general, using interfaces for your type-hints is a "better practice" that concrete classes. Even if you never need to do it, by using the interface type-hint, you (or Symfony) could, in the future, replace the ServiceLocator class with a totally different class. As long as that new class implements ContainerInterface, your code will still work. By using interface type-hints, we allow the "implementation" (i.e. specific class) to be replaceable with any other implementation of that interface.

In fact, Symfony feels so strongly about promoting this best practice, the a lot of "autowiring" (the ability to type-hint an argument and have Symfony automatically pass you the correct service) ONLY works if you use the interface. For example, in this case, if you change the type-hint to ServiceLocator, it will not work - Symfony is more or less "forcing" you to use the interface to promote that best practice.

Let me know if this helps!

Cheers!

Now everything got sense. Thank you for brilliant and clear answer :). I regret now I didn't find this website when I started learning PHP :).

Regards.

Hey Abelardo L.

I believe you are rendering an Article in your front page and because of that "die" statement your script stops being executed. Just remove the "die" statement :)

Cheers!

Same for me, writing die in the constructor results empty page on the homepage.

Hey Wazir Khan

Is there any other place where you are using the MarkdownHelper service?

Cheers!

Nope, checked the code again and again, earlier it was used in the show controller, removed that including the use statement from the ArticleController class. But still same result. The difference that I can see (comparing tutorial code and my code) is that I am using SF4.2.8 and the Interface used in the code is deprecated now. But it comes in another namespace Symfony\Contracts\Service\ServiceSubscriberInterface, though, I tried with the deprecated interface as well, didn't work that too. my bad luck :)

Hmm, that's weird. I believe I'll have to look at your code. Can you upload it to github or somewhere else?

Hi MolloKhan , thank you for the prompt support. Just pushed my code to github.
Here's the link: https://github.com/ahmadzai...

Ohh, so the die statement is inside the Twig extension class. That class is not being lazy loaded, what's been lazy loaded are all the services you define inside public static function getSubscribedServices(), in other words, MarkdownHelper

Thank you so much, I should have re-read/re-listened the scripts. Sorry for inconvenience.
I got the point. Working with Sf for some time, but on crazy way, now learning many new things that I never heard about. Once again thanks for such a fun tutorials (Y)

NP man! I'm glad to hear that you like our tutorials :)

Cheers!

Hey Qcho!

You make a great point! We are absolutely using a service locator pattern in this situation. In fact, the whole "service locator"/"service subscriber" feature we're using in Symfony was made possible by PSR-11 (the fact that the Container->get() method has a standard interface).

In general, yea, I think using a lazy service proxy is a simpler solution - you just use DI like every other places, so there's nothing extra to learn. But, there's one problem: you can currently only make your *own* services lazy - not core services. We could totally make MarkdownHelper lazy here. But, if we also needed the entity manager, we cannot make that lazy (well, technically we could with a compiler pass, but gets really complex). The service locator is a way around this. It's not as elegant as normal DI for sure. But, at least we're not passing in the *entire* container: we're passing in a "mini" container that only has the stuff we need in it. It's an unfortunate, necessary evil in some situations.

Cheers!

Hey bartek

Are you talking about the "autoconfigure" functionality? In that case, I'm fraid not. You have to define your Twig extension as a service and give it its tag

Cheers!

I meant Lazy Performance solution in twig.

Oh, in that case you can just fetch it from the container, that's how things was done in Symfony2