DuoCMS 8

DuoCMS 8 is the latest iteration of our content management system. But in this article I’d like to talk less about what we’ve added and more about what we’ve taken away.

Reducing Technical Debt & Dependencies

Complicated software like our cms system aren’t written in isolation. They rely on lots of open sources dependencies. These are pieces of software which make it economical for us to write our system. Everything from talking to third party APIs, sending emails and authenticating users are all open source dependencies.

The very language we use, javascript, has seen numerous improvements since we developed Duocms7 4 years ago. Many of our dependencies are no longer required as the language itself provides those features. Also many of the dependencies haven’t seen updates, but as the code we write depends on them we can’t remove them without rewriting various elements.

This build up of work generated by systems we rely on changing, or needing to change, often referred to as technical debt, builds up within any system over time.

In addition to the gradual issues we’ve seen due to the inevitable ageing of our code, the past twelve months the javascript community has seen a few specific issues arise. We have had numerous incidents of open source dependencies being sabotaged by developers who no longer wish to support them. Some by handing control over to third parties, other deliberately breaking their packages. Although these incidents are very rare and isolated it serves as a good reminder that we need to reduce our number of dependencies when possible and lean more upon language features to fill those gaps.

To help make Duocms8 more resilient to technical debt, we have had a complete review of all our upstream dependencies and stripped as many as possible.

We’ve gone from 65 direct server production dependencies in duocms7 to only 42 in duocms8. In addition to that we’ve chosen more lightweight dependencies with fewer of their own dependencies. This has taken us from 715mb of third party code down to to only 249mb.

This reduction means we get

Faster site deploys due to less code to install
Fewer packages needing security updates
Smaller surface area for potential security flaws

Reducing Memory Usage

One of the biggest limiting factors of our websites is their memory usage. Our clients want their hosting to be as economical as possible so for many of them we use relatively small virtual machines to host their sites. Typically the more traffic a dynamic cms site gets the more memory it needs. So by reducing the usage we can get more scale from fewer resources.

During the development of cms8 we took care to check the impact of every library and how we use it.

Duocms8 no longer uses coffee script ( a compile to javascript language ) as this saves us several megabytes of memory by using vanilla javascript. We switched the underlying api framework to a more lightweight version and chose to pre-compile our site templates. In addition to this we moved away from using a full ORM (Object Relational Mapper) for our database queries in a favour of a simple query builder. This combined effort took a simple base website from using over 200mb down to using as little as 50mb of memory per javascript process.

Simplifying Security

Automation of Content Security Policies

Best practices dictate that websites should have a content security policy. This is a special piece of information sent with each page describing where it is allowed to collect its content from. This policy helps prevent various types of attacks on the site by telling the web browser to ignore content unless is comes from a specific whitelist of sources.

We had an interface for this in previous versions of the cms, but in general it was either unused due to the difficulty in understanding it. Or it caused unforeseen bugs by blocking too many things.

In CMS8 we have automated this process. The content security policy (csp) can now be set up with a default policy with the click of a button. While editing the site the policy can update itself to fix any issues caused. So by default youtube may be blocked, but if the site editor then chooses to insert a youtube video, the csp will be updated to allow video and image content from the domains that specific video requires. These updates to the csp will be logged for later auditing, recording who added these and when.

Preventing Spam

Feedback forms within websites can often be a constant source of spam abuse. To limit this we’ve always filtered our forms with a set of heuristics to determine how spammy the content is. We determine how long the user took to fill out the form and leave hidden fields in place, as robots fill these, unlike humans who can’t see them. This on the whole reduces spam, but doesn’t completely prevent it.

To improve this we’ve made it much simpler to add google’s re-captcha to all the feedback forms within the site. By simply follow a couple of simple instructions to generate a set of api keys we are able to pretty much eradicate spam.