Basically, I'm wondering what technologies, node modules, etc I could use to either future proof it, or just make it easier to make.
My current thought of things to use:
NodeJS 8 - Backend
EJS - Templating
MongoDB - Database
Just posting suggestions is fine, however, I'd appreciate it if you gave examples of how you have or how it can be used and some rough pros and cons of it are. (If you have an opinion that doesn't match everyone else's, I'd still love to hear it)
Thanks <3
Top comments (21)
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:
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 :)
Do yourself a favor and avoid all those three. Starting from the worst:
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)
Which frontend framework (if app)
API
What type of data do you have
If you find that Node is slow, there is something horribly wrong in the way your app is either written or deployed.
Next, every languages represent code as "text files"... compiled or not makes no difference. Code is a human readable set of instructions. The fact that it is not compiled does mean possible runtime uncaught exceptions. This is why we have linting, unit tests and acceptance tests... If, regardless of thise you still get errors, it brings me back to my first point: you're doing something horribly wrong.
An application is, in essence a group of tools, like a db, an http server, some caching, etc. With the language simply acting as a glue between them. I don't beleive that a language can be categoricaly inferior or superior to another one- just that they all have their perks. JS for APIs is a real breeze.
If you need some help setting it up, hit me up, my fees are reasonnable ;)
The glorified text field was refering to no type system that protects you. Unit test are no replacement for a type system.
Node is slow. I did a few benchmarks before choosing my Stack and node was the slowest of them. My Haskell server could handle twice as many clients before maxing out my test rig.
Js is not a breeze, it's horrible. The express API is the worst API i have ever seen. I would never even consider node for anything more than a prototype.
To each its own, innit?
Nodejs is awesome if you REALLY KNOW nodejs. So is anything else you REALLY KNOW...
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:
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.
Thanks for that insight, I feel that this will help me make the right choice. :)
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..?
Hard to explain but it’s like a social media site with stuff that isn’t social related, more form ish based
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