Open Source City CMS
This article is first in a series of three articles written from a technical perspective about the research, evaluation, and prototyping of an open source Content Management System for the City of Austin. This work is the product of collaboration between engineering, user experience design, and content strategy teams within the City’s “Tech Stack” modernization project.
Disclaimer: Engineers have a tendency to over complicate things to tickle their own fancy. Beware of engineers, like me, and their jargon.
In the fall of 2016, one of the inaugural City of Austin, Design, Technology & Innovation Fellows, Jacob Paul, wrote a post entitled “How We’re Thinking About Content Management for City Government.” I’d like to offer this series of posts as an update on our progress.
Since then, we’ve deepened our experience launching websites powered by content management systems. In this article, I will describe the four key concepts of the CMS architecture we are using to implement an open source CMS for the City of Austin.
1. Microservices
Microservices are independent applications that do only one thing and do it well. They can integrate with each other, but are built and maintained separately. As a result, each can use the tools most suited to the use case and technical context.
As a counter example, think of an all-in-one kitchen set.
It might be convenient at first — easy to install and providing all the basic functionality you need. But when the oven breaks or we decide we need a bigger fridge, we’re going to have to work harder to bend the whole monolithic system to our will.
Instead of using this type of all-in-one platform for the City’s website, we decided to take a different approach: We‘re creating independent components and connecting them in a flexible system. This will allow us to add, improve, and replace services without worrying about adversely affecting the larger system. This will also protect us from vendor lock-in since it avoids commitment to a particular tool.
2. Decoupled (aka Headless) CMS
Popular open source CMSs such as Drupal and Wordpress have a traditional system that includes two primary parts:
- An admin interface for writing content and managing data.
- An engine for displaying the content to website visitors.
In a decoupled CMS, you separate the web page creation into its own service. The content editor interface remains part of the CMS package. Instead of creating the fully formatted public pages, the CMS is only responsible for providing content as a stream of data through an API.
Why do that?
As you’ve already learned in Jacob’s article, this strategy has some key benefits:
- Reusability increases since both the content and public-facing interface components can be utilized by other websites, native applications on other devices, or freestanding kiosks..
- Integration with external applications via APIs is central to this approach, so there is potential for broader content and functionality provided by other third-party APIs. We also make it possible to expose parts of our content API to public civic tech communities to use in their own apps.
- Sustainability is enhanced with the ability to switch out different parts of the CMS system. In the future, we could design new content editing experiences and new engines for rendering content without throwing away the whole system to start from scratch.
In essence, we are designing a CMS that thinks beyond creating websites. It is designed to serve content to mobile phones, smart watches, Internet of Things devices, or whatever the future may bring.
In light of those intentions, a decoupled approach that uses the CMS only for the administrative interface makes sense.
But…if the CMS doesn’t generate the public interface, what does?
3. Static Site Generator
Static site generators produce lightweight flat files composed of HTML, CSS, and Javascript. When content is edited, it prompts the generator to rebuild the pages. It then deploys those lightweight static files to machines all over the world to spread the potential load of site visitors hitting the page simultaneously.
This is in contrast to the traditional CMS pattern where web pages are created dynamically on a server when content is requested.
Static Site Generators are common for sites where scale and security are paramount. The benefit of serving up flat HTML files is that they can be hosted anywhere and everywhere, like on a CDN. If your site is the target of a DDoS attack your visitor just gets served HTML files from the next closest node. More discussion of the benefits of static sites can be found in this article.
Now that we’ve identified how our code will be generated, what patterns should we use to present it?
4. Templates vs Components
Templates are sections of HTML that have sprinkles of logic mixed in. In the static site generator, Jekyll, that logic is written in the Ruby language. User interactivity is written in separate Javascript files.
Components are reusable, modular pieces of code that focus on smaller or atomic UI features. Components have HTML markup, Javascript interactivity (and sometimes CSS styling) included in same file. React and Vue are current leading examples of this paradigm within modern Javascript frameworks.
How about a metaphor to illustrate these differences?
Built in shelves are rigid, but still highly customizable to fit the needs of a wall. Modular shelving is both flexible and customizable. It is also reusable in case you ever decide to move to a new place.
Templates are like built in shelves. They are fully capable and commonly used across CMSes. Components are more dynamic and flexible. They have advantages for reuse and sustainability. They are also the trending pattern in the web industry.
Conclusion
These are the key concepts we think are important to consider as we design an Open Source City CMS.
- Microservices — how might we coordinate interactions between specialized apps?
- Decoupled CMS — how might we make content available in many interfaces?
- Static Site Generator — how might we build reusable front end code that can scale?
- Templates vs Components — how might we build reusable front end code that is fun to write, easy to maintain, and fast to prototype.
