Designing a static / dynamic website builder hybrid
This is part of a series about the technology behind one of my projects, Barkeeper. In this post, I'll give a rough background about what Barkeeper is and how I approached its website build system.
The full version of this post is available on the Nekotachi Blog.
Barkeeper is a platform for bars and clubs to improve their online presence, without needing to know how to code or do anything more complicated than use a word processor.
Further posts will discuss its AI-based features, such as its sentiment analysis system, seo and event suggestions, and review  metascoring.
What we are going to discuss today is Barkeeper's website generator. It allows customers to build great website for their venue without having to worry about things like mobile friendliness, search engine optimization or any of those other headaches that make web development tricky for non-technically inclined people.
The technical stack
The website builder is made up of a handful of services which make up the overall stack:
- A Ruby on Rails API application to manage the content and interact with the customer facing application
- A couple of Golang applications to handle template parsing and the actual generation of the HTML
- A VueJS frontend for the customer to interact with when adding their content and updating details of events, etc
- A second Ruby on Rails API application that handles dynamic parts of the generated websites, such as time-sensitive events like calendars and booking space in events
Static / Dynamic Hybrid build system
I consider this solution a "hybrid", as the majority of the content served to end users is statically generated HTML and some Javascript and CSS to handle presentation and so on.
For some features, however, generating all the possible content permutations is prohibitive, like events on a calendar, or handling ticketing for entry to a venue. To achieve this, parts of the templates are "dynamic blocks" which will load some placeholder content to prevent page reflow, and will asynchronously populate themselves with the data in the background while the rest of the page is loading.
This allows for the benefits of having very fast websites from all the static content and efficient caching of assets, etc, without needing to sacrifice dynamic content altogether.
The concept itself is of course nothing new. This was basically how all "web 2.0" websites worked before modern frontend frameworks like VueJS / Angluar and ReactJS came along.
What's useful here is that we can also effectively and efficiently cache the responses to those asynchronous requests too. Modern backend frameworks like Rails make it possible to have flexible and fine-grained caching control, while also making invalidation reasonably straightforward.
Of course, as the websites are mostly static content, every time a full build is completed is effectively the same a purging the cache on a Wordpress site.
Want to know more?
The full version of this blog post is available on the Nekotachi Blog.