Introducing Dato: CMS for static sites

Is this really the best that the IT sector has to offer? We need to improve. And we have to, because the fact is that we can. For the past month we — at LeanPanda — have been working on finding a solution for these problems: we've given the result of this work the (still provisional) name Dato.

DatoCMS is CMS-as-a-Service: a centralized system providing a web interface through which site content can be modified, just like the service offered by Wordpress and other similar companies. So, how what sets it apart from Medium, Wordpress.com or even Tumblr? At least two important things:

• An administrative backend tailor-made for the specific editing requirements of each individual site;
• Every data modification produces 100% static site, published automatically to a CDN: quick, low-cost, safe and scalable.

Curious about what motivated us to do this? Keep on reading :)

First of all, what difference is there between a static site and a dynamic one? To the outside observer, none whatsoever: both look exactly the same. The difference lies in the way that the HTML that makes up the site is written.

A static site is composed of a series of HTML files organized into different directories. No PHP, no Ruby, no databases, no CMS. Simple, old, boring text files that are uploaded to a hosting service when they are created and, from that moment onwards, present an unchanging aspect to all visitors to the site.

A dynamic site, in contrast, is one in which HTML pages are "written" on-demand every time a new visitor arrives at the site. Who writes them? Software residing in the hosting space that is constantly listening out for new requests to be satisfied.

In order to be able to present different information to different visitors, a site has to be dynamic. It is for this reason that, today, almost all of the sites that we visit on a daily basis are built in this way.

This drastic change, from static to dynamic, is what has made the digital revolution that we are living through in this decade possible. However, it has not come without certain disadvantages and costs:

1. Hosting e performance. A static site can be hosted in an extremely simple way on a CDN, a server network distributed uniformly across the globe. A CDN is able to guarantee an extremely rapid, uninterrupted service: if one of the servers in the networks goes down, the traffic is simply redirected to another. In contrast, if I have an hosted Wordpress website, and the server catches fire, my site goes off-line. Simple as that.

2. Safety. A static site doesn't have "moving parts", so it's physically impossible to subject it to an attack of any kind. Full stop. Once online, a static site will remain online forever.

3. Speed and simplicity. Having been entirely produced and prepackaged upstream, a static site doesn't require any engineering work to optimize page rendering times. Furthermore, it requires no maintenance over time whatsoever: servers and software, being absent from the architecture, don't need to be updated.

4. Costs. Scaling, ensuring that a site will keep on functioning correctly if the number of visitors increases, is far, far easier with a static site. There's no need to purchase more spacious hosting services or manage sudden spikes in traffic: everything is handled automatically by the CDN.

Returning to the topic we were discussing previously: almost all of the sites we visit on a daily basis are dynamic. In the light of everything we've just said, an obvious question raises its head: have we, perhaps, gone a little overboard with making sites dynamic? :)

Let's set aside for a minute Facebook, Twitter, Google and the other web giants, and focus on the remaining 98% of the Web: how many of these sites actually present different information to each visitor who arrives or are updated in real time? How many, on the other hand, are — exaggerating things a little — updated not more than once a day?

The only ones who really take advantage of the "dynamic" part of these sites are the administrators, who are able to navigate the backend of their site at the same time as they update it.

The rest of the time, millions of servers around the world continue to produce, in real time, exactly the same page they made a second previously, and visitors are "subjected" to a dynamic architecture that has purely negative effects on their viewing experience: slowness, instability and potential vulnerabilities.

It's important to realize that "dynamic" architecture is, for the overwhelming majority of websites, a huge, unjustified cost: what we need as standard for a typical site is a "semi-static" architecture, capable of bringing together the best of both worlds:

1. provides a CMS in which anyone can update their own website, without needing advanced IT skills;
2. following each modification of the site content by an administrator, automatically generates new static HTML pages one at a time and transmits them through the CDN until further modifications are made.

The second point has fortunately already been solved, thanks to the creation of tools known as static site generators. There are already hundreds of them in existence, for all tastes and every possible programming language. The problem is that today they are niche products, whose users are mainly programmers. To use them you need to know how to input terminal commands, manage file Markdown, modify file configurations... nothing very complex, but still things that would be impractical for a non-technical user who is used to the speed and simplicity of a web-based CMS.

We imagined a service able to resolve all of these problems, and now we've built it, as a self-consciously MVP: the Minimum Viable Product to validate the underlying idea. What we now want to share is the result of the first 100 hours of development.

Suppose we want to use DatoCMS to create a website for the Italian Rubyday 2015 conference. DatoCMS is able to generate what we have called a Space: a real administrative backend, through which it's possible to manage content of any format or type. The first step is to direct a second level domain of our choosing (e.g. http://admin.rubyday.it) towards a specified Space by means of a CNAME entry. Once this is done, it's possible to associate an unlimited number of editors with our Space, who will then be able to log in and manage the site autonomously.

Sponsors, Talk, Posts, Service pages... a developer can configure the interface experience required to manage them all in just a few minutes, no coding required. Everything is tailored to the specific requirements of the site, and it's possible to set up Content Types customized to have the exact number of fields necessary.

As of today, DatoCMS includes the following (optionally multi-lingual) field types:

• Text (Title with slug, String, Textarea, WYSIWYG)
• Numbers (integer, float)
• Boolean (checkbox)
• Time/date
• Image (Drag & drop with AJAX uploading on Amazon S3 and image processing using * Imgix)
• SEO information (fields including meta title, description, Twitter Card, * Facebook Opengraph, …)
• Relationship between records (one-to-many, many-to-many)
• Geographical coordinates (using Google Maps)

New fields will be added as and when we feel the need for them. The Content Types can generate collections of Records (e.g. blog articles) or have the "singleton" type, making it possible to edit a single Record (for example, relating to the Homepage settings).

DatoCMS makes use of an API that can be used by any static-site generator to obtain all of the necessary data for its backend. Thus far, a first plugin has been created for Middleman, one that makes it possible to work with DatoCMS as if it were one of its own local Data files. We have also implemented some handy Middleman helpers capable of automatically generating SEO information for each page.

DatoCMS works in synchronization with a Continuous Deployment system (we've currently implemented an adapter for Gitlab CI): as soon as any data modification carried out by the editor is detected, DatoCMS advises the user of the need to publish those modifications and is able to use a webhook to request the generation and publication of the site modifications on Amazon S3 in the space of a few seconds:

Sure, 100 hours of development isn't much — and there's a lot of work still to be done — but what we've done so far has been sufficient for us to be able to see in production, with our own eyes, the potential an architecture of this kind has:

• indestructible sites, ready for prime-time television;
• hosting costs reduced to practically zero;
• a simple editing system as good as any other CSM on the market;
• radically reduced development times (thanks to Middleman!);

### Important update!

One year has passed, and <strong>finally DatoCMS is in public beta</strong>! Create your first totally static site with DatoCMS signing up on <a href="https://www.datocms.com">http://www.datocms.com</a>