Dissecting Laravel Application class

This class along with core framework represents cornerstone of internal Laravel machinery. In the spirit of good software design it is responsible for one thing. This class, speaking from the highest level is conducting everything that exist in the framework core. It provides life to all service providers. But, underneath the simple surface we can find very sophisticated design with complex relationship to and from client and framework. Let’s take a peak inside.

This class is instantiated very early in application life cycle. It happens in start.php file under bootstrap/ folder . And it is initiated by client request. We already can see that it has direct relationship with HTTP protocol and transport layer. To proof take a look at Applicaton constructor - it is expecting Request object as it’s argument:

//
public function __construct(Request $request = null)
{
$this->registerBaseBindings ($request Request::createFromGlobals(

$this->registerBaseServiceProviders();

$this->registerBaseMiddlewares();
}
//

In case there is no explicit Request, constructor will fetch request data from globals. It is internally done by Symfony request class - which is used by Application. Alongside Symfony request class , our Application has relationships with 17 classes. We can see that Application is simply using those classes which are represented as service providers. They create a compositional relationship. On the other hand, our Application is extending Container class (in other words becomes a container ) and implements three interfaces. So already it can become a mass if the Laravel developers didn’t provide a way to organize those relations . It is done through Facade design pattern and Container bindings and resolving of service providers. These patterns deserves a dedicated posts, so let’s get back to more abstract view. One great geeky detail is that Application instance is registered to itself as a service provider in foundation/start.php file.

Application class contains 48 public and 13 protected methods. Those methods can be seen as implementation of Application responsibility to conduct all service providers in a consistent way. Most of ( but not all) Application responsibility is concetrated around service providers and HTTP request. It is not surprising since considering how important are those areas.

At the end of this brief overview try to imagine how would it be to create “headless” Laravel application or application without application ? Download core framework from the github and take a look at tests directory. Creator of Laravel did just that, by testing and simulating real environment - without app layer. Application class is present, but not outside of framework. It is instantiated from the tests. In my opinion developing in this way ( with tests ) is what is separating a real web-programmer from the rest of the world :)

Thanks for reading.

Laravel architecture layers

Let's talk about Laravel structure. What is it and why having good structure is important - in terms of built in framework architecture.

In this post, I will categorize some Laravel layers as architectural. It may sometimes clash with classic definition of architecture, but it helps me to build good mental model in order to understand framework.

From the highest level, around and inside of Laravel we can reckognize:

1. Client-server architecture
2. Laravel specific micro-architecture ( my term )
3. MVC (model, view, controller)

Client-server architecture lives on a level that is not specific to Laravel, but is implied by the framework. You can implement client-server architecture without Laravel, but opposite is not possible. Web as distributed system uses HTTP protocol as a transport layer to provide content to clients in the client-server model. It is true without any server side processing. Web 1.0 or static web is perfect example. Client-server model as such ( with transport protocol ) underlines whole Laravel implementations. It is implied that we will be writing applications that uses it. Further, we can say that client-server model with HTTP is a kind of edge layer to framework, which simply passes data to framework and give back response in the form of HTML document ( mostly ). Everything else is happening inside  framework - in  another Laravel specific layer. Point of entry to Laravel from client request is a public folder, which is read by server. After Laravel reckognize that request, it will forward data along with path and headers to something that I call Laravel micro-layer. HTTP request is indeed very simple, and there is nothing complicated with it. Best way to think about client-server model is as a transport mechanism that delivers data to some address.

Laravel specific micro-architecture is a middle layer that ties all pieces of framework together and connects client with Laravel. It is represented inside app folder structure. For me, best way to think about this layer is as  internal command-line for Laravel implementation. If you think, it acts like a CLI by calling core API and organizing service providers into meaningful structure. It is possible to interact with core without app layer, but that is not very useful if you are not writing tests. So app layer is a front-end layer of two part internal Laravel architecture. It becomes obvious whan you download core framework from github, without application. Developers spend most of their time in app layer, since it is made for interactiong with Laravel internals. App layer is at the deeper level represented in the form of Application class - a class that server as a glue for all service providers.

Think about service providers as a row power for your application, that comes in many forms. That power should be used in a way that is appropriate for you app. Service providers have their own responsibilities and are already ready to use. Thinking about providers leads us to next layer.

MVC (model, view, controller) is a well known architectural pattern for separating view from data (model). It is implemented in a Laravel through Model, View and Controler folders in application along with their associated classes. As you can guess, MVC classes are provided to application like a service-providers. MVC providers should be considered as primary points of organization and interaction inside application. Everything else is related to MVC. That's why there are dedicated MVC folders in application. If client-server model is responsible for physical separation ( or n-tiered ) MVC represent logical division inside application. Client-server model is exposed to clients while MVC is exposed to developers. All other providers are directly of indirectly related to MVC. For example session, cookies, filesystem, cache, database - these are all persistance mechanisms that finds their place in MVC designed Laravel application. In fact MVC is dominant pattern in the web frameworks, so it is not strange that Laravel is implementating it in its own way.

Everything else beneath MVC and overall architecture belongs to design decisions - how to connect or interact with providers, or how to extend their functionallity. Architecture establishes common structure in which design is possible. With Laravel this is represented through layers described above. I think that it is crucial for serious Laravel developer to become familiar with this layers, in order to master this awesome framework.

Thanks for reading.

How I moved to PHP thanks to Laravel

Structure is one of the area that brought me a lot of pain while learning programming.

 If I tell you that my first language was Javascript, you'll understand why that's the case. I don't have anything against JS, I love and use that language daily. It had awesome brain-teasing mix of paradigms. Problem is ( as noticed by many developers ) that JS is lacking a good structure. It can especially confuse someone who is introduced to programming with Javascript as a first language ( like me ). With JS you are launhed straight into orbit of closures, prototypes, mutability and incredible dynamism.

That's why, in one moment of my career  I decided to move to some more traditional and better structured language. PHP was somehow natural choice, since I am a web developer. In the beginning ( while PHP was mostly procedural and represented by Wordpress and family ) I couldn't quite grasp it. I was a experienced JS commando that used to shoot with first class functions and throw objects around freely. So PHP wasn't a good choice at that time. And then came newer version of PHP that introduced support for object-oriented and functional  paradigm (a among other goodies ).

Along with the PHP transformation Laravel was born, and I was hooked. I had finally language and framework in which I can approach web development in the way I want ( and programming in general ).  So Laravel is responsible for my PHP adventure. And not just PHP. My knowledge about obligatory design patterns and whole object-oriented paradigm was missing some glue. Sure, thanks to previous experience with JS, in which I had to read about whole programming history and evolution of modern languages, I can flow between PHP code with no real struggle.

And of course, beautifully structured and designed Laravel is a joy to read without writing a single line of code - like a great novel. Class bases languages and frameworks like Laravel helps me to write better organized and more secure code - which is standard for server side applications. So my approach to Laravel is not just from the point of someone who wants to write web-applications and learn API. Through Laravel, I am making progress as a programmer, and I hope I'll be able to contribute to Laravel core soon :)

So this post somehow represents a long introduction to my future writings about Laravel internals, so stay tuned and thanks for reading.