The client-server model has been in use for around 60 years, but over the past two decades, the idea of serverless computing has become feasible and popular. In case you aren't familiar with serverless computing, allow the collective consciousness of StackExchange (ChatGPT) to explain: "Serverless computing? More like 'server-less headaches.' It's not truly 'serverless' because, surprise, servers still exist! You're just off the hook for babysitting them. Think of it more as 'servers on demand' with a fancy billing twist." While not babysitting servers sounds great, most people would prefer not getting billed for the pleasure. In this paper, we will investigate "free serverless", also known as serverless at home.
For hosting, we use Github Pages. It’s a free, powerful solution for your frontend AND backend needs! You can create your stunning frontend with HTML/CSS/Javascript and power it with Github Actions to produce a functional and modern website!
Perhaps a more intuitive definition of serverless would be one where there simply is no server (outside of the server hosting the html files). At first, this definition may sound too restrictive to have interesting websites, but by using web assembly (WASM) and javascript we can make the client run all the code to make our site interesting. We've shown this functionality with our previous SIGBOVIK entry: Ringfuck. While WASM makes creating interesting websites pretty easy, javascript psychopaths have been doing the same thing for years without it.
If we want true serverless at home, we need to be able to replicate the functionality of database-driven websites for free. To do this, we take inspiration from others who have sought to innovate by taking other people’s backend and making it their own (see https://www.youtube.com/watch?v=c_arQ-6ElYI). For our backend we leverage Github and its most recent feature (besides stealing everyone's code to train a Kamikaze CoPilot) CI/CD, or Github Actions as they call it. Github's CI/CD allows you to write a custom bash script to be run in a Docker container. This allows us to edit our html with simple CLI tools like cat, echo, sed, and awk and then commit those changes back to the repo. The final step is to simply trigger the CI/CD to run when a user performs an action requiring a server operation. To perform this, we use some simple javascript along with a Github auth token to trigger the action, then query the Github API to determine when the change has finished so that we can automatically refresh the page.
Something to consider is that our choice to stick to CLI tools is only because we wanted to stay simple and fast. If those are not concerns for your website, you can easily set up a CI/CD pipeline that includes advanced tools like Python for machine learning, SQLite for relational databases, or Elasticsearch for search engine capabilities! The possibilities are truly endless, as long as Github doesn’t notice your compute time and start charging you money.
While there are security concerns with this serverless at home methodology, a lot of potential security issues are shared with other applications that accept user input, so we will not be discussing these. A unique issue with our CI/CD approach is the need for a publicly accessible Github auth token. To mitigate this risk, it is recommended to use a fine-grained access token for the specific repository. The major downside to this is that the token must have an expiration date, thus creating some maintenance. To avoid maintenance, you could create a dummy account with a classic access token, but this would allow anyone to attempt changes on public repos with your dummy account.
On the privacy front, there are a couple of unique issues with serverless at home. First is the classic git problem of it being very difficult to permanently delete content that was committed. Thus, any sensitive data in a comment will remain visible to everyone until an administrator removes it, which may never happen since owners of github repos are notoriously picky about other people changing their precious code. The next concern regards user sessions. While it is possible to have the CI/CD system create user sessions by creating subdirectories and deleting them later, these sessions would be viewable by anyone interested enough to pull up the source code. Since this is not easily mitigatable, our recommendation is to simply inform the users of your site that they have no privacy. So if you've read this far, congratulations you've been informed.
Traditional hosting and serverless are a pretty polished experience for devs and users, especially compared to serverless at home. So why would you ever use serverless at home? One selling point is the fact that it is totally free, as long as you don't have a bunch of users, which shouldn't be a big concern for most readers. Another benefit of serverless at home is the nostalgia for dial-up internet. Some people would argue there are better free alternatives, like Wordpress. Which brings us to our next selling point: freedom. Services like Wordpress might be free, but they restrict what you can do with your site to try to get you to pay for more freedom. But with serverless at home, as long as you can code it to run when the Github Action triggers, you're free to do it. Finally, the biggest reason to use serverless at home is so that you can deliver an awful user experience to your "friend" when they ask you to make a "simple" website for them.
Is serverless at home revolutionary? Let us know in the comments! 👇
Comments