GitHub provides a very powerful platform for developing applications. When you use the base GitHub functionality in conjunction with Github Pages and the Github API, some pretty interesting approaches to application deployment emerge.
I learned this approach from Development Seed while working with the White House to open up data across federal government agencies, but it's an approach I have evolved and improved upon while developing what I am going to call GitHub micro tools.
My GitHub micro tools run 100% on GitHub, using GitHub Pages as the front-end, the GitHub repo as a backend, and the GitHub API as the communication between—with GitHub OAuth as the security broker of who can put the application to work.
I needed to use this approach across several different micro tools, so I thought I'd create a base template that I can use as forkable base for these tools I'm building while also sharing the approach with others.
Apps Running 100% on GitHub
I like my apps like my APIs: small and reusable. Building applications that run entirely on GitHub makes sense to me because it is focused on developing apps that anyone can fork and put to use under their own account, relying on GitHub to do all the heavy lifting and cutting out the middleman (me). Each micro tool runs as a GitHub repository, which comes with all the benefits of GitHub like versioning, social coding, issue management, and much more. You can fork my project on GitHub and begin using it in your Github user account or organization.
GitHub Pages as Application Front-End
One of the interesting features that GitHub provides with each repository is the ability to launch a simple static site using GitHub Pages. I use these static project sites to run all my API projects and it's something I have been evolving it to be a front-end for this approach to providing micro tools. GitHub pages provide a simple place to put all my applications where I can store and manage in a very static, secure, and stable way (well, the security and stability are offloaded to Github).
Static Jekyll Application Front-End
Github API as an App Connector
With the base of an application, I am using the GitHub API as the connector for reading and writing data and content to the base GitHub repository for this application, in addition to relying on the native features available in Jekyll and Liquid. The API allows any application to access its underlying data store when a user is properly authenticated using a GitHub personal OAuth token.
Github OAuth for Authentication
To allow this application interaction to securely occur, I am relying on GitHub OAuth as the gatekeeper. For this example, I am using GitHub personal tokens retrieved from within any GitHub account instead of using a proxy or service like OAuth.io because I want this solution to be forkable and self-contained. Your tokens will not give you access to this application when it exists under my GitHub account, but if you fork it, your tokens will give you access to only your forked version. All you do is pass a token into this page using ?token=[your token here], and the API will allow for writing to the underlying repository.
Cookie.js to Store the OAuth Token
Github.js to Communicate With API
Forkable Base for Apps That Run 100% On GitHub
I hope this provides a base project that demonstrates what is possible when you build applications on top of GitHub. I am going to fork it and build another prototype that reads and writes to a YAML file in the _data folder for the underlying repo, exploring what is possible when it comes to using GitHub as a data-driven micro tool platform.
The code that makes this happen is pretty simple and the GitHub repository is meant to be pretty self-contained. Here's a list of technologies at play here:
You can find the front for this app here, and the repo behind this project over at my Github account. Have fun, and feel free to submit any issues if you have any questions or comments.