DLI: Distribution, Logic, Interfaces

After writing about how I crafted my blog, I realised that I’ve actually set up an architecture that’s very much aligned with how I’d like the web to work. It might even be a software architecture pattern others would like to follow.

Here is how my blog works.

I write my posts on my computer as simple text files (usually markdown). Then, I use a static blog generator to render my blog as HTML pages, and upload them to Amazon S3.

There is also a script running periodically on my computer. This script checks for two things:

1. tweets linking to my blog and
2. webmentions and pingbacks that webmention.io has received for one of my posts. If something new comes up, the script modifies the related posts to include the tweet or the webmention/pingback from other sites, re-renders the blog HTML and uploads the modified pages to S3.

The components.

So, I actually have three components:

1. Distribution. This is the most obvious. My content is distributed using a very “dumb” web server, that in my case happens to be an Amazon S3 bucket. It could be any web server that does the bare minimum.
2. Logic. Everything that I’ve actually programmed is done on my own home computer: the way the pages are rendered, the polling of twitter and webmention.io, etc.
3. Interfaces. Twitter and Webmention.io are actually my blog’s public interfaces to the world. They are the points of contact for anyone that wants to interact with my blog. These can be considered “inputs”, but I also have “output” interfaces. For example, after uploading new content, my home script pings superfeedr, a service that notifies PubSubHubbub clients that my RSS feed has been updated. If I wanted, it could also notify my twitter followers (by posting a link on twitter), or use the Mailchimp API to send a mail to my mailing list.

Why DLI (Distribution, Logic, Interfaces) is interesting.

The most important part of the architecture, the Logic is hosted as close as possible to the user, on his own home computer for example. The user has total control and ownership of the logic and content.

The problem with hosting one’s web services on his own infrastructure is scalability: a home computer has limited resources and it’s usually connected to the Internet through a relatively slow and unreliable connection. That’s OK, because in DLI you can use cheap but very scalable distribution services, like Amazon S3. In addition there is no lock-in: if tomorrow you don’t like S3, you can just move your content to GitHub Pages or any other hosting provider you like.

Input Interfaces give the world a way to interact with your content. They are (usually) scalable, always-on buffers for signals and interactions. They register these interactions, and you (the Logic) can ask for them whenever you feel it’s the right time, and process them.

Output Interfaces are usually multipliers. You (the Logic) ask them to contact a possibly large number of other services and devices and let them know something about your content: For example that it has been updated or that it has moved.

In other words, DLI is an architecture that could help build a decentralised, independent web, that’s also scalable. The users retain full control and ownership of what’s important (content and logic), and the components that need to scale are outsourced and commoditised.

This article was originally posted on Medium.