Features as Apps, Apps as Services

Posted Friday, July 15, 2011 at 12:49 p.m. by Chris Amico in News and Projects about journalism and programming

The CMS is a dying concept. Erik Hinton at TPM gets us started on thinking beyond One System To Rule Them All:

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:



Comments:

aug 6, 2011 at 10:12 a.m. // Alex Bowman said:

I think the biggest challenge to avoid is the n(n-1)/2 problem.

Systems get bigger, and spend more time talking to themselves/getting fixed so they can talk to themselves than doing anything.

Interesting to watch. Cheers Chris, long time no comment. :)

Comments are closed for this post. If you still have something to say, please email me.