Over the past year, Vimeo developers have written backend code in a variety of languages - PHP, Go, Ruby, Python, NodeJS, Java, C, C ++ and a little Rust.
In 2004, we started with just one thing: PHP. It was the perfect language for new startups like Vimeo. The PHP interpreter allowed entrepreneurs to quickly develop prototypes and had a large standard library that eliminated the hassle of day-to-day tasks such as sending emails and accessing databases.
Most of the startups fell apart, but some of them, based on PHP, were still alive after a decade. Few of them achieved dramatic growth, and later some of them these startups (the most notable example is Facebook) decided that PHP was the bottleneck and started migrating from it. There were two good reasons for this outcome: PHP’s performance and the difficulty of maintaining large PHP codebases.
In terms of performance, PHP in 2014 was slower than it should be and arrays consumed much more memorythan was necessary. Support for large PHP codebases was further complicated by the lack of good static analysis tools capable of massively recognizing bugs.
Vimeo has grown many times over ten years since 2004, and our PHP codebase has grown with it, but we haven’t grown enough to face these challenges in full force. However, when Facebook publicly abandoned PHP, some developers decided that PHP was slowly becoming the FORTRAN of the Internet era. A new wave of backend developers have begun to plan how we can transform 500,000 lines of PHP code into a set of better designed, more performant, and testable Go services.
It seemed inevitable for a while, but we never got to the point of completely abandoning PHP. There were obvious reasons for this: rewriting the entire codebase is costly and error-prone. However, there was another, less obvious reason: PHP got better.
The words “PHP has gotten better” do not fully describe its transformation. Over the past six years, the execution time of PHP code has more than halved, the developer community has grown significantly, and a popular trend has emerged to improve PHP codebases (old and new) based on conclusions drawn from static analysis.
It took some time for the PHP enhancements to penetrate into Vimeo. First, we had to get rid of the old PHP version (5.4), which had been working in production for many years after its expiration date. Thanks to the migration to PHP 7, the backend response has been significantly accelerated; in addition, the improved syntax of PHP 7 allowed our developers to write slightly cleaner code with full support for return types and parameters.
PHP hasn’t stopped updating – version 8 released at the end of November brought with it many improvements at the language levelwhich will allow our developers to express business logic more concisely. We plan to upgrade to the new version in early 2021.
Static analysis is cool
PHP greatly lowers the entry threshold, but as standard it does not provide much protection against being shot in the foot. Countless developers tried PHP for a short time over the years, then accidentally shot themselves in the foot and abandoned the language.
Sometimes I also shot myself in the foot while working with PHP, but decided not to give up, but to create a tool that would improve my accuracy. So was born Psalm Is a type checking tool for PHP based on static analysis.
The basic functionality of Psalm is roughly similar to TypeScript’s typing, and also borrows some ideas from Facebook’s Hack language (derived from PHP). Psalm informs the developer when PHP code may cause a type mismatch error in production, or when the logic is not clear. In addition, the tool has additional functionality such as detecting unused classes and methods, allowing you to automatically fix many of the found problems.
The use of Psalm in our CI pipeline over the past few years has transformed the way we write PHP code in Vimeo: Psalm gave us the confidence to make large-scale changes without worrying about the whole thing breaking.
These changes, some of which have introduced modern PHP coding standards to our codebase, have removed the legacy flavor – if you feel it’s safe to make changes to your code, it’s not legacy anymore.
I created Psalm to solve my own problems, but when we released it to open source it helped a lot of other people’s problems as well. Psalm recently helped us identify a bunch of security vulnerabilities in our codebase even before attackers could exploit them.
If someone reading this is working with a large legacy PHP project that is afraid to make big changes, then I highly recommend using a static analysis-based typing tool. Psalm (and similar tools) can get rid of existing problems in the codebase, allowing you to gradually improve the quality of your code.
Old code is not necessarily legacy
In the mid-2000s, there were no quality ORMs for PHP, so we created our own. Fortunately, PHP has many building blocks for creating a simple ActiveRecord-style ORM, including MySQL support, query parameter bindings, and magic getters and setters. It also helped us that really smart engineers took over this task.
The last major update to our ORM was released ten years ago. It includes some minor improvements – bug fixes, improved types and a few new features, but the basic structure remains the same.
We have made several attempts over the years to use a different ORM, but none of the proposals was designed to respond to new business needs; rather, their creation was motivated by a disappointment with the ActiveRecord pattern.
Ultimately, none of these proposals caught on. It turns out that old code may be preferable to new code if it meets the following requirements:
- Effectively fulfills its task
- Easy for static analysis
- Well tested
Fortunately, the ORM we created meets all four criteria.
In addition, keeping legacy code reliable gives us the opportunity to focus our development efforts on the business that benefits the business, and under the contract I am obligated (but also happy) to say that Vimeo has been on the rise lately with the release of lots of great products like Vimeo Record.
PHP doesn’t have to be terrible
Many developers wrote in PHP a decade ago, and have since moved on to more respected languages. They often readily tell others how glad they are that they no longer have to write PHP and that it cannot be fixed.
I believe it is possible, and Vimeo’s long-term success with PHP is proof that it is a great tool for fast-growing businesses in 2020.
The PHP resurgence has convinced at least one former skeptic. A colleague and longtime critic of the language once called me aside and thanked me warmly for showing him that “working with PHP doesn’t have to be terrible.”
Epic servers – this virtual servers for hosting sites from a small blog on WordPress to serious projects and portals with a million audience. Create your own tariff plan in a couple of clicks, maximum configuration – 128 CPU cores, 512 GB RAM, 4000 GB NVMe!