In a quick post to his site Sameer Borate looks more in-depth at how MVC routers work to translate the incoming request and point it to the right code for handling.

A MVC Router class or a Dispatcher inspects the URL of an HTTP request and attempts to match individual URL components to a Controller and a method defined in that controller, passing along any arguments to the method defined.

He provides the code for a simple example, matching the path directly from $_SERVER['PATH_INFO'] to a key name in a set of routes. Routes are added to the list via an add_routes method and are only matched directly. This is the most basic version of a router with many other frameworks stacking features on top including wildcard matching, optional parameters and regular expression matching.

Sergey Zhuk has a post on his site that covers using a Router with a ReactPHP component. This router lets you more easily direct the HTTP requests coming into the application to the correct piece of functionality.

Router defines the way your application responds to a client request to a specific endpoint which is defined by URI (or path) and a specific HTTP request method (GET, POST, etc.). With ReactPHP Http component we can create an asynchronous web server. But out of the box the component doesn’t provide any routing, so you should use third-party libraries in case you want to create a web-server with a routing system.

He starts with an example of manual routing, showing the code for a basic server and adding in handlers based on the path+HTTP verb to respond with different content. He expands this basic example out to a more "real world" situation of the usual CRUD handling for "tasks". The post then shows how to change things up and use the FastRoute routing package to remove the manual route definitions from the server and define them in the router instead. It can then dispatch these to the correct location more easily. The post finishes up showing an additional feature: how to use wildcards in these URL definitions.

On the Symfony blog they have a post covering the result of some changes to how the framework handles incoming requests in Symfony 4: a performance and speed increase in the router making it even better than before.

Symfony 4 is the fastest PHP framework according to independent benchmarks, but we are continuously working on making it faster. In Symfony 4.1, we improved the Routing component to make it much faster when matching incoming URLs.

The post starts with a look at the two functional pieces of route handling: the generation of a URL to match and the matching the framework performs. Symfony 4 has sped things up by creating a "matcher" class during the compilation phase using some of these suggestions. The biggest change was to modify the regular expression URL matching to combine all patterns into one, reducing the number of calls to preg_match and locate the correlating route. The new routing requires no changes in your current Symfony 4 application, it just makes all of the updates it needs behind the scenes during compilation.

Rasmus Lerdorf has shared a post to his site detailing how he upgraded his EdgeRouter Lite router (hardware) to use PHP 7 for the uI handling and processing, upgrading it from the PHP 5.4 it came installed with.

After nearly 7 years of service I retired my Asus RT-16 router, which wasn't really a router, but a re-purposed wifi access point running AdvancedTomato. In its place I got a Ubiquiti EdgeRouter Lite. It is Debian-based and has a dual-core 500MHz 64-Bit MIPS CPU (Cavium Octeon+), 512M of ram and a 4G removable onboard USB stick for < $100. The router is completely open and, in fact, any advanced configuration has to be done from the command line. The Web UI has been improving, but there are still many things you can't do in it. In other words, exactly the type of device I prefer.

He made use of the open platform the router has to upgrade both the PHP installation and a bit of the web UI code to make things work happily with PHP 7. There's just three steps in his process:

• Getting a Big-Endian MIPS64 build of PHP 7
• Configuration (php.ini)
• Fixing broken stuff

The "broken stuff" in this last item was only a few small changes that needed to be made to the web UI code for raw POST data fetching and session writes. He ends the post with a little summary of the performance post-changes and some about the opcode handling and memory use per request.

On the Toptal.com blog there's a recent post about true dependency injection with Symfony between components in your application and only using the dependency injection container for its intended purpose.

Symfony2, a high performance PHP framework, uses Dependency Injection Container pattern where components provide a dependency injection interface for the DI-container. This allows each component to not care about other dependencies. [...] But this means DI-container can be used as a Service Locator.

[...] In this article we will try to build a Symfony2 application without implementing Service Locator pattern. We will follow one simple rule: only DI-container builder can know about DI-container.

They start off by talking about the structure of the dependency injection container and how it relates to the three main types: controller, method and property injections. He then starts in on creating the sample project and requiring only the Symfony DI, configuration and Yaml components. He then creates a ContainerBuilder class and sets up the HttpKernel functionality to pull the response from the container. He then makes a simple controller with a default action that just responds with text. With this working he updates it to pull in an input variable. He then makes updates to the application with changes to the route handing, templating (Twig), Doctrine (database) and tag handling.

Dylan Bridgman has posted a new tutorial talking about building one of the key pieces of any framework (and most applications) to help get requests to the right place - a basic routing system.

There is always value in learning about the internals of the frameworks and libraries we use. It allows for a deeper understanding of the problem being solved and appreciation of the work that has gone into these projects. So today I will be building a basic router to explore this fundamental part of even the smallest framework. The idea is not to create something complete or production-ready but rather the minimum set of features needed to be considered a router.

He creates a simple script that handles both static and variable routes as well as throw an error when a route match isn't found. He starts off talking about the structure of URLs and shows the setup of a rewrite rule to forward all requests to an index page (where the router lives to handle them). Then he talks about the structure of the routing table and how to structure the route-to-action formatting. He opts for a simple PHP array with a closure as the action portion as a starting place. He shows how this is useful for static route matching but upgrades to regular expression matching (passed through a preg_match) to allow variables.

Piotr Pasich has a new post to his site today showing you how you can use the Symfony2 router with CakePHP, another popular PHP framework. He talks about some of his own experiences using CakePHP and how one module "left a bitter aftertaste" when using it - the route handling.

The second version of CakePhp still has a lot old-fashioned patterns, singletons or lack of tests, but I can live with that. I saw a lot of better or worse frameworks in my life.

He goes through an example of the CakePHP routing including some sample code and a walk-through of the code that actually handles the request. He points out some of the "clean code" violations it makes and gets started integrating the Symfony2 router instead. He extends the CakePHP router and uses this plugin to bridge between the two. He then can call the Symfony router with only slight modifications to things like the "getPath" calls.

On the Aura Framework blog, they continue their look ahead at the coming version of another of the framework's components, the Aura v2 Router. The Aura framework is a decoupled, modular framework that focuses on minimizing dependencies.

Lately, we’ve been going over the migration of v2 packages from v1. Today, I’ll talk about the updated Aura.Router v2 package. While not an example of extracting a new package from an existing one, it has a couple of features that other routers don’t currently have, in addition to being truly independent and completely decoupled from any other package.

They focus on some of the basics (more detailed information can be found on the package page) of the package's new features and its focus on routing rather than dispatching. Sample code is included showing it in use. The examples show basic routing, routing by server values and attaching route groups. There's also a brief section about adding REST routes via an "attachResource" method call.

On NetTuts.com today there's a new tutorial posted about "taming" Slim 2.0, the latest version of the popular PHP microframework. They look at application structure and share some tips to using this update.

Slim is a lightweight framework that packs a lot of punch for its tiny footprint. It has an incredible routing system, and offers a solid base to work from without getting in your way. Let me show you! But that’s not to say that Slim doesn’t has some issues; it’s one-file setup becomes cluttered as your application grows. In this article, we’ll review how to structure a Slim application to not only sustain, but improve its functionality and keep things neat and systematic.

He starts with an example of "vanilla Slim" and looks some at what's happening behind the scenes in the routing engine. They then give you a step by step installation and usage guide including updating the router to use class files. An example controller is included as well as some basic error handling using a Twig template for use across the application.

With all of the recent talk about the Aura framework that's been happening lately, Stan Lemon thought it would be interesting to see how a microframework based on the Aura packages would be to create. He's posted about his experiences on his site today.

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.