Github has been playing a central role in my existence as the API Evangelist for a number of years now. I began migrating all my side project to use Github Pages back in January of 2013, something I continued to evolve throughout the year, resulting in an approach to running applications entirely on Github Pages and uses the Github master repo as the backend.
This approach to building using Github repos, Github Pages is not a design approach you want to use in all use cases, but I'm enjoying using it for some very simple, yet forkable applications:
- CSV Converter - A CSV to JSON, and back again converter, with ability to store converted data in the master repo via the Github API.
- RSS Aggregator - A multi-RSS feed aggregator, which pulls RSS feeds of URLs in a central JSON file, then writes the aggregate posts to another JSON file -- with RSS feed of aggregate.
These are just two examples of simple client-side solutions I'm developing. I'm further solidifying my approach to what I was going to just label simply as Single Page Apps (SPA), but really they are more of a Single Repo App (SRA) -- because we need another fucking acronym. Seriously though, I'm going to dial this in, and use to develop an army of apps, that do one thing and does it well.
I like this approach because it allows me to keep the apps I develop small, and easy to design, develop, operate, and then also easily thrown away and /or replaced. Or not throw away, and just let them live on, with minimal maintenance. Part of what makes this possible is that these apps run 100% on Github, with the following architecture:
- Github Master Branch - This acts as the starting point for every app, using Github as its OS, but also the master branch as its central public or private data store.
- Github Pages Branch - This acts as the UI for each application, providing a public, SSL enabled URL for engaging with each application that is made available.
- Jekyll - This provides content and data management system for the application, allowing for the app to be published, using Markdown, Markup, with a central YAML data store.
- YAML / JSON / CSV Data Store - By using Jekyll, you immediately get an _data folder which turns any YAML, CSV, and JSON file into a data store for each application.
- Liquid - Jekyll employs Liquid for rendering data and content to each site page, allowing for the publishing of any data you have available in the _data folder.
- Github API - The Github API provides access to all the moving parts of each app that is developed in this way, allowing for programmable control over all architecture.
- Github.js - A Github API JavaScript client which allows you to enage with the Githbu API within any application using Github Oauth and personal tokens.
- Github Oauth - Each app leverages the existing Github authentication infrastructure for managing user profiles, as well as authentication needed to use API for reading and writing of content or data.
- Github Issues - Each app uses the Github issue management as its central support and communication channel, allowing for engagement with key stakeholders, as well as end-users.
Each application runs 100% on Github, and works to minimize its dependencies on external resources. If it does work with outside elements, it uses RSS, an API, or other open approach to operate. I'm seeing more API providers also leverage Github authentication, when they have API management providers like 3Scale, making authenticated API access a reality, as well as using resources from publicly available APIs.
What I like most about this approach to developing apps, is that they can be forked and run by anyone who uses Github. I watched my GF Audrey Watters fork the RSS Aggregator in about 5 minutes with just a couple of hiccups, which I will smooth out. The goal is to make them easily forkable, minimizing its dependencies, and empowering any users to put to work to solve a single problem they have. (aka convert CSV to JSON, aggregate RSS feeds).
Anytime data or content needs to be written to the underlying data store, you just have to have an OAuth token or personal token issued from a Github account who has permission to the Github repo in which an app operates in. Github makes it easy to generate and manage these within your Github account, but I also use OAuth.io to help streamline this when needed. Ultimately, I try to minimize the dependencies when I can. I want to get better at minimizing all external dependencies, and being more clear about which ones end up needing built in.
I have a whole list of Single Repo Apps I'd like to see become a reality. Now that I'm seeing some agility in my infrastructure after going API first for all my Kin Lane and API Evangelist operations, I'm able to focus more energy on extending this way of life to how I build out tools and apps. This is why I'm formalizing my approach, drawing a line in the sand, and making sure every new UI, tool, or app I build from here forward, is developed in this way. Eventually I'd like every aspect of my UI to operate as Single Repo App, providing me (and anyone else) with a lego box of UI goodness.
