How we host our sites

There are so many available solutions to website or blog hosting that it almost seems like a non-problem. One does not even need any technical skills to set some of them up. The question remains, how do you decide what to use?

As with any technology, when choosing your solution, you need to have an end goal in mind. Do you know what you need and what problems will you be facing? How will you be using your available tools on a day to day basis? Will they be enough in a year? As with everything else we do at Ellarion Cybernetics, our approach is to find the easiest and lightest solution to provide the desired outcomes. And this is precisely what we have done in this case.

TL;DR

We host multiple sites (ellarion.com, biokeanos.com and arachne.ai), from the same python Flask template. It allows us to deploy static sites with a simple command.

What is out there?

Website builders such as Wix or Webflow or even Mailchimp provide an all-encompassing solution from the concept, from registration, design to hosting. Glancing over dedicated publishing tools such as Ghost, we move slightly on the spectrum and arrive at writing platforms. The examples include [Medium] (https://medium.com) or Substack that provide recommendations and create communities around subjects, facilitating the discovery and spreading of the ideas. Similarly, Github Pages offers a handy, minimalistic approach of co-hosting a site with a code project and even allows for blogging. Further down, we see battle-tested, mother-and-bane-of-nearly-50%-of-all-Internet WordPress - with a variety of ways to host it and plenty of small companies that make a living from catering for the needs of businesses using it. Finally, we reach a realm of mini-frameworks and custom-made, tailored solutions. It's hazardous territory. A dedicated, sophisticated solution can bring additional functionality to light when such a need arises. Realistically, however, it very rarely does. More likely, it will serve as a distraction, especially for more technically-minded people. Instead of solving actual problems, you divert your resources - and most importantly, time - to an activity that may well be a vanity fling. So unless you have an excellent reason, please don't do it. You may have already guessed that we are writing this from experience because this is exactly what we have done.

Why would you overcomplicate this?

An excellent question indeed. And one we have kept asking several times already. Let's first try to enumerate our train of thought that led us to this state: - There are at least three websites that we knew we would need to build. - We're here for the long run - we want this to be stable and grow with us. - We have some really basic knowledge of Html / CSS / JS. Enough to manipulate an already existing template but not to create a consistent design from scratch. - We want to reduce costs. The highest price is not measured in the currency of your choice but in time. And this includes the time taken to talk to specialists who would do this beautifully for us. - Speaking of time, shouldn't we be doing something more valuable than writing this post? Perhaps. It is, however, essential to keep reminding ourselves of our values and good practice, starting with the very basics. At the same time, it occasionally is very tempting to go into a full-blown technical frenzy. - In the past, we have used several of the methods outlined in the first section. So we knew what to expect of each approach and how each will interfere with other work.

Go static

We subscribed to the paradigm of hosting static pages when possible. Static refers to the content that doesn't require the server to do any work other than sending files to render (HTML, style sheets, images, scripts). If this sounds like what you thought websites are all about - well, you're right, but perhaps a bit old-school. Most of the time, especially when an interaction is required, your single request ends up using a fair amount of computation, hitting databases, making API calls, dynamically rendering Html templates (although that's a bit old school nowadays as well). It is more challenging to organise static content. The tooling is available in the likes of Hugo, Jekyll or Gatsby - there's plenty more. They are, for a good reason, opinionated and have their particular quirks. This approach is also limiting - you restrict yourself to documents - and not interactive content. You can use third-party plugins for some additional functionality - like commenting (e.g. Disqus) or subscription (we use Mailchimp). Speaking of subscriptions, why not subscribe at the bottom of the page to get our newest writing on the intersection of technology, biomedical data and AI/ ML? What are the advantages? There are two that are real game-changers. - Speed - because the content is pre-rendered, it can be sent over the wire straight away once the user requests it. No long list of database calls, no chain of calls in the background. Also, such content can be distributed easier via Content Delivery Networks - so it's closer to the users requesting it. - And more importantly, at least for us - not having to maintain a live server - or care too much about one. Computers are fickle beasts. They need care, provisioning, updates, monitoring etc. - all measured in time. It is much easier to host the documents on a third-party service, in our case - Amazon Web Services S3. There are servers involved, but the redundancy and uptime AWS provides for this service are unparalleled. While this is a relatively modern approach, this is nothing too novel or surprising. Some companies provide such a system as an integrated solution - e.g. Jamstack. One aspect was missing for us - the tooling. As already mentioned, there are some static sites generators available. However, from our perspective - they are rather complicated, if still not fully mature and written in languages not too familiar to us to understand and perhaps adjust some of their functionality.

Overcoming the limits of the generators

We have our biases just like everyone. And our preference is firmly towards limiting our stack when sensible. There are great reasons to use multiple languages or frameworks in different parts of your work. However, it is much simpler and less time consuming (some may say lazy) to limit yourself to tools that do the job and minimise the strain. Since most of our work revolves around data - and more precisely, delivering data to analysts, data scientists and AI/ML researchers - it is only natural to use Python a lot. Flask is a common, minimal web framework that allows for a quick start and has plenty of plugins. The default debugger allows for rapid local iterations in a standard server mode. There is a slight twist here - Flask's inbuilt server is not sufficient for production deployment - so we swap it for cheroot. Our in-house knowledge is minimal, so we stick to tried and tested Bootstrap. Some sites, e.g. BiŌkeanós, cannot be made fully static in practice because of the underlying search engine. However, with the help of Frozen-Flask it is easy to generate pre-rendered documents, ready to be synced to S3 (using s3cmd). Cloudflare provides a delivery network and a layer of security. To facilitate blogging, we sprinkle Flask-FlatPages on top, which converts Markdown markup language into Html and allows us to use YAML to add post metadata.

There you have it - a minimal core project template in our prefered stack. The way to make your life more complicated initially but with realistic odds that it will pay off in time in the long run. And that is the approach that has worked in our experience.