Where this all started

During college, I volunteered to maintain my fraternity's "family tree": a hierarchy showing the pairings of little bros & big bros. Everybody has one big bro; a big bro may have zero, one, or multiple little bros. We also gave names to our families, originally dividing into two main groups named the Saints and the Regulators. Over time this grew to a total of five different families, with some guys deciding to spin off to call their lineage a new family name.

I originally maintained the family tree using flowchart software (Microsoft Office Visio). This worked in the beginning, but as the families grew in size it was no longer manageable to fit everyone on one page. After graduation, I decided to build a website for the family tree and automate the work of arranging everybody. Thus, the Framily Tree website was born!

Computer Science background

In computer science terminology, we call this a Tree data structure. This data structure is defined by nodes which will each have zero or more child nodes. This concept maps nicely to what we're trying to track: each fraternity member is represented by a node, and their little bros (if they have any) are represented by child nodes. Each of the different families (ex. Saints, Regulators, etc.) are represented as their own tree graph.

Design

The main design parameters for this project were:

1. Easy to maintain/update
2. Easy to share
3. Interactive
4. Free to host the family tree website

This led to a few key pieces of technology:

1. Google Sheets to keep track of the big bro/little bro data
2. Needs to be a website for easiest shareability
3. Use Vis JS for an interactive graph
4. Use GitHub Pages for free hosting, and GitHub actions to pull data from the spreadsheet to the GitHub repo

Design consequences and trade-offs

Although GitHub Pages is free for hosting, this only hosts the "frontend" of the site. To keep this totally free, the Framily Tree project has to work without a need for the backend. Normally a backend would be used to facilitate communication between the frontend (the web page) and the data storage (our Google Spreadsheet).

Since we don't have a backend, instead this project uses a workflow to propagate spreadsheet changes into the GitHub repo. This relies on a Google Apps script (in the spreadsheet) which provides a menu on the Google Sheet to call the GitHub API, which then triggers an GitHub Action Workflow to pull the spreadsheet, commit the changes, and merge to main branch. See pr #63 for details.

Prior to using the automated GitHub Actions workflow, I previously used an npm script to run the steps from the commandline. These steps still work, although they're obsolete assuming the spreadsheet automation is working correctly. This involved pulling the data with npm run getData, creating a git commit, and then pushing the changes to the main and then to the gh-pages branches on GitHub.