Instead of revolving around a monolithic central piece of software, we have adopted the paradigm of feature-as-app. Our frontpage: an app. Our slideshow: a different app. Article publishing: yet another app. You get the picture. At the heart is a simple and flexible API that digests manifold requests from the different applications. For example, Moveable Type is great at publishing entries and updating its database accordingly. Our new system will simply wrap the MT database in a cached layer and incorporate its content. Our new gallery app — currently active on the site — creates slideshows, writing its changes to central datastore as well. The frontpage maker reads from the API and is made aware of MT updates, galleries, and all other content that has passed through the system.
How does this solve the CMS problem? Isn’t this just a metastisized not-invented-here-syndrome?
First, the core of our new system is its input-agnostic API. This makes it easy to drop in replacements for facets that have outlived their usefulness. One day, we may no longer want MT publishing our entries. All we have to do is write a wrapper for Tumblr, Wordpress, or some new backend and we are set. We don’t have to worry about dependencies being broken. Because all requests go through our as-of-yet-unnamed central API, all requests are translated into generic requests. From the point of view of the other apps, nothing has changed.
Furthermore, we are not tied to any language or technology. Through the core of our system is written in Ruby, any language that can make a request to the API — details on this to come in subsequent entries — can talk to Baroque. Rather than design the system just for our needs, we are designing it to be used by future editors and developers who think every feature was misconceived. That’s fine with us. Just drop in something new.
Even better, here's TPM's new front-page workflow: