Auth Facade Baseline 0:00Let's talk about the new contracts repository in 4.3. So, I know that we have a new auth generator, but let's imagine that you're not using that. So instead, we will create one on our own. And maybe we will call this SessionsController and make that plain. Okay, let's take a look. Now, imagine right here when the user wants to log in, well, you would typically use the auth facade, right? So you might do something like this, auth attempt, and then you pass in the data, right? Now, generally, this is fine. Nobody's going to beat you up too much about it.Now, generally, this is fine. Nobody's going to beat you up too much about it. And that's because, well, one, because we're using a driver system, and if we take a look at config slash auth, you could create your own driver and immediately allow for a different form of authentication, a custom one. So that's pretty cool. You would only need to update, for example, a service provider to immediately change out the functionality. Next, it's still testable if we can assume the framework. So maybe something like a functional test.Next, it's still testable if we can assume the framework. So maybe something like a functional test. And that's because we can do things like auth should receive attempt once and return. And that will use mockery behind the scenes. So it seems like all of this is taken care of. However, like I said, it still assumes the framework. It still assumes that we know what a facade is. So if you want to, for example, unit test this or use it outside of a Laravel application, well, you can't really do that. You'd have to rewrite your code. Abstractions vs Concretions 1:26well, you can't really do that. You'd have to rewrite your code. So what if instead we could follow basic solid principles? The type that state you should depend upon abstractions rather than concretions. And mostly, that's just a sophisticated way to say depend upon an interface rather than a specific implementation. And that way you decouple your code. As an example of that, imagine that when a user logs in, you need to send some kind of notification. Well, you could use something like pusher.you need to send some kind of notification. Well, you could use something like pusher. Maybe you have some pusher class to allow for that. However, now our controller is coupled to a concrete class, a specific implementation. And that means down the line is some new notification service becomes available. Well, if I want to embrace that service, I'd have to rewrite a lot of my code because I did not depend upon an abstraction. I depended upon a concrete class. So in this example, rather than expecting pusher, we would just expect some kind of contract, something like notifier.So in this example, rather than expecting pusher, we would just expect some kind of contract, something like notifier. And then, of course, behind the scenes, we can bind our pusher implementation to this contract. However, with this approach, when we do decide that we want to use something else, we only have to update one line of code to switch out our services. And that's the basic idea behind this concept. Depend upon abstractions, not concretions. Okay, so let's get rid of this example and bring it back to authentication. What is the solution? Inject Underlying Guard 2:55Okay, so let's get rid of this example and bring it back to authentication. What is the solution? Well, let's take this in incremental steps. If we don't want to use the facade here, then you could inject the underlying class. And that's still a concrete class, but we'll get there. Let's take it one step at a time. So that means within the constructor, we could inject it. But it's not quite as simple as just injecting the facade. Let me show you. Let's go to Laravel.com slash docs slash facades.Let me show you. Let's go to Laravel.com slash docs slash facades. And if we take a look at the facade class reference, you'll see that for our auth instance, this is the actual class that we would want to inject. So that means we could use this class and alias it as guard. And now we are doing a little bit better. Rather than using the facade here, we are injecting the underlying class. So now, like before, we can say this auth attempt. So you might prefer this. However, like I was saying earlier, we still aren't following this rule. Using Contracts Interfaces 3:53So you might prefer this. However, like I was saying earlier, we still aren't following this rule. We are depending upon a concrete class here. Instead, I want to depend upon an abstraction. And that's specifically what the new contracts repository in Laravel 4.3 allows for. If we switch to the browser and visit github.com slash illuminate slash contracts, you'll see that we have various interfaces for basically every single component. So let's take a look at auth in our case. Well, notice that we have everything from the user interface to the authenticator. And if we look through this, and by the way,Well, notice that we have everything from the user interface to the authenticator. And if we look through this, and by the way, notice how if nothing else, this makes for really good documentation. You can hunt through these interfaces and get a perfect idea of what the public interface actually looks like. So in our case, notice that, yes, we still have the attempt method. So let's pull this in. Notice that the interface is illuminate contracts auth authenticator. So we will update this. Back in sessions controller, I will remove this and instead pull in the authenticator.So we will update this. Back in sessions controller, I will remove this and instead pull in the authenticator. And to be quick, let's alias that as auth. So now we've only updated one line. However, we've now made our code that much more flexible. For example, if you wanted to unit test our sessions controller, well, it's as easy as pie to mock this interface and then perform your expectations. So for example, if you were using something like PHP spec, then you would type in what you are mocking, the auth interface, and then you could say auth attempt should be called if that's what you want to do.then you would type in what you are mocking, the auth interface, and then you could say auth attempt should be called if that's what you want to do. And now we don't have to depend upon our code knowing what a facade is or our code having awareness of the Laravel framework. Instead, we just have a series of contracts that we can very easily mock. So here's another example. Imagine that when somebody destroys a session, I don't know, maybe when somebody destroys a session, you want to update a file. It doesn't really matter. Not the most real world thing, but just to give you an example.It doesn't really matter. Not the most real world thing, but just to give you an example. Well, we need access to a file system, right? So once again, yes, you could just say file and delete. Like I was saying, nobody's going to beat you up too much. However, that makes it a little more difficult to unit test this. So why don't we use method injection in this case? I'm going to pull in not the file system class specifically, but instead the file system contract. Now, once again, I can say file system delete and everything's still going to work.but instead the file system contract. Now, once again, I can say file system delete and everything's still going to work. But now, rather than assuming that we have access to a specific Laravel component, we're just making a request for a contract. And if this is still confusing to you, just break it down to something as simple as possible. For example, imagine that you're a kid back in school and the teacher needs somebody to deliver some papers to the principal's office. Well, we can assume that the teacher doesn't care which student actually delivers the papers. The teacher just needs a volunteer. So if we were to translate that to code, a volunteer would sort of be like a contract.The teacher just needs a volunteer. So if we were to translate that to code, a volunteer would sort of be like a contract. The teacher says, I need some volunteer to do this work for me. I don't care who specifically, I just need someone. So volunteer is the abstraction. So in the context of code, maybe we have deliver to office, and we won't expect Susie or Johnny, we just want some kind of volunteer. So hopefully that helps illustrate it a bit. Now, on this node, if you're like me, you might wonder how, by type hinting an interface, it still gives us the correct implementation by default. How Interface Bindings Work 7:35Now, on this node, if you're like me, you might wonder how, by type hinting an interface, it still gives us the correct implementation by default. And if you were to research it, for example, you went to auth service provider, you might try to find some section where we say, when you receive a request for this contract, here's the implementation that I want you to use. However, it doesn't look like we see it here. And that's because you need to go to application.php within Illuminate Foundation. And now here's where you can see the bindings. So for our demo, here's auth.driver, which means, by the way, you could also do make auth.driver, and now you have a short alias that will refer to the implementation.So for our demo, here's auth.driver, which means, by the way, you could also do make auth.driver, and now you have a short alias that will refer to the implementation. You probably would never do that, but just as an example. And then we also used file system, and there you go. Here's that other binding. Now, here's the best part. Because the contracts repository allows us to not depend upon concretions, but instead abstractions, think about how much easier and lighter this is going to make your package development. If you write a package that uses Laravel, but doesn't necessarily require it, Benefits for Package Development 8:39this is going to make your package development. If you write a package that uses Laravel, but doesn't necessarily require it, well, in the past, you basically had to pull in all of these dependencies. If you wanted to use Laravel's native file system class, then you had to pull that in as a dependency. If you wanted to use queues or something else, once again, you had to pull that in. However, now that's really no longer necessary. Rather than requiring all of those dependencies, you just require Illuminate contracts. And then within your package, if you do want to use queue, you don't assume a specific implementation.And then within your package, if you do want to use queue, you don't assume a specific implementation. You just say, hey, I need some kind of queue provider, and anyone is free to step up and provide that functionality. So in closing, yes, I know this isn't the most glamorous thing in the world, but this is immensely useful. So don't forget about these.
