Designing a static / dynamic website builder hybrid

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.

Processing the templates and serving the website

The templates are a mixture of HAML and Handlebars. They support partials and flow control as you would expect. They get parsed through our go template builder which navigates through the partials, combines everything together and generates the resulting HTML.

The resulting website is served by Caddy, which gives us great support for handing SSL automatically through ZeroSSL, and also integrates nicely into our build process.

Caddy also proxies some requests through to the underlying Rails API to handle the dynamic requests.

For our standard website configuration of  5 main pages, it takes 0.3 seconds to generate the website from parsing the template and building.

We track page views and other metrics automatically by recording them with an extension to Caddy.

Want to know more?

Barkeeper is currently in closed beta. If you are interested in joining the testing group, please send an email to [email protected] to get more details.