Today marks the release of Lumen, a new micro-framework from Taylor Otwell, the creator of Laravel. A lot of people have strong opinions on Laravel and the community is most definitely split. I decided to give it a try a few times with version 4 but never got on with it. I tried again just after version 5 was released, and now having built a couple of side projects using it, I'm a convert.
I'm not going to recommend we use it for anything in my day job just yet, because my day job is very enterprise-y, with 10 year+ lifespans, large teams, and clear upgrade paths, and Laravel is known to introduce BC breaking changes in minor versions from time to time, and in my current work environment that's not cool. As a Rapid Application Development (RAD) style framework for my side projects though, I'm really impressed with it, and it's a joy to work with.
Alongside this, and for several years, I've been pondering, designing, working on, and abandoning ideas for a component-based framework which comes in 3 distinct flavours: Micro, RAD, and Enterprise. The idea is that each would be setup or "bootstrapped" differently, and have different levels of configurability and scaffolding, but would share a common philosophy and API with easy migration paths between each. You could pick the one that suited the project you were working on, with all three being interoperable, and move between them with relative ease. This also has the added benefit of shared knowledge and shallow learning curves. With Lumen, Taylor has completed 2/3 for me.
At this point you generally get two distinct types of developers disagreeing. The first, I'll call the Enterprise Everywhere developer. They would say that this solves a problem that shouldn't exist. You should extract your Domain Model and then use a Hexagonal Architecture with Ports and Adapters so that the framework becomes an implementation detail and is easily swapped out. They're right, of course, but only if your application falls into what I would call the Enterprise Zone. An Enterprise Zone application is an application that is either sufficiently complex to warrant proper Domain Modeling, sufficiently large in size, or will live long enough to see major revisions and needs a clear migration path between entire frameworks, framework major versions, or organisational pivots.
The truth is, not every application is an Enterpise Zone application. Whilst you can solve many of the same problems that a Framework Trinity addresses with these techniques, they represent a significant investment that doesn't always pay off, especially if you're the second type of developer, a type of developer that I'll call a Framework Specialist. A Framework Specialist typically comes from an agency environment, and develops what I'll call Agency Applications.
Agency Applications have very different metrics for success to Enterprise Zone applications. Often, the key issues for Enterprise Zone applications are:
Enterprise Zone applications are typically worked on by teams of developers for a long time. Maintainability and Stability are key for these applications to ensure that Velocity doesn't slow to the point that you're paying 10 full-time developers to add a single feature per month, or worse, and every time you deploy or change the application it breaks in unpredictable ways. This will destroy the business' confidence in your team and can take years to recover from.
This differs from Agency Applications, which are typically measured in:
Agency Applications are typically worked on by single developers or small mixed disciplinary teams of developers and designers. A significant portion of these applications will never be touched again after they are delivered. They could be MVPs, prototypes, custom content management systems, temporary or time-bound applications (think sporting or arts events) or simply marketing websites that get thrown away and re-built every 3-5 years. The key here is delivering the most features in the shortest amount of time to increase return for the agency and make the most profit. Writing maintainable code isn't high on the list of priorities, because these applications won't be maintained. That's why Agency Applications are usually developed by Framework Specialists. Framework Specialists love the speed benefits and simplicity of frameworks, and most of this comes from convention over configuration - you learn the framework way of doing things, buy into it fully, and then the software seems to almost write itself.
This brings us on to the issue at hand, what I call the Messy Mixed Middle (M3). You end up in the Messy Mixed Middle in one of two ways: under-engineering or over-engineering. Writing an Agency Application that should have been an Enterprise Zone application (many startups end up here by creating a RAD MVP then finding Velocity drops and they need to re-write for version 2), or similarly, writing an Enterpise Zone application that should have been an Agency Application. Either way, the result is the same. You have an application that is massively over-burdened with Technical Debt. The only way out of the Messy Mixed Middle is to refactor, and that's expensive and can take time.
At this point, many organisations look at the cost of refactoring their applications and opt to go down the Tiger Team route. You keep half of your team working on adding features to your current application, so development doesn't stall and your customers/the business remains happy, and half of your team work on a new greenfield project to do things The Right Way. This almost always fails. The main reason for failure is that the Tiger Team is unable to keep up with the new features being added to the application, and they lose the context of much of the code in the original application, so you end up with regression bugs.
The trouble is, especially in an agency environment, you don't always know how an application will end up when you start writing it. In the past I've created an event registration website for a one off event, only to have the customer come back and say the following year that the event was such a success they're doing it again, and can they re-use the site with these changes... Times that by 3, 4, 5 years and you could end up with an unusable application and a customer that can't understand why they can't make this simple change without breaking everything.
This is where I think having three different frameworks with a shared API would help massively, and is why I've been thinking about it on-and-off for the last 4/5 years, ever since I worked in an agency environment myself.
Being able to extract code from a RAD style application into micro-services, or share code for an API, would be massively helpful for applications in the Messy Mixed Middle. It introduces a low cost refactoring step that gets you half way to the benefits of an Enterprise Zone application without the same investment of time and resources.
Symfony & Silex
You could argue that we started down this path with Symfony and Silex, however there is one major difference between Silex and Lumen - Silex does not have a shared syntax or API with Symfony. There is no clear upgrade or downgrade path. Silex is a micro-framework built on top of Symfony Components, but is not itself designed to be interoperable with Symfony, and to me that makes Lumen stand out.
So where does that leave us? Hopefully you can see the benefits that something like Lumen can introduce for organisations that are trapped in the M3 Zone, but unfortunately only if they started their RAD journey with Laravel. Either way, I find it highly encouraging to see a major framework go down the same path I've been considering myself, and would like to see more framework vendors follow suit.
The next logical step is for Laravel to introduce an Enterprise version. Many would argue that Laravel is already an Enterprise framework, but it is not. Enterprise Zone applications should be written in the manner we described previously: with a Domain Model, Hexagonal Architecture, and Ports and Adapters. That means that the framework itself doesn't really matter, as our application is written in Plain Old PHP, not in any framework, the framework becomes our Delivery Mechanism and only does things like routing, and session and database management. You can already do that with Laravel. Laravel even goes one step further than most, by introducing the Laravel Contracts project. Laravel Contracts is a collection of Interfaces that are used in Laravel so you can write your own custom components and swap them with the Laravel ones. Just like the PHP-FIG creates Interfaces for interoperability between frameworks, Laravel Contracts defines interfaces for interoperability between your custom application components and the framework. For Enterprise Zone applications this is a massive win and is something else I hope other frameworks start to copy.
Whilst all of this is great progress, in reality, even though these tools and techniques can keep you de-coupled from your framework, you don't want to be spending your time swapping out your Delivery Mechanism, you want to spend your time where it matters, in your application code adding value. At the same time, you need a framework that you can upgrade and patch reliably and safely. That means design by committee, formal documented processes and procedures, mitigation of the Bus Factor, and Long Term Support (LTS) releases. That's why we'll be sticking with Zend in my day job for the foreseeable future, but with the release of Lumen, it does look like the future will be a little brighter for Laravel.