Building simple websites with the Silex microframework, as a gateway to bigger frameworks

Tuesday, January 20, 2015 - 19:25

One of the most exciting consequences of Drupal 8 being built on components from Symfony is that either of them becomes a gateway technology for learning the other. While old Drupal hands like myself will doubtless need to seriously upskill when D8 becomes the CMS technology of choice, that upskilling will nonetheless put us on something of a plateau when it comes to moving sideways into Symfony development; similarly, I feel like the advent of D8 has coincided with a large influx of newer (and, on average, younger) attendees at Drupalcons and camps: are the walls coming down on Drupal's own garden?

At the same time, the more large and complicated frameworks can in themselves be a challenge to learn. If someone comes from an environment where they write code procedurally in order to make the HTML DOM appear, starting at <html> and finishing at its closing tag, then it can come as a shock, having to learn about controllers, page routing, middleware, services etc. But this is where microframeworks come in and, when it comes to the Drupal–Symfony ecosystem, a great example microframework is Silex. This microframework originally comes from the same software house as Symfony, and is built on a small number of Symfony components plus its own application-container glue.

When you've "installed" Silex (I recommend you use Composer to do it) then, unlike with "macroframeworks", you don't begin with a working website! Indeed, you have to write an index.php yourself. This is the closest I think you can get to a bridging technology: leading from procedural custom-PHP websites, to a more framework-oriented approach. From the outset, it's recommended you follow best practices like having your webserver look only in a subdirectory e.g. web/index.php, thus protecting much of your codebase from prying eyes.

The Silex documentation provides a simple "Hello, World" example in its documentation, and you can move on from there. As you proceed, you become conversant in how to use PSR-0 and PSR-4, the standards that permit autoloaders to find your code classes easily, and are encouraged—but not forced—to adopt some of the best practices that macroframeworks have already long since embedded and absorbed into their deepest layers.

The point is that—as far as I can tell—your index.php, the core of your website, is always going to be a little bit ad-hoc with such a microframework, and even when you start introducing controllers (request handlers) and services (shareable business logic) you can still feel like you know how (almost) each bit of what you've written works, and how it hangs together. Gone is the magic inherent in macroframeworks, when the heart of your own written code can look a bit like this:

<?php
/**
 * @file
 * Website index.
 */
 
require_once __DIR__.'/../vendor/autoload.php';
 
// Create application.
$app = new Silex\Application();
 
// Add services
// 1. 3rd party Twig templating via $app['twig'].
$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.path' => __DIR__ . '/views',
));
// 2. Custom input check: matches our business expectations?
$app['input_checker'] = function () {
  return new ExpensesRecorder\Services\InputChecker();
};
 
// Routing.
$app->get('/', 'ExpensesRecorder\\Controllers\\IndexController::get');
$app->post('/', 'ExpensesRecorder\\Controllers\\IndexController::post');
$app->get('/thanks', 'ExpensesRecorder\\Controllers\\PagesController::thanks');
 
// Run app.
$app->run();

And that's the whole point. You could even sneak Silex into your existing application's index.php, and start serving some of your website through it, piece by piece, until it's converted to "proper" Symfony-like components. The point is that such microframeworks make it easy to learn and employ best practice, and—if it's where you want to go—move towards the macroframeworks that, being much more heavyweight, really pack a punch.

Comments

ja (not verified)

Wed, 28/01/2015 - 06:29

microframeworks are indeed a breath of fresh air. it feels lighter and you have more control. you can exercise some flexibility but with less code since you are utilizing something built already