Time for a controversial opinion…about @laravelphp…facades.
Let’s think about the kind of technical debt that opponents to this idea/framework like to talk about. Facades, they say, make it difficult to know what dependencies a class has/needs; and when/where/how it is used.
The Laravel facades act like singletons (which means you initially access them through static methods). They resolve an instance of something through the IoC container. Ok, everyone who cares knows this.
So, it’s possible that when you call Cache::flush, you’re not flushing with a driver that ships with Laravel. It’s possible, when you’re calling the global view function, that you’re not getting a view from framework code.
That’s a good reason not to use the framework, assuming it’s the only way you are able to access cache and views. But, it’s not.
Aside from the shortcuts Laravel provides (facades being a shortcut), there are a myriad of ways to access things in the container. There’s class/method auto wiring/injection and manually resolving things out of the container, to name two.
At no point does the framework force you to use facades. At no point are you required to use global functions. They’re shortcuts. You wouldn’t cook a 4-course meal in the microwave, but it’s useful for heating pizza every now and then.
Now, imagine a world where you were forced to use Laravel facades. Why would they be a problem? Well, suppose you or something on your team overrides the default implementation.
Suppose you or someone else now gets unexpected behavior when they call facade functions. That’s a problem. To mitigate this risk, you should use interfaces.
Taylor saw this and created the contracts. Every meaningful bit of functionality is covered by an interface, and every meaningful driver implements an interface.
So, when you make your custom driver or use someone else’s custom driver; make sure it implements the corresponding interface and you’re set. That’s assuming you don’t work with or communicate with people.
If you do, there’s an even easier approach. Communicate with the people you work with. This can be through Slack or docs or tests or even Song.
🎵 I have replaced the cache driver with a new cache driver 🎵.
🎵 I have replaced the cache driver with a new cache driver 🎵.
The people who are most vocally abusive about the framework and its ideas chase the idea that they can step away from the project and whoever works on it will be fine. No magic. No bad ideas.
That’s a great goal, but it’s the less useful 100% unit test coverage of our time. You will never be able to step away, as the primary developer of non-trivial app, and have someone take over without issues.
The trouble isn’t just technical debt. It’s the knowledge you have in your head. You need to communicate that well or your code purity is bullshit. You do that by talking and documenting and singing (maybe) about what you know.
Laravel has damn good docs. They could be better. Show me large and popular free software that couldn’t do with more docs. They communicate facades and the alternatives. You have the choice.
There may be technical things the framework does that you don’t agree with, and that’s fine. Don’t use it. Feel free to not talk about the ways you hate it.
What you should realise is that maybe you’re using facades as an excuse to pick software that enables you to communicate less. Maybe you’re throwing the tools out with the communication bathwater. Or something.
If you can live with the optional tools the framework provides (talking about similar frameworks like @adonisframework and @masoniteproject too), and they make you money; then consider supporting the framework with your money and time.
