Why a Micro-Framework?
Sometimes you don’t need a full-stack framework. You might be working on a simple restful service that doesn’t require controllers, models and views. You could be prototyping a new concept, or maybe building a custom application framework specific to your (or your company’s) needs. In all of these cases, you may want to consider using a micro-framework.
Let’s be clear about what a micro-framework is, and what it isn’t. A micro-framework is a very light codebase with little or no structure (it might even all be contained in one file, although it doesn’t have to be setup like this), that usually provides API access to a library that gives you a way to provide routes and basic responses through lambdas and closures. A micro-framework is not a smaller, simpler version of an existing large framework.
Usually a micro-framework leaves pretty much everything up to you. You can do with it as you please and mostly you can get away with anything. Unlike a regular, full-stack framework, a micro-framework will not dictate much in terms of where to put things or how to do things — other than a basic set of guidelines that should generally be followed.
Why Silex?
Silex uses Symfony components. This is good — Symfony is tested, audited, backed-up by an enormous community and usually has a component for what you want to do. Symfony uses Composer, which is also a big plus. The company that brings you Symfony makes Silex, and they know how Symfony works, and how to integrate it properly.
Silex has a large community and therefore a nice support ecosystem. As it is used a lot, it gets a lot of answers on Stack Overflow and a lot of bugs reported and fixed on Github. This is good for any open source project (yes, Silex is free).
Getting Started
To start using Silex, simply use Composer:
Once Composer has installed your Silex application (in the /vendor director) create in index.php file:
Now, once your app in initialized, and before the run command, you can build your application. The first thing you may want to do is turn on debugging — Silex has a nice function to allow you to see errors with a meaningful call stack. Do this as follows:
Routing is handled via lambda functions and closures, meaning that you can return the response to a request with a few short lines, as follows (note the response is returned, not printed or echoed):
Want to grab a posted form and then send an email? Do this simply:
Notice lines 5 and 6 — these are Symfony components we are using out of the box, so that we don’t have to do any of the dirty work in validating requests and formatting responses — the Symfony components do this for us.
Dependency injection is handled by Pimple, which is a base component of Silex, as well as a dependency injection container available here. Pimple allows us to define any value as a parameter of the $app variable, meaning we can say things like:
The example above shows how you would assign values to the app and then, by converting the anonymous function into a closure, we can use those values accordingly. This gives you enormous flexibility for things like config and database settings.
Middlewares are nice hooks that allow you to get into specific parts of the application and change behavior. A few examples would be the “before” and “after” hooks, which would be something like:
There is a lot you can do here — all of which is well documented.
You may be wondering how Silex handles databases. MySQL is of course the default support, with doctrine being the default service provider, however, as Silex is a micro-framework, only the doctrine DBAL is supported. There are a few ports that allow you to implement a Doctrine ORM, the best of which is this one. Connecting to doctrine is simple, and as we see below, we can connect to multiple databases at the same time.
That’s all we have time for right now. Next time we’ll take a look at a few more in-depth examples of how to use Silex. To explore on your own, check out the documentation.
