People worry that choosing Laravel means that you're betting your product on one person's opinions on Taylor's choices, or Laravel's ecosystem, or Laravel's way of doing things. And if Laravel ever went sideways, then, well, you're trapped. And there's truth to all of that. Framework coupling is real, but the degree of coupling, and whether it matters to your project, depends on choices that you make while building. So let's look at the coupling that actually exists, and where Laravel gives you

project, depends on choices that you make while building. So let's look at the coupling that actually exists, and where Laravel gives you some escape hatches. To start, we can just look at code that we have already written. I mean, the money class that we wrote, and the building calculator. These are, of course, just plain ordinary PHP classes. I mean, look at what's not here. There's no illuminate, there aren't any facades. There's no app helper.

There's no illuminate, there aren't any facades. There's no app helper. In fact, there's no helpers whatsoever. And there's no dependency injection, but you know, that that's nothing that we really need to be concerned with because, you know, thinking in terms of going from a Lara vel application to some other framework, every framework these days is going to have some kind of dependency injection.

of dependency injection. Now how it works is, well, that depends upon the framework, but we wouldn't have to worry about that in our own code. But the pure PHP code that we write, well, of course, work perfectly in Laravel . It would also work perfectly in symphony, in slim, in any other custom framework, or no framework at all, Laravel didn't force you to couple it here.

framework, or no framework at all, Laravel didn't force you to couple it here. It's your choice not to second, Laravel implements standard PHP interfaces where they exist. This means that your code can depend on abstractions instead of Laravel's concrete implementations. And to see which standards Laravel supports, just go to the vendor folder, we want to scroll on down to PSR and then everything inside of this PSR are standards that Lara vel supports.

on down to PSR and then everything inside of this PSR are standards that Lara vel supports. In fact, any component that Laravel uses will implement these interfaces, if it makes sense. For example, the logger, if you look at the source for the logger interface, well, Laravel's own logger implements the logger interface. So you could build to these abstractions and not use Laravel's implementations at all,

So you could build to these abstractions and not use Laravel's implementations at all, if that's what you wanted to do. That's perfectly acceptable. And the most powerful decoupling technique is designing around our own interfaces and then binding the implementations in the container. I mean, let's look at the app service provider because we've already done that. We defined this logger interface so that we could implement that interface and use our

We defined this logger interface so that we could implement that interface and use our own concrete loggers, where we had the file logger and then we had the database logger that doesn't do anything. But you know, that's the general idea. So that's we build around our own code so that if we ever need to move away from Laravel, then you know, everything is already there. The only thing that we would have to do is in whatever framework is set up the

then you know, everything is already there. The only thing that we would have to do is in whatever framework is set up the binding between our interfaces and our concrete classes and then go from there. If our concrete classes are coupled in any way to Laravel, then we would just have to make the necessary changes or rewrite. I mean, there's a lot of variables to account in that. But if we design our applications around our own code, then the better off we will be

But if we design our applications around our own code, then the better off we will be if we ever need to migrate away from Laravel. But now let's address the elephant in the room. And that is eloquent models. Eloquent uses the active record pattern. And our domain entity extends a framework class. If it's user, then it's authenticatable, authenticatable. Yeah, authenticatable. If it's something else, then it is going to implement the model.

Yeah, authenticatable. If it's something else, then it is going to implement the model. So it inherits save and delete query scopes, relationship loading, hundreds of methods that Laravel's base model class has. And this, this is coupling. And this is probably going to be the hardest part of the coupling because every application works with data, usually that data is in a database. So if we need to move away from Laravel, then every model needs to be rewritten

works with data, usually that data is in a database. So if we need to move away from Laravel, then every model needs to be rewritten . And that, that could be horrible. But this is where other patterns can at least provide some kind of boundary, like a repository. We could define a repository that essentially wraps around our models. And that will allow us to decouple our domain from eloquent. But it's still a lot of code for a problem that, well, let's face it, most projects will

But it's still a lot of code for a problem that, well, let's face it, most projects will never face. Because here's the question, will you actually migrate away from Laravel? For most applications, the answer is no. The productivity you gain from eloquent relationships, query scopes, and all of the wonderful features that eloquent brings outweighs the theoretical coupling cost. But if you're building a product that generally might need to support multiple frameworks,

But if you're building a product that generally might need to support multiple frameworks, or if portability is a hard requirement, well, then the repository pattern gives you at least some kind of boundary, Laravel doesn't prevent you from building it. It just kind of makes things hard to get away from. But that's going to be true for any framework. So are you locked into Taylor's decisions? Well, you're coupled to Laravel in the places that you choose to be coupled, routing,

Well, you're coupled to Laravel in the places that you choose to be coupled, routing, migrations, eloquent, that coupling is usually worth it. But if you care about escape hatches, Laravel doesn't prevent them. Just be honest about the trade-off. Productivity now, extraction costs later. Laravel isn't a trap, it's a choice.