How I learn’t how Laravel works

An illustration or image

One of the best things to happen to developers in the 21st Century is open source, at least for me. The power to look under the hood of some of the key software out there is mega. Not only do you better understand the software, you become a better developer by learning as well.

Getting Started with Laravel.

Prior to Laravel I did most of my PHP projects in either Yii , CakePHP and Slim for my APIs. Then the Laravel hype got to me , So on my next project I decided to try it out and it turns out its hyped for a reason. It had some interesting concepts that I wanted to understand.

Learning beyond the Docs

The default place to look up possible things you can do with any piece of software is its documentation . I must mention that Laravel has very good documentation . But then again the single source of truth is the Laravel code base. Documents are prepared based on what is present in code and the code is more accessible to me than the docs. So why not look up that instead :) . You might be thinking this is hard to do . Its very easy . Example

lets say you want to work with Laravel’s collection, which is a nice way to work with arrays. To make a collection out of an array you first collect it eg collect(["name"=>"joe"]) now depending on the editor or IDE you use you should be able to locate where the collect method lives by placing your cursor on it.

An illustration or image Places the collect keyword exist

With most IDEs pointing your cursor on the keyword and pressing down on CTRL or Command will show you where this keyword is implemented and sometimes places you have used it. With this you are able to see how this is implemented as well as discover other callable methods.

List of other callable collect methods

For me this is gold as at a glance I can experiment and know what more I can do as well as understanding how these things are implemented. This saved me one time where I had code for counting my collection collect([])->count() . Count is just a wrapper around the PHP count function and so I knew if the collection ever ended up being a string I will silently get back 0 so I handled that nicely as the collection count method won’t do that for me.

Using Tinker.

Well once I get to see all the options I have for a given Concept, Class or Function I immediately try out these methods using tinker. Tinker is the default REPL which allows one to try out Laravels components without having to deal with views. Its similar to the rails and Django console.

It also has some cool features which I won’t get into, but as mentioned its one of the quickest way for me to try out stuff I discover within the framework.

./artisan tinker

From the above you will notice it also gives the namespace which collect belongs to. From there I can also go ahead and look it up some more.

Using dd(debug_backtrace());

Alright so we’ve looked at how to discover some of the things packed in Laravel for developers. One other important piece is understanding how Laravel deals with the request/response flow.

For me whenever I need to understand the flow of any PHP project I pull out die(var_dump(debug_backtrace())); . I drop this at any part of the code I understand and run the app once again, view this in my browser and I end up with a complete execution stack up to where I dropped this. I can then follow through and understand how each class/method/file processes the request and hands over execution to the next. This gives me an understanding of how the app works as a whole. With Laravel even better we can replace die , var_dump with dd so we end up with dd(debug_backtrace()); which gives us something much more pleasant to the eye.


So above I have the complete execution path till it gets toServiceController You can see that the request came through the Controller.php file from within the Routing package. Ow by the way the laravel framework it self is based of a bunch of packages together known as illuminate which you can find on GitHub. There use to be lots of Symfony parts in there as well . With every new release of Laravel I run debug_backtrace just to see if there are any changes in the request/response flow. You get to learn a lot by doing this . Also it might take you a while to understand exactly what happens at every point.

Learning from other Laravel Projects.

One interesting thing about code is that not even the authors of the tools can completely predict how developers will be using some of the things they created.

For example some developers use blade for scripting and others as a stand alone tool for creating static pages. This is also true for things within the framework.

One of the best ways to pick up some of these things is to read the source of Laravel projects by other developers. One of the ways I decide which project to look at is through the GitHub PHP trending pages This way am more likely to find young Laravel projects that have smaller footprints. I can now follow the progress of this projects and learn while its grows. Also the few contributions I have made has been through this process.

People Behind the Framework

One other important step that I take is to lookup those involved with the development of Laravel. This not only allow me keep up with the state of development of the framework. It also gives me a sense of why something exists or was added. I picked this approach up from school , where the only way I could understand something like calculus was to follow the life story of Newton and how he stumbled on Calculus. Also with something like PHP following the story allowed me understand why we have strtoupper and str_replace which is because the implementation is by two different people :). Anyways.

These are some of the techniques that came to mind that I use. There might be more that escaped me but hopefully you find some of these techniques useful, And apply them as you try and understand the inner parts of Laravel.

Here is another article for you 😊 "I love the internet habitat f**k MARS"