Separating Content Creation and Content Delivery into Distinct Concerns

The Separation of Concerns design principle is common among software developers and architects, especially now that we are in a world of virtual machines, err "cloud", and microservices. Software is returning to its "do one thing and do it well" roots. This is not a new concept, but one that microservices has brought back to the forefront of good design. That said, Drupal, Wordpress and other content management systems don't seem to follow this principle. They lump content creation and delivery into a single system. Sure, there is often a back-end, admin/author view for content creation and editing, and then a front-end layout or theme engine that does the rendering, but maybe it is time to completely separate these so that the backend can focus on the content creation and front-end can be, well, anything really.

The Create Once, Publish Everywhere model is slowly being adopted by content creators, but I don't feel we have a "Start with COPE" methodology. If I were to design a publishing platform from scratch today I would divide the system into four distinct parts: Content Creation, Content Storage and Indexing, an API Gateway, and then the Content Rendering.

Content Creation

For content creation I would use Drupal. It is a very flexible publishing system with powerful content type and entity relationships built in. It is much more robust than Wordpress and I know it already has solid modules for interfacing with search indexes (concern #2).

Content Storage and Indexing

In this system the Drupal code would push content to Elastic Search. I have no real preference between Elastic Search and SOLR here, other than Elastic Search clusters can be spun up on AWS very easily. Both SOLR and ElasticSearch are interfaced with via HTTP APIs and specialize in indexing and retrieving content based on criteria. In the past I have used SOLR as an interface to iOS applications and that experience has made me think we should serve more content straight from search indexes.

API Gateway

For a front-end to the Elastic Search index I would use an API Gateway such as Amazon's. If you're going to expose your content to a front end through an API you are going to want to put some rules around it and that is exactly what API Gateway from Amazon does. Alternatives are to spin your own up using Nginx, or find another third party that does it. The goal is to be able to have development and production instances that allow your editors to preview content that isn't live otherwise, and also to be able to rate-limit and cache the results so that you don't have to query elastic search on every single page request. Another way of accomplishing this is to have your Content Creation system only push data to the correct index when it is ready for the public. In that case you may not need the API Gateway, but I still prefer having one to implement rate-limiting and authentication (if necessary) for you.

Content Display

Once you have the content creation, indexing, and api gateway in place the sky is the limit for creating front-ends that consume and render it. I would lean towards a static single-page-application written in Angular and hosted on Amazon S3. Throw Cloudfront in front of it with an S3 bucket for storing images and you have a very low-cost, high-availability system. You could also easily write mobile apps that consume the API.

Next Step: Proof of Concept

This idea has been floating around in my head for a few years back to when I was supporting news driven Drupal sites and dealing with the related performance and front-end issues. Currently this site is hosted on github and generated by Jekyll. Our company site is also Jekyll but it using a cool S3 Integration to store it on S3. I want to actually implement this proposed architecture as a Proof of Concept and will probably use the Digital Ambit site so I can put my money where my mouth is.

Hopefully my blog posts over the next couple of months will center around my efforts to spin up this architecture and see if I can make it work. I would like to have it done before I head to DrupalCon in New Orleans in early May.