In the post Scaling Silex applications I wanted to organize a one Silex application. In one comment Igor Wiedler recommended us to use RouteCollections instead of define the routes with a Symfony's Dependency Injection Container. Because of that I started to hack a little bit about it and here I show you my outcomes:

He includes example code for creating the application, setting up the main "routes.yml" file with some defaults and two other files for routes in other parts of the site - "api" and "blog". Then he makes the controllers related to these three sections with basic actions catching each of the routes. The source for the entire thing is over on github.

My idea is to store this information within a Service Container (we will use Symfony's DIC). For example here we can [define] our routes.yml. [...] We need to implement one Extension for the alias "routes". We only will implement the needed functions for YAML files in this example.

He includes the code for the extension ("SilexRouteExtension") that can be used to parse the "routes.yml" file to inject the custom routing into your application. This includes the pattern to match, the controller to route it to and the target method. You can also set some requirements like the request method (in this case "GET").

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. [...] But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler.

The profiler provides information on which components were accessed, their memory consumption and how long they took to execute. The integration happens via the WebProfiler provider for Silex and is already integrated into the Silex skeleton base application.

I was approached by a betting/gambling development company who potentially needed a middleware building that would pull from an existing gambling web service and basically transmit to connected iPhone clients the changes from the web service. At first, the obvious answer might be to create another REST web service that the iPhone clients could just ping for changes. However, one of the devs explained that this wouldn't be fast enough, or scale - they'd need changes to be transmitted as soon as possible, as the app would be a real-time betting app and there'd be thousands of connections to the server.

His solution involved hooking together Ratchet, Redis, Silex and Predis-async to create this sample tool for handling the websocket requests. it uses the "pubsub" mechanism of Redis to push the updates out to listening clients.

I was recently working on a small project that used Silex. As I browsed my vendor folder, I realized how much extra "stuff" I had inherited with Silex. There were a bunch of other components required when all I wanted was some quick and easy routing, micro-framework style. When I think about going lean I always find myself coming back to Aura. Micro-frameworks are not a new to idea to Aura, so I wondered if I could take the elegance and ease of Silex by wrapping up Aura.Router and exposing it through a similar API.

The result of his work is Aura.Micro, a simple microframework that really just handles routing (unlike Silex with builds on the Pimple DI as well). He includes an example of it in use, defining several different kinds of actions on the routing like "before", "finish" and a few "get" routes.

A couple of weeks ago Igor wrote a fantastic blog post about "Scaling a Silex code base" which made me remember a story I wanted to share about how I fell in love with Silex. This blog post aims to tell that story. If you never heard of Silex is let me paste the blurp from the silex home page for you: "Silex is a PHP microframework for PHP 5.3. It is built on the shoulders of Symfony2 and Pimple and also inspired by Sinatra."

He talks about some of his "first steps" with the framework and their need for a smaller system that could run embedded on a local machine. He talks about how Silex let him rapidly prototype and develop the application with only what was needed. He shows the evolution of his route handling from simple closures to method calls on objects out to using providers.

Supposing we want to render some HTML, do we want to inject the template engine in to the controller? Should the controller be responsible for knowing how to render the template? I'm not sure, but if I can have it not do it with minimal fuss, I think I'd rather it not. The full stack framework has the @Template annotation, which allows developers to assign a template to a controller and then simply return an array. If they can do it in the full stack framework, we can do it in Silex.

He includes the code for an example of a 404 handling page that uses the "convert" method to configure a route (path to a controller) for the currently matched route. He also shows the creation of a simple "CustomRoute" class and a "TemplateRenderingListener" to make it simpler to customize the handling and output of the request, all injected into the application's DI for later use.

One common misconception about silex and microframeworks in general is that they are only suited for small, simple apps, APIs and prototyping. Of course, those use cases are the main selling point, but they are by no means the limit of what is possible.

He shares some code that's the common "first steps" for someone using the framework, but points out a better way - moving your controller handling out into separate files instead. With a built-in feature of Silex, you can specify the "path" to another class file that will handle the request and return the response back to the main app. He also suggests extracting even more of the functionality out into "service" classes to handle the processing, cleaning up the controllers even more. He finishes off the post with a brief comparison between Silex and a full Symfony2 application, noting that Silex is a bit more "free form" when it comes to structure where Symfony2 apps are pretty well defined and have their conventions.

Last days I've playing with Behat. Behat is a behavior driven development (BDD) framework based on Ruby's Cucumber. Basically with Behat we defenie features within one feature file. I'm not going to crate a Behat tutorial (you can read more about Behat here). Behat use Gherkin to write the features files. When I was playing with Behat I had one idea. The idea is simple: Can we use Gherking to build a Silex application?. It was a good excuse to study Gherking, indeed.

He includes the example feature file - one that builds an API that lets you list users, get the information for a specific user and update the user's information. Also included are two simple requests to be made to the API and the actual script that makes the Gherkinn-to-Silex translation possible. You can find the full code on github.

There's currently a pull request in the queue for Silex that adds a cookbook entry for using controller classes, but I wanted to take it a step further and have my controllers as services, much like what's possible with the full symfony framework (See Richard Miller's post for further reading).

He includes some example code showing the creation of the Silex application with a service definition, the custom "ControllerResolver" to override the default and a simple controller class ("PostController") that just returns a JSON response. You can find the full example code for it on github.