Maintaining a PHP Publish/Subscribe Client Library

We have a ton of client implementations here at PubNub, even with newer and more exotic languages like Google Dart. So obviously PHP, being the 3rd (after C and Java) most popular programming language worldwide, also needs a client-side implementation, so we built a PubNub PHP publish/subscribe SDK.

To be usable, every library has to support almost any version of its language translator and SDK that exists. This is usually not a big deal, and it’s uncommon for a Java application to crash or fail to compile when the next JDK is released…

Maintaining PHP Versions

However, not so with PHP. My first idea was to have several versions of the code for every major release of PHP, but as changes and fixed will start flowing, it will quickly descend into unmaintainable mess. Having a single version of codebase seemed impossible, mainly because namespaces are missing from versions prior to 5.3, and those are still in common use today.

After some doubt, I decided to make a single codebase which is written in pseudo-code, not directly compatible with any PHP version, calling it ‘php_’, and a simple preprocessor to build out code applicable for a given version out of it. If you want to change something in the functionality, you should just change *.php_ files in ./core/src folder of the project, and then run ./build.sh in ./core.

Voila! Your files are up-to-date for latest versions and old ones like 5.2! Ability to do so helps a lot to automate building and testing.

Unit Tests

Next question was unit tests – which are especially multiplied by the diversity of PHP behavior dependent on the version of interpreter. I’ve covered most functions with PHPUnit tests, but then I faced another problem.

PubNub developers normally use

for most of their projects to manage and automate testing process, but we’ve faced an issue with switching of PHP version.

Jenkins was not designed for PHP testing, and it doesn’t have native possibilities to pick different versions for tests. There exists a wonderful tool called PHPBrew that helps with such switching… and has one more issue: after small investigation, I found problems with PHP 5.2.

So I needed to choose another autotesting tool.

Picking an Autotesting Tool

Picking between several options, I chose Travis-ci. Travis is a good choice for automate testing in direct meaning. You don’t need to think about storing source code on some servers (or local machine). Rather, you can configure the testing system once and it loads all current code fixes automatically from GitHub and does a coverage.

As I expected, it turned out that most of the existing PHP releases, except a couple I tried it on myself before, failed some tests. It could take a lot of work to find it out otherwise, because setting up every PHP version manually will also pull with itself a lot of incompatibilities with other libraries – imaginable if i set up many virtual machines for tests, but I am happy I avoided it.

For better performance, HTTP pipelining was implemented. This method gives opportunity to send several server requests simultaneously and as a result application shows better average response time.

Working on PHP client library rewrite for PubNub, I faced many interesting challenges, all done to optimize throughput, unify codebase and provide full test coverage. It is now ready for production use and apart from asynchronous calls, provides interface to everything PubNub has to offer.

Enjoy!