Since early 2018 my framework of choice has become Laravel.
I’m not strictly a Laravel developer and am not a fan of any framework being put before the word developer. If there is a better tool for the job (including no tool) I use what fits for the project. I don’t use PHP and Laravel to solve every problem.
Before Laravel
Prior to 2018 I was a fan of the Zend Framework which I started using 2009, before that was the time of self-built frameworks/libraries.
Everyone had their own library prior to the great framework era. Mine was created, improved, and tweaked over a period of ten years. As I worked on more varied projects the scope of my own framework increased to include eCommerce.
In 2008 I retired my own framework, as with most passion projects, my desire to continue supporting it diminished and there were plenty of better options appearing.
Why Laravel?
I was a fan of ZF but when I was about to start building the Costs to Expect API, I figured it would be wise to read the room and see the current state of the ecosystem. I was starting to create a Business around Costs to Expect. If I wanted to employ developers, I needed to ensure my products were using a framework which I could hire for.
The only two that stood out were Laravel and Symfony. I’d used Symfony and figured it was time to try something else so opted for Laravel. I’m sure there was a little more to it but 5 years later, I’m comfortable with both frameworks so it didn’t really matter in the end.
The Laravel Way, Nope
To me, a framework is a tool, no-one will ever be able to say I code the “Laravel way”. This isn’t to say I work against the framework, but I tend to prefer writing agnostic code. When I create a library or package, it doesn’t have the name of a framework in front of it, I don’t like tying code to a framework.
I’ve adapted over time but there are a couple of core architecture concepts I am just not a fan off. If you check my early Laravel code and my latest Laravel code you will be able to see this resistance but as I have said, it has waned over the years, particularly when the Laravel way is simpler or easier on the eyes.
Regrets?
Do I have any regrets, would I make any different decisions? One, if I had to make all the same decisions today, I think I would opt to use Symfony for the Costs to Expect API and stick with Laravel for much of the rest.
The Costs to Expect API is the backbone of the entire Costs to Expect service and it will be supported for many years. Plans for version 4 of the API mean significant changes are coming. The API uses very few of the features Laravel is famous for, a more traditional framework might suit it more. I’ve no plans to rewrite the API so it is Laravel for life now, it is however a change I would like to make.
Learnings
I’ve written several posts about Laravel on this blog and over time my knowledge has increased significantly. I haven’t read the entirety of the documentation, but I must be getting close.
Below are a few of the blog posts I have written relating to Laravel, as I write additional blog posts, I will update this section, so it is as up to date as possible.
Project Setup
Blog posts about either my project or development setup.
My typical project setup for Laravel: An overview of my typical project setup for a Laravel application, if you use Docker, Windows, WSL2 and PHPStorm this should be of interest to you.
Architecture
Laravel based blog posts on system design or architecture.
Action class usage in my Laravel Apps: How I structure my action class depends on the structure of the App. Is the App a typical App or a frontend for a REST API.
Invokable controllers: Invokable action classes are great and something I use all the time, but there are times when they are not suitable. Invokable controllers can come to the rescue, you get all the benefits of action classes and you can more easily organise your code.