SOA - Service Oriented Architecture in Laravel

My previous post title was n-tier meets MVC.
In this post I want to add one more thing to that conclusion - n-tier meets MVC with the help of SOA.

Yes, besides n-tier (client/server) and MVC our favourite framework is implementing one more well known architectural pattern. It is called SOA or Service Oriented Architecture. Wikipedia has got pretty good explanation of SOA.


Take a look at this sentence from Wiki:

Service provider: The service provider creates a web service and possibly publishes its interface and access information to the service registry.

Sounds familiar ? Well it took me a while untill I finally realized what is Laravel doing in one of its core parts. Like many Laravel developers I was struggling with facades, providers and containers terminology without knowing that it is just an implementation of well known pattern. Modified, but concept is still the same.

Less obvious part of this  is why Taylor Otwell actually decided to design framework with SOA style incorporeted ?
Knowing that he has strong .NET background can help. In Microsoft world, they traditionally care about services. I was teached to think Restfully, so this was hard concept to grasp.

So the story is:

In the middle of the Laravel  kingdom lives Application, that depends on its citizens and servants. Application can exists by its own, but there is no point in empty kingdom. Every kingom has a treasury.  So they build one. In this kingdom it is called Container . 
Then Application defined  a rules and exposed them publically through its main  accociate - ServiceProvider class. All new citizens have to behave and look the way it is defined by the king.
ServiceProvider announced that everyone who wants to be a part of Application kingdom must implements two methods:

• register and
• boot

Register to become part of kingdom and boot to invite their friends to join. Also, Application allows some level of freedom to their citizens and let them choose their names and how they will be called. Speeking in Laravel terms, they can use Aliases and Facades for their access.

But, not everything is perfect . Some citizens are on the higher position then others. So they are treated specially. e.g. Request class is called very early, and it is bound directly, without use of ServiceProvider class.
On the other hand some citizens choose fancy names like Config, but underneath they are originally called Repository.

What would be a kingdom without a police ? Events are everywhere.
They provide welcome to every new citizen (provider) and take care of illegal activities. If something bad happened they will fire its main weapon - Exception. In our kingdom it is allowed to have private police.
It is no problem. Even better - it is a free gift from one of the highly rated Applications servants. If you want to take care if right type of rules are applied in your Validation, just call Event police - and it will fire all exceptions.  

So, even it sometimes looks that things are out of order in typical Laravel application, it is just because developer didn't understood properly how framework is internally designed and with what intention in mind. In all other casess, we have great tool for building web applications.

Thanks for reading.

n-tier meets MVC in Laravel

This is the post about two fundamental architectural patterns that can be found in most todays web framerworks. These patterns are:

• n-tier represented as client/server model and
• MVC (model,view,controller)

There is a lot resources online client/server, n-tier so I will take a look at Laravel specific implementations of these patterns. You can argue is MVC architectural or design pattern. I think MVC is closer to well established arch patterns due to its usage and overall complexity.

In Laravel we can exactly detect boundary between them as so as their main flow. Client model starts in the form of HTTP request, which is received from the browser (mostly) and provided to main Application class:

public function __construct(Request $request = null)
 {

  $this->registerBaseBindings($request ?: $this->createNewRequest());

  $this->registerBaseServiceProviders();

  $this->registerBaseMiddlewares();
 }

Request comes in a form of Laravel request which extends Symfony class. After application receives a request, it will registered it as a protected property (object). In this phase, flow is pretty straightforward. If there is no custom middleware functionality, request will end waiting for handler method. There are some minor processing like attaching session driver, but main job is done in a layer that comes after.

I mentioned middleware, which is actually all functionality that lives in a space between the reqeust hits the internal application routes. Laravel (from 4.1 Iversion) implements StackBuilder middleware, which can be used  like a flyweight alternative to caching and session management (and for some other things).

Here is a method that implements StackBuilder:

protected function getStackedClient()
 {
  $sessionReject = $this->bound('session.reject') ? $this['session.reject'] : null;

  $client = with(new \Stack\Builder)
      ->push('Illuminate\Cookie\Guard', $this['encrypter'])
      ->push('Illuminate\Cookie\Queue', $this['cookie'])
      ->push('Illuminate\Session\Middleware', $this['session'], $sessionReject);

  $this->mergeCustomMiddlewares($client);

  return $client->resolve($this);
 }

StackBuilder andLaravel Application class implements Symfony\HttpKernelInterface in the form of handle method. That is why it is called stack - it just forwards request further down the stack till it reaches main Application handler

When request hits Application handler, it is on the door of MVC part of Laravel, which leads further to domain logic and the heart of application.

Take a look at the main handler:

public function handle(SymfonyRequest $request, $type = HttpKernelInterface::MASTER_REQUEST, $catch = true)
 {
  try
  {
   $this->refreshRequest($request = Request::createFromBase($request));

   $this->boot();

   return $this->dispatch($request);
  }
  catch (\Exception $e)
  {
   if ($this->runningUnitTests()) throw $e;

   return $this['exception']->handleException($e);
  }
 }

As can be seen, it is dispatched to router, for further processing and which will result with HTTP response.   For now I wont go deeper into source code, since point of this post was just to show conceptual boundary between these two layers. This boundary is sometimes not so visible, due to frameworks specific implementations. One thing that is worth mentioning is that client/server model is dominant model in distributed systems like internet (where client is present), while MVC originated in the deskop environment. If not designed properly, applications made with the mix of these patterns can become very complex and lead to bugs and potential break. For me, it was very important to reckognize them in Laravel, so I could have better insight into awesome framework design.

Thanks for reading.

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.