"Why you should never, ever, ever use MongoDB" (2015): http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...

Choose boring technology - especially for a relatively simple use case such as a CMS.

2015 was a while ago for MongoDB and most of those issues no longer apply. That article could stand an update.

Frankly I have no intention to write an update to the article.

Anyone who, after reading that list of issues and seeing the repeated sketchy behaviour of MongoDB (the company), still doesn't recognize the deep-seated issues behind how MongoDB is being developed and marketed, isn't going to be convinced by an updated list of grievances either. It'd be a waste of my time and energy.

But if you insist on evidence that they haven't actually meaningfully improved, this is their latest problem, from a few months ago: https://www.ongres.com/blog/benchmarking-do-it-with-transpar...

Seriously. My original article wasn't just a to-do list for the MongoDB developers. It was meant to illustrate the deeper problems with MongoDB, and how it's a database that was developed just to have a product to sell, not to actually build a better database.

If that message still hasn't gotten through to people, well, I've tried.

There are competing implementations of MongoDB's API. Microsoft's CosmosDB is promising but, last I tried it, not complete enough for Apostrophe. AWS DocumentDB may be up to the task, if the plaintext search indexing features of Apostrophe were replaced with an alternative.

In the meantime, PostgreSQL has perfectly good querying capabilities, including for JSON if you need schemaless data for some reason, working full-text search, and (unlike MongoDB's API design) an injection-resistant query API.

What's the point of continuing to pour engineering resources into something that doesn't actually improve upon what's already available?

MongoDB supports indexing of nested and array properties and has a 16MB document size limit for BSON documents. Those things help a lot in a CMS; if you prettyprint an Apostrophe page in MongoDB the structure just pops out at you.

We've had good experiences hosting it both with the community edition and with Atlas. When your documents make up a page tree and have a lot of structure within each document that would otherwise involve extra joins, it's a nice representation and we really haven't paid a price for using it. If we had, we might have made other choices. YMMV.

Yes, used it for a government gig.

Who knows why, but the gov dept wanted Apostrophe.

It was mostly good to use. Admin UI on mobile pretty terrible, but they weren’t worried about that.

Most of the work involved configuring the CMS, customizing templates and hacking on CSS to implement the site design. Wrote a couple Mongo queries, that’s it.

Not the best dev experience, but I wouldn’t run from another Apostrophe project.

No doubt, the version numbers from PHP to Node are weird.

Here's what happened: when we first came to Node back in 2012, Node itself was being very, very cautious about releasing a 1.0 version, something that didn't happen for quite some time after. So the culture was to be conservative with module version numbers, and we felt our first Node release shouldn't be 1.0 or 2.0... and we wound up releasing it as 0.4. Then the second major release on Node, which should if anything have been 3.0, as 0.5.

Then node version numbering got rational, we got serious about semantic versioning, and for our next major rewrite we went to 2.0. Still confusingly close to the old PHP 1.5 version number, but at least it's not a smaller number!

2.x is an LTS (Long Term Support) release, supported through 2023, so we've been iterating on it while maintaining bc. 3.x, which will finally break bc but also be an LTS for quite a while, will be released sometime in 2020.

Many feature additions in the past few years have been driven by enterprise support from Michelin and other clients, which is why there's a strong emphasis on workflow and localization (see the apostrophe-workflow module, which is an optional npm install so that projects that don't need it can easily skip it).

The price?

It's open source. We do have one or two closed source modules we're pursuing, but we've learned our lesson watching what happens when other companies closed-source the wrong functionality. If it's a big win for most websites, and not just those at the largest scales, it should be open source.