Static Site Generation
I can still recall the article back in 2012 that convinced me to ditch any compromise with the CMS frameworks had long been pushed as the default for public content-heavy site deployments, and to move fully into static sites (with dynamic content on the front-end powered by lean services / APIs). The article is perfectly commonsense and unobjectionable today—but at that time, the concept of static sites being a realistic path for even large & sophisticated public-content sites was far from conventional wisdom. I became an advocate on campus since that time, attempting informally or in professional presentations to convince other units to drop the CMS and then watch their deployment, availability, security, and limiting development headaches nearly disappear, with the chance to host on a CDN with near-perfect speed and availability if desired.
The first static site frameworks with which I worked were ruby-based, and my usage is detailed here. In more recent years, it is gatsby
that I primarily use, and I am also an occasional contributor to its codebase. Beyond the smooth integration with React (transparently rehydrating server-rendered pages so that they spring to life), it is the data-layer capabilities that I find compelling, and the choice of GraphQL as the primary tool for querying all assets and attached data sources. My code contributions were in this area of building out its GraphQL capabilities so that external schemas or sources can be integrated.