-3

I'm currently in the planning stage of a new project which is a content management system.

The basic requirements are somewhat straight forward:

  1. Rich text capability ✅
  2. Real-time collaboration ✅
  3. Subject-based search and indexing ✅
  4. Scalable (possible multi-server deployment in future)
  5. Online/offline sync
  6. Roll-back capability

The last few is where I'm a bit hung up on the plan. The way the requirement is, git or something extremely similar would be the ideal. Lossless, lightweight, and storage space efficient.

So I started doing some research looking to see whether anything "git-like" was available as a back-end plugin. I was looking specifically at mongoDB capabilities at first and pretty much found that building my own methodology from scratch was what I'd have to do to get everything I want.

Then I found this article from 2016 describing a way to create a no-SQL database with git itself. https://www.kenneth-truyers.net/2016/10/13/git-nosql-database/

Thinking this through it seems very doable and interesting, and I'd get to use git directly which comes with familiarity on my part, a huge amount of documentation and utilities, and a buttload of features. That being said, I am wondering about the scalability of this method.

If I went with this route, then I was asked to deploy to a multi-server cluster with active-active capabilities would there be any way to do that? I could simply setup a master repository and sync all nodes with git pull before accessing the on-demand content rollback features; or setup a hook based sync between server nodes (something like what's outlined here https://blog.tinned-software.net/git-repository-cluster-setup/).

However, I'm not sure if I'm trying to make something work in a way that it really shouldn't be and I should just sigh, make peace with my lot, and start building the roll-back system from scratch.

Any advice or thoughts would be appreciated.

Improve this question
4
  • 1
    Answers to this question may help: stackoverflow.com/questions/4185105/… or the versioning pattern described by MongoDB: mongodb.com/blog/post/… – rb612 Feb 23 at 3:46
  • 6
    Which of Git's features precisely do you need for your CM? Only versioning/history/rollback? Or more features like text-based diff/merge? Branching/merging/tagging? Distributed and offline capabilities? – Doc Brown Feb 23 at 5:50
  • @DocBrown Specifically I'm looking at the differencing-based storage approach (less expensive for many additive changes which will be the most common), the diffing itself so users can get an overview of changes easily, currently there's no requirement for branching but would be an interesting option to have. – Ethan Feb 23 at 13:50
  • @rb612 unfortunately the MongoDB pattern specifically calls out that it assumes there won't be too many revisions. I expect there to be hundreds+ revisions for each content package and the only thing I'm interested in truly versioning is the content itself not the metadata. There will be thousands of documents (though can be split into different folder by project name). That document and ones like the SO linked one are the reason I was looking at git instead of trying to build out something myself. – Ethan Feb 23 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.