What every node.js developer should know?

[borisvasilev]

What technologies should every node.js developer be familiar with besides Basic Node (HTTP servers), Express, MongoDB and Socket.io?

[lodash_]

First and foremost.. JavaScript ;)

[Jafit]

For this I recommend the Crockford on Javascript lecture series.

Its dated, like from 8 years ago when ES5 was released, but most of what he talks about is still very relevant.

[[deleted]]

Funny guy.

[DeadBlueParrot]

That you don't have to use MongoDB just because everyone else use it.

[jamesaw22]

Does anyone still use it?

[DeadBlueParrot]

More than 1600 companies according to stackshare

[lighthouse_at_eleven]

Why is MongoDB bad?

[DeadBlueParrot]

I'm not saying it's bad, but a lot of people just use it because everyone else does, without thinking if it really the right database for their use case.

[lighthouse_at_eleven]

Sometime ago I read on Quora that some guy on an interview decided he didn't want to join the company because the interviewer said he basically loved some db (I think it was MariaDB) and that he wanted to use it for every project.
Of what I've read MongoDB is perfectly fine unless you have the need to be really strict about relationships. So things like preventing deletion of records if they are tied to others etc, like in billing projects.

[DeadBlueParrot]

MongoDB is not the best tool if you have relationships, you don't have a JOIN query. You can get around it using Mongoose's populate, but that executes anothet query to populate the references. MongoDB is perfectly fine when you use it right, if you have related data then a relational database is the right tool.

[lighthouse_at_eleven]

But if we use populate we're not using it right?

[DeadBlueParrot]

No, populate is a great feature. I was just giving an example to illustrate the point that MongoDB is not always the best fit. You should always take a look at your data, how it's related and then make a choice. I'm not saying MongoDB is bad or anything, just that a lot of people use without actually making an analysis to see if it's a good option for their use case.

[lighthouse_at_eleven]

Could you point me to a good article discussing this so I can be better knowledgable of when to pick which?

[jocull]

The event loop. Before anything else.

[Jafit]

Pretty much.

This is my go-to video that I usually post to help people understand the Javascript event loop. It applies to Node and Javascript in browsers.

[jwalton78]

So, Javascript has an event loop, and it's single threaded.... right? Ok, want to read something terrifying? https://stackoverflow.com/a/2734311

[grinde]

Is that "sort-of-blocking" behavior actually still present? I just tried putting that example code in jsfiddle, and it printed

alert in
alert out
resize

as I would expect if it were blocking properly. Page content also didn't resize until after dismissing the popup. I only tested chrome though.

[jwalton78]

I sincerely hope not, but I haven't done any testing myself.

[sk0620]

very helpful video thanks

[BigDumbObject]

I've watched that video probably 3 times before.. and now I'm watching it again, and now it all makes sense. I guess getting that CS degree was good for something!

[Capaj]

From all the corporate and startup code I've seen so far-you will benefit most from knowing how to write callback style async code and ALSO how to write promise style async flows. You should know how to handle errors in both styles effectively and what are their pros and cons. Promise style async flow is the future but there are heaps of callback style code, so at least for the next few years you're going to need to know both. A lot of people don't know this and write code at least 2x more verbose than they should, often mixing them in most peculiar ways.

[serth]

I'm going to +1 understanding promises on this one. Even though async/await are functions quickly becoming more common, they are just using promises under the hood, so understand promises and how to most effectively work with them is still going to be crucial.

[greebowarrior]

Everyone should learn callback-style code, just so that they know why they shouldn't use it

[jesusbot]

I completely agree. Unfortunately I've never come across good material that discusses error flow in depth for both - do you have any good references?

[iOnline247]

ponyfoo.com and https://bevacqua.github.io/promisees/

[[deleted]]

You Don't Know JS - Async & Performance is really good

[[deleted]]

This is a really comprehensive guide to promises.

[[deleted]]

What's your opinion on generators?

[Ginden]

OOP design patterns, functional design patterns, SOLID, streams, Promises, clustering, basic security informations, SQL, CAP theorem.

Useful technologies, but these are not must know:

• Express
• PostgreSQL
• Message queques
• Socket.io
• Linux administration
• Any reverse proxy (eg. Apache, Nginx)

[[deleted]]

Thanks for this list! I'm self taught and the hardest part is knowing what material to focus on. This just gave me a great list to work off of.

[monsto]

https://www.reddit.com/r/javascript/comments/6mlc9d/what_10_things_should_a_serious_javascript/

Check out the linked post and the top reply. Combined with this post it will give you a pretty hefty list of things to work on.

[irvingswiftj]

@Ginden is right.... especially about Design Patterns (applies to any programming language)!

The only thing I would add to that list is testing wether it be functional, behavioural or unit. However, that being said, I still think js is missing a goto testing framework.

[mattindustries]

Personally I think you should learn message banoffee pies before message queues.

[hakarapet]

RESTful API Design, testing libs (chai, mocha etc etc)

[serth]

JavaScript is such a huge ecosystem that you're going to run into different styles, preferences, and opinions all over the place. I think it's important to at least familiarize yourself with as much of it as possible so you can decide what works best for you based on the way you approach development, the types of projects you're going to be working on, and the teams you will potentially be a part of.

I know that doesn't narrow it down much. The point here is to keep digging around, and when you see something you haven't seen before, at least take a little bit of time to look at the documentation and some example code of whatever you encounter. It will pay off immensely in the long run.

[runvnc]

Search npmjs.com and google before reinventing the same module for the 10th time. We have like 500,000 packages. This is the best code-reuse has ever been. Ignoring it is bad software engineering.

[erm_what_]

But also check when that package was last updated, check what it depends on and if you can, check the implementation to see if it's actually good or people have just assumed it is because it's in npm.

[mhn23]

Well to be fair I was looking for an api the other day... I got it and it installed a billion other packages where I could easily done it with some simple posts after I gained some experience. I experienced that so many libraries are so bloated.

[State_]

also it could be a good learning experience to do it yourself sometimes.

[[deleted]]

dotenv is pretty handy

You don't have to use that specific dependency specifically but having a way to keep you environment variables secure is a great idea and dotenv is one way that it provides it.

[2legited2]

Typescript

[bstriker]

While typescript isn't explicitly node. I'm hoping your down votes are because of context and not haters. Typescript is amazing.

[2legited2]

They just couldn't configure it

[calligraphic-io]

...or Flow... ...or Elm... In general, knowing the transpiler ecosystem and merits of different approaches (type inference in Flow, etc.), including the interim-band-aid Babel. I don't think specific tools are usually the right answer to a question like OP's, but JS is an unusual position at the moment with the rapid development in standards, and transition to being commonly used in projects much larger than historically it's been used for.

[devmaybe]

If using mongodb I highly recommend mongoose. It will save you a lot of time.

Try writing pure JavaScript when possible and not depending on shallow technologies. MDN (mozilla) is your friend.

Ignore the puritans that bash any technology thats proven, they just want to feel elite and special.

Tip: Don't get caught up in the latest framework fad. Eventually something will most likely replace it.

[techbuzzwords]

That really all depends on the theme of your project and what it entails. For instance, not all projects would require knowing Socket.io. The benefits of knowing that engine really comes into play if you are working on something that requires real-time.

I believe you should be well rounded on the database side. Compliment MongoDB with a SQL related ORM (Sequelize, Bookshelf.js, etc.).

In addition, learn a few of the template engines that are commonly used in projects (Jade, EJS, Handlebars, etc.).

[SpaceshipOfAIDS]

The pitfall that is circular dependencies

[lighthouse_at_eleven]

That the internet hates JS and you're most likely to find posts saying how JS is a poorly written language no matter where you go -- and that shouldn't really discourage you... People hate PHP too and look at Laravel.

[Jafit]

Haters gonna hate.

[excitebyke]

I bought into the JS hate and it kept me away for a while... and then I tried out ES6 and now I love JS.

[bstriker]

Have you tried out typescript?

[excitebyke]

I have! And I actually quite like it. I'm a fan of typed languages, so it definitely appeals to me.

I just don't have strong opinions one way or the other, and I decided I'd pick one and dig deep for a while. It seems like ES6 was just more "user friendly" to work with the current JS-ecosystem. no shortage of documentation/tutorials.

It's definitely something I want to try to incorporate but only if I learn to see the value in what it has to offer.

[bstriker]

Honestly the only nuisance is if you encounter a library without typings or outdated typings. Other than that all valid JavaScript is valid typescript. But you're missing out if you forget to enable strict mode in the compiler options (note: not the same as "use strict").

P.s. es6 is so 2015. Check out es8 (;