Looking to gracefully shutdown your Nodejs HTTP server? Well, it's actually a little more difficult than you think. Without handling process signals, like "ctrl-c", your application terminates immediately. Which means, there may be requests still processing that you terminated before completion. In a live environment, this is a horrible user experience. Unfortunately, even if you did catch the process' signals, Node doesn't actually have a built in mechanism for gracefully shutting down a running HTTP server.

The singleton is an anti-pattern. Out of all of the object-oriented patterns, the singleton pattern is one of the most widely bastardized and misused. It secretly undermines good choices in application design and introduces global state into an application which tends to bring about unnecessary restrictions. Nine out of ten times the singleton pattern is either implemented wrong, used incorrectly, or just completely unnecessary. The remaining one out of ten it might be appropriate - but I doubt it, and you should to.

It's really tough to develop well written code. Luckily, object-oriented developers have been gifted a series of programming patterns to make their job easier. These patterns are a set of proven techniques that promote proper code reuse as well as application design. And, while there are many patterns to draw from, few are more beneficial than the decorator pattern.

Basic authentication is an extremely popular means of authentication due to it's simplicity and ease at which it can be implemented. Unfortunately, over HTTP, it's also the absolute worst way you could have your clients authenticate! Basic authentication utilizes the Authentication HTTP header to transmit the clients username and password credentials. The client simply takes the given username and password, base64 encodes them both, and inserts them into the HTTP header when making a request to a server.

Immutability is often a subject that is not commonly understood in newer developers (or even older ones for that matter). The pros and cons of creating immutable objects are often not considered when coding which, for the most part, doesn't cause any initial concern. However, when a program reaches a certain complexity developers inevitably make mistakes. This is compounded when there is more than one member working on a programming project. Creating immutable structures is a powerful paradigm in defensive programming, especially when it comes to the common practice of using static lists!