Laravel sandwich

This morning, while reading  my favourite PHP frameworks code, it occured to me that Laravel application looks like one big, yummy sandwich. Well, that may sound weird but sometimes while coding, language concepts are presented in my mind like something that have nothing to do with programming. Or it does ?

So Laravel sandwich like every other is consists of three main parts:

• top piece of bread (Application is called)
• yummy layer (all good things like config, routes,controllers,models...)
• bottom piece of bread (return what the client was asking)

When we transform these food terms into programming we got this:

//top piece
        $app = new Illuminate\Foundation\Application;

       // what was called
 public function __construct(Request $request = null)
 {
    
  $this->registerBaseBindings($request ?: $this->createNewRequest());
   
  $this->registerBaseServiceProviders();

  $this->registerBaseMiddlewares();
 }

As you can see above, app is called with provided request - which is little later registered into container. I was wondering why request is not registered as service provider - now I now . Request has to come first, before any bindings.
And that's all, belive it or not. Nothing fancy is happening here. Just some administrative tasks in the form of registering request into application. Yes, behind scene Symfony is doing a lot work while receving and preparing HTTP request, but it is not important for now.

Yummy part lives in the middle of our sandwich, and presents most delicious layer of Laravel delicacy. In fact we can say that this layer is most important in whole Laravel application. Here we can find all calls to routes, controllers, models, db - in other words it is the heart of domain layer, mean machine that has to be controlled somehow and from somewhere. If you don't understand what do I mean when I talk about "yummy layer" take a look at the content of these folders and files:

app/
        commands/
        config/
        controllers/
        database/
        lang/
        models/
        start/
        storage/
        tests/
        views/
        filters.php
        routes.php

You will be looking in the heart of nuclear reactor. That power needs some kind of control, or it will blow away everything. So let's push the red button. Or, let's eat our sandwich. We can do that with this method:

App::run();

        //in other words

 public function run(SymfonyRequest $request = null)
 {
  $request = $request ?: $this['request'];

        // calls dispatch route method
  $response = with($stack = $this->getStackedClient())->handle($request);

  $response->send();

  $stack->terminate($request, $response);
 }

Not so obvious ah ? Well I hope I will visit Laracon one day and thanks Taylor Otwell for this awesome piece of software that we enjoy somuch. Till next post, try to dig deeper into Laravel source code from App:run() point - there is a lot things inside.

I hope you like my post, and sorry for beeing too abstract sometimes.

Laravel environments setup

Why does it matters ?

Ability to have multiple environments and to switch between them quickly is of big importance for any non-trivial web development task.
For example, if you test your application data layer, test code shouldn't be hitting real database tables in any case. Instead it should rely on mocked and prototyped tables that is easy to create and drop.
Laravel makes that process very easy by offering three main types of environments:

1. development
2. production
3. testing

How to choose environment ?

Entry point for choosing is located in bootstrap/start.php file in the root folder of Laravel project, at ine 29 (Laravel version 4.1):

Original function looks like this:

$env = $app->detectEnvironment(array(
 'local' => array('your-machine-name'),
));

As can be seen, env is detected by providing array with env name and value in the form of key-value pair.

My custom version looks like this:

$env = $app->detectEnvironment(function()
{
    return getenv("ENV") ? : "local";
});

Instead of array, this function accepts function(closure) that returns type of env. That type will be auto deteced with the use of ternary operator.

How to setup environment ?

By just choosing, we didn't do much. We have to customize desired env and tell Laravel when to find them. All env settings are stored under app/config directory.  Default env is production, so if you don't create new, Laravel will treat all config settings as production. Easy task of setting custom env is done by just creating new folder under app/config directory. So if you want to have one env for development and one for production, just create new folder and name it development. Now all that we place inside will be red by Laravel only in case we explicitly choose in bootstrap/start.php file.  Note that development is just a convention, I instead name my development env as local - It is easier that way for me to differentiate. Name is not important, as long as it is in sync with name of the folder and vice verse. Most common reason to have different env are a database settings. By default, they are stored in app/config/database.php file. 

Here is my  database.php file, placed under app/local/ directory:

array(
  'mysql' => array(
   'driver'    => 'mysql',
   'host'      => 'localhost',
   'database'  => 'local-db',
   'username'  => 'root',
   'password'  => '123456',
   'charset'   => 'utf8',
   'collation' => 'utf8_unicode_ci',
   'prefix'    => ''
        )
)];

These setting works under local environment  common ( apache, localhost, mysql configuration ).

 And here are production settings: 

array(
  'mysql' => array(
   'driver'    => 'mysql',
   'host' => getenv("DB_HOST"),
   'database' => getenv("DB_NAME"),
   'username' => getenv("DB_USER"), 
   'password' => getenv("DB_PASSWORD"),
   'charset'   => 'utf8',
   'collation' => 'utf8_unicode_ci',
   'prefix'    => ''
      )
)];

Note that in order for these production values to have affect, you'l have to "catch" env variables that are specific to server environment.

Here I simply import them with native PHP getenv function.

Last and not so commonly used is testing environment. It is provides automatically by Laravel, so you don't have to worry about that. 

Here is how Laravel detects if we are using testing env:

public function createApplication()
 {
  $unitTesting = true;

  $testEnvironment = 'testing';

  return require __DIR__.'/../../bootstrap/start.php';
 }

This is excerpt from TestCase class which extends PHPUnit_Framework_TestCase and is locate under app/tests directory.

Again, in order this to work, we have to create new testing directory and place all out settings inside. One gotcha when migrating database table for testing purposes is to forgot to tell Laravel the type of env we want that table to be used for. If don't, Laravel will be using default environmet. 

To choose right type of env it is enough to add --env="testing" at the end of migration command like this:

php artisan migrate --env="testing"

It can be used for local/development purposes also.

php artisan migrate --env="local"

Thanks for reading.

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.

REST cheat sheet

I created a simple cheasheet table, like every day reminder for creating beautifull rest API-s. So, if you have experience with old PHP routing style in the form of:

"http://host/resource /?id=some_id"

it is time to refresh your skills by moving to more modern approach. Fortunately, REST (Representational state transfer) is supported in all new frameworks like ExpressJS or PHP Laravel.
So this table can help because it can be sometimes confusing to remember which verb belongs to which path.

Here it is:

Thanks for visiting my blog.
Miro

How to properly understand Javascript language PART 1 ?

Hello;

My first programming language was Javascript. Learning JS without previos knowledge of programming theory ( paradigms, history and language background ) was a very painful process, full of pitfalls and roaming in the dark.  As I can see, a lot of people had a same experience. From my point of view it is because  in JS it is relatively  easy to write applications that looks like a real applications - with the help of large number of  libraries that provides usefull abstractions in the form of their "easy to learn" API.  Canonical example is jQeury - with a minimal code you can have reference to DOM object, without knowing what is happening in the back:

    //
    var elem = $("div")
    //

I am not saying that abstractions are evil, and that we should avoid them. It should be a nightmare to write code without them. After all with the help of abstractions, we are not writing assemby anymore, or in the case of jQuery, cool animations. I want to say that when learning language  starting with libraries like jQuery can cause  unnecessary confusion, which is hard to correct.

This is even more the case with JS, because of it‘s weird combinations of paradigms and idioms. For example, concept of closure  has become trademark of a language, that is very hard to pick without a knowledge about its context, root and origin. To proof, term closure is one of the most searched programming term online, with blogs and even whole sites dedicated to it.
People are really having problem to digest closure. It is not a surprise, because it is one of the hardest programming concept that exist.

After years of struggling with JS I created my mental model about what is Javascript. Of course, it is not just a theory. I am a programmer and the whole point of this post is to better understand Javascript so I can express my self with code.

So lets examine some of the main bulding blocks of JS.

I‘ll start with syntax, since it is very natural to start with when learning new language. Javascript belongs to so called "curly-braces" family of languages, which is mostly influenced by C.
Take a look at the following examples:

    //
    var i;
    for ( i = 0; i < 5, i++){
          console.log("hello");
    };
    int i;
    for ( i = 0; i < 5, i++){
          printf("%s\n","hello");
    };
    //

These two examples are identical, except one cosmetic difference. To write to output, Javascript uses console.log method, which is specific to browser environment, and C uses printf. Their syntatic similarity can also be seen  through code formating that I use in this blog. Both loops are formatted using same pre tag ( <pre class = "brush:js">), which is JS specific. But the output is still well formed, except some minor color differences.  Looking deeper in the languages syntax, there is very, very close relationship between them. I don't want to spend too much time dealing with that topic, since it is covered in more details on other places. To start with syntax comparison read a great Wiki articles: Comparison of programming languages syntax and List of programming languages by type.

The main takeaway from this is: Take some to learn basis of C programming language.  There are tons of great resources and tutorials online. You'll be surprised how much is Javascript influenced by C. In the beginning that influence can be seen as only syntatical, but with experience you'll see how much  have you missed. I became enlightened after learning C.

And that is just a beginning. In the future posts I'll cover other important Javascript  paradigms - first object and then functional.

Miro.