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 interest 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 is 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.
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 within your Github user account or orgnization.
One of the interesting features 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 project and is 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 al my applications, where I can store and manage in a very static, secure, and stable way (well the security and stability is offloaded to Github).
Jekyll provides a simple, static way to help tame the front-end of the applications I am building. The static content management system provides tools for managing the look and feel of each application, the pages within, and allow me to have a blog if I want. Additionally, Jekyll provides a YAML and JSON core, which when combined with Liquid and JavaScript, opens up to some pretty interesting opportunities for building applications.
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.
To allow this application interaction to securely occur I am relying on Github OAuth as the gatekeeper. For this example, I am using a 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.
Once the OAuth token is passed into the URL I use cookies.js to store the token for use across all potential pages of a micro tool. This approach helps prevent it being included in any links and passed between pages. Once each cookie expires, the user is required to pass another valid token in through the URL to set the cookie again, opening up API access to the applications backend. This project is meant to be interactive, and you can validate there is a token here:
With a valid OAuth token, I use Github.js as the client side JavaScript client for interacting with the Github API. While Github.js allows for using almost all available API endpoints, most application functionality will be just about reading and writing YAML and JSON files using repository paths. For most of the application functionality, I will rely on Liquid for reading YAML and JSON data, and Github.js for writing of data to the underlying repo using the Github API. If you have a valid Github OAuth token passed in and have access to the Github repository for this application, you can click below to see if it will successfully write:
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, and here are list of technologies at play here:
You can find the front for this app at github-micro-tool.apievangelist.com, 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.
