Intro to Service Container 0:00Okay, so let's move on to the Service Container, and I'm going to tackle this in two different videos. To start, we will review the basics of binding into the Service Container, and then in the next episode, we'll switch over to Service Providers, and we'll discuss how that fits into the picture. So to start, I'm just going to place this test code within my routes file. Now, Laravel offers an app facade where we can bind into the Service Container, the dependency injection container. But like Request or like Vue, there is a companion helper function. So we could call a Vue function anywhere, a Request function anywhere, and then also Binding With Closures 0:28But like Request or like Vue, there is a companion helper function. So we could call a Vue function anywhere, a Request function anywhere, and then also a App function anywhere. So if we want to bind into the container, we can reference any class path. For example, maybe I have a AppBillingStripe class, and within its constructor, it has some arguments that Laravel can't magically figure out for you through reflection. Maybe you have to give it an API key or something of that sort. All right. So let's pass a closure here. And now think of it this way.So let's pass a closure here. And now think of it this way. When the user requests an instance of Stripe, we're going to call this function and return whatever is necessary here, almost like a little factory. So we could return a new instance of AppBillingStripe, and then we could pass through the API key. And very possibly, that could be stored within a configuration item. So a lot of your services, when it comes to config, will be stored right here. And you'll see a few out of the box, like Mailgun, SparkPost, Stripe. These are here to get you started if they are necessary. So maybe you want to grab your secret key. Using Config and Services 1:31These are here to get you started if they are necessary. So maybe you want to grab your secret key. OK. You could say config, give the name of the config file, dot, and then the name of the key here. So if I want Stripe and then the secret key, I could always say services.stripe.secret. OK. So at this point, we've successfully registered this class with the service container. So now, if the user ever tries to resolve something out of the service container, and I'll show you two ways to call that, we could do app make, and there's also a helper function Resolving Bound Instances 1:55So now, if the user ever tries to resolve something out of the service container, and I'll show you two ways to call that, we could do app make, and there's also a helper function named resolve, which I quite like. But anyways, we could say app make, and then provide the class path. And let's see. Let's grab that, and then simply die and dump. But right now, we haven't even created this class. So let's say app, billing, Stripe.php, and then set our namespace like so. But next, we do need the constructor, right, that will accept the API key, which I can assign.But next, we do need the constructor, right, that will accept the API key, which I can assign. OK. So we're all set to go. We bind into the container, and that will, of course, return a new instance of the Stripe class passing through a secret key. And then later, we resolve that Stripe instance out of the container, and then we dump it to the page. So if we switch over to Chrome and run it, there we go. We have our instance.So if we switch over to Chrome and run it, there we go. We have our instance. Now, in this particular case, we don't have a secret key. So like if we go back to config services down to Stripe, yeah, why don't we just set something here? I'm sorry. We want Stripe secret. So we can set this within our environment file. And this will generally be the shape things take. In your config files, you don't want to reference private keys. Storing Secrets in .env 3:10And this will generally be the shape things take. In your config files, you don't want to reference private keys. Instead, reference environment variables. And then in your .env file, this is where you will store those secret keys. And they will not be part of your version control. They will be safe and secure. OK. So now, at the very bottom, I could say Stripe secret is the secret API key that Stripe.com gives me. OK.gives me. OK. Well, now, if we give this a refresh, sure enough, we have it. And this is really useful because otherwise, every single time I need to build up a new instance of Stripe, I would be forced to pass in all of its dependencies. And in a lot of situations, you have multiple dependencies. And you have to build it up, and you have factories, and it's fairly complicated. But with this approach, you do it one time. You register this into the service container. And then anywhere else in your app, you can resolve it out of the container.You register this into the service container. And then anywhere else in your app, you can resolve it out of the container. Now, to finish up, like I said, if you don't want to do app make, you can also use this helper function named resolve. And this will give us the exact same thing if I refresh, which is nice. There's actually a simple app function as well. Does the same thing. Resolve is just an alias. Stick with one or the other. I don't want to overwhelm you with choices there. Singletons and Advanced Methods 4:21Stick with one or the other. I don't want to overwhelm you with choices there. And finally, to finish up, there's actually a number of different methods you can use with the service container. I'm not going to cover them too much because you probably won't reference them overly much at this beginning of your Laravel stage. I would even say I bet some of this is confusing to you at first. If so, that's totally OK. But as a quick example, you can register singletons into the container. And a singleton is a single instance of a class.But as a quick example, you can register singletons into the container. And a singleton is a single instance of a class. So if you do it like this, no matter how many times you resolve this out of the container, you're going to get the exact same instance. It's not going to build up a new one and send it through to you. And that will be useful in a lot of situations. You also have other things where you can say, app, the current instance that you have of app billing stripe. Well, I want to swap that out with maybe something else I have or an existing object that I've already created.Well, I want to swap that out with maybe something else I have or an existing object that I've already created. So that will be available as well. There's a lot of flexibility here. Some of it's more advanced. So do not worry at all if it's confusing. But now, right now, we're throwing this all within our routes file. And we definitely don't want to put it here. So that begs the question, where should registrations like this be placed? Well, we'll talk about service providers in the very next episode.So that begs the question, where should registrations like this be placed? Well, we'll talk about service providers in the very next episode.
