I'm planning on creating a website with NodeJS, What can I use to future proof it?

MongoDB fits when you design a database based on the way the data will be accessed. That way with one read operation you can get all the data you need to show in the client. Application oriented design. If you don't know the way the data will be accessed or you want 'however' access you should normalize your entities and their relationship (SQL approach)

And about MongoDB.You must know some things like:

• Document max size is 16 MB
• Embedded arrays are not the Panacea. You should use it to represent relationship one to many when that many are a FEW and grow in a predictable way.
• MongoDB atomicity is document level. There is an operator to do a kind of transaction but there is no rollback.
• MongoDB have started recently to implement joins to database level (so another relational database are much more powerful and advanced in this field)

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.

Do yourself a favor and avoid all those three. Starting from the worst:

• Template strings will be very messy, you do not get a good IDE support, and you will lack proper interaction (depends on how "static" your page is)
• There is no reason to use MongoDB from the start. Fulstop. In general use SQL databases as long as you do not notice performance problems. Then you can either get familiar with scaling SQL or you can look at NoSQL. Transitioning from SQL to NoSQL is a lot easier than the other way round. Having a Schema in your DB helps you a lot in avoiding invalid data due to bugs which are common in the beginning.
• Node.js, I always wonder why people choose node for production (!) software. It is slow, most of the trivial bugs you write (e.g. typos) are only detected at runtime (if at all) and Javascript as a language is weak. You basicly trust your business to a glorified text file

There is no "general" future proof stack. Pick the stack that's now the best for the job and not because they have biggest marketing claims (cough MongoDB cough). When I start a new project i basicly follow this plan:

• Is it a website or an app (eg blog vs dataviz)

  • Blog: Static site generator, I like Hakyll a lot
  • App: continue



• Which frontend framework (if app)

  • No react/redux (not a framework, but also not a simple library, forces you do follow weird OOP approach, in case of redux a lot of boilerplate)
  • No Angular (Bloated, too much "magic", if something fails, reason is not clear)
  • I like Cyclejs, but as Co-Maintainer I'm biased. I would recommend Cycle if you want to do a lot of async stuff (e.g. websockets)



• API

  • No Node, see above
  • I've grown to love Haskell servant, which lets me specify the URL, let me write the handler and does all the plumbing for me. Also the type system saves you a lot from errors



• What type of data do you have

  • Logging data (mostly append): TimescaleDB (Postgres plugin)
  • CRUD: Postgres/MariaDB
  • Images/Videos: Document database (NoSQL)

When selecting databases, I would really recommend getting an understanding of how they all fit in and are related to eachother.

All database types have their merit. So I wouldn't bash on mongodb vs mysql or any other for that matter. The selection of the right database type is entirely based on your own use cases and future use cases.

Whilst CAP theorem is out dated it is important to understand why it came about and the point it was trying to make: en.wikipedia.org/wiki/CAP_theorem

Then there is the discussion about the 3'Vs of data, which will allow you to understand whether right now or even in the future will you be dealing with "big data" and therefore do you need to adjust your technology now or later to meet these requirements: whatis.techtarget.com/definition/3Vs

When it comes to SQL vs NOSQL or even more exotic database structures it is important to understand how brands try to claim they cover all the bases, but ultimately they will all have something they can not do. Whilst SQL databases typically drop you into a relational world, there are "families" of non-relational databases. Selection of the right family is purely down to the use case.

As an example, whilst you may know of MongoDB, Cassandra, Neo4j as being non-relational databases each of these fall within specific families. There's a bunch of them ranging from:

• Column stores
• Key value stores
• Document stores
• Graph relational

Each of them have a specific use case and its important to understand when one should be used over another. For a good breakdown of this information take a look over this:
jamesserra.com/archive/2015/04/typ...

Remember, just because google are using spanner and pinterest are using Cassandra, does not mean you need to be using it in your latest project. It also does not mean you need to pick 1.

To give some context to my statement you may find that you want a flexible schema database that you will iterate your front end client application numerous times during your build. Typically the data to be stored requires little in the way of joins and the queries you need to execute are simplistic. Your front end would benefit from receiving all the data in one request and is happy enough to work against a REST API. In this scenario you may say a document store would work quite well, like MongoDB.

Later on in your project you realise you wish to provide text searching across a number of collections within MongoDB and provide site wide search for products including the usage of fuzzy matching, auto completion and "did you mean" type scenarios. In this instance a text search database, potentially based on the lucene engine like Solr or Elasticsearch may serve you best. Yes, you could use MongoDB for this, but you may find you are starting to push complex query and join logic into a database that is typically trying to remain simplistic.

If you want development speed you want to use Meteor.JS. Is a node.js with steroids (~10 custom plugins and a special MongoDB). You'll have a full website in a matter of minutes if you already know your way around with : hot code push, database data in your client browser, websocket connection, ability to fetch/call server side functions, user system etc.

I recommend Meteor only if you want to prototype OR make a small website, with large /heavy traffic websites I would say to make a more custom solution.

For a more simple, custom and straight forward option you will want a bundler like webpack and start pooring frameworks in it (Babel, ReactJS etc).

I used template systems all my life (>10yrs), I strongly recommend WebComponents (Vue,React etc), this is a newer better way to do HTML/JS/CSS.

MongoDB vs MySql (any NoSQL vs any SQL) is all about your data sets, needs and queries. They also work together for the same website, storing different things. Use MongoDB for faster iterations, simple queries and low overhead.

What kind of website is it? Is it a web-app, that has lots of forms and interactions, or is it a blog, or..?

Instead of EJS - Templating, you could create an api and output json, in combination with a single page application as frontend.

If you are going to develop any kind of social network where data is "strongly related" watch out to use any kind of graph database as Neo4j