Hello there friend! You’ve landed on the REST API that backs my personal web site, https://lawrencemcdaniel.com, written in ReactJS and Redux and served from AWS Cloudfront. This backend REST API on the other hand is built with WordPress and runs on Ubuntu EC2 and MySQL RDS instances located at the Amazon Web Services (AWS) data center in Oregon. I implemented this REST API in mid-summer of 2020 and I’m quite satisfied with it in terms of usability, customizability, performance, reliability, cost, and maintainability.
“Why build a REST API with WordPress?” great question! Even though my own vanity and technology stack preferences tend towards, well, any other option besides WordPress, I must point out that it is a smart, pragmatic solution for many use cases.
Importantly, WordPress offers excellent tooling for image content management simply by virtue of its expansive ecosystem and rich catalogue of mostly-free plugins. As of Aug-2021 around 455 million web sites on the Internet were running on WordPress. This is a major consideration in my case due to the extensive use of imagery on my personal web site. But it’s certainly not the only factor that drove my implementation strategy. Following is a complete and prioritized accounting of the decision factors that drove my decision:
1. Image content management. Simple and effective image management is extremely important to me. My personal web site contains more than 500 images, and all of these need to be individually compressed, optimized and cropped based on how they are presented on each page which frankly, is pretty arbitrary. Site visitors’ attention instinctively flows towards the site’s images, so these need to be quickly and efficiently delivered to the browser and well-presented, which is more technically difficult and tedious to achieve than it might seem. Furthermore, image optimization itself is notoriously difficult to do well, and I would lose dozens of hours a month on this one mundane task if not for the professional quality image tools that are available in the WordPress ecosystem.
I quickly upload raw original images which are then automatically compressed, cropped, optimized and then transferred to a CDN hosted by AWS, all via a seamless automated work flow pipeline. Each of these tasks individually is hard to do well, but with WordPress and a $100 dollar investment I had all of this working in less than three hours. The end results are quite satisfying: all of the images that appear on my personal web site are perfectly sized and optimized; and with zero effort on my part beyond simply uploading the original images.
One the driving reasons that I purchased WP Offload Content is because in addition to automatically syncing the contents of my image media library to AWS Cloudfront, it also automatically rewrites URL’s in api responses.
Note that Imagify creates several versions of each image, and WP Offload Media re-writes URLs for each of these. This combination of functionality allows you the luxury of deferring decisions on which image to present in the browser until its actually needed, which in turn enables you to select the smallest/lightest image in real-time based on the user’s window size and their browser’s cache contents at that exact moment.
2. Ease of implementation. There are a half dozen api end points for my personal web site, and each of these are pretty simple. I’ve never found anything as easy to implement as WordPress for simple backend jobs like this, even though I actually work extensively with Django REST Framework in my day job. This entire site is created with zero PHP custom programming. Instead, I use a couple of free WordPress plugins.
3. Ease of Use. In addition to the site images, nearly all of the text content on my personal web site is stored as collections of WordPress posts, organized by custom tagging and categories that are managed by the Advanced Custom Fields WordPress plugin. This is important to me because after having invested several weeks developing the ReactJS /Redux site, going forward I want to minimize my time cost for keeping the site updated with new portfolio entries, technical skills, client logos, LinkedIn recommendations and so on. With WordPress I’m usually able to add new content in only a couple of minutes.
4. Ease of Maintenance. By the same measure, I also want to minimize my time requirements for keeping this site up, running, secure and healthy. This is easily achieved with a 3rd party backup solution (Updraft) along with security tools (Wordfence). Additionally, I minimize the number of WordPress plugins installed on the site, in the interest of keeping the environment as simple as possible. Maintenance of this site takes me around 10 minutes a month.
5. Performance. performance? WordPress? Really???? Well, as a matter of fact yes. It’s VERY difficult to beat the observed performance realized via image optimization, CDN delivery, and api page caching that you easily achieve with this simple combination of WordPress plugins. Additionally in my case, the cache hit ratio for this site is effectively 100% since the content of this api is mostly static. API requests are therefore mostly served in-memory by the site’s caching engine (WP Rocket), achieving response latencies of between 50ms and 100ms per request. But don’t simply take my word for it, you can test any of the end points on this site with a page performance service like Solar Winds’ Pingdom.
6. Operating Cost. I’m sensitive to running costs since this REST API supports my personal web site which obviously is not a revenue-generating venture. This site consumes negligible resources and runs effectively for free, as it is colocated among several other sites running on the same shared infrastructure.
I should mention that I have a variety of existing infrastructure on which I could install a site of this size; the point being that my “free” options are not limited to WordPress or even LAMPs for that matter. Among my other free or nearly-free options: Django REST Framework, NodeJS, AWS API Gateway, and Ruby on Rails. Each of these are fine technologies, and in point of fact I do spend considerable time working with some of them. The achilles’ heel with most of these regards shortcomings related to image management. I simply do not find image tooling on par with that of the WordPress ecosystem in any of these alternatives. Secondarily, it would have taken a lot more effort on my part to achieve at best, a comparable end result.
Production API Endpoints
Clients – Open edX