Critical AdjustmentsA Handful of Crucial Website Changes |
The upcoming project was beginning to suffer from scope creep and so it was split into two smaller projects. The first, Project 11: Cache Busting & Data StoreCreate a cache busting feature to ease deployment and testing, and create a local data store to hold database content on the web server., will focus on more pressing issues such as the need for cache busting functionality as well as the poor startup performance of the website when the database goes dormant. Additionally, it will be addressing concerns with the current code organization and the removal of line feeds and carriage returns from the content data. The second, Project 12, will be about revising the Javascript development environment using Jest to add automated unit testing.
A much-needed change was the addition of cache busting. In development, I had gotten used to periodically clearing the browser cache on my MacBook to test changes, however having to do this on multiple devices and multiple browsers to see the impact of changes made on the production server became burdensome. I took the roll-your-own approach and created a function that added the file update timestamp to local links of *.css, *.js and image files (e.g. /css/tbd-chart.css becomes /css/tbd-chart.20180228073458.css). The .htaccess file was updated to add a Rewrite Rule that stripped out the timestamp.
Using the example above, the actual file remains /css/tbd-chart.css and the source HTML references that location. When the page is requested from the server the timestamp is automatically added and the reference becomes /css/tbd-chart.20180228073458.css. The browser now receives a unique name for every version of the file and if the file changes, the name changes so it can not use a previously cached version of the file. When the browser requests the file from the server, the Rewrite Rule strips out the timestamp and points the link back to the original file.
The introduction of a local store was a more extensive change. In the production environment, a serverless AWS Aurora MySQLRelational database used to hold website content and search data. database was used in the hopes of reducing cost; which in all fairness it can. It saves money by going dormant when no requests are received in a set timeframe. This, however, can lead to slow response times on the first visit to the website after the database has gone dormant. If health checks are implemented against the web server it forces the database to remain awake and that startup lag is eliminated, however, the cost increases dramatically. So in order to make cost and performance more predictable, the Model classes were redesigned to optionally to use files stored on the web server to supply the data needed to populate the web pages. This behavior can be toggled off and on using an environmental variable.
The Javascript project folder was also removed from the PHPServer-side scripting language for web development. environment. Originally I thought it would be useful to have it under the document root for a file explorer project I had in mind but now I think keeping them separate would make them easier to manage. Additionally, the Content EditorDevelopment of the code to support the editing of the site's content via an Editor page. was updated to remove carriage returns and line feeds before saving to the database. These characters did not appear in my development environment but were displayed on the web pages as "\r\n" in production.