{"id":323,"date":"2012-05-11T20:40:38","date_gmt":"2012-05-11T19:40:38","guid":{"rendered":"http:\/\/blogs.kent.ac.uk\/webdev\/?p=323"},"modified":"2012-05-26T08:26:16","modified_gmt":"2012-05-26T07:26:16","slug":"using-laravel-first-impressions-of-a-php-framework","status":"publish","type":"post","link":"https:\/\/blogs.kent.ac.uk\/webdev\/2012\/05\/11\/using-laravel-first-impressions-of-a-php-framework\/","title":{"rendered":"Using Laravel: first impressions of a PHP framework"},"content":{"rendered":"

\"laravelOur team recently faced a typical (PHP) developer problem: build a simple app in a few days that\u2019s good-looking and feature-rich enough to convince your customers right from the start that you mean business. After all first impressions really do matter. We wanted to find a PHP framework that would let us develop rapidly, while also giving us long-term scope for rich development on a large project. We might also want to use the framework on other projects too. A couple of days of searching, forrsting<\/a>, and general trawling through the internet and we came up with a couple of prime candidates for a PHP MVC framework – FuelPHP<\/a> and Laravel<\/a>. They are in fact rather similar. Children of 2011, both are based on the hugely successful CodeIgniter<\/a>. They improve on their mentor in a number of ways – often specifically PHP 5.3 (and 5.4) related ways. The heavy use of namespaces<\/a> and closures<\/a> are things which spring to mind. We particularly liked Laravel early on because of its clear documentation, and a healthily active community of developers working both on the core and a raft of handy plugins (aka bundles). We also found some particularly good tutorials by Dayle Rees<\/a> who has even published an ebook called Code Happy with Laravel<\/a> We found a great little CRUD app on GitHub<\/a> which seemed a good way to get started with Laravel. It uses twitter bootstrap<\/a>too, and looks great! So we went for Laravel.<\/p>\n

Simple (and fun!)<\/h2>\n

The first thing that struck us about developing with Laravel was how simple it was. Our usual experience with big frameworks (you know which ones I\u2019m talking about\u2026) is that you end up spending about a week\/month grappling with obscure YAML config settings, unhelpful helpers, fussy syntax, partially documented classes, and a general sense that the framework isn\u2019t in the end really saving you a lot of time or effort. We just didn\u2019t find that at all with Laravel. One of Laravel\u2019s selling points is that it brings the fun back into PHP development. And you think \u201cyeah right, well they would say that wouldn\u2019t they\u201d. And other things along those oh so cynical lines. But our experience was that it really did seem to make development more fun. Laravel provides just enough built-in features that you can focus on the more interesting parts of your app without having to worry too much about the boring basics. So what are these features?<\/p>\n

Eloquence<\/h2>\n

Laravel uses its own ORM, called Eloquent. This is based on PHP ActiveRecord, although I\u2019m not clear at this stage how exactly it differs. But it does work well – and simply – while allowing for more advanced features like eager loading<\/a>. Unless you have a really crazy schema the chances are Eloquent will work well for you. Certainly the schema for our project is somewhere in between basic and complex, and we\u2019ve not yet come across any gotchas. A project I worked on a year or so ago ended up using key-value storage in a MySQL db. It wasn\u2019t an easy decision. If you\u2019ve ever tried key-value storage with a relational ORM you\u2019ll know what I mean. Mercifully life doesn\u2019t have to be that cruel, and if your friendly neighbourhood sysadmin is having a good day things like MongoDB and Redis are there and ready to serve. My point being? Laravel has Redis support built in. How nice. You can also build your own queries with Laravel\u2019s Fluent Query Builder, or if you really need to you can always just write those SQL queries in the raw like mama used to make. Laravel does come with a handy db migration tool too. It\u2019s not super-sophisticated, but it is useful for running (and rolling back) schema changes. Added to this is the Schema class, which basically lets you very easily create database structure without coding any native SQL.<\/p>\n

Bundles<\/h2>\n

An important feature of any framework is a community of developers who contribute extra functionality to the core through some form of plugin system. Laravel is no exception. It has just over 80 \u201cbundles\u201d (when I started thinking about writing this post 2 days ago it had 80. Today it has 82. Crazy!) ranging from a scaffolding tool called Bob<\/a> to a very simple profiler<\/a> bundle which adds the PHP Quick Profiler<\/a> to your site. Bundles are hardly at the volume of symfony or Drupal plugins\/modules, but it\u2019s impressive work for a framework that barely existed a year ago. Also I\u2019d say from my experience developing with WordPress and Drupal that it\u2019s far<\/em>better to have a few well-maintained plugins than a sea of plugins that worked really well a year ago in version 1.0<\/p>\n

The rest<\/h2>\n

I don\u2019t want to downplay the many other features that Laravel has, but there\u2019s little point in describing them in detail here. If you want a really nice outline then take a look at the clean and clear Laravel docs<\/a>. Basically Laravel has a bunch of features that are pretty much what you\u2019d expect from a framework: form helpers, caching, session tools, authentication, security features\u2026 You know the kind of thing, and it\u2019s all good stuff.<\/p>\n

What we did<\/h2>\n

Our goal for sprint 0 (we\u2019re an Agile team you see) was to build the beginnings of a CRUD app to manage University course details. It needed forms for editing courses, LDAP authentication, some role provisioning, and importantly a versioning system that would track all edits and allow rollback to earlier versions of courses. We (3 developers) managed to get from absolute 0 to beyond our sprint minimum viable product in about 40 developer-hours. Most of that time was actually spent planning how the app would work, working out the data model, and generally making it look nice. We spent almost no time at all worrying about how to get Laravel working for us. The whole thing really was great fun! And on top of that our customer was really happy with the result. We love happy customers!<\/p>\n

Nice-to-haves<\/h2>\n

We enjoyed using Laravel. That doesn\u2019t make it perfect, so here\u2019s a couple of things that would be nice. I suppose instead of sounding like I\u2019m moaning too much I should just git<\/a>in there. Anyway\u2026<\/p>\n