Make sure you're being thoughtful about your decision to use MongoDB. It's as "future-proof" as MySQL is; both are being actively developed and maintained.
As far as I'm concerned, the only use case for Mongo is where you have a bunch of big JSON objects, you don't care what's in them or how they relate to each other, and you just need a place to stuff them - you'll be storing the entire object and retrieving the entire object each time. Of course, Mongo allows more complex operations, and there are packages that allow you to relate objects and enforce a schema and so forth, but at that point you might as well be using SQL. SQL is very good at storing objects that relate to each other and have strictly-enforced types. And, with the right optimizations in place, it's super fast and reliable.
SQL's also been around the block enough times to have a gigantic community, an ORM for most languages, and a solution for almost every use case.
That's not to say you should never use Mongo, just that you should ask the right questions about it. And "is it future-proof?" is kind of a moot point.
Rethink seems well done, but it doesn't scream future-proof. I wouldn't go that route unless the realtime event stuff is critical right now for you. In general I'd focus more on being methodical as you go as opposed to overthinking everything now. Future-proofing is a real easy way to fall into paralysis-by-analysis.
One the DB side, from my observations, Mongo is usually thought of as the default in Node stacks and there seem to be a lot more Mongo tutorials and tools. I have a hard time understanding why this is, but it's what I've observed. Postgres is my definition of a stable go-to database that does what you probably want it to do, but Mongo has really found popularity with Node and I wouldn't swim upstream if you don't need to.
I have noticed the trend with Mongo + NodeJS. Thanks for the suggestion about Postgres, I'll have to look into it more. Also thanks for the advice on the analysis :)
I'd also say you can probably rewrite portions of the app like templates if it comes to it and as long as the app is generally well-thought out and tested, you'll be fine. It's really hard to know now what problems you'll run into, so pick something that seems decent based on what you know of the immediate problems at hand.
Make sure you're being thoughtful about your decision to use MongoDB. It's as "future-proof" as MySQL is; both are being actively developed and maintained.
As far as I'm concerned, the only use case for Mongo is where you have a bunch of big JSON objects, you don't care what's in them or how they relate to each other, and you just need a place to stuff them - you'll be storing the entire object and retrieving the entire object each time. Of course, Mongo allows more complex operations, and there are packages that allow you to relate objects and enforce a schema and so forth, but at that point you might as well be using SQL. SQL is very good at storing objects that relate to each other and have strictly-enforced types. And, with the right optimizations in place, it's super fast and reliable.
SQL's also been around the block enough times to have a gigantic community, an ORM for most languages, and a solution for almost every use case.
That's not to say you should never use Mongo, just that you should ask the right questions about it. And "is it future-proof?" is kind of a moot point.
What would you say about rethink? But thanks for the MySQL suggestion ;)
I don't know much about RethinkDB. Seems like a useful product, for some situations.
I should clarify that I'm not partial to MySQL or really any flavor of SQL, I just gave it as an example.
Ah I see, thanks
Rethink seems well done, but it doesn't scream future-proof. I wouldn't go that route unless the realtime event stuff is critical right now for you. In general I'd focus more on being methodical as you go as opposed to overthinking everything now. Future-proofing is a real easy way to fall into paralysis-by-analysis.
One the DB side, from my observations, Mongo is usually thought of as the default in Node stacks and there seem to be a lot more Mongo tutorials and tools. I have a hard time understanding why this is, but it's what I've observed. Postgres is my definition of a stable go-to database that does what you probably want it to do, but Mongo has really found popularity with Node and I wouldn't swim upstream if you don't need to.
Thanks Ben,
I have noticed the trend with Mongo + NodeJS. Thanks for the suggestion about Postgres, I'll have to look into it more. Also thanks for the advice on the analysis :)
I'd also say you can probably rewrite portions of the app like templates if it comes to it and as long as the app is generally well-thought out and tested, you'll be fine. It's really hard to know now what problems you'll run into, so pick something that seems decent based on what you know of the immediate problems at hand.
Sounds good to me :)