jump to navigation

Rapid Application Prototyping in PHP Using a Micro Framework (Silex) — Part1 Introduction May 22, 2014

Posted by Tournas Dimitrios in Silex.
Tags: ,

Silex framework logoSetting up a Framework up to the point of a working web application isn’t difficult these days. We just have to open a terminal and take advantage of Composer’s functionality. Composer will handle the whole process of downloading the required package and its associated dependencies in just a couple minutes. Most popular Frameworks nowadays are distributed via packagist , a Composer package repository, which finds packages and lets Composer know where to get the code from. An important decision has to be made though, which framework should be chosen as a foundation for our web application ? Not a simple question indeed. An American pioneer of computer science (Kenneth Thompson) had proposed the “Unix philosophy” : >>> Building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators <<< Many [PHP]frameworks follow the aforementioned philosophy very closely, their components are autonomous blocks of code which can be used by other frameworks as building blocks. A characteristic example is Symfony, its modules are used by many frameworks and libraries.

Silex is a PHP Micro-framework based on Symfony 2  components that has been built to focus on smaller web-applications. Silex handles basic tasks (ie routing , DI) without getting in our way, acting as a great base upon which we can architect the rest of our application. The “Application Class” (core component) of Silex is extending Pimple,  it’s a [small] service container, more formally known as a Dependency Injection Container. If you are new to Pimple, reading up on it is going to be extremely important. Pimple’s documentation is pretty easily to follow. As many other dependency injection containers, Pimple is able to manage two different kind of data: services and  parameters (key/value pairs). Developers familiar with Symfony’s  Service_Container , Laravel’s IoC container or ZF2′  Service_Manager component  will immediately recognize that some features which are inherent in those modules (and are required on large scale applications) are not available “out of the box” in Silex . This framework (Silex) is an excellent tool to build simple web applications, but also, it can be used for software prototyping and for building RESTfull API’s.

“Micro” does not mean that the whole web application has to fit into a single  file, although it certainly can. Nor does it mean that Silex is lacking in functionality. The “micro” in micro-framework means Silex aims to keep the core simple but extensible. Silex won’t make many decisions for us, such as what database to use. Almost everything is configurable by the developer, so that Silex can be everything we need and nothing we don’t. Extending Silex’ functionality is simple as registering one of its build-in ServiceProviders, also, writing our own ServiceProviders (extensions) isn’t difficult to accomplish .

The first example on Silex’s documentation page is a great example of how simple Silex is. You can literally get to “Hello World” with auto-loading, full blown routing and output escaping in six lines of code:

// web/index.php
require_once __DIR__.'/../vendor/autoload.php';

$app = new Silex\Application();

$app->get('/hello/{name}', function ($name) use ($app) {
    return 'Hello '.$app->escape($name);


The code isn’t difficult to understand, the same motif is also used by other frameworks (Laravel , Slim). The get() function takes two parameters (a route and a closure), a controller is emulated by a closure which simply maps a GET request parameter to a variable (optional parameters are written inside brackets). The value retrieved from the GET request parameter is escaped before it’s returned to the browser. Each closure is mapped to the specified route (first parameter of the get() function) , when the route matches, the function is executed and the return value is sent back to the client. The code couldn’t be written simpler, but not without consequences of course ,  ie test-ability and maintainability were  sacrificed aiming to achieve simplicity, it hasn’t to be so though (we will get into these subjects in later parts of this article).Can you imagine how the code would be if we had to write (hard-code) business-logic into the closure, even worse , what would happen if the same business-logic is required across different routes (closures) ?  Copy/pasting ? Of course not, this style of coding isn’t acceptable anymore, separation of concern is the de facto  design principle nowadays.

Is it really so bad to put the whole logic into closures ? Actually it’s not, especially on small-simple projects this is the usual way of coding. Another implementation of this style of coding is while prototyping parts of a web application, there is no reason to follow “good coding practices”  just to demonstrate/test a specific functionality of a library.For instance, wouldn’t it be a waste of energy/time (by delegating a specific task to separate classes) just to showcase/explore how  Symfony’s Session module works ? That last example was randomly chosen, I hope you get to the point of my thoughts.
Controllers and Services Classes are the recommended style of coding when the application is meant for production.You never know, over times a simple five page website can evolve into a full featured web application (freelancers know exactly what I’m talking about🙂 ) .
Of course a Silex application can be structured on coding styles (practices) used by enterprise level Frameworks. Zend Framework 2 has modules , Symfony 2 has bundles , Laravel 4 has packages and Silex has …. Service Providers .

What is this article all about ?

I strongly believe that long articles overwhelm the reader (are boring so to speak) , this article will be posted into a multi-part series of short articles. Each separate post will present practical examples how to achieve a specific task , for instance : Sessions , Twig templating , Doctrine ORM / DQL , Basic authentication , Logging … and more. All these aforementioned tasks are building blocks upon which most web applications are build.This first part of the article took a philosophical approach to the subject, next post will examine basic concepts of the Silex framework . All following articles will dig into actual practical code examples .

Keep yourself healthy, hope I’ll see you next time .

Links :





No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s