7 ms·

An Incremental Approach to Content Management Using Git

52 points by rchaudhary 12y ago

teleclimber 12y ago
This makes me think of http://decoupledcms.org/ 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).
Zelphyr 12y ago
"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.
joeclark77 12y ago
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.
johncoltrane 12y ago
Who is the genius whom devised such an horrible way to mark up hyperlinks?
mtdewcmu 12y ago
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.
fiatjaf 12y ago
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 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/ http://fiatjaf.github.io/edit/
jamesdeer 12y ago
Have a look at GatherContent.com as well :) http://www.gathercontent.com http://www.gathercontent.com
rudyrigot 12y ago
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.
muhuk 12y ago
In this talk Robert C. Martin describes a similar situation: http://www.youtube.com/watch?v=asLUTiJJqdE 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.

52 points by rchaudhary 12y ago

This makes me think of http://decoupledcms.org/ 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).

Zelphyr 12y ago

"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.

joeclark77 12y ago

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.

johncoltrane 12y ago

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

mtdewcmu 12y ago

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.

fiatjaf 12y ago

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 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/ http://fiatjaf.github.io/edit/

jamesdeer 12y ago

Have a look at GatherContent.com as well :) http://www.gathercontent.com http://www.gathercontent.com

rudyrigot 12y ago

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.

muhuk 12y ago

In this talk Robert C. Martin describes a similar situation: http://www.youtube.com/watch?v=asLUTiJJqdE 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.