zen of coding

The State of PHP MVC Frameworks in 2017 (Laravel, Symfony, CodeIgniter, CakePHP, Zend)

A simple question prompted me to sit down and write this follow up to my article from about a year ago.

Q: Any thoughts about where things are today? (2/24/2017)

A: “I’d say it’s pretty much down to Laravel and Symfony at this point; when it comes to PHP frameworks. I don’t feel that there is any specific value to using CakePHP, Zend, CodeIgniter, Yii, etc. if you are starting a new project.
Only if you already know those frameworks or have developers that are used to working with them, I could see a reason to use them.
When real development starts you have to be able to find tools, plugins, answers to common problems. And with Laravel and Symfony communities and constant development of new “modules” or features, you never feel like you’re left behind. Laracasts alone (even if you don’t develop in Laravel) are simply fantastic.

Whether it’s integration with services like iron.io or other SaaS providers, support for a wide variety of data-sources, local dev env like “Homestead”, these frameworks and supporting modules are much more forward driven.

Complimented by Lumen for quick API development Laravel really shines as a great approach to rapid application development and prototyping nowadays. Not to say that it’s somehow limited [when it comes to building] larger applications.

Generally speaking, however, we’re definitely seeing a shift towards a container-based architecture, where MVC plays a much lesser role. It’s all about microservices, orchestration and building apps as “functions” (i.e. AWS Lambda and similar services). Perhaps it’s time to brush up on your Node/JS and GoLang skills :)”

Although I felt generally happy with this answer, I couldn’t help thinking that elaborating on some of these points and taking a fresh look at where things are would be a good idea.

Before I jump into the strange topics like “GoLang”, let’s actually take a step back and glance at the trends in 2017, in the PHP MVC Frameworks World.

PHP MVC framework trends in 2017 (CakePHP, Laravel, Symfony, CodeIgniter, Zend)

I would say that the trends we’ve observed in the past are holding up. Laravel is still pushing forward, while most everyone else is falling behind. There is a little uptick in Symfony popularity, probably due to the much awaited release of Symfony 3.

(I have tried more specific searches for comparison such as “CakePHP 3”, or “ZF2”, however those did not produce statistically significant trends).

This year I’ve included CodeIgniter because it is very popular, as evident. I received a number of questions about CodeIgniter and my thoughts on where it stands in the PHP MVC community…
Well to keep it short, CI is still out of the competition because it’s not a true MVC framework. I don’t know what to call it other than an organized collection of POPO’s …

Let’s just take this quote directly from their manual:

CodeIgniter has a fairly loose approach to MVC since Models are not required. If you don’t need the added separation, or find that maintaining models requires more complexity than you want, you can ignore them and build your application minimally using Controllers and Views.

When it comes to building a framework I simply disagree with this approach. Perhaps it’s a decent boilerplate, hence CodeIgniter’s popularity, however there must be some discipline enforced by the framework, otherwise the eventual product winds up being a mess of spaghetti code, wrapped into some sort of a “pattern”.

Moving on, Symfony 3 brought us some decent improvements in developer experience, dependency injection and a number of other features. Like many PHP counterparts it now offers a micro-framework. ZF3, comparatively, delivered a set of improvements, like support for PHP7 (finally) and even a micro-framework of its own… but like their manual says:

For Zend Framework 2 MVC users, the differences are subtle…

I was really hoping that they would say that the differences are dramatic, that there was some great architectural improvement, wonderful new modules that help you develop things in a modern way. Alas, for the most part ZF3 remains pretty similar to ZF2.

Long story short

Here’s how I see the world of PHP frameworks today:

  1. Symfony or Laravel, depending on your needs
  2. The rest

Hands down, Laravel stole the show. The amount of information available, Laracasts, world wide developer talent, simple pattern implementations, integrated testing toolsets, active record implementation in the form of Eloquent, lightweight version in Lumen, local development using Homestead (Vagrant) make this framework really stand out for new and seasoned developers.

However Eloquent models can get unruly and rather large in size, too many Laravel services may be created (not to be confused with microservices) and people start thinking about Repository pattern implementation where it doesn’t belong. Thus a Monolith is born.

If you are not comfortable with the active record pattern and need the added flexibility of Repositories, or perhaps you’re seeing too many anonymous functions for your liking, then use Symfony + Doctrine.
Do I consider Symfony a gateway to monolithic applications? To some degree, yes. However, it is probably the most elegant one.

Overall, I would not call it a drastic change from the last year. Still, we need to take a look at the bigger picture: a properly designed application goes beyond just MVC; it’s about infrastructure, deployment pipeline, decoupled architecture. All of these can be achieved in an MVC stack, but one needs to be extra mindful to avoid the Monolith.

Advent of Microservices

Earlier I’ve alluded to the rise of the microservices and the need to brush up on GoLang or Node skills.
Indeed, even in the PHP MVC article it would be silly not to mention a clearly happening move towards microservice oriented architecture (MOA); and it’s gaining momentum like you wouldn’t believe it.

While the two concepts are not mutually exclusive there’s no reason trying to find parallels between the two, as they really do represent different, albeit intersecting philosophies.

As an example, putting your MVC app in one container and MySQL in another and then linking them together, doesn’t necessarily represent a proper MOA.
This is certainly a better approach, in fact much better, than trying to install MAMP, XAMPP or whatever other clutter you need in order to get your local machine to serve an application.

Additionally, it may solve some issues like ease of running a local environment across different platforms (developers) and perhaps deployment strategy, in some cases, but you are stuck with an MVC Monolith in your app layer/container.

Destruction of the Monolith

This “destruction” is what microservices are all about.
While MVC addresses your code structure and organization by providing a solid approach to the separation of concerns, this concept is extended even further by the containers/services/MOA.

Instead of just separating your views from your models, you are now separating each “chunk” or logical unit of your application into an individual service, designed to properly handle its own responsibilities.

If your MVC app has a “Search” controller, action, and relevant Model methods, then we already have an example of a monolithic application.

In contrast, using MOA approach, we’d have a service for each one of those processing units. As an example:

  • Router Service
  • Request Service
  • Query Service
  • DataSource Service
  • Response Service

Wait, but aren’t all those “services” are just a part of an MVC stack. Well, yes, exactly. They are the building blocks of our Monolith.

With MOA each service runs within its own environment, and as developers, but more so as architects we are free to design the best approach to solving a specific need.

As an example if I were to write an Image Processing Service within a Laravel environment, I’d probably be using something like PHP-GD2 extension, which may not be the most efficient way to process images. A C++ service that handles my needs of image processing, may be a lot faster and definitely more robust at scale. To elaborate even more we could now take the output of the Image Processing Service and send it off to DataStore Service, CloudStorage Service and Queue Email Service.

Solving this same challenge with a bunch of cron jobs and possibly a couple of separate MVC apps and custom scripts is how we did things back in the day (i.e. 2 years ago). Time to move forward.

Scalability

This is where the problems start (or end, depending on where you are headed). On one hand it’s hard to scale a Monolith, if you build more and more logic into the same MVC stack you’ll be stuck with, perhaps, a well structured application of horrendous complexity.

On the other hand if you build a thousand microservices in a variety of languages, how do yo manage THAT mess?

There is more than one disaster that has been reported.

There are various container orchestration tools (like Kubernetes, Swarm, Mesos), container deployment services (i.e. GKE and AWS ECS), however few enterprises have nailed the Docker architecture. There are definitely success stories in building out of the infrastructure using Docker or other container technologies (i.e. GKE). Most of these stories come from companies that can afford to spend resources on architects, devops, DBA’s and engineers. Still, as it stands now there are countless debates about how to deploy a well orchestrated and elegant MOA. One size definitely does not fit all in this case and there is a multitude of ways to solve your challenge.

Either way you’re not going to solve this problem alone (DevOps FTW!), and not until you’ve hit a relatively massive scale, will this problem actually need solving. Maybe it’s not the right time to over-engineer.

A happy middle for today (and for those that deal with apps of lesser complexity or traffic requirements) is to offload many typical services to third party providers. Almost everything is available as service now. Background jobs, image processing, authentication, data analytics, logging, email sending, queue systems need not be built within the same MVC stack, rather an Architect should think about what could be offloaded to a SaaS system for a low monthly cost (i.e. search by Algolia) or perhaps a custom-built docker service running in some cloudy space, which handles that annoying image processing.

I guess the point here is that you should not jump into a re-architecture project head first, do not dump everything you have today, and release docker swarms wherever imaginable. There are ways to gradually roll out an improved foundation by decoupling what’s possible, learning about bottlenecks in the system and applying the notion of separation of concerns to these problem areas.

Summary

2017 is going to bring us more conversations and production deployments of container-based and MOA. My points and ramblings about Docker, using GoLang or Node, do not mean that PHP is “dying” or anything of that sort … I feel that as developers we need to stay on the cutting edge of things, so if microservices is where it’s at, then why not learn GoLang? It is ideally suited (due to low footprint, speed and parallel processing) for developing tiny containerized apps. Node and GoLang are fun because they allow you to build little services, who are all part of a larger tribe, link them together, and release them as an epic swarm of Docker containers if you so desire.
Yet, all this awesomeness and cutting edge solutions and languages does not mean that PHP is somehow no longer relevant or is otherwise “dead”. We’re definitely going to be building MVC stacks and API endpoints for a while.

One of the issues, which has not been solved by MOA, is that while containers help us to kill the Monolith on the backend we are still faced with many architectural issues in our front-end layer, UI or the view.
We can build an awesomely robust backend application, but in the end it will respond with a JSON, which somehow must be rendered in the client application. Does it matter if the eventual response object arrives from a simple PHP, let’s say, Lumen driven endpoint (URL) or an orchestra of decision making and processing units decoupled by a messaging interface? This, indeed, very much depends on your needs and the requirements of your application.

For this year, learn Laravel keep an eye on Docker, GoLang and definitely focus on the deployment pipeline. Getting from local to production should be smoother than it has been for a while now, especially when building your MVC apps.

  • davidyell

    This could be titled ‘Why I like Laravel’. It feels very one sided, stating features of Laravel as though they aren’t available in other frameworks, which they actually are. It’s great to be passionate about your chosen tooling, but presenting a balanced outlook would be valuable to the wider PHP community. I do understand it’s your blog and it’s an opinion piece, but some more in-depth research would have yielded a more balanced article.

    • There was some specific reason to make it kind of one sided (or two sided including symfony). I did a much more thorough analysis in the previous article and this was mostly a follow up to what happened since last year… And Laravel did gain more popularity and momentum throughout the year, than any other PHP framework, which is evident from trends, tooling, information about common questions and developer talent.

      • Josh Kisb

        great applications are not all about popularity of the tools you use.
        its best to evaluate the frameworks on their actual merits.
        don’t be biased by opinions of others when doing that research

      • just curious, what do you consider “actual merits”?
        either way my point was within a very specific context. also as I mentioned above, this is a follow-up post. please see a more in-depth analysis in a previous one. considering i have years of experience with many frameworks i would hardly call my opinions influenced by bias of others… as a matter of fact this blog used to be all about CakePHP (so if anything I should be biased towards that one).

  • Symfony isn’t considered an MVC framework. Hasn’t been for a long long time. http://symfony.com/what-is-symfony

    • I quoted the same paragraph in my previous article.

      For convenience purposes it can very well be considered an MVC framework, because it separates everything into those three distinct layers.

      Whatever acronym you feel like using next to symfony, is fine by me.
      Don’t see how it affects the substance of the post. Silly semantics, if nothing else.

  • Pingback: The State of PHP MVC Frameworks in 2017()

  • Judd Bundy

    Silly. Just silly.

  • Pingback: The State of PHP MVC Frameworks in 2017 | ItsSpicey()

  • Pingback: The State of PHP MVC Frameworks in 2017 – Media News()

  • Vladko, for the last year I’ve been working on my PHP Web UI library. My open-source project is located here https://github.com/atk4/ui which strongly focuses on object-oriented PHP web interface components. I have had requests from developers who write in Laravel, Yii etc asking me to offer a better integration between Agile UI and Full-stack frameworks.

    With the state of PHP MVC framework, do you think that existence of standard UI layer across our segmented market would be a good contribution to the ecosystem of a PHP?

    Thanks and I appreciate your insight.

    • great project, thanks for sharing. a standard UI implementation for PHP projects, would be a miracle :)

      i feel that this is a noble idea and it’s definitely needed for many use-cases.

      unfortunately many frameworks come up with their own “widget makers” (i.e. CakePHP’s form helper) or blade-based libs for Laravel. Of course in Symfony you have Twig and related tools.
      the way to get wider support would be to create adapters for popular frameworks, so that developers can opt in to use your solution. because everyone (each framework) tries to come up with yet another templating layer/language/standard… it’s a hard battle, i have to admit.

      also when working on a team with designers or pure front-end engineers, there is always a concern about using PHP or writing UI components in PHP, since most of them prefer everything from good ol’ JS to jQuery, to Angular, to VueJS.. well, anything except server-side language.

      I was planning to do a post on the state of the front-end technologies today, and how we’ve managed to achieve good structure on the backend, but created a bit of a mess on the client side in the process.

%d bloggers like this: