An Incremental Approach to Content Management Using Git

This makes me think of http://decoupledcms.org/

I don't know who is behind that org, and whether all the technology they reference is completely valid, but the point is that a CMS that is made up of parts is far easier to deal with in the long run than a monolithic entity.

We're already seeing this decoupling happen a lot in practice with static site generators, but there is a long way to go (static sites are rather limited).

If this interest you guys, you will most likely be interested by what we do over at prismic.io too. Basically, we're a service too, we output content as JSON too, and are very focused on versioning too; but we also have what we call the "writing-room", a very user-friendly UI to let non-technical content writers write comfortably without needing tech tools such as Git; and we come up with our own content query API.

It works with most technologies (we have kits in JS, Ruby, PHP, Java, Scala, Python, ...), and we did release a static website generator based on a JS engine which we called baked.js.

Check us out if you're interested in tech-flexible, design-flexible content management where content is nicely versioned.

People interested in this article could also take a look at `coisas`, a tool I'm using for publishing my personal website using GitHub pages:

https://github.com/fiatjaf/fiatjaf.github.io

It is tangled with the website files, because it runs on pure Javascript, at the browser. And, yes, it only works on GitHub pages because when you click "Publish" it renders the content and commits to GitHub. Later I will make it more presentable, but for now it is working.

The goal is to make a tool that can publish any kind of data you want in almost any kind of format you want. It works with hierarchical documents (which are used for the paths of the URLs) with `kinds` (a markdown article, a table of data, a chart, a list of children documents -- for a list of blog posts, for example). To customize you just have to modify/add templates.

All the working code resides at `/edit` while the published pages themselves reside on the top directory. To create/update/delete documents just go to `/edit`:

http://fiatjaf.github.io/edit/

The filesystem, backed up by git, ought to be perfectly fine for serving text content.

It will be interesting to see what happens if they add a lot of images and videos and git starts choking.

The main benefit of adding a RDBMS in this scenario would be being able to run indexed queries using SQL. The text content itself wouldn't benefit much, of course, and would be better off with something like SOLR for search. But there will probably be dates and other loose metadata that is ideal for a RDBMS. If the content in the filesystem ends up with associated metadata in a RDBMS, they may wish they had just put everything in the RDBMS to keep it simple.

In this talk Robert C. Martin describes a similar situation:

http://www.youtube.com/watch?v=asLUTiJJqdE

They refrain from committing to a database server early on so they create an interface to storage and start saving data in files. He contrasts putting the database in the center of design vs. putting the application logic in the center of design.

Then he goes on to talk about hexagonal architecture. A very good talk if you haven't seen it.

"frameworks usually enforce their view of the world upon their developers, and trying to choose correctly at the point where you understand the least about the project is nigh-on impossible."

Spot on.

Have a look at GatherContent.com as well :)

http://www.gathercontent.com

Who is the genius whom devised such an horrible way to mark up hyperlinks?

Well, this is one way to solve the problem of database version-control... just store your data as flat text files. I can't help but think there's got to be a better solution.