Notes from LaraconEU

Having spent the previous weekend at LaraconEU, I wanted to jot my thoughts down about the conference, particularly some of the upcoming features unveiled by Taylor Otwell (the framework’s BDFL). To clarify, I’ve never used Laravel, have no plans to do so right now and all of these features are still in active development. I just want to talk about technical and community impressions so take everything you read with a grain of salt.

New directory structure

The next big Laravel release is going to ship with less of a Rails-inspired structure (think: app/models, app/controllers, or ZF1) and will instead move to a PSR-4 structure. This looks great for 2 reasons: first, it brings the framework more in line with existing community standards (and tooling). Second, I believe this change will encourage devs to design their objects more freely, rather than try to fit everything into the pre-labeled types of objects.

Taylor is also shipping a plugin that will support the old directory structure seamlessly, so you can go ahead and upgrade to the other stuff without letting this change hold you back.

Autowiring

One of the most controversial parts of Laravel are the Facades, essentially static shortcuts to objects in the DI layer. Stealing an example from the docs, you might have a controller like this:

class PageController extends BaseController {
    public function showStuff()
    {
        return View::make('some.template', []);
    }
}

In this case, the View object is the Facade. Being static makes it convenient but harder to test and isolate. While there’s some interesting stuff going on behind the scenes to make it somewhat testable, the new version of Laravel renders the point moot by adding autowiring IoC to more objects, like controllers. This lets us rewrite the above example to:

class PageController extends BaseController {
    public function showStuff(View $view)
    {
        return $view->make('some.template', []);
    }
}

This seems like a small change but the effect is profound. Our dependencies are clearer and we can mock them very easily. This new feature preserves the ease of use, makes room for better OO, and does it without breaking BC. Nice.

I’m not a huge fan of autowiring IoC myself but considering the tradeoffs, I think this is a great change. In fact, I’d go far as to say this is the killer feature for the next version and would highly recommend Laravel devs upgrade just to get access to this (when it’s deemed stable, of course).

Custom Requests

The most interesting feature was the new customs Request classes. Essentially, this let you create typed HTTP requests with custom validation and authorization rules that run before allowing access to the controller.

class UserController extends BaseController {
    public function createUser(CreateUserRequest $request)
    {
		// do stuff
    }
}

In the example above, if the HTTP request is a POST, the $request is already prefilled and validated before ever reaching the controller, cleaning up the code a bit. The custom Request classes can be generated with an artisan command to save some boilerplate setup.

Once you see it in action, it’s pretty clear this is an integrated Command Bus, which is pretty fascinating. If you know me, I’m bonkers about command bus service layers and this is the first time I’ve seen a framework take an opinionated stance in that direction so I consider this a plus.

At the same time, there were unresolved questions about this feature to me. Can I easily reuse this in CLI scripts to trigger the same actions? How extensive is the coupling to Laravel’s auth and validation libraries? Isn’t there a lot of state flying around with request method dependent behavior? Shawn McCool had some interesting ideas about this so I’m reserving judgement until I see the final feature.

Regardless, I can’t help but feel it’s a really cool to see a framework take a step like this, even if I have quibbles about implementation. Again, this seems like a measured tradeoff between ease-of-use and best practices.

Contracts

One of the coolest things at the entire conference was the upcoming Illuminate\Contracts repo, which is a repository of only key Laravel interfaces. This opens the door to a lot of standalone implementations and hopefully better architecture overall. This is something I’m 100% behind and hope to see more frameworks do in the future.

One of the new interfaces demoed was a Filesystem, with the first adapter backed by the Flysystem library. I think this is also fantastic for several reasons: OO filesystem access makes testing and decoration easier, Flysystem is a great library that deserves more attention and finally, this might help Frank de Jonge eventually become more famous than Scott Wilcox.

Socialize

This is a new social login library that’s coming with the next version. The version demoed used a static facade which I thought was unfortunate, but the functionality looked great. The application had a github backed login with literally less than 10 lines of code.

Wrapup

Looking at the decisions Laravel is making, I feel it’s moving in a good direction, while preserving a preference for leverage over abstraction. And you know what? That’s okay.

Generally, the audience felt open and willing to discuss challenging subjects. Topics like TDD and service layers were regularly discussed in the halls and I wish I’d had more time to mingle and meet folks. The level was mixed but folks were hungry to learn more. It wasn’t perfect, there were some awkward moments and not everyone was on board with everything. Nonetheless, there was definitely a feeling of going forward.

I’d like to give a shout out to some of the newer speakers like Kayla Daniels for an amazing first talk fighting the good fight, Erika Heidi the most improved speaker every time I see her, the fine speaker and gentleman Kirk Bushell and Matt Stauffer whose delivery will likely give me a run for my money soon.

I want to compliment the organizers for putting on a great conference. They’re friends of mine, so I have an obvious bias, but I thought everything from the food to the schedule to the venue was great.

There are some other possible reasons for this positive impression, it’s no secret my step up from dark horse speaker to closing keynote garnered me a lot of love. Still, I’d like to believe it’s because the Laravel community is starting to shed its reputation as a framework for beginners and making moves to stand as a valued member of the wider community; something should all welcome.