The ecosystem around making requests in Node.js applications is huge. With countless libraries available, it can be helpful to understand why they exist. This helps to improve your understanding of Node.js as a whole, and makes choosing an HTTP client easier. In the first post in this series, we looked at creating servers using Node's http module. In this post, we will explore making a request using the http.request method and handling the response.

Using Node.js on the web generally involves a server framework, like Express, Hapi, or Koa. These make working with the underlying HTTP support easier. Sometimes you need the full power of a framework, but in other cases that can be overkill. In this article, we'll ignore the benefits of a framework and look at the underlying features of Node's HTTP module and how you can use it to create a web server. In future articles, we'll examine other features of the HTTP module.

The SLAppForge Debugger NodeJS is a toolkit that can be utilized to perform step-through debugging for the Lambda functions executing on live AWS environment, using your own local IDE.

When you interact with a REST API, are you making calls directly or are you using a client from the API provider? Many APIs now provide clients, wrappers, or SDKs. These terms all mean the same thing in this context. What happens if the API you are using doesn't offer a client? Do you even need one? Is there any benefit? In this article, we will explore some of the reasons you may want to build one.

Out of the box, Node.js offers the http library for making requests, but it isn't particularly user friendly and requires some customization before it can be easily used. As a result, a large ecosystem of third-party libraries have emerged to make AJAX and HTTP requests easier. Some offer cross-platform (browser and Node.js) support, while others focus on bundle size or developer experience. With some many options, how do you choose?

Javascript's built in Error provides useful information, but can often feel lacking in clarity. One-size-fits-all is great for the language, but we can do better in our own apps. That's where custom errors come in.

Welcome to Part 2 in our series on building your own circuit breaker in Node.js. In Part 1, Building a Circuit Breaker in Node.js, we built a starter version that handles the core states of a circuit breaker. In this article, we will add configurability, manual overrides, and fallback request support. You can find the complete code for each example here.

Circuit breakers were originally designed to protect electrical circuits from damage. Software development has adopted the concept as a type of resiliency pattern and it can now be found commonly in the cloud-native and microservices stacks. They can also be valuable in any codebase that needs to offer more flexibility, especially when relying on third-party APIs. Welcome to Part 1 of this two part series on building a circuit breaker in Node.js.

Have you ever been building an application and thought: "I can make requests to this service's API, but is there a way for them to let my app know when X happens? You could try calling the API on a set interval. Take the response, compare it to the last, and go from there. This is polling, but it is inefficient and can be an easy way to hit rate limits. Instead, some APIs and services offer what's known as a webhook. Instead of contacting them, they contact you.