Structure of a Laravel application

Over the course of the next two chapters, we will install Laravel and create our first application. Like most frameworks, Laravel starts out with a complete directory tree for you to organize your code in, and also includes placeholder files for you to use as a starting point. Here is what the directory of a new Laravel 5 application looks like:

./app/                       # Your Laravel application
  ./app/Commands/            # Commands classes  ./app/Console/
    ./app/Console/Commands/  # Command-line scripts
  ./app/Events/              # Events that your application can raise
  ./app/Exceptions/
  ./app/Handlers/            # Exception handlers
    ./app/Handlers/Commands  # Handlers for command classes
    ./app/Handlers/Events    # Handlers for event classes
  ./app/Http/
    ./app/Http/Controllers/  # Your application's controllers
    ./app/Http/Middleware/   # Filters applied to requests
    ./app/Http/Requests/     # Classes that can modify requests
    ./app/Http/routes.php    # URLs and their corresponding handlers
  ./app/Providers            # Service provider classes
  ./app/Services             # Services used in your application

./bootstrap/                 # Application bootstrapping scripts

./config/                    # Configuration files

  ./database/
  ./database/migrations/     # Database migration classes
  ./database/seeds/          # Database seeder classes

./public/                  # Your application's document root
./public/.htaccess         # Sends incoming requests to index.php
./public/index.php         # Starts Laravel application

./resources/
  ./resources/assets/        # Hold raw assets like LESS & Sass files
  ./resources/lang/          # Localization and language files
  ./resources/views/         # Templates that are rendered as HTML

./storage/
  ./storage/app/             # App storage, like file uploads etc
  ./storage/framework/       # Framework storage (cache)
  ./storage/logs/            # Contains application-generated logs

./tests/                     # Test cases

./vendor/                    # Third-party code installed by Composer
./.env.example               # Example environment variable file

./artisan                    # Artisan command-line utility

./composer.json              # Project dependencies manifest

./phpunit.xml                # Configures PHPUnit for running tests

./server.php                 # A lightweight local development server

Like Laravel's source code, the naming of directories is also expressive, and it is easy to guess what each directory is for. The app directory is where most of your application's server-side code will reside, which has subdirectories both for how your application could be accessed (Console and Http), as well as subdirectories for organizing code that could be used in both scenarios (such as Events and Services). We will explore the responsibilities of each directory further in the next chapters.

The service container and request lifecycle

Whether you are a beginner in PHP or an experienced developer in a different language, it might not always be obvious how an HTTP request reaches a Laravel application. Indeed, the request lifecycle is fundamentally different from plain PHP scripts that are accessed directly by their URI (for example, GET http://example.com/about-us.php).

The public/ directory is meant to act as the document root; in other words, the directory in which your web server starts looking after every incoming request. Once URL rewriting is properly set up, every request that does not match an existing file or directory hits the /public/index.php file. This file includes the Composer autoloader file, which loads in dependencies (including the Laravel framework components) and also where to look for your application's code. Your application is then bootstrapped, loading configuration variables based on the environment. Once this is done, it instantiates a new service container instance, which in turn handles the incoming request, uses the HTTP method and URL used to access the application (such as POST /comments), and passes the request off to the correct controller action or route for handling.

Exploring Laravel

In this chapter, we are only covering the general mechanisms of how Laravel works, without looking at the detailed implementation examples. For the majority of developers, who just want to get the job done, this is sufficient. Moreover, it is much easier to delve into the source code of Laravel once you have already built a few applications. Nevertheless, here are some answers to the questions that might crop up when exceptions are thrown or when you navigate through the source code. In doing so, you will come across some methods that are not documented in the official guide, and you might even be inspired to write better code.

Browsing the API (http://laravel.com/api) can be somewhat intimidating at first. But it is often the best way to understand how a particular method works under the hood. Here are a few tips:

• The Illuminate namespace does not refer to a third-party library. It is the namespace that the author of Laravel has chosen for the different modules that constitute Laravel. Every single one of them is meant to be reusable and used independently of the framework.
• When searching for a class definition, for example, Auth, in the source code or the API, you might bump into Facade, which hardly contains any helpful methods and only acts as a proxy to the real class. This is because almost every dependency in Laravel is injected into the service container when it is instantiated.
• Most of the libraries that are included in the vendor/ directory contain a README file, which details the functionality present in the library (for example, vendor/nesbot/carbon/readme.md).

Changes in Version 5 from Version 4

Laravel 5 started life as Laravel 4.3, but was promoted to its own major version when it became apparent that this new version was going to be a radical departure from version 4 of the framework. Laravel 5 builds on Laravel 4 as a base, but makes architecting larger applications with things like an application namespace out of the box. Laravel 4 applications will need a fair bit of work to be ported to Laravel 5. Features that are new or have been updated in Laravel 5 include:

• Method injection: In Laravel 4, you could type hint (specify in the constructor) the dependencies a class needed, and Laravel would automatically resolve those dependencies out of its container. Now, Laravel 5 takes that one step further and will also resolve dependencies specified in class methods, as well as class constructors.
• Form requests: Laravel 5 introduces form request classes. These classes can be injected into your controller actions. They take the current request, and on it, you can perform data validation and sanitizing and even user authorization (that is, check if the currently-logged in user can perform the requested action). This streamlines validation, meaning you have to do very little, if any, data validation in your controller actions.
• Socialite: New to Laravel 5 is an optional package called Socialite that you can declare as a Composer dependency. It makes authenticating with third-party services a breeze, meaning you can easily implement functionality like login with Facebook in a few lines of code.
• Elixir: Laravel 5 also looks at making front-end development easier. A lot of developers these days are using languages like LESS and Sass to create their style sheets, and concatenating JavaScript files into one, minified JavaScript file to reduce HTTP requests and speed up loading times. Elixir is a wrapper around Gulp, a Node.js based build system that simplifies the tasks mentioned here. This greatly reduces the time needed to get up and running with a new application, as you don't have to install Node.js modules or Gulp files from other projects. You get it free from the get-go.