Symfony offers a state-of-the-art foundation on which they can build custom features with ease. Not only that it offers the tools to build the features, it also offers an unparalleled debugging environment which also includes a birds-eye view over an entire request, starting from the configuration of the environment going to a timeline of the request showing all the moving parts in a specific request.
Symfony2 was built for PHP5.3, meaning that it takes full advantage of its features: Namespaces, Autoloading and Anonymous functions (Lambdas). It also keeps up with PHP’s development by supporting new PHP features while keeping Backward Compatibility.
Having lots of built-in components is good but it is never enough. For the need of third party components we are using packagist, the online PHP package repository, and composer the PHP package manager. On packagist we search any package we need (be it an integration with a third party provider, a payment gateway, a new logging system, or anything we can think of) and, with a little composer magic, we’re all set up in a matter of minutes, ready to build the feature around the module. Most of the modules are already production-ready and unit-tested, so we don’t need to worry about their stability.
Speaking of testing and stability, Symfony2 comes with good PHPUnit integration and with a thing called “The Dependency Injection Container” which introduces a fresh perspective on application structure. This Container allows our developers to define their modules’ dependencies and then it takes care of the rest. By defining dependencies beforehand, our developers make the code highly modular and unit-testable. Everything can now be tested, having a clear set of dependencies which we can “mock” in the tests.
The Container I mentioned above is at the heart of Symfony and one of the things which make it highly modular. Because of it, basically anything that is included in the Container can be replaced with ease, from anywhere in the code. Even Symfony’s internal components can be overwritten.
The Symfony Project is only a set of components. Around these components there is something called “The Symfony Full Stack Framework” which includes other high profile third party projects, like Doctrine, Swiftmailer, Twig and Assetic. Each of these projects was included to fulfill a specific role.
The Doctrine Project handles anything Database-related. It’s both: a highly-capable Database Abstraction Layer, and an Object Relational Mapper. The DBAL supports any backend that PHP’s PDO supports (MySQL, SQLite, PostgresSQL, MSSQL, Oracle SQL etc) and also supports master-slave setups or even Multi-Master setups (to the delight of our DevOps).
The Doctrine ORM supports elaborate relations between entities, custom hydration schemes and entity events (with an additional module, Doctrine ODM, it even supports MongoDB as storage backend and can have relations between entities across Database engines, like between MySQL and MongoDB).
Swiftmailer performs only one task: sending emails. Even though it seems to be a small task, most developers out there will know how hard it is to merely send emails. This project abstracts away all the pains of delivering an email and it’s awesome at it ! It supports custom transports (forget about SMTP; REST APIs are the future) and filters. For example, our developers are actively using the rewrite filter to send any email from their local environments to their own inbox, so that they can implement and debug the emails.
Twig’s task is templating, rendering views (putting the V in MVC). It is a great templating engine that supports includes, macros, variables, filters and functions. It is easily extensible with any filter, function or even tag that is needed. It has a pretty exhaustive list of functions and language constructs out-of-the-box.
Assetic handles your applications wp-content. It can package your wp-content for both, production and development environments, it can filter them with his built-in filters (like Google Closure Compiler, YUI Compressor, SASS, LESS etc) or you can roll your own filters ! Not only that it packages and filters the wp-content, it also takes care of generating their URLs, even if their hosted on CDNs.
Why DevOps love Symfony ?
It has never been easier for our DevOps to deploy and scale a project. The most important feature of Symfony is the fact that the entire framework is built around the request. In some aspects, it’s just an application server that can be scaled horizontally to the limits of the infrastructure. Deployment of a machine is as easy as running “cap deploy” using the provided Symfony-Capistrano integration, Capifony.
Our DevOps also love Symfony’s logging capabilities. It offers them solutions to centralize the logs (syslog, graylog) and also stats (the well known, battle-hardened New Relic, or the cheap, self-hosted statsd + graphite).
These tools give them never before seen levels of detail for logs or statistics that delight them.
