Oh My GHaaD: Git Hosting as a Database

Hey, everyone. My name is Chris Griffin, and today I'm going to be talking about a side project I made called Oh My God, which is Git Hosting as a Database. Now, you might not understand what that means yet, but by the end of this, it might make a little more sense. The goal of this is not to have you use my project. It's more to just get you thinking outside the box and think about some fun projects you could do that reimagine how you see what a backend might be and how applications can be built.

So first, a little bit about me. I've been a software dev for around ten years. I'm a developer advocate at GitKraken, and I'm a Twitch programming streamer. If you want to connect with me on social media, just scan this QR code. It's prerecorded, so you can just rewind this when it's published finally. But, yeah, connect with me and let's chat. But let's get to it. I don't have much time.

First off, what is a backend? It's going to be important to recognize what makes a backend to our applications function, because then we can start reimagining where that backend can live. Your backend is just data, authentication, and authorization. Data can be your MySQL database or a Postgres database. It could even be in Mongo or CouchDB or DynamoDB or all sorts of places in NoSQL. But increasingly these days, we see that data can be file-based. You can just have files living on S3 and query them with Athena. You can also query files with Presto or Hive. There are even ways to query parquet files with, I think, Snowflake or things like that. The idea of just querying files that live somewhere instead of querying this live connection database that you can write to and do all sorts of stuff, yeah, file-based databases are actually increasingly more common, and that was my inspiration for building Oh My God.

There are even ways to query parket files with, I think, Snowflake or things like that. I'm not too versed in that stuff. But the idea of just querying files that live somewhere instead of querying this live connection database that you can write to and do all sorts of stuff, yeah, file-based databases are actually increasingly more common, and that was my inspiration for building Oh My God.

Authentication is basically telling the server who you are, right? It could be in a cookie or a token, but it's just a way of authenticating with the server and it constantly knowing who is making this request to it so it knows what to do and all that. So really, pretty simple. And then authorization is what you can do with that cookie or token. So that might be your read permissions, your write permissions, your ability to do admin things. All of this stuff is just kind of separate from the authentication part, but they go hand-in-hand. When you combine all those things together, right, if you squint your eyes and blur your vision just a bit, you might see through this magic eye, and with a little bit of help, because I was always bad at these, with a little bit of help, you might start to see something like GitHub.

I used Oh My God as a framework. I built an application with this similar architecture before, but I decided I wanted to build something that was a framework that I could use to build other smaller applications in the future, and it was just kind of a fun. Let's think about GitHub, GitLab, and Bitbucket. How could they be a back end? Well, data can just be JSON in a repo. Authentication can just be OAuth, right? It's just, you know, login with GitHub and you are OAuthed, and then you have access to all of your repos, even private repos, etc. from your organization. And then finally, authorization, well, yeah, we all have ways of inviting collaborators and giving them specific permissions of read-only or write-only or even admin-level access. But yeah, combined together, GitHub, GitLab, Bitbucket, etc. can be a back end to your application.

And let's look a little bit about how I've put this together and how it's architected, because I thought it was kind of fun. So before we get to that part, let's think about some of the interesting features of putting your back end in a Git repo. Well, number one, backups are easy. It's just a Git clone. We're copying the files around. It's serverless. And I don't mean that there isn't a server, right? GitHub runs on servers. But we don't care where the servers are, and that's really what serverless is meant to mean.

Serverless is just an idea of I don't care where this stuff is hosted, and I'm not worrying about the scalability of it, that's someone else's problem. Someone else's problem is one of the best camouflages in the world. And one thing I do want to have to clarify is with GitHub, it's not fully serverless. You do need a back end endpoint to do the token exchange because of the implementation of OAuth that they use. In GitLab, you can totally do a fully client-side application and just get the token directly from them.

And then finally, yes, public and private repos. You don't have to expose your data in a repo out to the world with GitHub, GitLab, Bitbucket. You can do a private repo that's just available to you and your organization or the team that you work with, which is pretty powerful. So let's dig into some of the core concepts that make up this application framework, or whatever you want to call it. We have collections, we have adapters, we have engine, and integrations. And the engine is the main thing, but we'll go through the process a little bit, but I do have to be wary of time.

A collection is just the model of your application. So in the app that I'm going to show you here as a quick demo of my framework in action, we have conferences. So I'm using an app to track the conferences that I have applied to. And I can track the talks that I've given for them, whether they've been accepted or not. And it's something that I can just use to make sure I track this. There are apps like Sessionize and some others that track these things, but not all conferences go through Sessionize. So yeah, let's take a look at it. We have the conference schema so that we can validate these things because forms are important, right? We have this conference collection that has the ID of the collection. We have the ID function that we pass to it so that we can create new conferences that have unique IDs of their own. And then we have the names that we can reference these within our application. And then finally, we attach the validator so that we can wire up things like React hook form.

The adapter is one of the most important parts because that's what makes this actually adaptable to the different providers, right? So GitHub and GitLab are adapters I've already made. But if someone wanted to make a Bitbucket adapter, all they'd have to do is follow this interface on the right. They'd have to implement the fetch repositories method, fetch file, fetch file history, create commit, create file, update file, and delete file. Just basic crud. Now, the reason that we needed this adapter is that not all of these APIs function the exact same way, and we'll dig into a way that they are slightly different in just a sec. Here, we see the GitHub adapter. In the GitHub API, they just have a single endpoint called put, and this is going to put the contents of the path in your repo. And then we use that put method inside of our create file and update file, because those are the two top-level methods that are actually used by the engine to do things. But then when we look at GitLab, we actually do something slightly different. GitLab doesn't have putting the contents of a file. They have creating a commit because, again, it's Git-based. But when they create the commit, it's either creating a file, right, with the action that we see in the middle there, or it's updating a file with a slightly different action. Those have to be in the two separate methods that we have, create file and update file, but we're going to see eventually if we were to look at Bitbucket and other platforms, that maybe they differ in some very minute way. But just wanted to show that the adapters are there to smooth over the differences between REST APIs.

Finally, there's the engine, and this does most of the actual work. This is actually calling out to the adapter for a lot of things. It's setting a lot of the state, and when you're building an application using this framework, you're probably going to be interacting with the engine most. Last but not least, we have the idea of integrations, and integrations are just what rig up to our frontend framework. So in React here, we have to create a custom hook, and this custom hook just has a use state and a use effect, and as the engine decides to notify its subscribers, it triggers the use effect, it updates the state, which then allows our components or our routes to re-trigger a render.

So just you could have an integration for any other framework, but this is a React conference, so we're not going to dig into how we might do that with Vue or Svelte or whatever. So what can you build with it? So real quick, I'm going to gloss over it as fast as I can. I built a CFP tracker for conferences, and we can see that I'm connected up to getcrackin slash CFPs. This is for work, and we can see all the conferences that I applied to specifically for work stuff. I've got here my conferences, the talks that were proposed, whether I was accepted or not. I have the talks that I can then associate with those conferences. It's actually pretty cool, but for the sake of time, I have to gloss over this, and let's get back into things. And just think about what you could build that's a nice small application that you could use with this framework. And this is what one of the repos, maybe not that exact one, looks like. It's just JSON files in a repo.

Warning, though, there are some copyouts. Number one, you're going to hit rate limiting on various platforms. GitHub, GitLab, Bitbucket all have various amounts of rate limiting, and I'm unsure if it's specifically to your token or if it's to the application that you've had to wire up through their back end. But you will hit rate limits, so you don't want to build something majorly scalable. You're not going to release the next Facebook using Oh My Gut. But it's still kind of a cool idea for micro-apps. Permissions. Yes, you have to invite collaborators. It's not automatic. Managing that can be a little annoying. You have to go into the provider and set this stuff up, because it's not something that we want to ask for permissions for from the framework level. And then org-level permissions, right? Well, maybe you could have everyone in your org get access, but who of us actually have the ability to do that, to modify that at an org level? And is it actually even a good idea? Are there other caveats? Probably. But I haven't used this enough to really know. It was just a fun thought experiment.

So what are the key takeaways that I want you to have from this? Well, number one, should you use Oh My Gut for everything? Probably not. But hopefully this was some good inspiration for you to think outside of what makes an application work and how it can work. Because I don't have any backend. I'm letting GitHub be the backend. I'm letting GitLab be the backend. All I'm doing is building a client-side application that I can host basically anywhere, which is pretty powerful. So I know I'm slightly over time by about a minute. I just want to thank you for giving me an opportunity to talk about this and to just kind of talk about a fun side project that I worked on, because I just like building stuff on my Twitch stream. And like I said, if you want to connect with me on socials, here is my QR code and I would love to chat more. And yeah, let's hang out. Cheers.