Why I am writing a web interface for a static site generator
Let us talk about drunken pandas, sake and why I am trying to tie a static site generator to a SQL database and a Django process. There are actually two simple reasons: The first one is that I want more comfort while blogging without losing the advantages of drupan. The second one is that I hope to enable more people to use a static site generator and own their content without losing any comfort or having to put up with managing a small, likely virtual, server.
While drupan hit 2.0 some weeks ago and is doing pretty well I decided to take on a project I already talked about. Making it easier to create content, bringing features of full blown content management systems to the world of static site generators and still keeping the whole thing simple enough that lots of people will be able to set it up and use it. As I already mentioned one of the reasons is that I want more comfort, but let us focus on the other one for now.
There is certainly a trend to use a service that provides you a hosted blog, no matter if Blogger, Svbtle or Medium, according to rumors there is even one person left publishing stuff on LiveJournal. But in my opinion you give up too much just for the convenience of not having to take care of a bit software. It varies from service to service, sometimes you do not own your content, sometimes you have to live with the fact that it could be required at one point to publish things under your real name, no matter what the consequences would be, sometimes the service tries everything so the content you create is not associated with you but the service, sometimes the service is just a mess and the downtime is higher than the uptime. There are so many reasons why hosting your own content is a good idea. But why do more and more people favor hosted services?
One word: Convenience. You enter your email and a password and start typing. That is it. If it would be a bit more trivial someone would create and send you your credentials the moment you are born. A self hosted solution will never be able to provide this level of convenience. But there are certainly ways to get closer to it than what we have right now.
Uptime, performance and security
Those three points are likely the three biggest offenders when it comes to convenience. How many blogs did we see going down because there was an article making it to the front page of HackerNews or reddit? How often do you have to update your system and your blogging software to have a vague chance of keeping everything secure? How often do cheap, and sadly also sometimes expensive, VPS providers fail when it comes to reliability?
I can understand anyone who does not want to administrate yet another VPS. There are only two options to get around this: use a hosted blogging service or a managed server or platform. The first and most important goal for drupan and Sakebowl is to solve those three problems. Let us take a look at the idea.
Drupan deploys your site to AWS S3 + CloudFront. CloudFront and S3 are doing an awesome job keeping static files online. And I believe not many people are willing to try to achieve the same level of reliability than those services offer.
You can run Sakebowl wherever you want. On your laptop? No problem! One click deployment to Heroku using the Heroku button? Sure. On the server in your basement or a VPS? Despite trying to solve the problem of having to take care of a VPS it is certainly possible and painless. With Sakebowl you get an intuitive web interface, your data stored in a database and with one click you generate and deploy your site using drupan. Sakebowl does not have to be online or reachable by the whole world to do its job.
How far did I get and what will Sakebowl look like?
At least that is the idea. I started working on Sakebowl, making sure it can import existing drupan sites and generate and deploy them. It is hard to start with the minimal necessary functionality and keep a certain target audience in mind – websites and blogs – since drupan is designed to get out of our way no matter what you create with it. But it is currently focusing on exactly this, websites and blogs. Features like multiple users with roles are something I already thought about, but they will have to wait. I always appreciate feature requests, but anything beyond the basics would end in many blog posts and no results.
The primary focus for the beginning will be deployment and setup. The setup process should look like this
- click on Heroku button
- enter AWS credentials
- answer some simple questions (site name etc.)
- write your first blog post
The setup will be 100% automatic, you will not have to configure the whole AWS stack yourself. Sure, it involves a Heroku and AWS account. This is not targeting end users who have trouble singing up for both services. The target audience is the technical crowd who is fine with following an easy tutorial that involves ~ 20 steps to get their blog online, knowing that they do not have to put up with the usual problems that occur after the setup.
I want to use Sakebowl, so it will happen. Eventually it will also help other people to own their content without the usual troubles, at least I hope so. If you have any ideas how the process should look like, what features it will have to ship to be usable or if you want to discuss that I should stop wasting your time with blog posts about projects I am working on that sound like sales pitches – yeah, after reading it I am aware of that – just mail me, I’d love to hear your thoughts.