Node.js is an open-source, cross-platform runtime environment that runs on the V8 JavaScript engine. It is designed to build scalable network applications. Node.js is event-driven and non-blocking, which makes it efficient at handling concurrent requests. Node.js is a popular choice for building real-time web applications, such as chat applications and streaming applications. It is also used for building server-side applications, such as web APIs and microservices.

Here are some of the key features of Node.js:

• Event-driven: Node.js is event-driven, which means that it only executes code when an event occurs. This makes it efficient at handling concurrent requests.
• Non-blocking: Node.js is non-blocking, which means that it does not block the main thread when it is waiting for an event to occur. This makes it efficient at handling concurrent requests.
• Cross-platform: Node.js is cross-platform, which means that it can run on Windows, macOS, and Linux.
• Asynchronous: Node.js is asynchronous, which means that it can handle multiple requests at the same time.
• Scalable: Node.js is scalable, which means that it can be easily scaled to handle more requests.

What are the top use cases of Node.js?

Node.js is a popular runtime environment that is used for a wide variety of applications.

Here are some of the top use cases of Node.js:

• Real-time web applications: Node.js is a popular choice for building real-time web applications, such as chat applications and streaming applications. This is because Node.js is event-driven and non-blocking, which makes it efficient at handling concurrent requests.
• Server-side applications: Node.js is also used for building server-side applications, such as web APIs and microservices. This is because Node.js is asynchronous, which means that it can handle multiple requests at the same time.
• IoT applications: Node.js is used for building IoT applications, as it can be used to handle the high volume of data that is generated by IoT devices.
• Content management systems: Node.js is used for building content management systems (CMSs), such as WordPress and Drupal. This is because Node.js is scalable and can handle a large number of users.
• E-commerce: Node.js is used for building e-commerce websites, as it can handle the high volume of traffic that is generated by e-commerce websites.
• Logistics: Node.js is used for building logistics applications, such as tracking shipments and managing inventory levels. This is because Node.js is scalable and can handle a large number of transactions.
• Financial: Node.js is used for building financial applications, such as trading platforms and risk management systems. This is because Node.js is scalable and can handle a large number of transactions.
• Healthcare: Node.js is used for building healthcare applications, such as electronic medical records (EMRs) and patient portals. This is because Node.js is scalable and can handle a large number of users.

What are the features of Node.js?

Node.js is a popular runtime environment that is used for a wide variety of applications.

Here are some of the key features of Node.js:

• Event-driven: Node.js is event-driven, which means that it only executes code when an event occurs. This makes it efficient at handling concurrent requests.
• Non-blocking: Node.js is non-blocking, which means that it does not block the main thread when it is waiting for an event to occur. This makes it efficient at handling concurrent requests.
• Cross-platform: Node.js is cross-platform, which means that it can run on Windows, macOS, and Linux.
• Asynchronous: Node.js is asynchronous, which means that it can handle multiple requests at the same time.
• Scalable: Node.js is scalable, which means that it can be easily scaled to handle more requests.
• JavaScript: Node.js is based on JavaScript, which is a popular programming language that is easy to learn and use.
• Ecosystem: Node.js has a large and active ecosystem, which means that there are a wide variety of modules and libraries available for Node.js.

What is the workflow of Node.js?

Here are some additional details about each step:

• Creating a project: The first step is to create a project. This can be done by creating a new directory and initializing it with the npm init command. The npm init command will prompt you to enter a few basic details about your project, such as the name of the project and the version number.
• Installing dependencies: The next step is to install the dependencies for your project. This can be done by running the npm install command. The npm install command will install the dependencies that are listed in the package.json file.
• Writing code: The next step is to write the code for your project. This code will be executed by the Node.js runtime environment. The Node.js runtime environment is a JavaScript engine that is designed to execute JavaScript code on the server.
• Running the code: The code can be run by executing the node command. The node command will execute the JavaScript code that is contained in the file.
• Testing the code: The code can be tested by using a variety of testing frameworks, such as Mocha and Chai. Testing frameworks are used to automate the testing of code.
• Deploying the code: The code can be deployed to a production environment by using a variety of deployment methods, such as Heroku and Amazon Web Services (AWS). Deployment is the process of making the code available to users.

How Node.js Works & Architecture?

Node.js is an open-source, cross-platform runtime environment that runs on the V8 JavaScript engine. It is designed to build scalable network applications. Node.js is event-driven and non-blocking, which makes it efficient at handling concurrent requests. Node.js works by using a single-threaded event loop to handle all of the requests that are made to the server. The event loop is responsible for calling the appropriate callbacks when events occur. Events can be triggered by a variety of things, such as HTTP requests, file system changes, and timer events.

The Node.js architecture is divided into two main parts: the event loop and the modules. The event loop is responsible for handling all of the requests that are made to the server. The modules are responsible for providing functionality to the Node.js runtime environment. The event loop is a critical part of the Node.js architecture. It is responsible for making sure that all of the requests that are made to the server are handled in a timely manner. The event loop is also responsible for making sure that the Node.js runtime environment is not blocked by anyone’s request.

The modules are a key part of the Node.js architecture. They provide functionality to the Node.js runtime environment, such as HTTP request handling, file system access, and database access. The modules are written in JavaScript and can be installed using the npm package manager.

Node.js is a powerful and versatile platform that is used for a wide variety of applications. It is a good choice for applications that require scalability, efficiency, and versatility.

Here are some of the key features of the Node.js architecture:

• Single-threaded event loop: The Node.js event loop is a single-threaded event loop. This means that only one request can be processed at a time. However, the event loop is non-blocking, which means that it can handle multiple requests in parallel.
• Modules: Node.js modules are a key part of the architecture. They provide functionality to the Node.js runtime environment, such as HTTP request handling, file system access, and database access.
• JavaScript: Node.js is based on JavaScript. This makes it easy to learn and use, and there is a large and active community of JavaScript developers.

How to Install and Configure Node.js?

Here are the steps on how to install and configure Node.js:

• Download the Node.js installer. You can download the Node.js installer from the official Node.js website.
• Install the Node.js installer. The installation process will vary depending on your operating system.
• Configure the Node.js environment variables. You will need to configure the Node.js environment variables so that you can run Node.js applications from the command line.
• Verify the installation. You can verify the installation by running the node -v command.

Node.js provides a robust server environment for companies to develop web apps swiftly and securely. In a world where taking quick decisions and actions is the key to achieving success in business, Node.js proves to be an excellent platform for developing enterprise applications

Key points of Node.js as a Platform

Node.js is an open-source platform which can essentially run JavaScript codes outside a web browser. With developers writing command-line tools which then run server-side scripts, Node.js can efficiently produce dynamic web page content even before the page reaches the user’s web browser.

Using asynchronous programming and implementing push technology over web sockets in the real-time web applications, Node.js has been able to transform the process of web & request-response. Now, the server and clients can freely communicate and exchange data and enjoy an unrestrictive two-way connection. Developers can share the same piece of coding with the client and server side through Node.js’ asynchronous programming.

According to a survey held back in 2019, Node.js was deemed as the most popular platform among developers in the category of “Frameworks, Libraries, and Tools”. According to a user survey held for Node.js users, more than 40% of Node.js programmers use this platform to develop enterprise apps. A majority of developers of this percentage were surprisingly working for Fortune 500 companies. With numerous companies claiming that Node.js increases developer productivity, the number of downloads of this platform is steadily increasing by a whopping 40% every year.

Benefits of Node.js

Before delving into the detailed reasons as to why enterprises should hire a Node.Js/ React.Js Development Company for their next app project, let us look at some quick benefits of using Node.js as a platform:

• The Node.js platform facilitates quick development of applications.
• It is fast in executing codes in other languages.
• It is highly efficient when it comes to bridging the gap between frontend development and backend development. 
• It provides LTS or long-term support. 
• It allows developers to reuse application codes and build cross-platform desktop apps.
• It is ideal for microservices in companies which are essentially breaking up the application into smaller parts and then scaling and deploying them individually.

5 main reasons why enterprises should consider Node.js as their app development platform

Node.js provides you with several benefits to prove its case as one of the best platforms for enterprise app development. Here are five top reasons as to why you should consider Node.js for developing speedy and efficient enterprise applications:

• Node.js allows cross-platform app development.

One of the main reasons why companies time and again comes back to Node.js as their preferred platform of app development is due to its ability to build cross-platform desktop apps. Node.js allows users to use platforms such as Electron and NW.js, and make desktop apps that work with any kind of operating system.

Developers, who might not be skilled in languages such as Objective-C, Swift, Java that are used to build native apps, can still create web and desktop apps with the help of Node.js. These developers can reuse their codes from their web applications and implement it on desktop applications which have compatibility with Windows, Linux, and macOS.

Node.js dismisses the need for a Mac machine to build macOS applications or Windows machine for building Window apps with its developer tools. Every significant developer tool which is related to Node is cross-platform. Moreover, Node.js allows its users to get exclusive access to Google Chrome Developer Tools which ultimately gives them all the necessary equipment to debug efficiently and provide better desktop versions of the application. 

• It does not have a steep learning curve.

Node.js is very easy to learn and master. Without a steep learning curve, developers can easily understand the workings of this platform. Furthermore, developers who were using a different platform earlier can easily shift to this platform without particularly extensive knowledge about it. The platform allows developers to use JavaScript to build web applications which is convenient and easy to learn.

With Node.js as the base, developers can easily build scalable applications that work on both Windows and Unix. Enterprises usually turn towards Node.js as their app development platform due to the ease and convenience of finding developers, or app development companies that provide high-quality professionals, adept in developing through Node.js.

• Node.js provides high-quality performance.

The platform is essentially based on V8 runtime of Google Chrome which is written in C++ and which overall, acts as a major advantage for the programmers. They can build applications which are compatible with several operating systems at a time without necessarily re-coding for every new OS. Moreover, both the Node.js platform as well as Google’s V* receive regular updates for utmost optimization of their performances. 

Node.js can easily manage multiple server connections simultaneously due to its single-thread architecture. Thus, the platform will not create any additional threads for each new request that it gets. This not only makes the app operate faster but also prevents excessive usage of RAM.

• The platform is known to provide LTS or Long-Term Support.

The Node.js platform provides its users with a long-term support feature which, according to a survey held in 2018, more than 60% of developers deems to be important. With the IT world’s fickle nature and dynamic changes, it is not a surprise to see technologies falling apart before they could even offer LTS. Node.js is equipped to counter this trend and provides its users with consistency with its support and updates.

• Node.js provides an NPM or Node Package Manager.

For enterprises who are dwelling over the privacy and security concerns over their app development platform, the Node.js platform provides an enterprise version of its Npm. Npm offers a range of benefits to the users. From installing and using small modules to identifying and replacing unsafe code, the enterprise version of npm can improve the developmental process of enterprise apps to great extent. This feature by Node.js was widely acclaimed by developers worldwide and is still growing in terms of its operations and abilities.

While these were only five reasons, Node.js provides several reasons for companies to consider developing their apps on this platform. Node.js facilitates seamless development of apps without adding any kind of complexities. With its fast-paced V8 engines and single code base, Node.js consists of all the prerequisites necessary for developing and deploying comprehensive enterprise apps.

Author Bio:

James Grills is a marketing advisor – currently associated with Cumulations Technologies, a Flutter App Development company. He is a technical writer with a passion for writing on emerging technologies in the areas of mobile application development and IoT technology.

The Evolution from On-Premise to Cloud

Mobile app development teams have not always had the luxury of elastic, remotely hosted infrastructure. Before cloud platforms matured, the standard approach was On-Premise: every server, storage array, and development tool lived in the same physical building as the engineering team. That model created predictable headaches — limited physical space, large upfront capital expenditure, complex licensing, and slow provisioning cycles that blocked development velocity.

The emergence of cloud computing introduced three foundational service models that progressively transferred infrastructure responsibility away from in-house IT teams:

• Infrastructure-as-a-Service (IaaS) — virtualised compute, networking, and storage delivered on demand.
• Software-as-a-Service (SaaS) — fully managed software applications delivered over the internet.
• Platform-as-a-Service (PaaS) — a managed environment that provides the runtime, middleware, development tools, and services a team needs to build, test, and deploy applications without managing the underlying infrastructure.

Each model sits at a different level of the stack, and choosing the right one depends on how much control versus convenience a team needs.

SaaS vs. PaaS: What Changed and Why

SaaS was the first widely adopted cloud model for many organisations. It replaced on-premise software licences with subscription-based, browser-accessible applications — think email, CRM, or collaboration tools. For end users this was transformative, but for development teams building custom mobile applications, SaaS alone was not enough. Developers needed a managed environment where they could write, test, and ship code, not just consume finished products.

PaaS filled that gap. Rather than purchasing and maintaining servers, configuring runtime environments, or negotiating separate tool licences, a development team can provision a PaaS environment and immediately start writing application logic. Key practical advantages PaaS offers over SaaS for mobile development teams include:

• Richer feature set — databases, messaging queues, authentication services, and CI/CD pipelines are available as managed add-ons.
• Reduced operational budget — infrastructure management overhead shifts to the cloud provider.
• Faster time to launch — pre-configured environments eliminate lengthy setup phases.
• Elastic scaling — storage, compute, and bandwidth can be adjusted as the application grows or shrinks.
• Location independence — resources are delivered from data centres irrespective of where the development team sits.

Mobile PaaS: Handling the Heavy Lifting

Mobile app development carries unique complexity compared with traditional web development. A single application may need to run correctly across multiple operating systems (iOS, Android, and various vendor-specific environments), screen sizes, hardware capabilities, and network conditions. That cross-platform burden can consume engineering attention that should be focused on product features rather than environment configuration.

Mobile PaaS (sometimes abbreviated mPaaS) addresses this by providing a managed backend and toolchain specifically optimised for mobile development workflows. The platform abstracts away infrastructure concerns so developers can focus on application logic and user experience.

Multi-Language and Framework Support

A well-configured PaaS environment supports a range of programming languages and frameworks out of the box — commonly including Python, Node.js, Java, and C# — along with popular frontend frameworks and UI toolkits. Development teams can select the language stack that matches their skills and project requirements, then provision the required runtime without manually installing or patching dependencies on physical machines.

Integrated Development Environment (IDE) Capabilities

Many PaaS offerings include or integrate tightly with cloud-hosted IDEs. This means the full development loop — writing code, debugging, running automated tests, and deploying to a staging or production environment — can happen within a single, consistent toolchain. The alternative — context-switching between local IDEs, separate test environments, and manual deployment scripts — introduces friction and increases the chance of environment-specific bugs surfacing only after release.

A cloud IDE also makes it straightforward to spin up sandbox environments for experimenting with new features or architectural approaches without disrupting the main development branch.

Security in a PaaS Model

Security for mobile applications is not limited to the application layer itself. Data in transit between the app and the backend, data at rest on servers, and access control across a distributed team all need to be managed. PaaS platforms typically provide several security capabilities as managed services:

• Centralised authentication — identity providers and OAuth flows managed by the platform, reducing the risk of custom-built authentication mistakes.
• Role-based access control (RBAC) — fine-grained permission assignment so developers, testers, and automated pipelines only access what they need.
• Single sign-on (SSO) — consistent identity management across services.
• Data encryption — encryption at rest and in transit handled by the platform, with key management often delegated to managed key stores.
• Backup and recovery — automated snapshots and point-in-time recovery reduce data loss risk without requiring a dedicated database administrator.

These capabilities allow smaller teams to maintain a security posture that would otherwise require dedicated security engineering resources.

Pay-As-You-Go (PAYG) Pricing Model

Traditional on-premise infrastructure required organisations to provision for peak load, which meant paying for capacity that sat idle during normal operation. PaaS platforms overwhelmingly use a consumption-based or pay-as-you-go pricing model, which aligns costs with actual usage.

For mobile app development specifically, PAYG pricing means:

• Server capacity can be scaled up ahead of a feature release or marketing campaign, then scaled back down afterwards.
• Storage can grow incrementally as the user base grows rather than being purchased in large fixed blocks.
• Teams are not locked into long-term hardware depreciation cycles.
• Licensing costs for middleware, databases, and tools are folded into a single cloud bill rather than managed as separate vendor contracts.

This model removes a significant administrative burden from development teams and gives finance teams more predictable, usage-correlated expenditure.

Choosing the Right Cloud Model for Your Mobile Project

IaaS, SaaS, and PaaS are not mutually exclusive. Many production mobile applications use PaaS for the application runtime and development toolchain, IaaS for specialised compute workloads (such as video transcoding or machine learning inference), and SaaS tools for project management, monitoring, or customer support. The key is understanding what each model manages on your behalf versus what your team retains responsibility for:

For most mobile app development teams, PaaS strikes the best balance: it eliminates low-value infrastructure management while preserving full control over application code and data design. Teams that need more control over OS-level configuration may lean toward IaaS; teams that only need pre-built tools without custom development can rely on SaaS.

Key Takeaways

• On-Premise infrastructure created space, cost, and licensing constraints that slowed mobile development teams.
• IaaS, SaaS, and PaaS each abstract a different layer of the stack, trading control for managed convenience.
• PaaS is particularly well-suited to mobile app development because it provides language runtimes, IDEs, security services, and elastic scaling without requiring teams to manage underlying infrastructure.
• Pay-as-you-go pricing aligns cloud spend with actual usage, removing the over-provisioning problem inherent in on-premise models.
• Security capabilities — authentication, RBAC, encryption, backup — are available as managed platform services on most PaaS offerings.

Full-text search can be both scary and exciting. Some popular databases such as MySql and Postgres are an amazing solution for storing data… but when it comes to full-text search performances, there’s no competition with ElasticSearch.

For those who don’t know, ElasticSearch is a search engine server built on top of Lucene with an amazing distributed-architecture support. According to db-engines.com, it is currently the most used search engine out there.

In this post, we are going to build a simple REST application called The Quotes Database which will allow us to store and search as many quotes as we want.

I’ve prepared a JSON file containing 5000+ quotes with their authors, we’ll be using it as our starting data for populating ElasticSearch.

Setting up Docker

First of all, we don’t want to install ElasticSearch on our machine. We’ll be using Docker for orchestrating both the Node.js server and the ES instance on a container, which will allow us to deploy a production-ready application with all the dependencies that it needs.

Let’s create a Dockerfile inside our project root folder:

FROM node:10.15.3-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install
RUN npm install -g pm2

COPY . ./

EXPOSE 3000
EXPOSE 9200

CMD npm run start

As you can see, we’re telling Docker that we’ll run a Node.js 10.15.3-alpine runtime. We’ll also create a new working directory under /usr/src/app, where we’ll copy both the package.json and the package-lock.json files. That way, Docker will be able to run npm install inside our WORKDIR, installing our needed dependencies.

We’ll also install PM2 by running RUN npm install -g pm2. The Node.js runtime is single-threaded, so if a process crashes, the entire app needs to be restarted… PM2 checks the Node.js process status and restarts it when the app goes down for any reason.

After installing PM2, we’ll copy our codebase inside our WORKDIR (COPY . ./), and we tell Docker to expose two ports, 3000, which will expose our RESTful service, and 9200, which exposes the ElasticSearch service (EXPOSE 3000 and EXPOSE 9200).

Last but not least, we tell Docker which command will start the Node.js app with npm run start.

Setting up docker-compose

Now you may be saying, ‘Great, I get it! But how do I handle the ElasticSearch instance inside Docker? I can’t find it in my Dockerfile!’… you’re right! That’s where docker-compose becomes useful. It allows us to orchestrate multiple Docker containers and to create a connection between them. So, let’s write down the docker-compose.yml file, which will be stored inside our project root directory:

version: '3.6'
services:
  api:
    image: node:10.15.3-alpine
    container_name: tqd-node
    build: .
    ports:
      - 3000:3000
    environment:
     - NODE_ENV=local
     - ES_HOST=elasticsearch
     - NODE_PORT=3000
     - ELASTIC_URL=http://elasticsearch:9200
    volumes:
      - .:/usr/src/app/quotes
    command: npm run start
    links:
        - elasticsearch
    depends_on:
        - elasticsearch
    networks: 
      - esnet
  elasticsearch:
    container_name: tqd-elasticsearch
    image: docker.elastic.co/elasticsearch/elasticsearch:7.0.1
    volumes:
      - esdata:/usr/share/elasticsearch/data
    environment:
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - discovery.type=single-node
    logging:
      driver: none
    ports:
      - 9300:9300
      - 9200:9200
    networks: 
      - esnet
volumes:
  esdata:
networks:
  esnet:

This is a bit more complex than our Dockerfile, but let’s analyze it:

• We declare which version of docker-compose.yml file we’re using (3.6)
• We declare our services:
  • api, which is our Node.js app. Just like in our Dockerfile, it requires the node:10.15.3-alpine image. We also assign a name to this container tqd-node, and here we call the previously created Dockerfile using the build . command.
  • We need to expose the 3000 port so we write these statements as follows 3000:3000. It means that we’re mapping from the port 3000 (inside our container) to the port 3000 (accessible from our machine). Then we’ll set some environment variables. The value elasticsearch is a variable which refers to the elasticsearch service inside our docker-compose.yml file.
  • We also want to mount a volume /usr/src/app/quotes. That way, once we restart our container we’ll maintain our data without losing it.
  • Once more, we tell Docker which command we need to execute once the container starts up, then we set a link to the elasticsearch service. We also tell Docker to start the api service after the elasticsearch service has booted (using the depends_on directive).
  • Last but not least, we tell Docker to connect the api service under the esnet network. That’s because every container has its own network. That way, we say that api and elasticsearch services shares the same network so they will be able to call each other with the same ports.
  • elasticsearch, which is (as you may have guessed) our ES service. It’s configuration is pretty similar to the api service. We’ll just cut off its verbose logs setting the logging directive to driver: none .
• We also declare our volumes, where we store the ES data.
• And we declare our network, esnet.

Bootstrapping the Node.js app

Now we need to create our Node.js application, so let’s get started setting up our package.json file:

npm init -y

Now we need to install some dependencies:

npm i -s @elastic/elasticsearch body-parser cors dotenv express

Great! Our package.json file should look like this:

{
  "name": "nodejselastic",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@elastic/elasticsearch": "^7.3.0",
    "body-parser": "^1.19.0",
    "cors": "^2.8.5",
    "dotenv": "^8.0.0",
    "express": "^4.17.1"
  }
}

Let’s implement our ElasticSearch connector in Node.js. First, we need to create a new /src/elastic.js file:

const { Client } = require("@elastic/elasticsearch");
                   require("dotenv").config();

const elasticUrl = process.env.ELASTIC_URL || "http://localhost:9200";
const esclient   = new Client({ node: elasticUrl });
const index      = "quotes";
const type       = "quotes";

As you can see, here we set some constants that will be incredibly useful. First of all, we create a new connection to ElasticSearch using its official Node.js SDK, then we define an index ("quotes") and an index type("quotes" again, we’ll see later what they mean).

Now we need to create an index on ElasticSearch. You can think of “indexes” as a SQL “database” equivalent. ElasticSearch is a NoSQL database, which means that it has no tables — it just stores JSON documents. An index is a logical namespace which maps to one or more primary shards and can have zero or more replica shards. You can read more about ElasticSearch indexes here.

Let’s now define a function that will create our index:

async function createIndex(index) { 
  try {
    await esclient.indices.create({ index });
    console.log(`Created index ${index}`);
  } catch (err) {
    console.error(`An error occurred while creating the index ${index}:`);
    console.error(err);
  }
}

Now we need another function that creates the mapping for our quotes. The mapping defines the schema and types of our document:

async function setQuotesMapping () {
  try {
    const schema = {
      quote: {
        type: "text" 
      },
      author: {
        type: "text"
      }
    };

    await esclient.indices.putMapping({ 
      index, 
      type,
      include_type_name: true,
      body: { 
        properties: schema 
      } 
    })

    console.log("Quotes mapping created successfully");
  } catch (err) {
    console.error("An error occurred while setting the quotes mapping:");
    console.error(err);
  }
}

As you can see, we’re defining the schema for our documents, and we’re inserting it inside our index.

Now let’s consider that ElasticSearch is a huge system and can take some seconds to boot up. We can’t connect to ES until it is ready, so we need a function that checks when the ES server is ready:

function checkConnection() {
  return new Promise(async (resolve) => {
    console.log("Checking connection to ElasticSearch...");
    let isConnected = false;
    while (!isConnected) {
      try {
        await esclient.cluster.health({});
        console.log("Successfully connected to ElasticSearch");
        isConnected = true;
      // eslint-disable-next-line no-empty
      } catch (_) {
      }
    }
    resolve(true);
  });
}

As you can see, we’re returning a promise. That’s because by using async/await we’re able to stop the entire Node.js process until this promise resolves, and it won’t do it until it connects to ES. That way, we force our Node.js to wait for ES before booting up.

We’re done with ElasticSearch! Now let’s export our functions:

module.exports = {
  esclient,
  setQuotesMapping,
  checkConnection,
  createIndex,
  index,
  type
};

Great! Let’s see the entire elastic.js file:

const { Client } = require("@elastic/elasticsearch");
                   require("dotenv").config();
const elasticUrl = process.env.ELASTIC_URL || "http://localhost:9200";
const esclient   = new Client({ node: elasticUrl });
const index      = "quotes";
const type       = "quotes";
/**
 * @function createIndex
 * @returns {void}
 * @description Creates an index in ElasticSearch.
 */
async function createIndex(index) {
  try {
    await esclient.indices.create({ index });
    console.log(`Created index ${index}`);
  } catch (err) {
    console.error(`An error occurred while creating the index ${index}:`);
    console.error(err);
  }
}
/**
 * @function setQuotesMapping,
 * @returns {void}
 * @description Sets the quotes mapping to the database.
 */
async function setQuotesMapping () {
  try {
    const schema = {
      quote: {
        type: "text" 
      },
      author: {
        type: "text"
      }
    };
  
    await esclient.indices.putMapping({ 
      index, 
      type,
      include_type_name: true,
      body: { 
        properties: schema 
      } 
    })
    
    console.log("Quotes mapping created successfully");
  
  } catch (err) {
    console.error("An error occurred while setting the quotes mapping:");
    console.error(err);
  }
}
/**
 * @function checkConnection
 * @returns {Promise<Boolean>}
 * @description Checks if the client is connected to ElasticSearch
 */
function checkConnection() {
  return new Promise(async (resolve) => {
    console.log("Checking connection to ElasticSearch...");
    let isConnected = false;
    while (!isConnected) {
      try {
        await esclient.cluster.health({});
        console.log("Successfully connected to ElasticSearch");
        isConnected = true;
      // eslint-disable-next-line no-empty
      } catch (_) {
      }
    }
    resolve(true);
  });
}
module.exports = {
  esclient,
  setQuotesMapping,
  checkConnection,
  createIndex,
  index,
  type
};

Populating ElasticSearch with quotes

Now we need to populate our ES instance with our quotes. This may sound easy, but believe me, it can be tricky.

Let’s create a new file in /src/data/index.js:

const elastic = require("../elastic");
const quotes  = require("./quotes.json");

const esAction = {
  index: {
    _index: elastic.index,
    _type: elastic.type
  }
};

As you can see, we’re importing the elastic module we just created and our quotes from a JSON file stored in /src/data/quotes.json. We’re also creating an object called esAction, which will tell ES how to index a document once we insert it.

Now we need a script to populate our database. We also need to create an array of Object with the following structure:

[
  {
    index: {
      _index: elastic.index,
      _type:  elastic.type
    }
  },
  {
    author: "quote author",
    quote:  "quote"
  },
  ...
]

As you can see, for each quote we’re gonna insert, we need to set its mapping to ElasticSearch. So that’s what we’ll do:

async function populateDatabase() {
  const docs = [];
  for (const quote of quotes) {
    docs.push(esAction);
    docs.push(quote);
  }
  return elastic.esclient.bulk({ body: docs });
}

Great! Now let’s create our main file in /src/main.js and see how we’ll structure everything we’ve written so far:

const elastic = require("./elastic");
const data    = require("./data");
                require("dotenv").config();

(async function main() {

  const isElasticReady = await elastic.checkConnection();
  if (isElasticReady) {
    const elasticIndex = await elastic.esclient.indices.exists({index: elastic.index});

    if (!elasticIndex.body) {
      await elastic.createIndex(elastic.index);
      await elastic.setQuotesMapping();
      await data.populateDatabase()
    }
  }

})();

Let’s analyze the code above. We create a self-executing main function which will check for the ES connection. The code execution won’t proceed until ES is connected. When ES is ready, we’ll check if the quotes index exists. If it doesn’t, we’ll create it, we’ll set its mapping and will populate the database. Obviously, we’ll do so only the first time we start up our server!

Creating a RESTful API

Now we need to create our RESTful server. We’ll be using Express.js, which is the most popular Node.js framework out there for building servers.

We’ll start with the /src/server/index.js file:

const express      = require("express");
const cors         = require("cors");
const bodyParser   = require("body-parser");
const routes       = require("./routes");
                     require("dotenv").config();

const app  = express();
const port = process.env.NODE_PORT || 3000;

function start() {
  return  app.use(cors())
             .use(bodyParser.urlencoded({ extended: false }))
             .use(bodyParser.json())
             .use("/quotes",routes)
             .use((_req, res) => res.status(404).json({ success: false,error: "Route not found" }))
             .listen(port, () => console.log(`Server ready on port ${port}`));
}

module.exports = {
  start
};

As you can see, it is just a standard Express.js server, we won’t spend much time on that.

Let’s see our /src/server/routes/index.js file:

const express    = require("express");
const controller = require("../controllers");
const routes     = express.Router();

routes.route("/").get(controller.getQuotes);
routes.route("/new").post(controller.addQuote);

module.exports = routes;

We just create two endpoints:

1. GET /, will return a list of quotes matching our query string parameters.
2. POST /new/, will allow us to post a new quote storing it inside ElasticSearch.

So now let’s see our /src/server/controllers/index.js file:

const model = require("../models");

async function getQuotes(req, res) {
  const query  = req.query;
  if (!query.text) {
    res.status(422).json({
      error: true,
      data: "Missing required parameter: text"
    });
    return;
  }
  try {
    const result = await model.getQuotes(req.query);
    res.json({ success: true, data: result });
  } catch (err) {
    res.status(500).json({ success: false, error: "Unknown error."});
  }
}

async function addQuote(req, res) {
  const body = req.body;
  if (!body.quote || !body.author) {
    res.status(422).json({
      error: true,
      data: "Missing required parameter(s): 'body' or 'author'"
    });
    return;
  }
  try {
    const result = await model.insertNewQuote(body.quote, body.author);
    res.json({ 
      success: true, 
      data: {
        id:     result.body._id,
        author: body.author,
        quote:  body.quote
      } 
    });
  } catch (err) {
    res.status(500).json({ success: false, error: "Unknown error."});
  }
}
module.exports = {
  getQuotes,
  addQuote
};

Here we’re basically defining two functions:

1. getQuotes, which requires at least one querystring parameter – text
2. addQuote, which require two parameters – author and quote

The ElasticSearch interface is delegated to our /src/server/models/index.js. This structure helps us maintain a MVC-ish architecture.

Let’s see our model:

const { esclient, index, type } = require("../../elastic");

async function getQuotes(req) {
  const query = {
    query: {
      match: {
        quote: {
          query: req.text,
          operator: "and",
          fuzziness: "auto"
        }
      }
    }
  }

  const { body: { hits } } = await esclient.search({
    from:  req.page  || 0,
    size:  req.limit || 100,
    index: index, 
    type:  type,
    body:  query
  });

  const results = hits.total.value;
  const values  = hits.hits.map((hit) => {
    return {
      id:     hit._id,
      quote:  hit._source.quote,
      author: hit._source.author,
      score:  hit._score
    }
  });

  return {
    results,
    values
  }
}

As you can see, we’re composing our ElasticSearch query by selecting every quote that includes a given word or phrase.

Then, we spawn the query, setting both page and limit values we can pass them in a query string, for instance http://localhost:3000/quotes?text=love&page=1&limit=100. If these values are not passed via querystring, we’ll fall back to their default values.

ElasticSearch returns an incredibly big amount of data, but we just need four things:

1. Quote ID
2. The quote itself
3. Quote author
4. Score

The score represents how close the quote is to our search term. Once we have these values, we return them with the total results number, which may be useful when paginating the results on the front end.

Now we need to create the last function for our model insertNewQuote:

async function insertNewQuote(quote, author) {
  return esclient.index({
    index,
    type,
    body: {
      quote,
      author
    }
  })
}

This function is really simple, we just post the quote and the author to our index and return the query result back to the controller.

Now the complete /src/server/models/index.js file should look like this:

const { esclient, index, type } = require("../../elastic");

async function getQuotes(req) {
  const query = {
    query: {
      match: {
        quote: {
          query: req.text,
          operator: "and",
          fuzziness: "auto"
        }
      }
    }
  }

  const { body: { hits } } = await esclient.search({
    from:  req.page  || 0,
    size:  req.limit || 100,
    index: index, 
    type:  type,
    body:  query
  });

  const results = hits.total.value;

  const values  = hits.hits.map((hit) => {
    return {
      id:     hit._id,
      quote:  hit._source.quote,
      author: hit._source.author,
      score:  hit._score
    }
  });

  return {
    results,
    values
  }
}

async function insertNewQuote(quote, author) {
  return esclient.index({
    index,
    type,
    body: {
      quote,
      author
    }
  })
}

module.exports = {
  getQuotes,
  insertNewQuote
}

And we’re done! We just need to setup our start script inside out package.json file and we’re ready to go:

"scripts": {
  "start": "pm2-runtime start ./src/main.js --name node_app",
  "stop": "pm2-runtime stop node_app "
}

We also need to update our /src/main.js script in order to start up our Express.js server once ElasticSearch has been connected:

const elastic = require("./elastic");
const server  = require("./server");
const data    = require("./data");
                require("dotenv").config();

(async function main() {
  const isElasticReady = await elastic.checkConnection();

  if (isElasticReady) {
    const elasticIndex = await elastic.esclient.indices.exists({index: elastic.index});

    if (!elasticIndex.body) {
      await elastic.createIndex(elastic.index);
      await elastic.setQuotesMapping();
      await data.populateDatabase()
    }

    server.start();
  }
})();

Launching the application

We’re now ready to start our application using docker-compose!

Just run the following command:

docker-compose up

You’ll need to wait until Docker downloads both the ElasticSearch and Node.js images, then it will boot up your server and you’ll be ready to query against your REST endpoints!

Let’s test with a couple of cURL calls:

curl localhost:3000/quotes?text=love&limit=3

{
  "success": true,
  "data": {
    "results": 716,
    "values": [
      {
        "id": "JDE3kGwBuLHMiUvv1itT",
        "quote": "There is only one happiness in life, to love and be loved.",
        "author": "George Sand",
        "score": 6.7102118
      },
      {
        "id": "JjE3kGwBuLHMiUvv1itT",
        "quote": "Live through feeling and you will live through love. For feeling is the language of the soul, and feeling is truth.",
        "author": "Matt Zotti",
        "score": 6.2868223
      },
      {
        "id": "NTE3kGwBuLHMiUvv1iFO",
        "quote": "Genuine love should first be directed at oneself if we do not love ourselves, how can we love others?",
        "author": "Dalai Lama",
        "score": 5.236455
      }
    ]
  }
}

So as you can see, we decided to limit our results to 3, but there are over 713 quotes!

We can easily get the next three quotes by calling:

curl localhost:3000/quotes?text=love&limit=3&page=2

{
  "success": true,
  "data": {
    "results": 716,
    "values": [
      {
        "id": "SsyHkGwBrOFNsaVmePwE",
        "quote": "Forgiveness is choosing to love. It is the first skill of self-giving love.",
        "author": "Mohandas Gandhi",
        "score": 4.93597
      },
      {
        "id": "rDE3kGwBuLHMiUvv1idS",
        "quote": "Neither a lofty degree of intelligence nor imagination nor both together go to the making of genius. Love, love, love, that is the soul of genius.",
        "author": "Wolfgang Amadeus Mozart",
        "score": 4.7821507
      },
      {
        "id": "TjE3kGwBuLHMiUvv1h9K",
        "quote": "Speak low, if you speak love.",
        "author": "William Shakespeare",
        "score": 4.6697206
      }
    ]
  }
}

And what if you need to insert a new quote? Just call the /quotes/new endpoint!

curl --request POST \
     --url http://localhost:3000/quotes/new \
     --header 'content-type: application/json' \
     --data '{
        "author": "Michele Riva",
        "quote": "Using Docker and ElasticSearch is challenging, but totally worth it."
}'

and the response will be:

{
  "success": true,
  "data": {
    "id": "is2QkGwBrOFNsaVmFAi8",
    "author": "Michele Riva",
    "quote": "Using Docker and ElasticSearch is challenging, but totally worth it."
  }
}

Conclusion

Docker makes it incredibly easy to manage our dependencies and their deployment. From that point, we could host our application on Heroku, AWS ECS, Google Cloud Container or any other Docker-based service with ease, without struggling to setup our server with their super-complex configurations.

Next steps?

• Learn how to use Kubernetes in order to scale your container and orchestrate more ElasticSearch Instances!
• Create a new endpoint that will allow you to update an existing quote. Mistakes can happen!
• And what about deleting a quote? How would you implement that endpoint?
• It would be great to save your quotes with tags (for instances, quotes about love, health, art)… try to update your quotes index!

Software development is fun. With Docker, Node, and ElasticSearch it’s even better!

Plug: LogRocket, a DVR for web apps

LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

Node.js Adoption Outpacing Security Readiness

Node.js has earned a strong foothold in DevOps toolchains, with NodeSource — a commercial Node.js runtime vendor — describing it as “the runtime of choice for DevOps.” Yet a joint survey conducted by NodeSource and application security startup Sqreen reveals a troubling gap: developer teams are adopting Node.js rapidly while underinvesting in the security practices needed to protect the applications they build with it.

Key Survey Findings

The survey polled Node.js developers and technology executives. Its headline findings paint a picture of widespread security anxiety paired with limited remediation activity:

• More than one-third of respondents expect their organization to be hacked, with many resigned to a significant attack within the next six months.
• 60 percent of developers expressed concern about the security of their applications.
• Only 16 percent were confident that third-party modules used in their projects are free of vulnerabilities.
• Only 30 percent combine manual and automated code reviews to identify known vulnerabilities.
• Only 30 percent reported scanning third-party code to detect vulnerable dependencies.
• Just 35 percent of companies combine code reviews with automated tooling to search for vulnerabilities.
• Only 23 percent of respondents use any form of real-time threat detection.
• The most common monitoring approach — used by 44 percent — is log inspection, a largely reactive method.
• 35 percent of developers acknowledged they have no reliable way of knowing when their applications are actively under attack.

Security Is a Concern, Not a Priority

“Our survey results clearly demonstrate that security is a concern for developers — but not a priority,” said Joe McCann, CEO of NodeSource, in a statement accompanying the survey release.

The findings reflect a tension familiar across modern software delivery: the pressure to ship code quickly competes directly with the time and discipline required to secure it. Release cycles that once ran monthly now run weekly, and individual code components may be updated multiple times per day. In that environment, security reviews are often deferred or skipped entirely.

Open Source Dependencies Amplify the Risk

Node.js development relies heavily on the npm ecosystem, which provides access to hundreds of thousands of open source packages. The convenience of reusing community-maintained modules accelerates development but introduces a significant supply-chain risk: vulnerabilities in upstream packages can propagate into production applications without any action by the application developer.

Security experts cited in the original reporting note that the greater availability and use of open source code — which is often maintained inconsistently — has heightened these concerns. The survey data supports this: only 16 percent of respondents expressed confidence in the security posture of their third-party dependencies.

Tools Exist, But Adoption Remains Low

“Developers have a wide array of security tools at their disposal that they are simply not using,” said Jean-Baptiste Aviat, co-founder and CTO of Sqreen. Aviat and his co-founder previously worked as security specialists at Apple before founding Sqreen, which provides runtime application self-protection (RASP) and security monitoring software.

The categories of tooling available to Node.js development teams include:

• Static analysis (SAST): Scans source code for known vulnerability patterns before deployment.
• Software composition analysis (SCA): Audits third-party and open source dependencies for known CVEs. Tools such as npm audit, Snyk, and OWASP Dependency-Check fall into this category.
• Dynamic analysis (DAST): Tests running applications for exploitable weaknesses.
• Runtime protection (RASP): Monitors application behavior in real time and can block attacks as they occur — the category Sqreen operates in.
• Security Information and Event Management (SIEM): Aggregates and correlates security events across systems for centralized visibility.

The survey found that SIEM adoption among Node.js teams was low, with log inspection being the dominant — and largely reactive — monitoring approach.

Real-Time Detection: The Most Critical Gap

Perhaps the most operationally significant finding is that only 23 percent of Node.js developers use any form of real-time threat detection. Relying on log analysis means that by the time a team identifies an attack, damage may already be done — data exfiltrated, services disrupted, or credentials compromised.

The 35 percent of developers who reported having no way to detect active attacks represent a particularly high-risk cohort. Without visibility into runtime behavior, these teams cannot distinguish normal traffic from exploitation attempts, nor can they respond to incidents in a timely manner.

What DevOps Teams Should Do

The survey data points to several practical areas where DevOps and development teams can close the security gap without overhauling their entire workflow:

1. Integrate dependency scanning into CI/CD pipelines. Running npm audit or a dedicated SCA tool on every build catches vulnerable packages before they reach production.
2. Automate code review checks. Pairing human code review with static analysis tools reduces the burden on reviewers and catches vulnerability classes that humans commonly miss.
3. Add runtime visibility. Even basic application performance monitoring (APM) with security alerting provides far more insight than log inspection alone.
4. Treat security as a pipeline gate, not a post-deployment audit. Shifting security left — embedding checks early in development — reduces the cost and disruption of remediating vulnerabilities found in production.
5. Inventory and continuously monitor third-party modules. As the npm dependency tree grows, automated tooling is the only scalable way to track which packages are in use and whether they have been flagged for vulnerabilities.

Conclusion

Node.js has become a foundational runtime for many DevOps teams, valued for its performance, extensive package ecosystem, and JavaScript’s ubiquity. But popularity without security discipline creates a large and growing attack surface. The NodeSource/Sqreen survey suggests that awareness of the problem is high while action to address it remains limited. Closing that gap requires treating security tooling as an integral part of the delivery pipeline rather than an optional add-on applied after the fact.

Original reporting: enterprisetech.com. Survey conducted by NodeSource and Sqreen (published 2017).

This tutorial walks through each stage of that pipeline using a Node.js example application:

• Continuous integration: Push code to GitHub; CircleCI automatically builds and runs unit tests.
• Continuous deployment: On a successful build, CircleCI deploys the application to Heroku.
• Continuous testing: After deployment, Assertible runs automated post-deployment API tests against the live application.

By the end, you will have a workflow that automatically builds, deploys, and tests your Node.js app after every push to your repository — with no manual steps required.

Continuous Integration with CircleCI

The pipeline starts when code is pushed to a GitHub repository. CircleCI picks up the new changes, installs dependencies, and runs your unit tests. Setting this up requires just two things:

1. Add a circle.yml configuration file to the root of your repository.
2. Connect the repository to CircleCI by adding it as a project in your CircleCI dashboard.

For a Node.js application, the default CircleCI settings are sufficient. CircleCI automatically detects Node.js projects and runs npm install followed by npm test without requiring any extra configuration in the YAML file.

A minimal circle.yml for a Node.js project looks like this:

machine:
  node:
    version: stable

test:
  post:
    - npm test

Once configured, every push to GitHub triggers a CircleCI build. If any unit test fails, the pipeline stops and the deployment step is never reached — protecting your production environment from broken builds.

Continuous Deployment with Heroku

After a successful build, CircleCI executes the deployment block in circle.yml. In this example, the application is deployed to Heroku by pushing directly to the Heroku Git remote using the commit SHA captured in the $CIRCLE_SHA1 environment variable.

deployment:
  production:
    branch: master
    commands:
      # Deploy the app to Heroku
      - git push git@heroku.com:your-app-name.git $CIRCLE_SHA1:refs/heads/master

This configuration tells CircleCI to trigger the production deployment only when changes are merged to the master branch. Feature branches will still be built and tested by CircleCI, but they will not be deployed to production.

Key points about this deployment step:

• The Heroku SSH key must be added to CircleCI’s project settings so the git push is authenticated.
• You can extend the commands list to run database migrations, flush caches, or perform any other pre- or post-deploy tasks.
• Heroku review apps can be used alongside this pattern to create isolated staging environments for every pull request.

Continuous Testing with Assertible

Unit tests verify your code in isolation, but they cannot tell you whether the live, deployed application is actually working correctly. That is where post-deployment testing comes in. After Heroku finishes the deployment, the pipeline uses Assertible to run a suite of API tests against the running application.

Assertible listens for GitHub Deployment events. When it receives a success deployment status for a repository it is connected to, it automatically runs the API tests you have defined. The github_deploy helper script (provided by Assertible’s open-source assertible/deployments repository) sends these events from within your CircleCI build.

Add the following steps to your circle.yml deployment commands, after the Heroku push:

# Download the github_deploy helper script
- curl https://raw.githubusercontent.com/assertible/deployments/master/github_deploy > github_deploy
- chmod +x github_deploy

# Notify GitHub of the deployment, then mark it successful.
# Assertible listens for the 'success' event and triggers API tests.
- |
  APPROOT=https://your-app-name.herokuapp.com/
  DEPLOY_ID=$(ENVIRONMENT_NAME="production" ./github_deploy $CIRCLE_SHA1 $CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME $APPROOT "pending")
  ./github_deploy $CIRCLE_SHA1 $CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME $APPROOT "success" $DEPLOY_ID

The script first creates a deployment record in GitHub with a pending status, capturing the resulting deployment ID. Once the deployment is confirmed live, it updates the status to success. Assertible detects this event and immediately executes the configured API test suite.

This automated post-deployment testing catches issues that unit tests cannot — such as misconfigured environment variables, broken integrations with external services, or unexpected runtime errors in the deployed environment.

Testing Staging Environments from Pull Requests

The same mechanism works for staging environments and Heroku review apps. When a pull request triggers a deployment to a staging environment, Assertible runs your API tests against that environment and reports the results as a GitHub status check directly on the pull request.

This means reviewers can see at a glance whether the new changes pass API tests before merging — adding an additional quality gate beyond code review alone.

Extending the Pipeline

Additional Automation with Heroku Add-ons

Heroku’s add-on ecosystem provides many ways to extend this workflow. You can automate database migrations, queue background jobs, flush CDN caches, or send deployment notifications to Slack — all as additional commands within the CircleCI deployment block.

Using Other CI Providers

The core pattern described here — build, deploy, emit a GitHub deployment event, trigger automated tests — is not tied to any specific toolchain. The same approach works with other CI providers such as Travis CI, Jenkins, Wercker, or GitHub Actions. The key requirement is the ability to make an authenticated HTTP request (or run a shell script) that creates a GitHub Deployment event with a success status after deployment completes.

Assertible’s open-source assertible/deployments repository contains scripts and documentation for integrating with multiple CI providers.

Summary

A complete continuous development pipeline for a Node.js application can be assembled from three focused tools:

• CircleCI handles building and unit testing on every push, and orchestrates the deployment step.
• Heroku receives the automated deployment and hosts the running application.
• Assertible listens for GitHub deployment events and runs post-deployment API tests to verify the live environment.

The result is a pipeline where every push to master automatically progresses through build, deploy, and test stages — with failures surfaced quickly at each gate, long before users are affected.