On Laravel’s Future

This summer marks the third anniversary of Laravel’s release. It has grown very quickly, and I think its future is very bright. In many ways I feel like “the best is yet to come”!

However, as Laravel has grown, it has become more difficult to maintain. With the launch of other “products” such as Forge, Cashier, Envoy, and Homestead, the time commitment required to maintain Laravel has grown substantially. Because of this, most of my time spent on Laravel has simply been managing issues and pull requests on the main Laravel repository. However, a key part of my vision for Laravel is to continue innovating and making it more enjoyable than ever to write robust, powerful, and maintainable applications.

As many of you know, I have spent the last several years working full-time at UserScape, primarily working on building Snappy. For about the past year, UserScape has also graciously allowed me to devote Fridays to Laravel, which has allowed me time to catch up on Github issues and pull requests.

However, I will now be moving to a part-time role at UserScape, and will divide my time evenly between UserScape and Laravel.

This transition means that I will spend every other week fully focused on Laravel, drastically increasing the amount of time I am able to devote to the framework and the surrounding ecosystem. With this change, I will be able to devote more time to Laravel than I ever have in the past, which is incredibly exciting!

In closing, I’m very thankful to Ian Landsman and the UserScape family for their investment in Laravel thus far (both financially and as a friend), and am thankful for this opportunity to continue working on two products I deeply care about!

Interop & Common Names

I’ve noticed a trend in various interop projects. Often, the proponents of the proposal will “poll” or observe various frameworks and try to pick the most common name in existence for the various interface methods. For example, in a Container interop proposal, the “get” method name might be chosen to retrieve a service from the container.

However, within the context of PHP, this approach couldn’t be more flawed. In my opinion, it’s the exact opposite of what they should be doing. A more verbose, less common name should be chosen. Here’s why.

In languages like C# which support method overloading, the same function may be defined multiple times with a different signature. For example:

public function get(String service);
public function get(String service, Boolean fresh);

So, in a language with overloading, it doesn’t matter as much what method names an interop interface chooses. If I already have that method with a different signature, it doesn’t matter. The same method can be defined multiple times as long as they have different signatures.

This is not possible in PHP. I can only define the method once with a single signature. Since most containers use a “get” method, using that name in an interop interface greatly limits the actual implementation that can ever be achieved by that container without choosing another method name (which might break backwards compatibility). Even if the two signatures do not conflit now, what if they do later? It is better if the interop interface selects a more verbose, less common name like “resolveService”, while the implementations use the more common “get” method to provide their own unique signatures and implementations. Most likely, the “resolveService” method would simply call “get” with a standard set of parameters.


Full IoC & Unit Testing With Laravel

Over the past few weeks, there has been some discussion about dependency injection, service location, and Laravel facades. So, I thought I would put together a quick video to demonstrate how Laravel supports both service locating facades and full-on, thorough dependency injection. In fact, not only does it support it, Laravel is one of the only full-stack frameworks that offers thorough IoC (even for controllers) out of the box. I also included basic unit tests. No facade calls in the entire application.

Enjoy and be sure to watch in 1080p HD!


Response: Don’t Use Facades

This afternoon an article was posted to Reddit that cautioned users of Laravel to stop using “Facades”.

In the context of Laravel, Facades are what you are using when you make what appears to be a static call to a class. For example:

Route::get('/', 'HomeController@showWelcome');

However, as many of you are already aware, this call may be rewritten like so:

$app['router']->get('/', 'HomeController@showWelcome');

The code may be written easier way because, at their core, facades are syntactic sugar for service location. When you make a call to a Facade, the Facade resolves the underlying class out of the Laravel IoC container and calls the intended method on the instance. They provide a very terse, expressive syntax, while still maintaining the ability to test your code.

However, service location can lead developers into some bad architectural habits. For instance, since service location is very “easy”, it can lead to responsibility bloat in your classes. Generally, classes with small, focused responsibilities are to be desired since they are easier to understand, test, debug, etc. However, if you are using Facades to push to the queue, send an e-mail, and validate some data all within a single class, that class’ core responsibilities are obscured. It is concerned about way too many things.

It is possible to use Facades responsibly and keep your class responsibilities narrowly focused. However, some prefer the discipline that constructor injection provides. Constructor injection means that a class’ dependencies are injected via the constructor when that class is created. It is an explicit declaration of what that class needs, and therefore gives an idea as to what that class does.

Before today, injecting the underlying class behind a facade required some explicit bindings to be registered in the IoC container; however, starting today, it is now just as easy to inject your dependencies as it is to use a Facade. By simply type-hinting the class underlying the Facade, it will automatically be injected by the container when it is needed as a dependency.

For example, need an instance of the Session injected into a controller? Just do this:


class HomeController extends BaseController {

	public function __construct(Illuminate\Session\Store $session)
		$this->session = $session;


There is no longer any need to do any extra configuration. Since all controllers are automatically resolved by the Laravel IoC container, the session instance will automatically be injected. Injecting the class underlying the Facade is just as easy as using the Facade itself! If you love using Facades, keep on using them, just keep an eye on those class responsibilities! If you prefer constructor injection, it just got a heck of a lot easier!

If you’re not sure what class to type-hint, check out the Facade To Class Reference from the Laravel documentation.


Unifying PHP

Over the last few weeks, there has been lots of talk about PHP community, packages, and tribalism. So, I thought I would offer a few thoughts on the topic. Currently, Laravel is the most eclectic full-stack PHP framework in existence. In other words, Laravel is the only full-stack PHP framework that actively eschews tribalism.

Laravel, in additions to using its own custom packages like Eloquent and Blade, utilizes a whopping 23 packages from the wider PHP community. Using the “best of the best” PHP packages allows for greater interaction between Laravel and the wider PHP community. But, perhaps more importantly to you, it helps you write amazing applications at breakneck speed.

We don’t want to just speak about community, we want to participate! It’s been a blast to coordinate and talk with developers of so many awesome packages, and I’m very thankful that Laravel has been made better by their efforts.

So, in this post, I want to highlight just a few of the wonderful packages that make Laravel awesome.

A few highlights:

Carbon: An expressive date library by Brian Nesbitt. This library is used to power Eloquent’s date mutators. It makes working with dates in PHP easy and enjoyable.

Predis: A robust Redis client authored by Daniele Alessandri. Predis powers all of the Redis interaction Laravel offers, including the Redis cache, session, and queue drivers.

Phenstalk: Full-featured PHP client for the Beanstalkd queue. Powers the Laravel Beanstalkd queue driver.

SuperClosure: Written by Jeremy Lindblom, this powerful library allows you to serialize and unserialize PHP Closures. It is used each time you push an anonymous function onto a queue.

Whoops: Displays the pretty error pages and stack traces while Laravel is in development mode.

Monolog: The de-facto standard of PHP logging libraries. Used for all logging. Primarily written by Jordi Boggiano.

Boris: Really slick PHP REPL which powers the amazing “tinker” console command.

PasswordCompat: Powers the secure Bcrypt hashing that is used by default by Laravel. Forward compatible with PHP 5.5. Written by Anthony Ferrara.

Symfony HttpFoundation: Extremely robust HTTP abstraction. Well tested and proven in many large, real-world applications. One of the most important community packages we use.

Symfony Routing: This package powers the compilation of Laravel routes to regular expressions, a trickier task than you might think! This library handles a lot of edge cases very well!

Symfony HttpKernel: The HttpKernel provides HTTP exceptions, which are used to indicate 404 responses in Laravel. Also, and perhaps more importantly, this package contains the HttpKernelInterface which is used as the bottom-level abstraction for a Laravel application.

Symfony BrowserKit: All that slick functional testing that Laravel offers? Powered by Symfony BrowserKit!

StackPHP: This project outlines a structure for building reusable, framework agnostic middlewares at the HTTP layer. Utilized in Laravel 4.1+ for all cookie encryption, sessions, and more. Developed by two of my favorite and most respected PHP developers: Igor Wiedler and Beau Simensen.