Upcoming Improvements To My Jekyll Site & Blog

Let's take a look at where the data for this website comes from. I'll also share current plans on how will change based on the work I'm doing on related projects. This is the first post in a series tagged "meta" where I'll write about issues I work through while building my personal site.

When this website was first published circa 2012, it was an aggregation of my social feeds and a directory of my personal side projects. My intention was to have a space online where I could share personal projects using my own custom design and UX.

Since then, this website has remained a digital sandbox where I explore and test new tools, technology, and designs. I moved the repository from my personal GitHub account and into its own account in February 2018 with the long-term plan of making it easy for others to bootstrap their own blogs using this code. It's possible to do that now, but I won't be prioritizing customization controls until I reach v1, and so anyone who uses this site will need to maintain their own fork and–or deal with my sporadic changes.

In April 2018 I moved the front end framework from Zurb Foundation 5 to Bootstrap 4 in order to update to jQuery 3 I have more recently been experimenting with migrating the current components and blog engine away from Jekyll over to a headless CMS and a React front end. For now, this blog is using a homegrown JavaScript framework that applies strictly to this website.

Below is a diagram showing where this site currently gets its data. As you can see, it's a mess! That is because this Frankenstein project is made up of many smaller projects that I have yet to tie together, and were built without that in mind. For v1, that will change as I establish a convention for adding new features to the blog.

Data diagram,

All of the components and services that go into this are open source projects available on GitHub.

ComponentSource Code
Blog Enginepersonal-site/blog
Personal APIpersonal-api/core
Instagram Feedpersonal-api/plugin-instagram
Recently Readchrisvogt/recently-read
Stats Pagechrisvogt/stats

Where this project is going

This project will continue to serve as my personal website and will evolve into a hub of personal information. I haven't done well with proactively blogging on a schedule, and so I'm leaning towards moving towards a wiki instead of a blog. I'm curious about what that might look like: to maintain a knowledgebase of living documents that I refine as I grow and my opinions change. Would the amount of content maintenance grow to be overwhelming? Should that supplement a blog? These are the questions on my mind lately around blogging.

My plan for the data flow is to clean up the flow and have all clients using my Personal API to access my data.

Proposed changes to

The separate stats page will go away and the report currently on it will move to my website's home page. The current stats code was an old PHP experiment that has been running for half a decade with nearly no major or breaking maintenance ever needed. It's old, and it isn't useful to me anymore in its current state.

Based on some experiments I am doing right now, the Personal API will either remain its own self-hosted repository, or will migrate to a serverless solution like Firebase and Firebase Cloud Functions. Already now much of the data for my site passes through Firebase databases, but I'm using a Node.js and Express server to call out to the Firebase APIs and other microservices. Ultimately, I want one, central project for all of this. Firebase also has scheduled jobs, which I'm already using now to sync my personal data every day.

In addition to reading data from a database, my Personal API and its job scheduler will be able to add events into a queue to kickoff actions that fetch and store updates to my data. My goal is that anyone can come to my website and get a brief visual representation of what I have been working on, and if they want, drill down into the individual projects and actions that fed into that visualization or report. There is a lot of data that will need to be synced on a daily basis to make that happen.

The items I plan on addressing soon are:

  • Reducing the number of network calls made by the client to render the site. The current website makes 7 client-side calls to render the home page. Once all data is available through the Personal API I will expose a route that returns all data needed to render the page in one call.
  • Reducing requests to external providers and gaining more control over my data by making scheduled jobs to fetch and store data.
  • Improving code convention and consistency by creating an abstraction layer for interacting with data through entities, which will be like Models in MVC architecture.

As progress moves forward it can be tracked on the @personal-site/blog GitHub Issues page and the @personal-api/core GitHub Issues page.

Updated 9/26/2019 with more details about my personal setup and future plans.

© 2020 Chris Vogt