DEV Community: Ifedayo Adesiyan

How to Upgrade AWS EKS Node Groups Without Downtime (Step-by-Step Guide)

Ifedayo Adesiyan — Thu, 09 Oct 2025 11:36:22 +0000

Upgrading Kubernetes node groups is key for better performance, scaling, and cost savings. But doing it carelessly can cause downtime. If you’re running on Amazon EKS (Elastic Kubernetes Service), AWS’s managed Kubernetes platform, this process becomes easier, but you still need a careful approach.

This guide walks you through a safe, step-by-step upgrade (using an example of moving from t3.small to t3.medium in EKS) without any disruption to your workloads.

Prerequisites

Make sure your apps have more than one replica, you can access the cluster with kubectl or your cloud CLI, and you understand how node pools/node groups work

In this tutorial, I’ll demonstrate upgrading from an AWS t3.small node to t3.medium node. You’ll notice commands use a — kubeconfig =kubeconfig.yaml flag. This explicitly points kubectl to the correct Kubernetes cluster configuration file, which is useful when managing multiple clusters or when your kubeconfig isn’t in the default location (~/.kube/config)

Step 1: Ensure Your Deployment Has Multiple Replicas

Check that your Deployments or StatefulSets run more than one replica, this redundancy keeps apps available during rolling updates.

#deployment.yml
spec: 
  replicas: 3

You can confirm by running the command below:

kubectl --kubeconfig=kubeconfig.yaml get deploy

NAME            READY   UP-TO-DATE   AVAILABLE   AGE
test-api        3/3     3            3           12d

NAME → The deployment name (test-api).
READY (3/3) → Shows replicas: 3 pods are ready out of 3 desired replicas.
UP-TO-DATE (3) → Number of replicas that match the latest Deployment spec.
AVAILABLE (3) → Number of replicas actually available to serve traffic
AGE (12d) → How long the Deployment has existed.
So the replica count is reflected in the READY column (3/3). If your Deployment was set to 5 replicas, you’d see 5/5 here when all are ready.

If replicas = 1, scale up before starting the upgrade by running

kubectl --kubeconfig=kubeconfig.yaml scale deployment test-api --replicas=3

Step 2: Edit the Node Group / Instance Type

Add new EC2 instances with the t3.medium type (either by updating the existing node group or creating a new one).

Join them to your cluster using your EKS configuration (this happens automatically if you update the node group, or manually if you create new nodes).

Label the new nodes (e.g., node-type=medium) so you can target workloads with nodeSelector or nodeAffinity. This ensures pods are scheduled onto the new t3.medium nodes first, before draining the old t3.small ones.

kubectl --kubeconfig=kubeconfig.yaml label nodes test-api-new-instance instance-type=t3.medium

This command applies a label to a Kubernetes node. Specifically, it adds (or updates) the label instance-type=t3.medium on the node named test-api-new-instance.

These are the current 2 instances we have:

i-036xxxxxxxxxx49ab is the t3.small node we will like to take out.

Step 3: Use nodeSelector or Affinity

Now that you’ve added new EC2 t3.medium instances to your EKS cluster, you want Kubernetes to place your workloads on them instead of the older t3.small instances.

Each EC2 instance in the cluster gets a label that includes its instance type. For example, a t3.medium EC2 will have:

kubernetes.io/instance-type=t3.medium

By updating your Deployment with a nodeSelector, you instruct Kubernetes to run your pods only on the t3.medium EC2 instances:

# deployment.yml
spec:
  template:
    spec:
      nodeSelector:
        kubernetes.io/instance-type: t3.medium

Step 4: Trigger a rolling update

Once the new nodes are ready and labeled, restart your Deployment to shift workloads:

kubectl --kubeconfig=kubeconfig.yaml -n production rollout restart deployment test-api

Kubernetes will then:

Spin up new pods on t3.medium nodes
Wait for them to be Ready
Gradually terminate old pods running on t3.small nodes

Step 5: Drain & remove old nodes

Once your application is fully running on the new nodes, clean up the old ones by draining them:

kubectl --kubeconfig=kubeconfig.yaml drain i-036xxxxxxxxxx49ab --ignore-daemonsets --delete-emptydir-data

This gracefully evicts pods from the old node while ignoring system DaemonSets. After the node is drained, you can safely terminate the t3.small EC2 instance from the AWS console or CLI.

Conclusion

Upgrading EKS node groups safely ensures better performance and cost efficiency without downtime. With careful scaling, labeling, and draining, your workloads move smoothly to the new instances.

Additional Resources

If you encounter any issues following this guide, migrating or upgrading your node groups, feel free to reach me on LinkedIn

Production-Ready Vault Deployment on EC2: A Detailed Guide

Ifedayo Adesiyan — Wed, 31 Jul 2024 14:30:36 +0000

HashiCorp Vault is a powerful tool designed for securely managing secrets and protecting sensitive data. It provides a unified interface to access secrets and protect sensitive data using a variety of methods such as encryption, access control, and dynamic secrets generation. Vault is widely used in modern infrastructure to ensure that sensitive information, like API keys, passwords, and certificates, is handled securely and accessed only by authorized entities.
This guide aims to walk you through the process of deploying a production-ready HashiCorp Vault server on an AWS EC2 instance. The goal is to help you set up a secure, highly available, and scalable Vault environment that meets the needs of a production system.

Prerequisites

Before deploying HashiCorp Vault on an AWS EC2 instance, several prerequisites need to be addressed:
AWS Account Setup: Ensure you have an active AWS account. This is necessary for creating and managing EC2 instances and other AWS resources.
SSH Key Pair Creation: Create an SSH key pair to securely access your EC2 instances. This key pair will be used to establish an SSH connection to your instance.
Security Group Configuration: Configure a security group for your EC2 instance to allow inbound traffic on necessary ports, such as port 8200 for Vault and port 22 for SSH access.

Installing Vault

To manage your EC2 instance, you'll need to connect to it via SSH. Open your terminal and use the following command, replacing /path/to/your-key.pem with the path to your SSH key file and your-ec2-public-dns with the public DNS address of your EC2 instance:

# ssh -i /path/to/your-key.pem ubuntu@your-ec2-public-dns
ssh -i tutorial-key.pem ubuntu@ec2-34-254-186-220.eu-west-1.compute.amazonaws.com

This command establishes a secure connection to your EC2 instance using the provided key for authentication.

Now you have gained entry into your ec2 instance.
First, ensure your package index is up-to-date to avoid installation issues using:

sudo apt-get update

This refreshes the list of available packages and their versions.

Installing Necessary Packages

Vault installation requires some basic tools like unzip. Install them using:

sudo apt-get install -y unzip

This command installs the unzip utility, which is needed to extract the Vault binary.
Next, download the latest version of Vault from the official HashiCorp release page. As of July 31, 2024, the latest version is 1.17.2. Replace the version number with the latest release if necessary:

wget https://releases.hashicorp.com/vault/1.17.2/vault_1.17.2_linux_amd64.zip

This command fetches the Vault binary in a zip archive.
Extract the downloaded zip file and move the Vault binary to a directory included in your system's PATH:

unzip vault_1.17.2_linux_amd64.zip

sudo mv vault /usr/local/bin/

This extracts the vault binary and moves it to /usr/local/bin, making it accessible from anywhere in your terminal.
To ensure Vault is installed correctly, check its version:

vault --version

Configuring Vault

To start configuring Vault, first create a directory to store the configuration file:

sudo mkdir /etc/vault

Next, create and edit the Vault configuration file:

sudo nano /etc/vault/vault.hcl

This opens a new file in the Nano text editor where you can define your Vault configuration.
In the vault.hcl file, specify the storage backend. For a simple setup, use the file storage backend, which stores data locally:

storage "file" {
  path = "/mnt/vault/data"
}

This configuration tells Vault to store its data in the /mnt/vault/data directory. Make sure this directory exists and is writable by the Vault process.
We will verify the directory /mnt/vault exists and that the Vault process has the correct permissions to write to it using the following commands:

sudo mkdir -p /mnt/vault
sudo chown vault:vault /mnt/vault
sudo chmod 700 /mnt/vault

Next, set up a listener to handle incoming requests.
For an EC2 instance, port 8200 is not open by default, you'll need to check and modify the security group settings to ensure that port 8200 is open.
Find your instance and select the security group; click on the Inbound rules tab, and then click the Edit inbound rules button.

To add a rule for port 8200, click Add rule, set Type to Custom TCP Rule, set Port range to 8200, set Source to 0.0.0.0/0 (for open access) or specify a custom IP range for more restricted access, and click Save rules

For production environments, it's crucial to use TLS to secure communications. To set up TLS certificates for Vault, you can either generate self-signed certificates or obtain certificates from a Certificate Authority (CA). Here's an example configuration for a TLS listener:

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/vault-cert.pem"
  tls_key_file  = "/etc/vault/vault-key.pem"
}

Replace /etc/vault/vault-cert.pem and /etc/vault/vault-key.pem with the paths to your TLS certificate and key files. This setup ensures that Vault communicates securely over HTTPS.

To enable the Vault web UI, add the following line to the configuration file:
ui = true
This setting allows access to Vault's user interface via a web browser, which can be accessed at https://:8200.
The disable_mlock = true setting in Vault's configuration disables the use of memory locking, which normally prevents Vault's sensitive data from being swapped to disk, potentially reducing security but improving compatibility in environments where memory locking is not available
Here is a minimal example of a vault.hcl configuration file:

# vault.hcl
storage "file" {
  path = "/mnt/vault/data"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  # tls_cert_file = "/etc/vault/vault-cert.pem"
  # tls_key_file  = "/etc/vault/vault-key.pem"
  tls_disable = 1

ui = true
disable_mlock = true

This configuration includes the basic setup for storage, disabled TLS connection, enabling the UI, and disabling memory locking. Ensure that all file paths and other settings match your actual environment.
With these configurations in place, Vault will be set up to run securely and provide its secret management capabilities through a web interface.

Starting Vault as a Service

To manage Vault as a systemd service, create a service file for Vault:

sudo nano /etc/systemd/system/vault.service

This will open a new file in the Nano text editor where you'll define how Vault should be managed.
Add the following content to the vault.service file:

[Unit]
Description=HashiCorp Vault Service- A tool for managing secrets
Documentation=https://www.vaultproject.io/
Requires=network-online.target
After=network-online.target

[Service]
User=vault
Group=vault
ExecStart=/usr/local/bin/vault server -config=/etc/vault/vault.hcl
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Here's what each section does:
[Unit]: Defines the service description and dependencies.
[Service]: Configures the service to run as the vault user, start Vault with the specified configuration file, and handle restarts and reloads.
[Install]: Configures the service to start at boot.

Ensure that the vault user and group exist or adjust the User and Group fields accordingly. You might need to create these if they don't exist:

sudo useradd --system --home /etc/vault vault

After creating the service file, reload the systemd configuration to recognize the new service:

sudo systemctl daemon-reload

Enable the Vault service to start automatically at boot and then start it:

sudo systemctl enable vault
sudo systemctl start vault

Verify that the Vault service is running correctly:

sudo systemctl status vault

This displays the current status of the Vault service, including whether it is active, and provides logs for troubleshooting if necessary.
By following these steps, you will have Vault running as a managed systemd service, making it easier to handle restarts, automatic starts, and other service management tasks.

Initializing and Unsealing Vault

Initialization is the first step in setting up Vault. It generates the encryption keys and the initial root token.
Before initializing, we need to run:

export VAULT_ADDR='http://<your private IPv4 address>:8200'
export DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus

export VAULT_ADDR='http://172.31.4.123:8200' sets the environment variable VAULT_ADDR to the URL of the Vault server, specifying where Vault commands should be directed.
export DBUS_SESSION_BUS_ADDRESS=$XDG_RUNTIME_DIR/bus sets the DBUS_SESSION_BUS_ADDRESS environment variable to the path of the DBus session bus address, helping avoid issues with runaway DBus processes.
To initialize Vault, run:

vault operator init

This will output several pieces of important information:

Unseal Keys: You will receive multiple unseal keys. These keys are used to unseal the Vault server after it has been started.
Root Token: The initial root token allows you to authenticate and configure Vault.
Important: Save these unseal keys and root token in a secure location. They are critical for accessing and managing your Vault instance.

Once Vault is initialized, it will be sealed. You need to unseal it using the unseal keys provided during initialization. Use the following command to unseal Vault:

vault operator unseal <Unseal Key 1>
vault operator unseal <Unseal Key 2>
vault operator unseal <Unseal Key 3>

You need to enter a majority of the unseal keys to unseal Vault. The exact number depends on your configuration, but typically it's three out of five.
You can also do this via the Vault web UI. Open a web browser and navigate to:

http://<your-ec2-public-dns>:8200

Replace <your-ec2-public-dns> with the public DNS name or IP address of your EC2 instance:

Ensure that the unseal keys and root token are stored securely:
Unseal Keys: Store them in a safe place, such as a secure password manager or a hardware security module (HSM).
Root Token: This token provides full access to Vault, so it should be treated with the highest level of security. Store it in a secure, encrypted location and use it only as needed.

Once you put in three correct keys, you'll be redirected to sign in. Use the root token obtained during initialization to sign in:
Enter the root token in the login prompt.
Click "Sign in" to access the Vault dashboard.

The Vault UI provides a user-friendly interface for managing secrets, policies, and configurations. From here, you can perform administrative tasks and configure Vault according to your needs.

Securing Vault Deployment

Enabling TLS for secure communication

To ensure that communication with Vault is secure, you should enable TLS (Transport Layer Security). This encrypts the data transmitted between clients and the Vault server, protecting it from eavesdropping and tampering.

Obtain TLS Certificates: Acquire or generate a TLS certificate and private key. You can use a certificate authority (CA) or a self-signed certificate for testing purposes.
Configure TLS in Vault: Update the Vault configuration file (/etc/vault/vault.hcl) to enable TLS:

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/vault-cert.pem"
  tls_key_file  = "/etc/vault/vault-key.pem"
}

Replace the file paths with the locations of your TLS certificate and key. This ensures that Vault uses HTTPS for secure communication.

Restart Vault: Apply the new configuration by restarting the Vault service:

sudo systemctl restart vault

Using Consul or Another Backend for High Availability (HA)

For production environments, it's crucial to ensure high availability and fault tolerance. Consul is a popular choice for Vault's high-availability backend, but other options like etcd or a cloud-based database can also be used.

Install Consul: Follow the Consul installation guide to set up Consul on your infrastructure.
Configure Vault to Use Consul: Update the Vault configuration file to use Consul as the storage backend:

storage "consul" {
  address = "127.0.0.1:8500"
  path    = "vault/"
}

Replace 127.0.0.1:8500 with your Consul server address.

Restart Vault: Restart Vault to apply the new backend configuration:

sudo systemctl restart vault

Configuring Auto-Unseal with AWS KMS

Auto-unseal is a feature that allows Vault to automatically unseal itself using a cloud provider's key management service (KMS). For AWS, this means using AWS KMS to manage the encryption keys.

Create a KMS Key: In the AWS Management Console, create a new KMS key for Vault.
Configure Vault for Auto-Unseal: Update the Vault configuration file to use AWS KMS:

seal "awskms" {
  kms_key_id = "arn:aws:kms:region:account-id:key/key-id"
}

Replace arn:aws:kms:region:account-id:key/key-id with the ARN of your KMS key.

Restart Vault: Apply the configuration by restarting Vault:

sudo systemctl restart vault

Setting Up Regular Backups

Regular backups are essential for disaster recovery and data protection.

Plan Backup Strategy: Decide on the frequency and method of backups (e.g., daily snapshots).
Backup Storage: Store backups in a secure and durable location, such as Amazon S3 or another cloud storage service.
Automate Backups: Use cron jobs or other scheduling tools to automate the backup process. For example, create a script to copy the Vault data directory to your backup location and schedule it with cron.
Test Restores: Regularly test backup restores to ensure that backups are valid and that you can recover data as needed.

Implementing Monitoring and Alerting

Monitoring and alerting are crucial for maintaining the health and security of your Vault deployment.

Enable Vault Metrics: Vault provides a built-in metrics endpoint that you can enable in the configuration file:

telemetry {
  dogstatsd_addr = "127.0.0.1:8125"
  disable_hostname = true
}

This configuration sends metrics to a monitoring service like Datadog.

Set Up Monitoring: Use a monitoring tool such as Prometheus, Grafana, or Datadog to collect and visualize metrics from Vault.
Configure Alerts: Set up alerts for critical metrics, such as high error rates or low disk space, to ensure timely responses to potential issues.
Review Logs: Regularly review Vault logs for any unusual activity or errors. Configure log rotation and retention policies to manage log files efficiently. By implementing these security measures, you ensure that your Vault deployment is robust, highly available, and resilient against potential issues, providing reliable secret management for your organization.

Conclusion

In this guide, we've covered the essential steps for deploying a production-ready HashiCorp Vault server on AWS EC2, including initialization, unsealing, and configuring Vault for secure and high-availability operations. Emphasizing security and reliability is crucial for protecting sensitive data and maintaining system integrity. We encourage you to explore Vault's advanced features and best practices further to optimize and secure your secret management infrastructure effectively.

Additional Resources

How to Connect an EC2 Instance Using SSH
Vault CLI tutorial
Auto-Unseal with AWS KMS
A Guide on Configuring Backup for Amazon EC2 Instances using AWS Backup Service

If you encounter any issues following this guide or setting up Vault in production, feel free to contact me on LinkedIn

Handling Paystack transactions using webhooks

Ifedayo Adesiyan — Mon, 17 Apr 2023 08:09:03 +0000

Paystack is a popular payment processing platform used by businesses and individuals in Nigeria and other African countries. One of the key features of Paystack is its ability to process transactions using webhooks. Webhooks are HTTP callbacks that enable the automatic transfer of transaction data from Paystack to your application in real-time. Webhooks are useful for a variety of reasons. They can automate tasks and streamline workflows by eliminating the need for manual intervention. For example, when a customer places an order on an e-commerce website, a webhook can trigger an automated process that sends a confirmation email to the customer, updates the inventory system, and notifies the shipping department to prepare the order for delivery.

Overall, webhooks are a flexible and powerful way to enable real-time communication and automation between web applications, making them a valuable tool for developers and businesses alike.

In this article, we will explore how to implement Paystack transactions using webhooks with TypeScript. We will cover the steps involved in setting up the Paystack API, creating a webhook endpoint, handling Paystack webhook events, and testing the webhook integration.

Setting up the Paystack API

To use the Paystack API, you will need to create a Paystack account and obtain the API keys needed for transaction processing.

Here are the steps involved:

Create a Paystack account: Go to https://dashboard.paystack.com/#/signup and follow the instructions to create an account. After getting access to the dashboard, on the left-hand navigation bar, you click on settings.

Obtain the API keys: Go to the API section of your dashboard and copy the secret and public keys.

You can use the Paystack API to initiate transactions by sending a POST request to the API endpoint with the necessary transaction details. Here is an example of how to initiate a transaction in TypeScript:

import axios from 'axios';

const API_SECRET_KEY = 'yoursecretkey';//Test Secret Key for Test mode on

const transactionDetails = {
  email: 'customer@email.com',
  amount: 10000,
  metadata: {
    custom_fields: [
      {
        display_name: "Customer's name",
        variable_name: "customer_name",
        value: "John Doe"
      }
    ]
  }
};

axios.post('https://api.paystack.co/transaction/initialize', transactionDetails, {
  headers: {
    Authorization: `Bearer ${API_SECRET_KEY}`
  }
})
  .then(response => {
    console.log(response.data);
  })
  .catch(error => {
    console.log(error);
  });

NOTES:

amount: 10000, Paystack divides the amount by 100 to have value for kobo which sets the current amount to 100 in naira.
In transactionDetails, metadata value don't necessarily have to be set.

{
  status: true,
  message: 'Authorization URL created',
  data: {
    authorization_url: 'https://checkout.paystack.com/tqvqyiwxlxm54cg',
    access_code: 'tqvqyiwxlxm54cg',
    reference: 'xrmihwxzv9'
  }
}

Let's breakdown the response from the Paystack API after initiating a transaction:

status: A boolean value indicating whether the request was successful (true) or not (false)

message: A message indicating the result of the request. In this case, the message is 'Authorization URL created', which means that the Paystack API was able to create an authorization URL for the transaction.

data: An object containing the data returned by the Paystack API. In this case, the data object contains three properties:

authorization_url: The URL that the user should be redirected to in order to authorize the transaction.

access_code: A code that is used to authorize the transaction.

reference: A unique reference code that identifies the transaction.

On following the authorization url, you redirected to a similar webpage like the one below where you can simulate different transaction scenarios.

Setting up the webhook endpoint

To receive and process transaction data from Paystack in real-time, you will need to set up a webhook endpoint. Here are the steps involved:

Create a webhook endpoint: You can create a webhook endpoint using an HTTP framework like Express. Here is an example of how to create a webhook endpoint in TypeScript:

import express from 'express';
import { json } from 'body-parser';

const app = express();

app.use(json());

app.post('/paystack/webhook', (req, res) => {
  const eventData = req.body;
  console.log(eventData);
  res.sendStatus(200);
});

app.listen(3000, () => {
  console.log('Webhook server started on port 3000');
});

Register the webhook endpoint with Paystack: Go to the Webhooks section of your Paystack dashboard and add your webhook URL. Paystack will send transaction data to this URL whenever a transaction event occurs.

To receive webhook events from Paystack, your endpoint needs to be accessible from the internet. Paystack does not allow to register localhost as webhook URL, however you can expose your local enpoint to the internet. One way to achieve this in a local development environment is to use a tool like ngrok, which exposes your local endpoint to a public URL that can be accessed from the internet.
Here is how to use ngrok to expose your local endpoint:

Download and install ngrok from the official website.
Start ngrok by running the command ngrok http 3000 (replace 3000 with the port number of your local endpoint).
Ngrok will generate a public URL that you can use as your webhook endpoint in the Paystack dashboard.

Handling the Paystack webhook events

Paystack sends different types of webhook events to your webhook endpoint, depending on the status of the transaction. Here are the steps involved in handling Paystack webhook events in TypeScript:

Verify the webhook event: Paystack sends a signature with each webhook event that you can use to verify the authenticity of the event. Here is how to verify the signature:

import crypto from 'crypto';

const API_SECRET_KEY = 'yoursecretkey';

function verify(eventData: any, signature: string): boolean {
    const hmac = crypto.createHmac('sha512', API_SECRET_KEY);
    const expectedSignature = hmac.update(JSON.stringify(eventData)).digest('hex');
    return expectedSignature === signature;
}

Handle the webhook event: Once you have verified the signature, you can process the webhook event based on the event type. Here is how to handle a successful transaction event:

app.post('/paystack/webhook', (req, res) => {
  const eventData = req.body;
  const signature = req.headers['x-paystack-signature'];

  if (!verify(eventData, signature)) {
    return res.sendStatus(400);
  }

  if (eventData.event === 'charge.success') {
    const transactionId = eventData.data.id;
    // Process the successful transaction to maybe fund wallet and update your WalletModel
    console.log(`Transaction ${transactionId} was successful`);
  }

  return res.sendStatus(200);
});

Testing the webhook integration

To test your webhook integration, you can use the Paystack Test Mode to simulate different transaction scenarios. Here are the steps involved:

Switch to Test Mode: Go to your Paystack dashboard and switch to Test Mode.
Initiate a test transaction: Use the Paystack API to initiate a test transaction with the necessary test parameters.
Check the webhook response: Once the test transaction is complete, check the webhook response to ensure that the transaction data was received and processed correctly.

To test your webhook processing logic thoroughly, you can simulate different webhook events by sending different test parameters to the Paystack API. For example, you can simulate a failed transaction, a disputed transaction, or a successful refund.

By following these steps, you can thoroughly test your Paystack webhook integration in a local development environment and ensure that your application can handle real-time transactions correctly

Conclusion

In this article, we explored how to implement Paystack transactions using webhooks with TypeScript. We covered the steps involved in setting up the Paystack API, creating a webhook endpoint, handling Paystack webhook events, and testing the webhook integration. By following these steps, you can easily integrate Paystack transactions into your TypeScript application and process transactions in real-time.

Further reading: Paystack API documentation, ngrok docs

Writing Your First Tests For Node.js Apps

Ifedayo Adesiyan — Fri, 24 Feb 2023 16:00:04 +0000

Software testing is a critical process in the software development cycle. It is the process of assessing the performance and features of a software application to discover and diagnose any flaws or bugs within it. This may entail running the software with different inputs to verify that the output meets predetermined criteria. The primary objective of software testing is to guarantee that the software is functioning as intended and satisfies the user's needs.
It is impossible to exaggerate the importance of software testing. It contributes to ensuring the usability, functionality, and dependability of the software. Also, it aids in lowering the price of rectifying errors, which can become significantly more expensive when found later in the development cycle.
There are different types of software testing, including functional testing, performance testing, and security testing. Each type of testing serves a specific purpose and requires a unique set of tools and techniques.
To ensure the effectiveness of software testing, it is crucial to have a comprehensive testing plan that includes the identification of testing goals, the selection of appropriate testing tools, and the creation of test cases.
This article will examine the best techniques for writing tests in TypeScript and provide code examples to illustrate them.

Prerequisites

Popular programming language TypeScript enhances JavaScript with sophisticated features like optional static typing. By using TypeScript to create tests, you can assure the caliber of your code and identify mistakes as they arise early in the development cycle.
The prerequisites for following this guide are npm (Node Package Manager) and typescript.
Let's check if we have npm installed on our computer

npm -v
# 8.3.1

This command will return the version number of npm if it is installed, or an error message if it is not. If you receive an error message, you will need to install npm on your computer.
To install npm, you can download and install Node.js from the official website. npm is included with Node.js, so when you install Node.js, npm will also be installed on your system.
To check the version of TypeScript installed on your system, you can use the following command in your terminal or command prompt:

tsc -v
# Version 4.7.4

This will display the version number of TypeScript installed on your system. If TypeScript is not installed, you will need to install it using a package manager like npm.
To install TypeScript using npm, you can use the following command:

npm install -g typescript

This will install the latest version of TypeScript globally on your system.

Assumptions

In this tutorial, I assume you already have a node.js project you want to write tests for. We will be writing tests for a CMS (content management system) with TypeScript and Mocha, a popular testing framework for Node.js.
We have the user and post model, with endpoints for authentication and CRUD operations for the post model.

Hands-on

To get started, we need to install some dependencies into our project. We can use NPM to install these dependencies by running the command below in our terminal or command prompt:

npm install --save-dev ts-node mocha chai supertest @types/mocha @types/chai @types/supertest

This will install Mocha, Chai, Supertest, and the TypeScript types for Mocha, Chai, and Supertest.
In your src folder, you create a new folder called tests, and inside the tests folder, you create two files: user.test.ts and post.test.ts. user.test.ts will contain all tests for authentication and user endpoints and post.test.ts will contain all tests for the post endpoints.
Add the following code to user.test.ts

import { expect } from 'chai';
import request from 'supertest';
import app from './../app';



describe('USER AUTH', () => {
    let testUserId: string;
    let authToken: string;

    it('should not create a new user with invalid data', async () => {
        const res = await request(app)
          .post('/auth/signup')
          .send({
            username: 'testuser',
            password: 'testpass',
          });
        expect(res.status).to.equal(400);
        expect(res.body.message).to.equal('Email is required');
    });


    it('should create a new user with valid data', async () => {
      const res = await request(app)
        .post('/auth/signup')
        .send({
          username: 'username',
          password: 'password',
          email: 'email@example.com',
        });
      expect(res.status).to.equal(200);
      expect(res.body.data.token).to.be.a('string');
      expect(res.body.data.user).to.be.an('object');
      expect(res.body.data.user.username).to.equal('username');
      expect(res.body.data.user.email).to.equal('email@example.com');
      expect(res.body.data.user.password).to.not.exist;
      testUserId = res.body.data.user.id;
    });


    it('should not login with invalid credentials', async () => {
        const res = await request(app)
          .post('/auth/login')
          .send({
            username: 'testuser',
            password: 'wrongpass',
          });
        expect(res.status).to.equal(401);
        expect(res.body.message).to.equal('Invalid username or password');
    });

    it('should login with valid credentials and return token', async () => {
        const res = await request(app)
            .post('/auth/login')
            .send({
            username: 'username',
            password: 'password',
            });
        expect(res.status).to.equal(200);
        expect(res.body.data.token).to.be.a('string');
        expect(res.body.data.user.id).to.equal(testUserId);
        expect(res.body.data.user.username).to.equal('username');
        expect(res.body.data.user.email).to.equal('email@example.com');
        expect(res.body.data.user.password).to.not.exist;
        authToken = res.body.data.token
    });

    it('should get the current user', async () => {
        const res = await request(app)
            .get(`/users/${testUserId}`)
            .set('Authorization', `Bearer ${authToken}`);
        expect(res.status).to.equal(200);
        expect(res.body.data.id).to.equal(testUserId);
        expect(res.body.data.username).to.equal('username');
        expect(res.body.data.email).to.equal('email@example.com');
        expect(res.body.data.password).to.not.exist;
    });

    it('should update the current user', async () => {
        const res = await request(app)
            .put(`/users/${testUserId}`)
            .set('Authorization', `Bearer ${authToken}`)
            .send({
            username: 'updatedusername',
            email: 'updatedemail@example.com',
            });
        expect(res.status).to.equal(200);
        expect(res.body.data.id).to.equal(testUserId);
        expect(res.body.data.username).to.equal('updatedusername');
        expect(res.body.data.email).to.equal('updatedemail@example.com');
        expect(res.body.data.password).to.not.exist;
    });

    it('should not update the current user with invalid data', async () => {
        const res = await request(app)
            .put(`/users/${testUserId}`)
            .set('Authorization', `Bearer ${authToken}`)
            .send({
            email: 'invalidemail',
            });
        expect(res.status).to.equal(400);
        expect(res.body.message).to.equal('Invalid email');
    });

    it('should delete the current user', async () => {
        const res = await request(app)
            .delete(`/users/${testUserId}`)
            .set('Authorization', `Bearer ${authToken}`);
        expect(res.status).to.equal(204);

        // Make sure the user was deleted
        const deletedRes = await request(app)
            .get(`/users/${testUserId}`)
            .set('Authorization', `Bearer ${authToken}`);
        expect(deletedRes.status).to.equal(404);
        expect(deletedRes.body.message).to.equal('User not found');
    });
});

These tests cover the authentication flow of creating a new user, logging in, and getting the current user's information. Additionally, it tests the user module's functionality by checking that the current user can be fetched, updated, and deleted.
It's important to note that these tests only cover basic functionality and that there may be additional edge cases and error scenarios that should be tested depending on the specific requirements of your API.
In post.test.ts , we will write tests for the posts endpoints

import { expect } from 'chai';
import request from 'supertest';
import app from './../app';


describe('POST', () => {
    let testUserId: string;
    let authToken: string;
    let testPostId: string;



    it('should create a new user with valid data', async () => {
        const res = await request(app)
        .post('/auth/signup')
        .send({
            username: 'username',
            password: 'password',
            email: 'email@example.com',
        });
        expect(res.status).to.equal(200);
        expect(res.body.data.token).to.be.a('string');
        expect(res.body.data.user).to.be.an('object');
        expect(res.body.data.user.username).to.equal('username');
        expect(res.body.data.user.email).to.equal('email@example.com');
        expect(res.body.data.user.password).to.not.exist;
        testUserId = res.body.data.user.id;
    });


    it('should login and return a token', async () => {
        const res = await request(app)
        .post('/auth/login')
        .send({
            username: 'username',
            password: 'password',
        });
        expect(res.status).to.equal(200);
        expect(res.body.data.token).to.be.a('string');
        expect(res.body.data.user.id).to.equal(testUserId);
        expect(res.body.data.user.username).to.equal('username');
        expect(res.body.data.user.email).to.equal('email@example.com');
        expect(res.body.data.user.password).to.not.exist;
        authToken = res.body.data.token;
    });

    it('should create a new post with authentication', async () => {
        const res = await request(app)
        .post('/posts')
        .send({
            title: 'New Post',
            content: 'This is content for new post.',
        })
        .set('Authorization', `Bearer ${authToken}`);
        expect(res.status).to.equal(200);
        expect(res.body.data.title).to.equal('New Post');
        expect(res.body.data.content).to.equal('This is content for new post.');
        expect(res.body.data.author).to.equal(testUserId);
        testPostId = res.body.data.id;
    });

    it('should get a post by id', async () => {
        const res = await request(app).get(`/posts/${testPostId}`);
        expect(res.status).to.equal(200);
        expect(res.body.data.id).to.equal(testPostId);
        expect(res.body.data.title).to.equal('New Post');
        expect(res.body.data.content).to.equal('This is content for new post.');
        expect(res.body.data.author.id).to.equal(testUserId);
        expect(res.body.data.author.username).to.equal('username');
    });

    it('should update a post by id with authentication', async () => {
        const res = await request(app)
        .put(`/posts/${testPostId}`)
        .send({
            title: 'Updated Post',
            content: 'This is an updated post.',
        })
        .set('Authorization', `Bearer ${authToken}`);
        expect(res.status).to.equal(200);
        expect(res.body.data.id).to.equal(testPostId);
        expect(res.body.data.title).to.equal('Updated Post');
        expect(res.body.data.content).to.equal('This is an updated post.');
        expect(res.body.data.author.id).to.equal(testUserId);
        expect(res.body.data.author.username).to.equal('username');
    });

    it('should delete a post by id with authentication', async () => {
        const res = await request(app)
        .delete(`/posts/${testPostId}`)
        .set('Authorization', `Bearer ${authToken}`);
        expect(res.status).to.equal(204);
    });
});

We will create our final file and name it combine.test.ts , this will help us run our tests in the specific order that we want.

// combine.test.ts
import './user.test';
import './post.test';

In this file, We decided to run the user test first before testing other modules. The order of running tests modules-to-modules can be switched in any desired manner.

Running Tests

To run our tests, we will be adding a command script to our package.json file, we call it test

// package.json
{
  "name": "devto-tutorial-project",
  "version": "1.0.0",
  "scripts": {
    "test": "mocha --require ts-node/register './src/test/combine.test.ts' --clearCache --timeout 60000 --exit"
    ......
    ......
  },
  ......
  ......
}

The code added defines a "test" script in the scripts section, it runs mocha tests using the ts-node/register compiler for TypeScript executing combine.test.ts. Other options such as --clearCache will tell Mocha to clear the required cache before running the tests. This ensures that any changes made to the required modules are reflected in the tests, --timeout60000 will set the timeout for the tests to 60 seconds (60000 milliseconds). If any test takes longer than this, it will fail and --exit tells Mocha to exit the test process once all tests have been completed.
To run the Mocha tests, you can use the following command in your terminal or command prompt:

npm test

This command will execute the test script defined in our package.json file and run our Mocha tests in the test folder and on combine.test.ts.
On your terminal or command prompt, you should have something similar to this

Summary

In this article, we've explored how to write tests for a TypeScript backend API using Mocha, Chai, and Supertest. We used a simple API for managing users and posts to demonstrate some best practices for testing a Node.js server.
By writing tests, we have ensured that our API behaves as expected and can catch errors early in the development process.
In conclusion, software testing is a critical process in software development that helps to ensure the quality and reliability of the software. It is an ongoing process that should be an integral part of the software development cycle.
Now go ahead and write some more tests for some of your other Node.js projects.

Building more reliable applications with Temporal

Ifedayo Adesiyan — Thu, 23 Feb 2023 21:35:14 +0000

The Temporal microservice orchestrator is a key component of the Temporal platform that provides coordination and management of microservices as they interact with one another to complete complex workflows. The orchestrator provides features such as task management, error handling, retries, and compensation to ensure that workflows are executed accurately and consistently, even in the face of failures or unexpected events.
Using Temporal in application development can help simplify the development of complex, time-sensitive workflows and improve the reliability and scalability of the applications. By using the Temporal orchestrator, developers can focus on the implementation of their business logic, and leave the coordination and management of the underlying microservices to the platform.

Illustration

Microservices architecture, for example, is used in company XYZ. The microservices approach to software development helps their teams deploy faster, but it comes with some issues, one of which is data consistency. How can data changes in microservice A be propagated to microservices B and C? send it through an event?
Yes, that works, but what if B updates itself and C had hiccups and just could not make the update?
Then that means we need to have a mechanism that allows us to handle such failures, make retries, and what else? How many situations like the one described above require us to write failure and retry logic?
Hence, the use of Temporal as a microservice orchestrator helps us solve the issues stated above.

Prerequisites

The prerequisite for this tutorial is having Go and Docker installed and configured.
Verify that you've installed Go by opening a command prompt and typing the following command

go version

It should return something similar to this

go version go1.19.3 darwin/amd64

Also, verify docker is installed with

docker --version
#Docker version 20.10.22, build 3a2c30b

Choice

Temporal can be used inside and outside your project directory, as long as your application can access it. Your individual needs and the project's infrastructure will determine your choice.
It may be simpler to maintain your project's dependencies and setup if you decide to execute Temporal inside of your project directory because everything is contained there. However, running Temporal outside of your project directory might improve the degree of concern separation and make it simpler to manage numerous projects that share a single Temporal instance.
However, in this guide, we will run the temporal server inside our project directory.

Hello-workflow

We will be using the simple hello-workflow to orchestrate tasks within a distributed system. The starter and workers are the two main components that enable the distributed system to run, and in this guide, we will be implementing the starter and worker.
Here's what our project directory will look like.

├── dynamicconfig
│ ├── development-cass.yaml
│ └── development-sql.yaml
| └── docker.yaml
|
├── src
│ ├── helloworkflow 
| |        └── workflow.go
│ ├── starter
| |        └── main.go
| └── worker
|          └── main.go
├── .env
├── docker-compose.yml

You create a new Go project, say tutorial-guide and cd into it, then open the directory on your text editor. You create dynamicconfig folder in the root directory of your project and add the 3 yaml files. These files are needed to have the temporal-server up.

# development-cass.yaml
system.forceSearchAttributesCacheRefreshOnRead:
  - value: true # Dev setup only. Please don't turn this on in production.
    constraints: {}

# development-sql.yaml
limit.maxIDLength:
  - value: 255
    constraints: {}
system.forceSearchAttributesCacheRefreshOnRead:
  - value: true # Dev setup only. Please don't turn this on in production.
    constraints: {}

# docker.yaml
apiVersion: v1
clusters:
  - cluster:
      certificate-authority: path-to-your-ca.rt #e.g/System/Volumes/Data/Users/<name>/.minikube/ca.crt
      server: https://192.168.99.100:8443
    name: minikube
contexts:
  - context:
      cluster: minikube
      user: minikube
    name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
  - name: minikube
    user:
      client-certificate: path-to-proxy-client-ca.key #e.g/System/Volumes/Data/Users/<name>/.minikube/proxy-client-ca.key
      client-key: path-to-proxy-client-ca.key #e.g/System/Volumes/Data/Users/<name>/.minikube/proxy-client-ca.key

Use docker.yaml file to override the default dynamic config value (they are specified when creating the service config). More information about the docker.yaml file and how to use it [https://github.com/temporalio/docker-compose/tree/main/dynamicconfig]

# docker-compose.yaml
version: '3.5'

services:
  elasticsearch:
    container_name: temporal-elasticsearch
    environment:
      - cluster.routing.allocation.disk.threshold_enabled=true
      - cluster.routing.allocation.disk.watermark.low=512mb
      - cluster.routing.allocation.disk.watermark.high=256mb
      - cluster.routing.allocation.disk.watermark.flood_stage=128mb
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms256m -Xmx256m
      - xpack.security.enabled=false
    image: elasticsearch:${ELASTICSEARCH_VERSION}
    networks:
      - temporal-network
    expose:
      - 9200
    volumes:
      - /var/lib/elasticsearch/data
  postgresql:
    container_name: temporal-postgresql
    environment:
      POSTGRES_PASSWORD: temporal
      POSTGRES_USER: temporal
    image: postgres:${POSTGRESQL_VERSION}
    networks:
      - temporal-network
    expose:
      - 5432
    volumes:
      - /var/lib/postgresql/data
  temporal:
    container_name: temporal
    depends_on:
      - postgresql
      - elasticsearch
    environment:
      - DB=postgresql
      - DB_PORT=5432
      - POSTGRES_USER=temporal
      - POSTGRES_PWD=temporal
      - POSTGRES_SEEDS=postgresql
      - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml
      - ENABLE_ES=true
      - ES_SEEDS=elasticsearch
      - ES_VERSION=v7
    image: temporalio/auto-setup:${TEMPORAL_VERSION}
    networks:
      - temporal-network
    ports:
      - 7233:7233
    labels:
      kompose.volume.type: configMap
    volumes:
      - ./dynamicconfig:/etc/temporal/config/dynamicconfig
  temporal-admin-tools:
    container_name: temporal-admin-tools
    depends_on:
      - temporal
    environment:
      - TEMPORAL_CLI_ADDRESS=temporal:7233
    image: temporalio/admin-tools:${TEMPORAL_VERSION}
    networks:
      - temporal-network
    stdin_open: true
    tty: true
  temporal-ui:
    container_name: temporal-ui
    depends_on:
      - temporal
    environment:
      - TEMPORAL_ADDRESS=temporal:7233
      - TEMPORAL_CORS_ORIGINS=http://localhost:3000
    image: temporalio/ui:${TEMPORAL_UI_VERSION}
    networks:
      - temporal-network
    ports:
      - 8080:8080

networks:
  temporal-network:
    driver: bridge
    name: temporal-network

Add the environment variables needed for the docker-compose.yaml file.

# .env
COMPOSE_PROJECT_NAME=temporal
CASSANDRA_VERSION=3.11.9
ELASTICSEARCH_VERSION=7.16.2
MYSQL_VERSION=8
POSTGRESQL_VERSION=13
TEMPORAL_VERSION=1.19.1
TEMPORAL_UI_VERSION=2.9.1

The source code for the workflow that the Temporal Server runs is located in the workflow.go file. It is in charge of generating activities, monitoring their completion, and controlling the workflow. It specifies every action the workflow must do and is started by an event, such as a message from a queue or the addition of a new data item to the system.

// workflow.go
package helloworkflow

import (
 "context"
 "time"

 "go.temporal.io/sdk/workflow"
)

func Workflow(ctx workflow.Context, name string) (string, error) {
 ao := workflow.ActivityOptions{
  ScheduleToStartTimeout: time.Minute,
  StartToCloseTimeout:    time.Minute,
 }

 ctx = workflow.WithActivityOptions(ctx, ao)

 logger := workflow.GetLogger(ctx)

 var result string
 err := workflow.ExecuteActivity(ctx, Activity, name).Get(ctx, &result)
 if err != nil {
  logger.Error("Activity failed", "Error", err)
 }

 return result, nil
}

func Activity(ctx context.Context, name string) (string, error) {
 return "Hello " + name, nil
}

The starter is responsible for coordinating the workflow executions within the system. It is responsible for scheduling the tasks to be executed and keeping the task statuses up to date. The starter also acts as a gateway for users to interact with the system via its API.
Now, we add these to our main.go file under the starter directory.

// starter/main.go
package main

import (
 "context"
 "log"

 "github.com/theifedayo/hello-workflow/src/helloworkflow"
 "go.temporal.io/sdk/client"
)

func main() {
 c, err := client.NewClient(client.Options{

 })
 if err != nil {
  log.Fatalln("Unable to make client", err)
 }

 defer c.Close()

 workflowOptions := client.StartWorkflowOptions{
  ID:        "hello_world_workflowID",
  TaskQueue: "hello-world",
 }

 we, err := c.ExecuteWorkflow(context.Background(), workflowOptions, helloworkflow.Workflow, "ifedayo")
 if err != nil {
  log.Fatalln("Unable to execute workflow", err)
 }

 var result string
 // store the result of the run
 err = we.Get(context.Background(), &result)
 if err != nil {
  log.Fatalln("Unable to get workflow result", err)
 }
 log.Println("workflow result:", result)
}

Workers are responsible for executing the tasks. These workers are deployed across different nodes in the system, and their job is to receive the tasks from the starter and execute them. The workers are also responsible for sending the results back to the starter. The Workers can be scaled up or down depending on the workload.

// worker/main.go
package main

import (
 "log"

 "github.com/theifedayo/hello-workflow/src/helloworkflow"
 "go.temporal.io/sdk/client"
 "go.temporal.io/sdk/worker"
)

func main() {
 c, err := client.NewClient(client.Options{})
 if err != nil {
  log.Fatalln("Unable to make client", err)
 }

 defer c.Close()

 w := worker.New(c, "hello-world", worker.Options{})
 w.RegisterWorkflow(helloworkflow.Workflow)
 w.RegisterActivity(helloworkflow.Activity)

 err = w.Run(worker.InterruptCh())
 if err != nil {
  log.Fatalln("Unable to start workflow", err)
 }
}

Starting Everything Up

To start our workflow, we need our temporal server up. Go to your terminal and cd to your project directory and run

docker-compose up

This will start up all the services in our docker-compose.yaml.
Next up, we start our worker.
In general, you should start the workers before the starter, as the starter typically depends on the workers being available to perform their tasks. This means that the workers should be started and initialized before the starter begins to coordinate their activities.

go run src/worker/main.go

2023/02/16 14:03:42 INFO  No logger configured for temporal client. Created default one.
2023/02/16 14:03:43 INFO  Started Worker Namespace default TaskQueue hello-world WorkerID 4465@Ifedayos-MacBook-Pro.local@

And finally, we start the workflow

go run src/starter/main.go

2023/02/16 14:05:52 INFO  No logger configured for temporal client. Created default one.
2023/02/16 14:05:52 workflow result: Hello ifedayo

Viewing Workflows

Navigating to the browser on localhost:8080, we have a UI that gives more information about the workflow

Temporal also provides a CLI tool for interacting with the Temporal server, tctl, which also performs various administrative tasks, such as starting and stopping workflows, querying workflow information, and managing workflow executions.

tctl workflow list

WORKFLOW TYPE |      WORKFLOW ID       |                RUN ID                | TASK QUEUE  | START TIME | EXECUTION TIME | END TIME  
Workflow      | hello_world_workflowID | 0454098f-cdd9-4f64-af8b-ab77a6f86c35 | hello-world | 13:05:52   | 13:05:52       | 13:05:52

Conclusion

In this writing, we've learned how what temporal is, why use it, an illustration of using it in a company, choices of setting up a temporal server, how to start the server inside your go project directory, running workflow and worker, and finally viewing your workflows in a UI or CLI.

Cheers 🥂! You're one step closer to building more reliable applications with Temporal.

Reading FILES as environment variables in nodejs

Ifedayo Adesiyan — Thu, 21 Oct 2021 06:35:12 +0000

Introduction

Recently, I had to write push notification in nodejs for a project, and this took more time to implement considering the time it would have taken if somehow had documented it, hence this article.
In developing softwares, there are some variables that are particular to your environment say test, development, production, staging...and there are particularly some credentials sometimes for third-party apps that you don't want to push to Github, these credentials are usually stored as environment variables which are set to strings and ignored by git as they are listed in your .gitgnore file.
They are usually something like this :

NODE_ENV = development
PORT = 3000
MONGO_URI = mongodb+srv://test-cruise:cruise666@cluster0.q1upa.mongodb.net/cruise-dev-DB?retryWrites=true&w=majority

Step One - Convert your JSON file to base64 encoded string

//convert.js

const fs = require('fs');

//service_account.json is gitgnored
let buff = fs.readFileSync('service_account.json');
let base64data = buff.toString('base64');

console.log(base64data);

Run the following command to convert

node convert.js

Step Two - Set service account variable

In your .env.development file, set SERVICE_ACCOUNT = your_encoded_string. Your encoded string is gotten from logging base64data.

SERVICE_ACCOUNT = Ly8gaW1wb3J0IGRvdGVudiBmcm9tICdkb3RlbnYnOwovLyBpbXBvcnQgZnMgZnJvbSAnZnMnOwovLyBkb3RlbnYuY29uZmlnKCk7CgovLyBpZiAocHJvY2Vzcy5lbnYuTk9ERV9FTlYgPT0gJ3Rlc3QnKSB7Ci8vICAgdHJ5IHsKLy8gICAgIGxldCBkb3RlbnZ0ID0gZG90ZW52LnBhcnNlKGZzLnJlY...........

Step Three

Add SERVICE_ACCOUNT to your secrets and export

//secrets.js

const dotenv = require('dotenv');
const fs = require('fs');

dotenv.config();

if (process.env.NODE_ENV == 'development') {
  try {
    let dotenvt = dotenv.parse(fs.readFileSync('.env.development'));
    for (const k in dotenvt) {
      process.env[k] = dotenvt[k];
    }

  } catch (err) {
     console.log(err);
  }
}

const secrets = {
  .....
  port: process.env.PORT,
  serviceAccount: JSON.parse(Buffer.from(process.env.SERVICE_ACCOUNT, 'base64').toString('utf-8'))
}

export default secrets;

Step 3 - initialize the firebaseSDK, and you're set to go

//push_notification.js

const admin = require('firebase-admin');
const secrets = require('./secrets.js');


admin.initializeApp({
    credential: admin.credential.cert(secrets.serviceAccount)
});


class PushNotification {

    //Replies on a user's comment
    commentReply = async (p) => {
        try {
            const { data, type } = p;     
            const user = await User.findOne({ _id: data.userId }); 
            let payload = {
                notification: {
                    title: 'New reply to your comment',
                    body: `${user.username} replied: ${data.reply}`,
......

Conclusion

The process is convert to base64 => set to environment variable => convert to string
This article is subject to change.
Github || Twitter