~$ Building DO's website in 6 days!
I wanted in this post to go more in detail on how I got the website of Digital Overdose off the ground and fully functional... in 6 days.
Summary
The ideation phase
When we came up with the idea of Digital Overdose Con, we had a few obvious things to set up. Part of it was our social media presence, the other part had to be the platform where people can find us at.
This platform would need to be a platform for the community, but also a platform for the community.
The idea was that visitors to the platform could have easy access to our various social media and event calendar. By looking a bit further they would have access to information about the conference, and about the community's team.
Choosing the underlying technology
One of the aspects I was striving for was familiarity, and cost-effectiveness. To that end, I chose to develop the application using the Angular framework, which I'd previously dealt with in a number of projects.
However, since hosting costs a lot of money, I thought I could potentially leverage GitHub Pages, a framework that helps serve static pages for free directly from a GitHub repository (a shared folder for code, if you would).
There came my first problem, as GitHub Pages serves static pages only (ie. pages that already have their content within them), and Angular produces a dynamic webpage.
In came the Angular Universal project, one aspect of which is something called Server-Side Rendering (or SSR for short). SSR basically generates the code server-side and sends it ready for the user to browse.
Now this is static, but only on the users' end, and in essentia still requires a server to run. However, one can leverage SSR to simulate serving a website locally, and taking snapshots of all the pages. Then one would only need to distribute the snapshot. This is called prerendering, and is what we used to make a dynamic site available statically.
There are a few drawbacks, sure, like for example needing to know all of the potential paths for content, so that the prerendering engine can take a snapshot of the pages, but that is quite manageable in the end.
Sources of inspiration
A website doesn't only require some technical know-how, but also some User Interfaces and Experience (UI/UX) knowledge, which I've had the opportunity to acquire in several classes, specifically a person-machine interfaces class.
Another major source of major inspiration was my own personal website, which may look radically different, but runs the same engine -- pardon the pun. That made development easier, but also made me have to fix some issues on both platforms at the same time (it's not a bug, it's a feature).
Domains and Cloudflares
Once the site started to look pretty, we got around to purchasing a domain name, and linking it to GitHub Pages, which is a pretty straightforward process.
But for various reasons, be it security or observatory analytics (among others) I suggested using CloudFlare as a passthrough service.
The setup for CloudFlare was easy, and I'd already spent enough time doing so for my own site that I knew which options to click -- or so I thought.
It turns out, that if you enforce TLS 1.3 on CloudFlare, many metadata scrapers (which help in search-engine optimization) start to fail. That took me longer than I'll admit to debugging, but in the end we have a beautiful site.