ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
Interfacing the PHP world
I have done a few tweets in the past weeks hinting at wanting to create a set of common interfaces for things like logging, caching etc. Now I pondered this some more and there are a couple of problems which I am not yet sure how to overcome them. Obviously the goal would be to make it easier to drop in components from one library/framework into another. If you want to see a concrete case where such interfaces could help just have a look at the recently created Doctrine Search project which needs an HTTP client.
Fixing the foundation of a standing house
I keep mentioning my stop building gold on top of crap blog post and here I go again. Basically the point of that blog post was that way too few PHP applications are build on top of a general purpose framework that enables developers to add custom functionality not directly related to the core of the application without having to commit suicide. Now I was arguing for these applications to adopt existing PHP frameworks. Obviously that would mean handing over quite a lot of control and for a large established application this might be a scary proposition even if it could save resources to focus more on the actual end user facing features of the application. Or there are others reasons, but either way it is a good move to think about how your foundation can empower such customizations. Interestingly enough I would claim doing so will also likely have a positive effect in your application on top as it will help untangle dependencies and assumptions into a cleaner structure. Even back when I initially posted my complaint Typo3 was already hard at work on doing exactly that: building a solid general purpose framework as the foundation of their next major CMS release. Today these efforts have come together in the first stable release of FLOW3! But other CMS are not idling either: With Nooku there will soon also be a rewritten core for Joomla and Dries and his team are also looking to clean up the core of Drupal to become more of a framework separated from all the higher level end user facing stuff in Drupal 8.
My PHP framework winner predictions
First up, I can only claim to be an expert in Symfony2. My knowledge of other PHP frameworks basically consists of actively following twitter for things related to PHP, reading planet-php.org and taking the time to read up on linked mailing list threads and IRC chat logs. I have not been that active on the conference scene in the past few years, but the ones where I did attend I also tried to take a peek at what others are doing. Also this post is kind of exploratory to see what other people think, hopefully without inviting a flame fest upon myself. So with this disclaimer out of the way, I think the big 3 frameworks for the next few years will be Lithium, Zend Framework 2 and Symfony2.
Drupal using Symfony2 HttpFoundation is huge
Drupal is big, no question. Over the last years Drupal has become one of, if not THE leading CMS. Now imho one of the reasons for its success is that it's a huge enabler for non programmers to get setup with a gigantic set of features. But here at Liip our bread and butter is highly customized applications or in other words if you can get your project done by installing a bunch of Drupal modules, then we are not the right shop to go to. We do however use Drupal when it's the best starting point for development like we did with Migipedia. However we have in many situations found that we could more efficiently implement custom logic outside of Drupal and then integrate it. Now since we have chosen Symfony2 for all future custom development, the fact that Drupal8 will use Symfony'2 HttpFoundation component is huge, because it will make integration a breeze.
Reverse proxy cache invalidation service
Liip is currently working on a news site. As news is all about being up to date, but still managing to serve a large number of users with milli second response time, we obviously run into a bit of dilemma. We can use Varnish to cache the content, but then we will need to use a relatively short cache time out or we risk not getting updates to our users quickly enough. A better approach is to use invalidation, where we can then set a relatively long cache time, but ensure that still no stale content is served. At Liip we provide a considerable budget for innovation available to all employees, so I figured it would be cool to use this to create a solution to allow us to move to cache invalidation for this site.