Top products from r/node

I really love nodeschool.io :)

Great that you're already quite familiar with Javascript, but if you haven't already read the excellent You Don't Know JS series by Kyle Simpson then I heartily recommend giving it a read.

Some recent titles that look pretty cool include:

• Node Design Patterns - this gets a lot of mentions and will teach design patterns that you can apply beyond a recent text's teachings of the current versions of Node, Express, etc
  
• Web Development with Node and Express - it covers Express 4.x
  
• Practical Node JS
  
• Pedro Teixeira's series on Leanpub
  
  Avoid titles like the ones listed in a recent reddit post as they (as as been commented) are pretty much history books.
  
  But things move pretty quickly so go through the nodeschool.io courses to get a good grounding then spend some time learning up on the good design patterns you could ("should") use as those will be more readily applicable.
  
  ---
  Edit: I forgot to mention The Node Way as a potential resource.

I can't possibly recommend Douglas Crockford's Javascript: The Good Parts enough. It's a quick read; I read through it in an afternoon. I've been doing professional node development for three years now, and I still reference The Good Parts.

Similar to what /u/AlexanderC89 said, there are high-level architectural and pattern differences between javascript and PHP. The key concepts, off the top of my head, that are most important to understand are:

• Prototypal (js) vs Classical (php, c/c++) inheritance
  
• Functions as first-class objects (and lambda functions)
  
• Asynchronous/event-driven I/O model
  
• Block scope (php, c) vs Function scope (and closures)
  
• Variable hoisting
  
• "==" vs. "===" and "falsy" values
  
  You can probably find good descriptions of all of these somewhere on the web, but I'd just as soon recommend reading The Good Parts. I'm not affiliated with Crockford or anything at all like that, quite simply just that The Good Parts is really that helpful.
  
  Honestly, I wouldn't sweat promises until you have a strong grasp of the callback model. They're important and very useful, no doubt. Its just that I've tried to introduce promises to a few colleagues whose understanding of the async callback model wasn't the strongest, and it really tripped them up. Once the callback model clicked for them, promises were a snap to pick up. YMMV.
  
  I can throw together some quick examples and descriptions for you, if you find that sort of thing helpful.
  
  (edit: formatting)

I've been using node for about a year now (was a PHP/mySQL dev for 6 years before that) and have come to realise that it's all about methodology. The language is just JS (I mean, you should get good at JS too) but it's how you use it that defines whether your node code will be good or not.

Some things I've found useful:

• JavaScript: The Good Parts If you're a JS developer, you just need to read this.
  
  
• Node Beginner Book Hands-on node is a little more rough around the edges but still worth a go. I bought the bundle for kindle and didn't regret it.
  
  My experience:
  
  
• Write everything in modules. Your index.js should be tiny. Ours just links URLs to modules.
  
  
• Try to make your modules reusable. We're (I'm) guilty of having my modules assume a http request, which means I'm ferrying the request and response objects around all over the place. It's not heinous, but it is bad.
  
  
• Put your modules in git
  
  
• Caching: Our stack is slightly unusual in that we've built a REST API in node which PHP then consumes to produce the HTML for the site, so end users never connect directly to node. (We have reasons for doing it this way). So we cache the API results based on URL in memcache. For a traditional web server model you'd probably use caching proxies in front of your node layer. I also cache database results based on the SQL string (I think we tested it to be faster than querycache. If not, why the hell aren't we just using querycache? Hmm...), so even if the API-level cache misses, some of the data will still be cached hopefully. Your caching strategy will depend heavily on the frequency of data changes in your application. A lot of our data never changes. We certainly don't have sub-minute changes, and typically our data changes exactly once in its lifetime.
  
  
• A good proportion of the stuff I write is utility modules (like pluribus) rather than business-logic specific to our website. I've written a HTTP router, a caching object (which abstracts the cache mechanism away so if we wanted to move away from memcache none of our code would have to change, we'd just plug in a new storage module to cachejs), a twitter module, and a connection-pooling module. Some of these problems were already solved in existing modules (and we use a lot of 3rd party modules too) but often you'll find that it's not quite right for your use-case, doesn't scale well, or the github isn't up to date with the latest node etc etc.
  
  
• Node is getting better all the time. We've thrown away a few things we'd written because the functionality is in core now. That's good.
  
  
• github is your friend. We end up forking a lot of modules and issuing pull requests to them. If they don't accept it's a shame because we then will have to keep our version up to date with their fixes. We prefer to fork, fix, pull req and then switch back to their version when accepted.
  
  
• architecture is the most important problem to solve. We use rackspace cloud hosting and they provide cloud load balancers which helps a lot. Beyond that, we make use of a consistent hashing module to spread memcache data and load evenly. But for any large application you'll quickly find that you can't just keep it all on one fat box, and you'll need to think the architecture out avoiding single points of failure.

Two ideas: first is on crafting code; the second, on fullstack.

Input from programming legends on practices for writing clean code, including evolving code and code smells as indicators that things are not right in the code.

Clean Code: A Handbook of Agile Software Craftsmanship

This nonsense book gets right into initial decisions, sample application features, and architecture diagrams. Clarity is a good thing (measure twice and cut once). Developing on AWS is awesome and you are entitled to a free account for one year while learning AWS: AWS Free Tier.

Full-Stack JavaScript Development: Develop, Test and Deploy with MongoDB, Express, Angular and Node on AWS

(sp and added info)

Clean Code is a good one :) The book where he goes into SOLID is the Agile PPP book . I believe he refers to Clean Code as a sort of prequel to Agile PPP.

It sounds like you’re doing pretty well and on the right track. CORS is an area where I’m not especially strong, tbh. I would probably put the api on an api.example.com subdomain, but that’s sheer personal preference.

I’ve spent so much time in .NET recently, it’s nice to jump into a JS discussion. Time well spent, in my mind.

Javascript can be a really tricky language to truly understand. It's known as the "most misunderstood language" for a reason, and that's because for the most part, developers have been fine with just knowing the basics and coming up with solutions using limited knowledge. Your difficulty with getting the ball rolling with Node is almost definitely due to a lacking understanding of the Prototype-based nature of Javascript, and all the unique characteristics of a language as a result of Prototypes. I also started Node with a Java (OOP) background, and ran into difficulties right away. Here's how I approached Javascript (and Node) and saw quick results (don't get me wrong, there's a lot of work involved, but you'll notice how much more sense the language makes to you rather quickly).

1. Learn the very basics of JS however you want. I'm assuming you know enough to use functions, loops, conditions, etc. all the basics. If not, I recommend the first 4 chapters of Eloquent Javascript.
   
2. Take Udacity's Object-Oriented JavaScript Course (free).
   
3. Buy and read the entire YDKJS Series. Don't just read through it, but annotate a lot. Even for smaller bits of code, make sure you understand why things work the way they do.
   
4. As you're reading YDKJS, start studying Node.JS libraries that interest you. Try to make sense of what the developer is doing and how everything works together.
   
5. Read, annotate, and practice with chapters 5 - 11 of Eloquent Javascript.
   
6. Read all the way through Node.JS Design Patterns.
   
7. Continue to study and extend libraries. You can find inspiration for projects by reading through, understanding, and experimenting with open source libraries (Github is your friend).
   
   This method turned me from your average Javascript kiddie to a solid JS wiz. Might work for you too.

You should start by learning Go, Erlang, Rust and C.

/trolololololololol

Seriously, though, if you're talking about cramming as many users as onto a single machine as possible then node is not your runtime.

Node is great at building things that scale horizontally. It makes it really easy to write realtime, event based code. Node is really good at doing things that involve a lot of network IO since it's easy to do that in a non-blocking way. It's not a great choice for a high scale game server where memory usage is key.

If you want to know more about horizontal scaling patterns (which Eve only qualifies for if you squint a bit), I'd recommend starting here:

http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X

And looking at distributed consensus approaches, message queues, and bumming around http://highscalability.com/ a bit.

IMO you should go beyond learning node.
Learn javascript (node is just javascript with core libraries).
Actually don't learn javascript, learn how to code.
Even more, learn how to learn.

I'm not the only one with this opinion: http://blog.codinghorror.com/please-dont-learn-to-code/

Also a side point: learn how to test. Testing (may it be unit, behaviour, …) is really important. It helps you code better, have a stronger code (less bugs, or more easily identifiables), more maintainable, and so on.

If you know the basis of code, and how to learn, not only you'll know node, but you'll potentially know php, ruby, scala, whatever.

I strongly encourage you to read:

• Clean Code: A Handbook of Agile Software Craftsmanship
  
• Design Patterns: Elements of Reusable Object-Oriented Software
  
• Test Driven Development: By Example
  
  Those books are references to a lot of developers and will teach you techniques that you'll be able to apply not only to node, but to the most of languages you'll ever encounter.

Not focused on Node.js, but the following helped me a lot:

• John Papa's Angular style guide
  
• Eric Elliott
  
• Javascript Patterns
  
• Javascript: The Good Parts (by Douglas Crockford)
  
  ​
  
  As already said, not so much focused on actual Node.js, but those helped me to have a better understanding on what was "under the hood", so applying what learned to Node was automatic.
  
  
  Edit: oh i forgot https://www.codingame.com/ to look at others people craziest things in JS :)

Practical Node.js is pretty good.

Heres the table of contents:

> Chapter 1: Setting up Node.js and Other Essentials
>
>Chapter 2: Using Express.js 4 to Create Node.js Web Apps
>
>Chapter 3: TDD and BDD for Node.js with Mocha
>
>Chapter 4: Template Engines: Jade and Handlebars
>
>Chapter 5: Persistence with MongoDB and Mongoskin
>
>Chapter 6: Using Sessions and OAuth to Authorize and Authenticate Users in Node.js Apps
>
>Chapter 7: Boosting Your Node.js Data with the Mongoose ORM Library
>
>Chapter 8: Building Node.js REST API Servers with Express.js and Hapi
>
>Chapter 9: Real-Time Apps with WebSocket, Socket.IO, and DerbyJS
>
>Chapter 10: Getting Node.js Apps Production Ready
>
>Chapter 11: Deploying Node.js Apps
>
>Chapter 12: Publishing Node.js Modules and Contributing to Open Source

It'll cover everything you will need to know to start building websites with node

I don't think there are any good books out there that are bound to node. There seem to be a few JS books worth noting but the only one I ever read was Javascript: The good Parts. It's a fine read but pure JS.

If you want to dig into nodejs just search for talk on youtube and begin to lurk in this sub. Sometimes you find great talks/reads that you'll adapt rather quickly.

The problem is that any book written will be outdated extremely fast.

I'd recommend a couple of things:

1. This repo has a great README and is my go-to for new projects: hackathon-starter
   
2. This book really helped me get a good handle on Node: Practical Node.js

I'd recommend node design patterns (http://www.amazon.com/Node-js-Design-Patterns-Mario-Casciaro/dp/1783287314) for reading on the subject.

In general I make everything a module - from the router to the endpoint logic to the database integration. Not a full on NPM module, unless I'm doing microservices, but each module will have its own tests and generally not be coupled to anything else except its dependencies - it should stand on its own within reason, because then it'll be more testable and maintainable. The module system in node works very nicely for this, since you can just export the "public" functions and hide the private ones much like classes in a traditional OO language.

Also important is if you're using large libraries to make wrapper modules. Even if I don't ever plan to move off of mongoDB for my database module as an example example, I still expose my own interfaces rather than the direct library ones so if I ever need to swap it out its a simple method of updating that module, not any of the calls to it. Refactoring module interfaces often is what gets you in more trouble, so that lets me keep my changes in one place.

The rest you can get through guides and reading... error handling and asynchronous flow control (parallel, series, combinations) are the biggest hurdles in node. I use just callbacks and async because I feel its a little easier to reason about, but promises and async/await work as well. Whatever you use stick with it. Always handle errors - an uncaught exception will take down your server. Expect it to happen even if your code is rock solid, and have a plan for spinning down gracefully (uncaught exception handlers - read recent articles there's a lot of bad older ones out there) and restarting the process (forever, pm2, other process managers).

I was impressed with the author of Effective Javascript (link) when I heard him on the js jabber podcast.

Start with statistics basics, like average, median, standard deviation. For resources I recommend Wikipedia and "The Manga Guide to Statistics"[1].

[1] http://www.amazon.com/Manga-Guide-Statistics-Shin-Takahashi/dp/1593271891/

If you own the data, go with RDBMS. Every time. DDDB's are useful when you want to store data from other systems that you don't really give a damn about (in terms of structure or content).

If I were you I'd do some book learning.

You need to come to a consensus on what constitutes a record in your system and use that to design a primary key. I think if you do some research into introductory DB concepts the rest will become obvious over time, FWIW.

There's a misconception that microservices are 'simple'. That's not always the case, they can be complex, efficent beasts, include caching, handle millions of concurrent requests, etc.

However, architecturally, as seen from the outside, microservices do one thing and do it well.

https://youtu.be/CZ3wIuvmHeM

https://martinfowler.com/articles/microservices.html

https://martinfowler.com/microservices/

First of all you have to ask yourself what your service will do. That will drive the architecture. Your question is like asking 'hey I wanna build an app, how should I architecture it'. It all depends the constraints on your problem.

There are some books on the topic that might help.

https://www.amazon.com/Building-Microservices-Designing-Fine-Grained-Systems/dp/1491950358

> But it is still a lot more complicated that just letting the computer handle multithreading for you like you would in Java, C#, python

Not at all. Java Concurrency In Practice is 384 pages long for a reason. The way Node does concurrency is way simpler than using threads with manual synchronization.

Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design (3rd Edition) https://www.amazon.com/dp/0321884493/

https://www.amazon.com/dp/B07ZBF9VQQ

Hello u/julias0, it appears you tried to put a link in a title, since most users cant click these I have placed it here for you

^I ^am ^a ^bot ^if ^you ^have ^any ^suggestions ^dm ^me

read this books,
Node.js moving to the server side by shelly powers



Node.js In Action

It is your choice to choose a a web framework to use

This is the same approach described in the Node.JS in action book (http://www.amazon.com/Node-js-Action-Mike-Cantelon/dp/1617290572)

Read this:

https://www.amazon.com/Pattern-Oriented-Software-Architecture-System-Patterns/dp/0471958697

It is a classic work that includes a description of MVC.


MVC, like REST, is more misunderstood than understood. Every UI framework seems to claim to be MVC, while meaning something different.

MVC is a pattern invented for programming graphical user interfaces, before the web existed.

The notion that you should use in organising domain logic, but not front end, user interface logic is perplexing.

It would seem he tweeted a link to a page that says "codes of conduct shouldn't apply to 'aspies' with ASDs" by a guy who wrote a book called "Mate: What Women Want", which, god help me, surprisingly doesn't seem to be the kind of redpill dogwhistle-filled sexist hate-tract I'd expected, despite the fact that the co-author is someone named "Tucker Max". (I mean, yes, it's about how to modify your behavior and acquire the sex, but it goes out of its way to say that the whole 'alpha male' thing isn't any kind of solution.) So, yeah, perhaps the article and the author fall on the "not a sexist jerk, but #1 with sexist jerks" side of the jerk-spectrum, but if it does, it's very very much in the realm of the fair center. But as with the Origin of Species, there are lots of scientific papers that end up getting used by dysfunctional assholes, and I'm not entirely convinced that Rod Vagg isn't a bullying dysfunctional asshole in private. Nor am I convinced that the Ayo.js folk are the kind of core technical folk that a project like Node needs at all.

If I have a point, it's that Rod might need to realize that just because you have a hard time being polite, that doesn't mean you have a right to impoliteness, and to the complainants, just because someone is impolite, it doesn't mean that their contribution is outweighed by the burden of dealing with them. The reason CoC's exist is so that everyone can point at a reference and say "I'm uncomfortable because I [had to hear|shouldn't have said] <the bad thing>." and then move on.