Dynamic Web Apps on GitHub Pages FOR FREE
GitHub Pages is awesome. It’s convenient, it’s easy, and best of all — free. When it came to hosting, we at Pan Labs were at a small impasse. Hosting is important, you want scalability for whatever the future might hold but you don’t want to sacrifice your hard fought funds when you know that being scrappy can mean the difference between success or eating Taco Bell for the third week in a row.
Here’s the thing, GitHub pages allows you to host STATIC websites — we’re talking html, css, images and javascript. There’s no server-side anything so people who depend on php-based platforms and similar frameworks (see: WordPress) find little to be useful here. But we’re not WordPress or Squarespace artists over here at Pan Labs, we’re engineers and designers — this is a solvable problem.
The secret in the sauce comes from the ingredients: GitHub Pages, Firebase, and maybe even some Heroku depending on how fancy you want to get.
Create your GitHub Pages repo.
WARNING: Your repo should be named yourusername.github.io NOT somethingelse.github.io like I have pictured below (so ours looks like panlabs.github.io). If you know what you’re doing, the docs give you a few options.
Add your static files as needed. This is a GitHub repo so you can update your site using Git like a sane person, or if you enjoy the torture you can update the repo directly in GitHub. I’m just going to add a simple index.html file (and some css/Bootstrap cuz i’m not an animal).
In your repo, click Settings, navigate down to the Pages section.
After choosing a branch you want the site to be hosted from, click Save. You’ll see this in the Pages section now:
Your site is ready to be published at http://yourusername.github.io/Awesome, so now we’ve got a site! The url isn’t too pretty but, hey, it’s free (you can add custom urls).
Our site is pretty simple (and sick), or so it seems at first. I just want to add people to a mailing list, but right now we’re stuck with a static site that isn’t built to handle any meaningful user interaction. The first solution that comes to mind is to use jQuery to handle the REST call to an api server you already have that is built just for this sorta thing. If you were gonna do that you wouldn’t be reading this article. Our second option is to spin up a free-tier server on Heroku that could accept a REST call… this is an enticing solution but you’ll run into CORS issues and honestly not a lot of people feel comfortable with command line enough to spin up a dyno on Heroku and push out a simple node server (we will have a future blog post on doing this though!)
So what do we do? Curse the internet gods, give up, and head to Taco Bell? No way. Firebase to the rescue! Firebase has an insanely lucrative free-tier that is almost too good to be true. It’s so good that if we find ourselves in a position where the free-tier just isn't good enough anymore, we have the best kind of problems — too much business kind of problems.
Log into firebase, create an application.
After clicking Create Project, you’ll be taken to your projects dashboard, where you’ll see a menu that suggests you add your project to web app. Perfect.
Clicking this will bring up a window with some code you’ll need to copy. Now, with this code we can add it to our GitHub Pages project. My project is simple so I’m going to paste it at the bottom of the body of my index.html file.
Before your web app can begin communicating with Firebase, you’re going to need to write the appropriate security permissions to allow your app to write to the Firebase Realtime Database. To do this, navigate to your Firebase app’s console, choose “Database” from the left navigation and then click “Rules” from the Realtime Database top navigation. For now, we’ll just completely open up our database to allow all reads and writes (we’ll update this later).
Click Publish to save these changes.
From here, it’s just a matter of using the firebase api to send your data to firebase. So, back in your GitHub Project, you’ll eventually implement the ability to save your data to firebase:
Use the global firebase object to connect to your realtime database. We have a reference to a new child ‘subscription-entries’ (if the child doesn’t exist, firebase will make it on the fly). We use the push() method to create a new record in the ‘subscription-entries’ child — if we didn’t do this then we would be overwriting the same record over and over again, push() creates a new child as a unique id, and then we are setting our emailObject as the data to fill that record. Here’s an example of how this looks in the Firebase Realtime Database:
We see our top level child, ‘subscription-entries’, and then we see its children — each is a unique id created by push() and then we store our data as the child of the unique id. Thats it! Now your data is safely stored!
…sort of. We should probably protect your data so just anyone can’t come along and read all the email addresses you’ve collected for your sick marketing site!
Head back to Rules, and change the read permission to false. Boom.
Awesome. Locked down tight. Queue the next question “Well, how am I supposed to work with data even I can’t read back out of Firebase!?” Great question! The answer is custom auth tokens! And thats outside the scope of this article but I will show you how it’s used in a future post (How to Use Heroku + Firebase to Make a Free api Server)! Stay tuned!
In the (very near, like DAYS near) future I will be publishing articles on:
• How to Use Heroku + Firebase to Make a Free api Server
• How to move your entire technology stack to Firebase
