Static Petition CMS | Fight for the Future
This is really a project in two parts: a static site managed by Prose, GitHub Pages, and Travis, as well as an Express.js middleman (that’s middleman with a lower-case “m”) API server (hosted by Heroku) which obfuscates an API key, offers custom endpoints, and reduces client HTTP requests.
The site was converted into a Jekyll site hosted on GitHub pages. I wrote a shell script that enabled Travis CI to deploy the compiled site to the appropriate branch so we could still have access to more complicated build tools than a standard GitHub Pages site allows. I even wrote a short script to run the whole thing on Heroku so we could have review apps and a backup of production in case GitHub had a case of the angry unicorn.
Once that was set up, I began writing the configuration for Prose.io. This ended up being more complicated than it might sound, as I was building not only a CMS, but also a system for generating petitions with several fields and variables.
Once the config file had all the fields I needed, it was on to the API server. All our petition data was being sent off to Action Network behind the scenes, but since the GitHub Pages-based site didn’t have a back end, I was going to need a safe place to keep the API key. Conveniently, this server also gave me an opportunity to reduce client-side API requests. Occasionally the Action Network API would need a series of requests in order to get access to the data we needed, this server would obfuscate that. With a little bit of Express.js and a heavy-handed security audit, the server was deployed to Heroku and we were in business.
Ultimately, with a few
XMLHttpRequests and a traditional
<form> element that gracefully degrades, I was able to put together a low-cost, high-speed, and fully customized Petitions CMS for all the org’s campaigners.