I'm asking because, one day, someone here will leak the wrong key. I already have enough problems with legal on opensourcing our software (we built a very cool CMS that runs on Node.js and MongoDB we'd love to share) and I may need to come up with some creative answer fast.
Hopefully we'll get a full write-up so anyone else this happens to in the future will know what to do.
CMS using Mongo & Node? Sounds like a fad-fest about to be turned a disaster...
Of course, exploring new ideas always creates some rework due to bad decisions (and we had a couple of them along with the good ones).
Well, both projects are rather new and changing. So not a very stable base to base a business on.
Node.js is best suited for long-running, evented type web apps (games, chat, interaction etc), so a CMS would not be a good fit.
Mongo is also known to lose data, and needs several (3 at least) servers to be somewhat stable with this.
A CMS is also not particularly read or write heavy, so a standard DB would fit even better.
I assume the data already have some specific form, so the free-form (schema-less) of Mongo doesn't buy much (and you have to replicate some relational-es on top of Mongo anyway, if you want to avoid inefficient queries returning tons of unneeded data with the response that happen to be on the same level in the "tree").
In a CMS you also have a power-law distribution of read articles, or even worse, with the top page stuff getting the most hits, and older pages being statistical noise. So some caching should provide very good speed with very little memory needs.
(Funny aside/rant: once I've implemented a custom CMS for a large bank in my country, with plain ole Java and DB2. The bank people had fallen for some IBM crap, and wanted the backend to be Domino, which, at the time (2003) was, well, let's say, inadequate. Our team implemented a CMS on top of Domino, and, as it naturally was slow as molasses, I convinced them to let us rewrite it in a sane way, which I did by myself in 1/5 the time it took to build the BS Domino version (about 2-3 months). It even had fancy things like being able to have them just upload an Excel file and automatically populating currency rates and stuff from it, with proper Decimal support, fail-rollback, etc). Hah, I also used Lucene for FTS, which was at version < 1.2 at the time IIRC.
The CMS is also evolving fast. We are a web portal with a strong news side.
> Node.js is best suited for long-running, evented type web apps
This evented nature is handy when more than one person is editing a top page. It started, in fact, as an add-on to our previous CMS (the absolutely awful FatWire) that made it possible to quickly modify those.
> Mongo is also known to lose data
Most of the time, the CMS keeps a copy of the data in memory and spits it to the datastore. Making it DB-agnostic is on the roadmap.
> I assume the data already have some specific form
Not at all. One of the worst sins of any CMS is to constrain the structure of a given document.
> if you want to avoid inefficient queries returning tons of unneeded data
The CMS is not responsible for most of the content-delivery. Most page elements that rely on queries against the article base do so in efficient ways (the content has some structure - but only what's needed). We consider a problem when a page view triggers a DB lookup. We also keep an eye on returned vs. used rates.