In May, AWS announced the official launch of AWS Lambda support for the Node.js 10x runtime. While there were immediate concerns with the runtime, as detailed by Michael Hart at Bustle and others like Brian Leroux, the latest update appears to have solved many of the issues. Also announced in May, AWS Lambda has rolled out a new execution environment for AWS Lambda and the migration recently completed for all AWS Lambda functions on July 29th.

AWS Lambda is a service that confuses many people. For that reason, you may be wondering just how it works, and how you’d use it to build a highly scalable event-driven application. As someone who’s presumably no stranger to the internet, you must have seen the terms serverless, function-as-a-service, or AWS Lambda thrown across your screen a few times. Perhaps you’re looking to learn more. If so, you’re in luck.

The Node 10 release and the retiring of the Node 6 runtime created a debate around what you can expect from runtimes and from AWS. With that, came some criticism about AWS Lambda being too slow in adopting the Node LTS long-term support releases. However, shortly after the release, a bug was found in the Node 10 initial runtime which raised a question – should we give things a little bit of time to settle before rushing in and adopting them?

AWS has officially released the support for Node.js 10.x runtime in their AWS Lambda service. The Node.js 10.x runtime is available in all regions where Lambda is available. Node.js 10 (AKA “Dubnium”) is the official LTS version.

Making Node.js applications quick and sturdy is a tricky task to get right. Nailing the performance just right with the V8 engine Node.js is built on is not at all as simple as one would think. JavaScript is a dynamically typed language, where you let the interpreter assign types to variables. If you’re not careful this can lead to memory leaks.

What is the most important feature your Node.js application can have? Do you think it’s having fancy fuzzy logic for your full-text search, or maybe using sockets for real-time chats? You tell me. What’s the fanciest, most amazing and sexy feature you can add to your Node.js application?

Node.js monitoring is a tricky task. There are certain challenges to look out for. Because Node.js is a dynamically typed programming language and single-threaded you give the interpreter and runtime a lot of freedom to make decisions. This can easily result in memory leaks and high CPU loads. Parallel execution is simulated in Node.js by using asynchronous execution of functions. But, if a single function blocks the thread or event queue, the application performance will take a huge hit.

In the last decade, Node.js has rapidly risen in popularity as a server-side programming language. With that popularity, we’ve seen no shortage of frameworks aiming to make developers’ lives easier. Although they are lesser-known than other Node.js frameworks, Hapi, Sails, and Restify are a few options that have a lot to offer.

Debugging memory leaks is rarely a piece of cake, especially when they only happen in production. The best way I’ve found to debug memory leaks in a Node.js application on Heroku is to analyze heap dumps. Obtaining such heap dumps in production can be challenging, as it might be hard to connect remotely to a production instance with the debugger.

The increasing numbers of business are switching to e-commerce business to sell their products. As of now, there are more than 7,500,000 online stores operating around the world. Naturally, every online retailer is always in the lookout for the best possible ways to outlive their competition. E-commerce businesses cannot compromise on the performance, speed, usability, and scalability of their websites and this is why they need to choose the appropriate technologies diligently.