Because of the structure and API model of the Node.js platform, some patterns are more biased or natural. The most obvious are the event-driven and the event stream patterns. They're not enforced but strongly engrained in the core API, and you're forced to use it in some parts of your application, so it's better to know how they work individually, how they work together, and how you can benefit from them.

Using the core API, you can access the filesystem, for example, to read a file with a single method and a callback; or you can request a read stream and then check the data and end events or pipe the stream to somewhere else. This is very useful when, say, you don't want to look at the file and just want to serve it to a client. This architecture was designed to work for core modules such as http and net. Similarly, when listening for client connections, you'll have to listen for a connection event (unless you have defined a connection listener...

Your application won't be using only the core API. In a complex application, you will be using a lot of other modules, some made by you and others that you simply downloaded. Patterns exist everywhere in your application. When you use a module and you need to create a different interface, you would be using the adapter pattern, a structural pattern. If you need to extend the module you just downloaded with a couple of functionality methods, you can use the decorator pattern, another structural pattern. When the downloaded module might need some complex information to initialize, you may want to use the Factory pattern, a creational pattern. If your application evolves and this initialization needs more flexibility, you'll be using the Builder pattern, another creational pattern. If your application accesses relational data, you might have to use the Active Record pattern. If you use some kind of software framework, you might be using the MVC pattern.

Many developers...

Developing in Node.js is no different from other languages. You have some more or less native patterns, widely adopted and fully supported. One very common pattern is event-driven architecture. This pattern promotes production and consumption of events. This means that your code should be reactive to events instead of constantly trying to detect changes. Usually, many listeners can consume an event. There are some variations, such as having a way of stopping the event propagation or only allowing the first listener to consume the event, but normally all listeners will be able to consume all the events that they're listening to.

This pattern is very effective when you need to communicate inside your application in a one to many module of your code, as it gives you a very lose coupling. This is specifically interesting in service-oriented architecture (SOA) as it ensures your application components (your services) remain loosely coupled and can be upgraded over...

Using patterns improves your application, as you use well-proven and well-tested concepts that help developers to better understand and eventually improve your code. But improving your code doesn't end here. There is another type of pattern that varies from language to language, and we call it optimization.

An optimization is a pattern that is not specific to any problem but specific to a code structure. The idea is to change the code to be more efficient or to use less memory or other types of resources while doing the same thing. The goal of an optimization is not to get simpler code or to make it more readable. It can be bigger but still readable. Don't optimize for the sake of optimizing and reducing your code readability.

As Node.js uses the V8 engine as the language processor, we have to use V8-specific optimizations in the code. Some optimizations work across versions, others not so much and the effort of optimizing might be worthless. This is because V8 is...