Using GitHub Issues as a Data Source

Octocat: Github mascotOn a recent MVP, we needed a way for a client to maintain some simple information about several sponsors, like a name, an image, and a url. The client didn’t want to commit to a backend server this early in the game, so we needed a cheap but effective solution to store this data.

The client was already using GitHub repositories for tracking their To Do lists in the Issues tracker, and were familiar with creating and editing issues there.

So, as a starting point, we created another repo for their sponsor data. It has a single Issue, entitled “sponsors”, in which they maintain the sponsor data as a JSON formatted array.

[
{"name": "University of Greatness",
"url": "universityofgreatness.edu",
"image": "f.cloud.github.com/assets/uog.png"
},
{ "name": "Cloud City Development",
"url": "cloudcity.io",
"image": "f.cloud.github.com/assets/cloud_city.png"
}
]

This has the benefit that our javascript can hit the GitHub API to retrieve the Issue text and then parse the results as a normal JSON response.

We access the endpoint from a javascript ajax call like this:

function loadFromGitHub(){
 $.ajax({
   url: "https://api.github.com/repos/<<account>>/<<repo>>OSM_Website_Data/issues",
   dataType: 'jsonp',
   success: function(json){
     console.log (json.data[0].title);     // "sponsors"
     console.log (json.data[0].body);   // the json array
     // do your parsing of the array here
   }
 });
}

The client is happy (and able) to maintain the data in the JSON format, and they don’t have an expense for building and maintaining a backend server and data store. When they progress to needing a backend server, the existing javascript code will work once pointed to the new endpoint.

While this is not going to be a viable long-term solution for most projects (security, rate-limits, et cetera), it worked well for us to get a client moving forward and may be a useful technique if you just need a JSON source for prototyping and proof-of-concept.

After we implemented this approach, a fellow Cloud Citizen was at the Distill conference and learned about an interesting project that uses Google spreadsheets as a data source and GitHub pages as the host. That project is at: http://jlord.us/fork-n-go/. So, is this a common solution to use existing community tools as inexpensive, quick-start ways to ramp up?

Please weigh in if you've used other simple approaches. We'd love to hear how others are being clever and productive.


Contact us for a complimentary 30 minute consultation.

get in touch