The Gathering Technical blog

The new gathering.org

05 Apr 2015, by Christian Strand Young from Info:Systems

Apart from the new graphical design, have you noticed any other changes to the website this year? Well, you are right. For The Gathering 2015, we decided to rewrite the entire site from scratch. The result is what you see on gathering.org today.

The old gathering.org website was based on CMSMS, a PHP-based content management system that for several years have shown its limitations in what we can do with the site. Last year, the decision was thus made to create a new site from scratch. The concept for the new site was finalized in late 2014 by Info:Content, Info:Graphics and Info:Systems. It was implemented during January and February this year, and launched on March 1st. The front-end, back-end and CMS functionality is built with much help from our beloved Django Web Framework. This allows us to customize the site to our hearts' desire for the content-producing crews, enabling them to do their job as smoothly as possible.

The site is built with Django 1.7.7 as the back-end, with a fine soup of HTML5 and some nifty Javascript and LESS libraries on the front-end side. Although we use a MySQL database as our data store, we don't see much of it —Django abstracts away the database as much as possible by giving us data access through an ORM. This means that instead of writing complicated queries in SQL, we can use code like this in our back-end logic to e.g. get all our articles:

Article.objects.filter(published=True)

How the stack works

So, let us move on the technical bits. At the bottom of the stack in the production environment is our Django application with all its Python code, such as models, views and templates. This is served locally on the server through a Gunicorn WSGI server. We then use Apache to ProxyPass to the Gunicorn app. On top of this we have a Varnish cache that caches almost every page on the website so that the end users experience fast loading times—even when the server has a lot of concurrent requests.

Caching

Using the Varnish cache means that when a user hits a warm cache when viewing e.g. an article, no database queries, Gunicorn or Apache requests will take up any resources; the response comes directly from Varnish without going through the underlying layers of the stack. When something on the site gets updated, we invalidate the cache. This means that the first user to request the page will hit a cold cache. Varnish then forwards the request to Apache which in turn forwards it to Gunicorn. The response is then again stored in Varnish, and the cache is warm again for users to browse the content swiftly. :)

We hope you are as happy as we are with the new solution! It is a joy for us to code with a framework as fully-featured as Django.

This was Info:Systems' first post on the brand-new The Gathering: Technical Blog. In Info:Systems we have a ton of other cool and/or quirky systems that we would like to tell you about, so stick around to hear more about the technology that makes TG tick!

Christian Strand Young

Working as a software developer and consultant. Full-stack developer in several non-profit organizations including Chief for Info:Systems at The Gathering. In my spare time I like to be creative and play with technology and computer games.

Crew: Info:Systems
Author image: Christian Strand Young

About

TG - Technical Blog is the unofficial rambling place of the Info:Systems, Tech:Net and Tech:Server crews from The Gathering.

Filter posts by crew

Related sites

Collaborators