How Do You Work in Laravel — 2020 Edition
Back in 2017 I wrote a Medium post title “How Do You Work in Laravel”.
I was very interested in how many other people work with Laravel as I’ve seen a few different permutations. For example in my past article I wrote about a Service/Repository pattern, aside from that I’ve seen CQRS architecture placed on top of the Laravel MVC and I’ve seen many versions that are straight out of the box as per the documentation describes.
One innate thing about the human brain, it evolves. So our standards in coding change, ideally for the better. I wanted to write this article to represent my change in coding structure, plus how I work as my career has evolved more into a tech management space.
To start, a refresher of my previous patterns can be summed up in the following graphic: (Note: a deeper technical dive can be found in the old article)
As I worked in this pattern, it began to feel cumbersome to add a Service and Repository classes to everything. I began to ask myself..
Can’t the Laravel Model represent the repository layer just as well? Can I get code done faster and better if I remove this Service/Repository layer?
I mean for the most part, my code is straightforward input/output.
I’ve started using Model Events a lot more to handle extra layers of logic that do not need an immediate response in my API.
If my code needs to save to multiple tables or has extra complexity required for the API response, I do allow myself to create Service classes, but I try and use them in a very Domain/Action type of way. Single Action Controllers might also be a solution, but I have not bought into using them yet, maybe I need to evolve 😁.
Another tool I want to try out at some point is this package called Laravel Actions. Maybe that’s a future article.
So, did devolve or evolve?
The best way I can explain that is through my experiences evolving into technical management.
What are the benefits of sticking closer to the Laravel ecosystem?
- Laravel is open-source. It’s popularity cannot be understated. A simple glance at its Github repo shows over 2,000 contributors, 21,000 stars and growing, used by half a million projects on public Github (many, many more privately).
It has automated tests, an active community on GitHub issues, Discord, Slack, Twitter, and much more.
If you can’t trust the power of the hundreds of thousands (if not millions) of developers that use Laravel who can you trust? - Free Documentation! It makes hiring and training easier. Laravels great documentation means less I have to write in our company documentation. If a developer understands the Laravel codebase, they can reasonably push a great commit on their first day.
In my pre-framework days, we wrote our own frameworks from scratch, and very rarely they had proper documentation and very rarely did people stick to the conventions by the original architects and we ended up with quite a bit of tech debt. - Easier package integration. Not that I encourage using a package for everything, but there are some great packages out there and a lot of those great ones we can over-ride or extend their classes to handle our edge cases. The Laravel Auditing package comes to mind for me, as I had a case where I needed to create my own Audit model, and I was able to extend their Model class in their package and create my own Model methods and everything continued to work.
How you use Laravel is up to you. Just as I mentioned about Laravel Auditing I was able to extend it to my use case, the same is possible in Laravel through the standard OOP concepts. Need to create your own BaseModel class? Go for it.
Anytime you see:
That is Laravel telling you, you can put something here, or not, the software will continue working either way.
Another thing I wanted to touch on as part of my evolvement into tech management is the importance of planning.
As a young developer I loved diving into the code and building a solution. Over time, I’ve learnt that doesn’t always lend to the best code output. What I’ve seen in my code and others is something that resembles a comic that I used to read growing up called Family Circus.
In that comic it shows the path the boy travels through his neighbourhood(🇨🇦). Now imagine you are a developer diving into a bug without planning your route, you might start coding towards a solution, leaving a trail of code as you step through, adding some conditionals, debug statements and finally maybe you create variables that do nothing. Ideally a code review will clean this up, but it still can be missed.
For each step you added you create cyclomatic complexity and if you have automated tests in your code, you need to consider each new step you created.
But, what if you took the time to research and plan what you are doing and understand the problem before you write a line of code? Maybe the solution is one line in your Controller and you are done? You’ve created less Cyclomatic complexity, you have less scenarios to test and you have a readable solution. I mean, hypothetically that’s the goal. Sometimes you might still have to travel through the code and that’s fine, but you understand what you need to do much better.
Continuing the topic of planning, when in a planning meeting about a feature I like to come out with the following:
- Tickets — In our bug tracking software I like to have a list of API’s, components or tasks that we want to accomplish, if possible I like to have story points or some form of estimation to show complexity. If a ticket has a large story point/estimation value that’s usually a signal that we need to break this ticket down a bit more and plan it out.
In this scenario it’s also acceptable to not have an answer how you might code something, or how long it will take. In that case we create investigation tickets that are time-boxed to research a possible solution. - JSON Schema — I usually work in a world where the API is separated from the frontend or mobile app. What we do is create a JSON Schema file that is a contract that our API will deliver towards and our front end can expect to consume. From this “contract” team can create a temporary json file that represents the expected output that can be consumed by the frontend developers to create their tests and components. The API team can now use this json file to write their tests before they write the API and then as they write the API, they can expect this code should make tests pass. Voila TDD. 😉
- Wireframes/Documentation/Knowledge — In these planning meetings you might whiteboard some discussions or track some decisions made in the meeting. Now this information can be taken forward to showcase the plan and then future teams can also refer back to this information as needed when fixing a bug or adding a feature to the code.
While this topic shows less code examples than my previous article, my hope is that it helps some people define their processes to developing good software. Remember it’s ok to evolve and improve this process.
