
Why PHP for REST API?
I currently run this website on a pretty small 1 vCPU 512MB environment on AWS and it’s perfectly fine for a statically generated website such as this. In fact with AWS’s CDN it’s proven to be very fast. This is the real joy of static site generators such as Jekyll over classic database driven CMS environments such as WordPress, along with being substantially more secure. In fact as a static site is really all about network and storage I/O, the CPU utilisation has bearly risen above 0.2%. The idea of deploying my website to a VPC environment rather than shared hosting or S3, was that I’d have a Cloud ‘sandpit’ for other projects and experiments.
I thought I’d share my experience of building an REST API using PHP and provide a bit of a tutorial and hints and tips for anyone else out there wanting to do something similar.
The technical platform is NGINX on Amazon Linux AMI with PHP-FPM deployed on UNIX sockets. So given I didn’t want to go the expense of increasing my Cloud resources and costs, I decided I’d leverage the base environment to build my REST API server. I have been doing a lot of development in Python recently, for both Data Science and APIs. I’ve become a fan of OpenAPI 3.0 and have been using the Flask based Connexion OpenAPI framework.
Once I knew I was going to be building on PHP (7.2) I started to look around for a REST API framework. Swagger OpenAPI Generator supports PHP for the Slim framework, but I’m not a fan of Slim. Also the code generated for the Slim framework didn’t really provide that much acceleration or OpenAPI 3.0 validation. Nowhere near as much as the Python Connexion framework supports. However, deploying a Python Flask based runtime didn’t seem to make sense. I would just take another slice of memory. Also integrating HTTPS SSL with NGINX to PHP-FPM was going to be simpler than setting up a reverse proxy to a Flask server.
It’s been a while since I’ve done much development in PHP so I trawled the web for the current state of PHP MVC frameworks. In the end I opted for CodeIgniter 4.0. I’ve used CodeIgniter 3.0 in the past and have liked it’s balance of performance, ease of use and minimalism, yet is still feature rich.
MySQL / MariaDB is normally the database of choice with PHP, however MySQL is quite a memory hog. Although I have enough physical memory space to deploy MySQL I figured that it would take away cache being used by NGINX and so impact my website performance. So, I opted for the simpler route of SQLite3. Given the transaction volumes I am planning to put through this service, SQLite3 should be good enough, particularly as it’s deployed on a fast SSD.
A Quick Note on the PHP Debate
Historically PHP was seen by a lot of Software Engineers as a poor relation to languages such as C++, Java, Python and, more recently, NodeJS for backend web development.
PHP originally started out as an interpreted scripting language for Web Servers,. It suffered from weak typing and “spaghetti code” websites. However over the years it’s evolved and addressed a lot of the original deficiencies and criticisms. With the advent of PHP 7.x and the PHP-FPM daemon it’s also become a pretty performant platform. Even in 2020, with the rise of platforms such as NodeJS, Ruby and Go, ~80% of the Web is powered by PHP enabled sites - a lot of these are likely to be CMS platforms such as WordPress and Dupal. Even so, that’s a serious figure.