What is it?

A developer-oriented CMS meant to rapidly publish content to multiple sites while minimizing cloud deployment costs.

How does it work?

The application allows you to manage both sites and their static pages. Pages are published to S3 and assigned a CDN for a low-cost and high-availability site.

Architecture

The application is meant to be run locally and connects to AWS resources only when needed to minimize cost.

Terminology:

• site - Refers to a hosted site (belongs to a single domain)
• post - A page on the site

Dynamo DB

The application makes use of the AWS Dynamo DB free tier to ensure posts exist in the cloud. This ensures the posts are not ephemeral despite the short, containerized application lifespan.

All data is stored in a single table and horizontally partitioned by site. In Dynamo DB, you define a base table, which partitions the data on a partition key. In my case, my partition key was:

SITE#[domain name]

Example: SITE#brettnamba.com

So all pages for a single site will belong to their own partition. If a site has a significant amount more than other sites, the partition key can become unbalanced. You can then:

• Partition by date
• Partition by site sections

The adapters for storing the site and post data are below:

• AwsDynamoDbSiteRepository
• AwsDynamoDbPostRepository

Secondary partitions (global secondary index)

As mentioned earlier, there is only a single table. The table not only holds post data, but holds data about each site.

The site data will live in the same partition as the post data, but there are secondary indexes that allow you to do the following:

• Query all sites
• Query all posts

This is useful for the backend, so you can view all of your sites/posts to edit them. Note that in Dynamo DB, these secondary indexes are projections of the actual tables and are eventually consistent. The site edit-to-publish time allows for these indexes to sync.

Example data

The only real columns on the table are the keys (partition and sort keys). Any other columns are called non-key attributes.

In the above case, there will be two partitions for brettnamba.com and paylesscms.com. The sort key for posts contains a timestamp – this means that posts are sorted by their post date.

The serialized data fields are non-key attributes meaning they aren’t queryable efficiently. For this case, since we are just listing and displaying the pages, that is fine. If you wanted to make them searchable, you could:

• Add additional partition keys on something like page content and use tags as a possible partition key
• Elasticsearch integration - On a new post event, using Dynamo DB streams, you could sync post content to Elasticsearch for fast querying

Backend

The application has services that help it publish to AWS S3:

• HostCreatorInterface -> AwsHostCreator: Creates AWS infrastructure for deploying a site
• SiteFilesystemFactoryInterface -> LocalSiteFilesystemFactory and AwsS3SiteFilesystemFactory: Factory to get a filesystem (either local or AWS)
• PostPublisherInterface -> FilesystemPostPublisher: Publishes static files to the resolved filesystem (resolves using the corresponding factory)
• PostSitemapGenerator -> SimpleXmlPostSitemapGenerator: Generates a sitemap

The application is built in Laravel so it follows the basic MVC pattern:

• Models
  • Site
  • Post
• Controllers
  • Site
  • Post
• Views
  • Site
  • Post

Publisher

The publisher is in charge of creating the static files to publish to S3. The workflow is:

1. Resolve the target filesystem (the goal is to use S3, but you can use local publishing to view the site first)
2. Publish posts to file at the path of human-readable url
3. Publish post indexes (home pages)
4. Publish assets (images and scripts)
5. Publish sitemap
6. Remove stale files (any posts flagged as deleted)

When publishing a post, it uses Laravel’s templating system (that it uses to render views) to render post content. You create layout files for each site in the same way you create view files and then the publisher will push the content into them.

Post content can be in:

• Plain text
• JSON
• HTML

This allows you to tailor your template layout files differently for each site. For example, in an HTML page, you could just display content:

<html lang="en">

<head>
    <title>{{ $post->title }}</title>
</head>

<body>
{!! $post->content !!}
</body>

</html>

Or use subviews to vary the layout based on the URL:

<div>
  @if ($post->humanReadableUrl == 'resume.html')
  @include($post->site . '::subviews.resume', ['post' => $post])
  @elseif ($post->humanReadableUrl == 'works.html')
  @include($post->site . '::subviews.works', ['post' => $post])
  @elseif ($post->humanReadableUrl == 'personal.html')
  @include($post->site . '::subviews.personal', ['post' => $post])
  @endif
</div>

Or for posts with a lot of data you can use json, deserialize the data in the view template, and show it on the site:

<html lang="en">

@php($animal = json_decode($post->content, true))

<head>
  <title>Seattle Adopt a Dog - Hello, I am {{ $animal['name'] }}!</title>

Workflow overview

Below is the flow of the whole app:

Technologies

It is built with:

• PHP
• Laravel 8 framework
• AWS
  • DynamoDB
  • S3
  • Cloudfront
• Terraform
• Bootstrap
• TinyMCE

Post-mortem

One of the main reasons for creating this app in an MVC framework was to create a web interface that could easily switch between content types. This allowed me to edit:

• Simple static HTML sites
  • Example: Simple blogs or “feed” sites
• Complex HTML using TinyMCE
  • Example: My personal site
• JSON files to create many pages with the same pattern
  • Example: a dog adoption site with many fields or a site that listed new games on Xbox Game Pass

As some of these sites were retired, I found myself only needing simple content. I no longer needed a WYSIWYG editor like TinyMCE.

So I eventually redid my personal site in Hugo. The benefits were:

• A templating system of similar capability
• Simpler backups off-site (via version control)
  • “Post” content are just stored in static files in any git repo and no longer had a DynamoDB dependency