Forem: Adeeyo Temitayo

Why Every Millisecond Counts: Understanding Latency in Payments

Adeeyo Temitayo — Fri, 06 Dec 2024 19:51:38 +0000

Imagine this: It's Black Friday, and millions of customers are hitting the "Buy Now" button simultaneously. In the time it takes you to blink – about 300 milliseconds – dozens of payment transactions have either succeeded or failed. Each transaction is a race against time, where delays as small as 100 milliseconds can mean the difference between a completed purchase and an abandoned cart. In the world of payment processing, these milliseconds aren't just numbers – they're the heartbeat of your system.

The Real Cost of Time
When processing payments, time isn't just money – it's trust, user experience, and competitive advantage all rolled into one. Here's what can happen in the blink of an eye:

A stock trader loses a crucial opportunity because their payment took 50ms too long
A customer abandons their cart because the payment confirmation didn't arrive quickly enough
A cross-border transaction gets delayed because of cascading latency across multiple systems

What is Latency, Really?

At it's core, latency is the time delay between starting an action and completing it. In payment systems, this refers to the time between when a user initiates a transaction and when they receive a confirmation. It's often pictured as a simple request-response flow:

But in reality, modern payment systems are far more complex:

As you can see, there's a lot more happening behind the scenes!

The Two Key Components of Latency

Latency breaks down into two major parts:

1.Network Latency: This is the time it takes for transaction data to travel between systems. While important, network latency is often beyond your control, especially in cross-border transactions or when dealing with multiple payment rails (different payment pathways like Visa, MasterCard, etc.).

2.Processing Latency: This is the "hidden" work that happens during transaction processing. It includes:

KYC/AML verification checks (Know Your Customer/Anti-Money Laundering)
Fraud detection systems
Balance checks and holds
Currency conversion calculations
Regulatory compliance checks
Settlement processing (finalizing the transaction)
Payment rail routing decisions (deciding which payment provider to use)

A Real-World Example: Cross-Border Payment

Let's break down a typical cross-border payment:

Initial request network time: 50ms
Account validation: 6ms
KYC/AML verification: 50ms
Fraud detection: 25ms
Currency conversion: 10ms
Payment rail routing: 15ms
Final response: 25ms _Total Latency: 181ms _ As you can see, the actual processing involves multiple steps, each adding a bit of time to the overall transaction. It's not just about how fast data travels, but also about all the checks and processing that occur.

Measuring Performance: Going Beyond Averages

While average response times are helpful, they can be misleading. A single slow transaction could mean a missed opportunity or frustrated user. This is where percentiles come in — offering a clearer picture of real-world performance:

Understanding Percentiles:

P50 (Median): 50% of transactions are completed faster than this time
P90: 90% of transactions complete within this time
P99: 99% of transactions complete within this time
P100 (Maximum): The slowest transaction time

For example, in a system processing 1,000 transactions:

P90 of 200ms means 900 payments are processed faster
P99 of 400ms means 990 payments are processed faster
P100 of 2000ms represents the slowest payment

Why Percentiles Matter

Percentiles help you:

Spot problematic transactions before they lead to customer complaints
Set realistic service level agreements (SLAs)
Understand performance across different payment methods
Make informed decisions about system optimization

Understanding Throughput

Latency tells you how quickly you can process a single transaction. Throughput, on the other hand, tells you how many transactions you can handle per second. These two metrics go hand in hand, especially during high-volume periods like market openings or holiday shopping peaks.
Think of latency as speed and throughput as capacity. While latency is about how fast a single transaction is processed, throughput is about how many transactions your system can handle at once.

Best Practices for Latency Optimization

Here are some battle-tested strategies to keep your system running smoothly:

1.Monitor Everything (But Separately)

Track the performance of each payment provider
Monitor third-party service response times
Keep logs of verification check durations
Watch processing times across regions

2.Use Percentiles Strategically

Set different SLAs for different transaction types
Monitor performance by region to identify localized issues
Track performance patterns during peak hours
Set up alerts for unusual spikes

3.Optimize Strategically

Prioritize high-volume routes
Use smart routing between providers
Cache frequently used data
Optimize verification workflows
Use connection pooling for external services

4.Design for Resilience

Implement smart timeouts to handle slow processes
Use circuit breakers for failing services
Have backup providers ready
Plan for reconciliation
Consider regional processing centers

Real-World Impact

To put it into perspective, improving transaction time by just 200ms may not sound like much. But multiply that improvement across millions of daily transactions, and you're looking at:

Better user experience (transactions happen faster)
Reduced abandonment rates (users are less likely to drop off)
Higher transaction success rates (more payments complete)
Lower operational costs (less time and resources spent on retries)
Improved customer satisfaction (faster service equals happier customers)

Conclusion

Understanding latency is crucial when building payment systems that need to be both fast and reliable. By considering all components of transaction latency — beyond just network delays — you can build better systems that deliver both performance and security.

Remember:

Your system is only as good as its slowest transaction.

Identifying where that slowdown occurs is the first step in optimizing your system and improving user satisfaction.

How to Build Reliable Fintech Systems: Key Technical Patterns You Need to Know

Adeeyo Temitayo — Wed, 27 Nov 2024 17:28:09 +0000

Financial technology (fintech) has revolutionized how we handle money, transforming traditional banking services into seamless digital experiences. However, building fintech applications requires meticulous attention to technical patterns that ensure transaction safety, data integrity, and financial accuracy.

This guide explores three critical technical patterns that every fintech developer must implement to build reliable and secure financial applications. Whether you're developing a payment processing system, digital wallet, or banking platform, these patterns will help you avoid common pitfalls that can lead to financial discrepancies and security vulnerabilities.

While this guide focuses on three fundamental patterns that form the backbone of secure fintech applications, implementing these patterns alongside robust security measures, comprehensive testing, and regulatory compliance is crucial for a production-ready fintech system.

What is Fintech?

Fintech stands for financial technology – it's the intersection of traditional banking and modern technology. Think of fintech as a bridge that connects the traditional banking sector with the tech world. What once required physical bank visits and paper forms can now be accomplished with a few taps on your smartphone, thanks to fintech innovations.

1. For Inflow and Outflow transactions, always use ACID transactions.

Why? Let’s break this down with examples.

Case 1: Without ACID Transactions

Imagine you’re handling a user’s account where their balance is debited during a transfer. Here’s a simplified version of what the code might look like:

const user = {
  id: '1212121',
  balance: 100,
  currency: 'USD',
};

// User sends money to a friend
function sendMoney(amount) {
  // Step 1: Check if the user has enough balance
  if (user.balance >= amount) {
    // Step 2: Deduct the amount
    user.balance -= amount;
    console.log(`Transaction successful. New balance: ${user.balance}`);
  } else {
    console.log('Insufficient balance.');
  }
}

// Simulate sending $50
sendMoney(50);
// New balance is 50

Case 2: On-the-Fly Balance Updates with findOneAndUpdate

const users = [
  { id: '1212121', balance: 100 },
  { id: '3434343', balance: 50 },
];

// Simulate sending $50 from User 1 to User 2
function transferFunds(senderId, receiverId, amount) {
  // Find sender
  const sender = users.find((user) => user.id === senderId);

  if (sender && sender.balance >= amount) {
    // Deduct from sender
    sender.balance -= amount;

    // Update receiver's balance
    const receiver = users.find((user) => user.id === receiverId);
    if (receiver) {
      receiver.balance += amount;
      console.log('Transfer successful:', { sender, receiver });
    } else {
      console.log('Receiver not found.');
    }
  } else {
    console.log('Insufficient funds or sender not found.');
  }
}

// Transfer funds
transferFunds('1212121', '3434343', 50);
// Logs: Transfer successful: {sender: {…}, receiver: {…}}

This code looks functional but is risky without an ACID-compliant transaction. Imagine if the application crashes after the sender’s balance is deducted but before the receiver’s balance is updated. The money essentially disappears, causing financial discrepancies.

The Risk in Real-Life Terms

Without ACID transactions, your fintech app can suffer from:

Inconsistent Data: For example, if a user's balance is deducted but the transfer isn’t completed, it leads to a mismatch between accounts.
Real-life analogy: Imagine withdrawing money from an ATM, but the cash doesn’t come out even though your account is debited.
Data Corruption: A failed or partial update can leave your database in an unpredictable state, especially under high concurrency.
Real-life analogy: Think of a cashier debiting your account but failing to provide a receipt – neither party knows if the transaction went through.
Customer Dissatisfaction: Issues like "missing money" can lead to angry customers, loss of trust, and legal implications.

Solution: Use ACID Transactions

By using database mechanisms that ensure Atomicity, Consistency, Isolation, and Durability (ACID), you guarantee that all parts of the transaction either succeed or fail as a single unit.
Here’s how it would look:

async function transferFundsACID(senderId, receiverId, amount) {
  // Start a new session for the transaction
  const session = await database.startSession();
  session.startTransaction(); // Begin the transaction

  try {
    // Attempt to deduct the amount from the sender's balance
    const sender = await User.findOneAndUpdate(
      { id: senderId, balance: { $gte: amount } }, // Ensure sender has sufficient balance
      { $inc: { balance: -amount } }, // Deduct the specified amount
      { session, new: true } // Use the session for transactional consistency
    );

    // If the sender doesn't exist or has insufficient balance, throw an error
    if (!sender) {
      throw new Error('Insufficient balance or sender not found');
    }

    // Attempt to credit the amount to the receiver's balance
    const receiver = await User.findOneAndUpdate(
      { id: receiverId }, // Find the receiver by their ID
      { $inc: { balance: amount } }, // Credit the specified amount
      { session, new: true } // Use the same session to ensure consistency
    );

    // If the receiver doesn't exist, throw an error
    if (!receiver) {
      throw new Error('Receiver not found');
    }

    // If both operations succeed, commit the transaction
    await session.commitTransaction();
    console.log('Transaction successful:', { sender, receiver });
  } catch (error) {
    // If any operation fails, roll back the transaction to maintain data integrity
    await session.abortTransaction();
    console.error('Transaction failed:', error.message);
  } finally {
    // End the session to clean up resources
    session.endSession();
  }
}

Using transactions ensures that all operations are executed as a single unit, greatly reducing risks and maintaining data integrity.

Takeaway

Always use ACID transactions when handling financial operations. It’s not just good practice – it’s essential for building trust and reliability in your fintech app.

2. Always Debit the Customer Before Delivering Value to Avoid Risks

This might sound obvious, but there are scenarios where value is given before the customer's wallet is debited. Let's analyze both approaches with examples.

Case 1: Debiting Before Giving Value (Preferred Approach)

In this approach, the customer's account is debited first, and only if the debit is successful, the value is provided (e.g., a product is delivered or a service is activated). This ensures that the app avoids situations where value is given without receiving payment.

Example:

async function processPurchaseACID(customerId, amount, value) {
  const session = await database.startSession();
  session.startTransaction();

  try {
    // Step 1: Debit the customer's account
    const customer = await User.findOneAndUpdate(
      { id: customerId, balance: { $gte: amount } }, // Ensure sufficient balance
      { $inc: { balance: -amount } }, // Deduct the amount
      { session, new: true } // Use the transaction session
    );

    if (!customer) {
      throw new Error('Insufficient balance or customer not found');
    }

    // Step 2: Provide the value (e.g., activate subscription, deliver product)
    const valueProvided = await Value.create(
      { customerId, value },
      { session } // Use the transaction session
    );

    // Commit the transaction after successful debit and value provisioning
    await session.commitTransaction();
    console.log('Purchase successful:', { customer, valueProvided });
  } catch (error) {
    // Rollback transaction on failure
    await session.abortTransaction();
    console.error('Purchase failed:', error.message);
  } finally {
    // End session
    session.endSession();
  }
}

Case 2: Giving Value Before Debiting (Risky Approach)

In this approach, the value is provided first, and the user's account is debited afterward. This can lead to major issues, such as the customer receiving the value but the debit failing due to insufficient balance, system crashes, or concurrency issues.

Example:


async function processPurchaseWithoutACID(customerId, amount, value) {
  try {
    // Step 1: Provide the value first (e.g., activate subscription, deliver product)
    const valueProvided = await Value.create({ customerId, value });

    // Step 2: Attempt to debit the customer's account
    const customer = await User.findOneAndUpdate(
      { id: customerId, balance: { $gte: amount } }, // Ensure sufficient balance
      { $inc: { balance: -amount } }, // Deduct the amount
      { new: true } // No transaction control
    );

    if (!customer) {
      console.log('Debit failed after providing value. Manual reconciliation needed.');
    } else {
      console.log('Purchase successful:', { customer, valueProvided });
    }
  } catch (error) {
    console.error('Error during purchase:', error.message);
  }
}

Risks of Giving Value Before Debiting

Insufficient Funds: If the customer's balance is insufficient after providing value, the app must handle reconciliation manually. Real-life analogy: Imagine sending an online order before the payment is confirmed, only to find out the customer’s card has insufficient funds.
System Crashes or Errors: If a failure occurs after providing value but before debiting the account, the customer receives the value for free.
Concurrency Issues: In highly concurrent systems, other transactions might reduce the customer's balance before the debit, causing the debit to fail.

Takeaway

Always debit the customer's account first before giving value. This approach avoids critical issues like unpaid value, ensures better data integrity, and reduces financial losses. Using ACID transactions in this workflow guarantees that the operations (debit and value provisioning) succeed or fail as a single unit, ensuring consistency and reliability.

3. Always Keep a Ledger and Journal Table to Track Inflows and Outflows

It's essential to maintain a ledger and journal in your system to keep track of all financial transactions. Here’s why:

Audit & Transparency: A ledger helps you keep a clear record of balances, which is critical for audits and regulatory compliance.
Dispute Resolution: Journals track individual transactions, making it easier to resolve disputes.
Fraud Prevention: Detailed records help spot irregularities and prevent fraudulent activities.
Error Recovery: If something goes wrong, the ledger and journal help restore the correct state of the system.
Reconciliation: They ensure that your internal records match external financial accounts.

Real-World Applications

Digital Wallet Systems
Payment apps like Venmo and Cash App use ACID transactions to ensure money transfers complete fully or not at all
Example: When splitting a dinner bill, the app must handle multiple simultaneous transfers without double-charging or losing funds
Investment Platforms
Trading platforms like Robinhood implement debit-before-value to ensure users have sufficient funds before executing trades
Example: When purchasing stocks, the system verifies and locks funds before placing the order
Subscription Services
Streaming services like Netflix use ledger systems to track recurring payments and usage
Example: When a subscription payment fails, the system can reference the ledger to determine the last successful payment and current service status
International Money Transfers
Services like Wise use all three patterns to handle currency conversions and cross-border transfers
Example: Converting USD to EUR requires atomic transactions across multiple currency accounts while maintaining detailed records

Testing Financial Operations

Implementing robust testing strategies is crucial for fintech applications. Here are essential testing approaches:

Unit Testing Transaction Flows

describe('TransferService', () => {
  it('should successfully complete transfer when sender has sufficient funds', async () => {
    const result = await transferFundsACID('sender123', 'receiver456', 100);
    expect(result.status).toBe('success');
    expect(result.senderBalance).toBe(previousBalance - 100);
  });

  it('should roll back transfer when receiver account is invalid', async () => {
    const result = await transferFundsACID('sender123', 'invalid456', 100);
    expect(result.status).toBe('failed');
    expect(result.senderBalance).toBe(previousBalance);
  });
});

Concurrency Testing
Implement stress tests simulating multiple simultaneous transactions
Test race conditions with parallel requests to the same account
Verify transaction isolation levels under heavy load
Integration Testing
Test the entire transaction flow from API to database
Verify ledger entries match actual balance changes
Ensure proper error handling and rollback mechanisms
Reconciliation Testing


describe('LedgerReconciliation', () => {
  it('should match account balance with sum of transactions', async () => {
    const account = await Account.findById('acc123');
    const transactions = await Transaction.find({ accountId: 'acc123' });
    const calculatedBalance = transactions.reduce((sum, tx) => 
      sum + (tx.type === 'credit' ? tx.amount : -tx.amount), 0);
    expect(account.balance).toBe(calculatedBalance);
  });
});

Conclusion: Building Reliable Fintech Systems

The three patterns we've explored – implementing ACID transactions, ensuring proper debit-before-value delivery, and maintaining comprehensive ledger systems – form the foundation of reliable fintech applications. Together, these patterns create a robust framework that:

Guarantees transaction integrity and prevents data inconsistencies
Protects against financial losses through proper sequence management
Maintains clear audit trails for compliance and dispute resolution

When implementing these patterns, remember that they work synergistically. ACID transactions ensure atomicity across operations, proper debit sequencing prevents value leakage, and detailed ledger systems provide transparency and traceability. Following these patterns will help you build fintech applications that users can trust with their financial transactions.

I hope you found these insights helpful as you embark on your journey into the world of fintech. If you're working on a fintech project, I'd love to hear about it in the comments – let's start a conversation! And if you'd like to see more articles like this, just let me know. Stay curious, and happy coding!

DNS Explained: A Beginner's Guide to Domain Name Systems

Adeeyo Temitayo — Tue, 19 Sep 2023 19:02:33 +0000

Have you ever been amazed at how, with a simple click, you can go from typing "www.google.com" into your browser to being on Google's website in an instant? It's like a digital magic trick, right?

Well, let me share the secret with you: this digital wizardry is all thanks to a basic but often overlooked system known as DNS, or the Domain Name System.

In this article, we're going to explore three key concepts:

DNS: The Internet's Address Book
Domain Names: The Names of the Web
DNS Resolvers: Your Internet Tour Guide

What is DNS?

DNS stands for Domain Name System. Think of it as the internet's address book. When you want to visit a website, your computer needs to know where to find it in the vast digital landscape. DNS is like the GPS for the internet, helping your device find the right destination.

What's a domain name?

A domain name is simply the agreed-upon name for a website. It's what you type into your browser's search bar to get to a specific site, like "www.google.com" for Google. Think of it as the internet's version of a street address.

How does it all work?
When you type a domain name like "www.google.com" into your browser, there's more to it than meets the eye. Behind that simple name lies a hidden digital address called an IP address. This IP address is like the coordinates on a map that tells your device exactly where to find the website you're looking for.

But here's where the magic happens: a special helper called a DNS resolver steps in. You can think of a DNS resolver as your trusty internet tour guide. It's a bit like a router that knows the way to the website's IP address. When you ask to visit a site, the DNS resolver figures out the path to get there, ensuring you reach your digital destination.

So, the next time you marvel at the speed and simplicity of the internet, remember that behind the scenes, DNS is the unsung hero making it all possible. It's the magic that turns your words into websites! 🌐✨

Leave Management system Node, MongoDB, Express

Adeeyo Temitayo — Sat, 21 Nov 2020 21:00:24 +0000

Node.js is eating the world. Many of the largest companies are building more and more of their backend using Node.js, NODEJS IS GROWING WE ARE ALSO GROWING.

This tutorial will take you step-by-step through building a fully functional Leave Management system. Along the way you’ll learn about Express.js, the most popular web framework, user authentication, locking down routes to enforce login restrictions, and performing CRUD operations with a database (creating, reading, updating, and deleting data). This tutorial uses the following technologies but doesn’t require any prior experience:

What we want to do.
We want to build a leave management system where a registered staff of an organization can request leave and the admin(manager or HR) will approve the leave request and an email notification will be sent to the staff.
This article will be broken into Modules.
1:Overview of dependencies, project setup, and server setups.
2:Authentication
3:Authorization
4:Leave request and approval

Main Dependencies
1:Nodejs must be installed
2:MongoDB database
3:Babel
4:sendGrid

Overview of dependencies, project setup, and server setups.
The src folder contains the source file of the project. the purpose of each of the subfolders will be explained subsequently.

Let's get to it.
Create a server.js file in the root folder and copy this into the empty file.

const express = require("express");
const app = express();
const port = process.env.PORT || 3000;
const vm = require("v-response");
const morgan = require('morgan');
const mongoose = require("mongoose")
app.use(express.json());
app.use(morgan('dev'));
const database = 'mongodb://localhost:27017/levemanagementdb';

mongoose.connect((database), {
    useUnifiedTopology: true,
    useFindAndModify: false,
    useNewUrlParser: true,
    useCreateIndex: true,
})
    .then(async () => {
        vm.log("connected to database", database);
    })
    .catch(err => vm.log("error mongodb", err));


app.listen(port, () => vm.log("server running on port:", port));

The server.js file will start up our Nodejs server to run this you can type this to your terminal

node server.js

If all goes well you should get this in your terminal

We need to create an endpoint whereby users can register to achieve that we need to create an authentication folder in our project and create four files inside the folder (auth.model.js,auth.route.js,auth.controller.js, auth.validation.js) in the auth. model file

const mongoose = require("mongoose");
const Schema = mongoose.Schema;


const userSchema = new Schema({
    fullname:{
        type: String

    },
    manager: {
        type: Schema.Types.ObjectId,
        ref: "user"
    },
    email: {
        type: String
    },
    password: {
        type: String
    },
    role: {
        type: String,
        enum: ['manager', 'staff'],
        default: 'staff'
    },
    deleted: {
        type: Boolean,
        default: false
    }
}, {timestamps: true});

const Usermodel = mongoose.model('user', userSchema, 'Users');
module.exports = Usermodel

auth.validation.js:

'use strict';
const Validator = require("validatorjs");

export const UserValidator = {
    /**
     * @param {Object} obj The validation object
     * @return {Object}
     * */
    validateAccount(obj) {
        const rules = {
            email: 'required|string',
            password: 'required|string',
            fullname: 'required|string',
            manager: 'required|string',

        };
        const validator = new Validator(obj, rules);
        return {
            errors: validator.errors.all(),
            passed: validator.passes(),
        }
    },
};

auth.controller.js

const UserValidator = require("./auth.validator");
const _ = require("underscore");

const User = require("./auth.model");
const vm = require("v-response");

/**
 * @controller User authentication controller
 * */
/**
 * @param
 * */

//CREATE ACCOUNT
exports.CreateAccount = async (req, res, next) => {
    try {
        let obj = req.body;
        const validateUserInput = await UserValidator.validateAccount(obj);
        if (!validateUserInput.passed) {
            return res.status(400)
                .json({
                    status: false,
                    code: 400,
                    message: "There's error in your inputs",
                    errors: validateUserInput.errors,
                })
        }
        const checkUserEmail = await User.findOne({email: req.body.email})
        if (checkUserEmail) {
            return res.status(409)
                .json(vm.ApiResponse(false, 409, 'email already exist'))
        } else if (!checkUserEmail) {

            _.extend(obj, {
                password: await vm.hashedPassword(obj.password, 10),
            });
            const account_object = await new User(obj);
            const saveAccount = await account_object.save();
            if (!saveAccount) {
                return res.status(400)
                    .json(vm.ApiResponse(false, 400, "Oops! an error occurr"))
            } else {
                saveAccount.password = null;
                return res.status(201)
                    .json(vm.ApiResponse(true, 200, `account created`, account_object));
            }
        }
    } catch (e) {
        return next(e);
    }

}


//LOGIN
exports.login = async (req, res, next) => {
    try {
        const checkEmail = await User.findOne({email: req.body.email});
        if (!checkEmail) {
            return res.status(400)
                .json(vm.ApiResponse(false, 400, 'email not found'))
        } else {
            const compareEmail = vm.comparepassword(checkEmail.password, req.body.password);
            if (compareEmail) {
                const signtoken = vm.signToken(checkEmail._id, 'yourSecret');
                checkEmail.password = null;
                return res.status(200)
                    .json(vm.ApiResponse(true, 200, "login sucessfull", {user: checkEmail, token: signtoken}))
            }
        }
    } catch (e) {
        return next(e);
    }

};

//list manager so when staff needs to register they can select their managers 
exports.listManagers = async (req, res, next) => {
    try {

        const findMangers = await User.find({role: "manager"})
        if (findMangers) {
            return res.json(findMangers);
        } else if (findMangers.length === 0) {
            return res.json('0 managers')
        } else {
            return res.json("Oops! an error occurr")
        }
    } catch (e) {
        return next(e);
    }
}

auth.route.js

'use strict';
const {Router} = require('express');
const UserController = require("./auth.controller");

const router = Router();
router.post("/create/account", UserController.CreateAccount);
router.post("/account/login", UserController.login);
router.get("/managers/list", UserController.listManagers);

module.exports = router;

So We are done with the first module which enables users to register and login into their account so in the next module we will be working on sending a leave request as a staff and notifying the manager of the leave request via email and also notify the staff when the manager approves or reject leave request for the email notification we will be using SendGrid you can create an account https://signup.sendgrid.com/

Create a Mailer.js file

'use strict';
const Helper = require("sendgrid").mail;
const sg = require('sendgrid')('yourkey');
const vm = require("v-response");
module.exports.sendMail = sendMail;
function sendMail(from, to, subject, content, template) {
    let fromEmail = new Helper.Email(from);
    let toEmail = new Helper.Email(to);
    let emailContent = new Helper.Content("text/html", content);
    let mail = new Helper.Mail(fromEmail, subject, toEmail, emailContent);

    let isEmailSent = false;
    let request = sg.emptyRequest({
        method: 'POST',
        path: '/v3/mail/send',
        body: mail.toJSON()
    });

    sg.API(request, function (err, response) {

        if (err) {
            vm.log("error");
            vm.log("err in sendgrid: ", err);
            isEmailSent = false;
        }
        vm.log("sendgrid body:", response.statusCode);
        isEmailSent = true;
    });
    return isEmailSent;

}

Create a leave folder and create three files(leave.model.js,leave.route.js,leave.controller.js)

Leave.model.js

const mongoose = require("mongoose");
const Schema = mongoose.Schema;

const leaveSchema = new Schema({
    reason: {
        type: String
    },
    staff: {
        type: Schema.Types.ObjectId,
        ref: "user"
    },
    leave_status: {
        type: String,
        enum: ['pending', 'approved', 'rejected'],
        default: "pending"
    }

}, {timestamps: true})


const leaveModel = mongoose.model("leave", leaveSchema, "Leave");
module.exports = leaveModel;

Leave.controller.js

const {sendMail} = require("../util/mailer");

const LeaveModel = require("./leave.model");
const User = require("../authentication/auth.model");
const _ = require("underscore");
const vm = require("v-response");

//request  leave
exports.requestLeave = async (req, res, next) => {
    try {
        const find_user = await User.findById(req.body.staff);
        if (!find_user) {
            return res.status(400)
                .json(vm.ApiResponse(false, 400, 'Invalid user details or unverified account'))
        } else {
            const leaverequestBody = _.extend(req.body, {staff: find_user._id, reason: req.body.reason})
            const createLeaveRequest = await new LeaveModel(leaverequestBody);
            await createLeaveRequest.save();
            const find_manager = await User.findOne({_id: find_user.manager});
            //notify staff manager about leave request
            await sendMail('noreply@leavemanagement', find_manager.email, 'Leave Request', `${find_user.fullname} is requesting for leave`);
            return res.status(200)
                .json(vm.ApiResponse(true, 200, "leave request sent"))
        }
    } catch (e) {
        return next(e);
    }

};

exports.approveLeaveOrRejectLeave = async (req, res, next) => {
    try {
        const findLeave = await LeaveModel.findById(req.query.leave_id);
        const findstaff = await User.findById(findLeave.staff);
        if (!findLeave) {
            return res.status(404)
                .json(vm.ApiResponse(false, 400, 'Leave request not found'))
        } else if (findLeave) {
            if (req.body.approvalstatus === 'approved') {
                await sendMail('noreply@leavemanagement', findstaff.email, 'Leave Approval', `Hello ${findstaff.fullname},your leave request has been approved`);
            } else {
                await sendMail('noreply@leavemanagement', findstaff.email, 'Leave Approval', `Hello ${findstaff.fullname},your leave request has been rejected `);
            }
            findLeave.leave_status = req.body.approvalstatus;
            await findLeave.save();
            return res.status(200)
                .json(vm.ApiResponse(true, 200, "leave request status updated successfully"))
        }
    } catch (e) {
        return next(e);
    }

};

Leave.route.js

'use strict';
const {ManagerChecker} = require("../util/RoleChecker");

const {Router} = require('express');
const LeaveController = require("./leave.controller");

const router = Router();
router.post("/request/leave", LeaveController.requestLeave);
//the ManagerChecker ensures that only a manager can approve or reject a leave request 
router.patch("/update/leave/status", ManagerChecker, LeaveController.approveLeaveOrRejectLeave);

module.exports = router;

Create a MangerCheck.js file

const User = require("../authentication/auth.model");
const jwt = require("jsonwebtoken")

exports.ManagerChecker = async (req, res, next) => {
    let token = req.headers.authorization;
    if (!token) {
        return res.status(400)
            .json("please login to continue")
    }
    if (token !== undefined) {
        let decodeToken = jwt.decode(token);
        let id = decodeToken.id;
        if (id) {
            let user = await User.findById(id);
            if (user && user.role !== 'manager') {
                return res.status(403).json({
                    status: false,
                    code: 403,
                    message: 'You are not authorized to do this action'
                })
            } else {
                return next();
            }
        }
    }
    return next();
}

And lastly, let's seed a manager account so we can test all our hard work if you've made it this far "Ooin you're doing well"

CREATE A seeder.js file

const mongoose = require("mongoose");
const bcrypt = require("bcryptjs");
mongoose.Promise = require('bluebird');
const db = 'mongodb://localhost:27017/levemanagementdb';

mongoose.connect(db);
const User = require("../authentication/auth.model");

async function seedUser() {
    const hash = await bcrypt.hash('password123', 10);
    User.create({
        email: "youremail@gmail.com",
        password: hash,
        fullname: "staff manager",
        role: 'manager',
    }).then(user => {
        console.log(`${user} user created`);
    }).catch((err) => {
        console.log(err);
    }).finally(() => {
        mongoose.connection.close();

    })
}
seedUser();

To use the seeder file add this to the script in your package.json file

"seed": "node util/seeder.js"

then run

npm run seed

if all goes well you should see this in your terminal

 user created

then start your Nodejs server

See API Documentation:https://www.getpostman.com/collections/02507f8d63e1342d42f6

See Github Repository:
https://github.com/waletayo/LeaveManagement-System-Node---devto/tree/main

You can also add other features to this simple leave management Restapi or do let me know in the comment section what you look out for next

Thank you Guys!!!

Creating a Subscription Application with Nodejs and MongoDB

Adeeyo Temitayo — Tue, 04 Aug 2020 19:21:03 +0000

Hey there,
This tutorial will guide you step-by-step through building a fully functional subscription-based platform. Along the way, you’ll learn about Express.js, a web application framework for Node.js.

What We’re Building.

We’ll create a subscription-based platform where customers need to subscribe to one of our plans to access exclusive content. Our plans will include options like weekly and monthly subscriptions.

Article Structure

This guide is divided into the following modules:

Overview of dependencies,project setup, and server setup
Authentication
Cron job setup

Main Dependencies

To follow along, make sure you have:

Node.js installed
MongoDB as the database
Moment.js for date manipulation
Node-cron for scheduling tasks
v-response for structured responses

Let’s dive in and get our hands dirty!

Server.js File

This is where we’ll set up our development server.

Upon successfully setting up the server, you should see the following logged in your console:

Creating the Plan Model

Let’s define our plan model file.

Creating the Plan Controller

Here, we’ll write the logic to manage our subscription plans.

Creating the Plan Routes

Next, we’ll set up the routes to handle plan-related endpoints.

Helper File for Payment and Subscription Dates

We need to create a helper file to process payments and calculate the user’s next payment date.

Creating the Signup Model

Now, let’s create the signup model to manage user registration and subscriptions.

Creating the Signup Controller

This is where we’ll handle user registration and payment processing. We’ll use Paystack as the payment gateway, but feel free to use any other provider of your choice.

Restricting Access to Subscribed Users

We’ll configure the login functionality to ensure that only subscribed users can access the platform.

Setting Up a Cron Job

Finally, we’ll use a cron job to deactivate user accounts once their subscriptions expire.

Additional Features

Here are a few more features you could consider adding:

Auto-renewal of subscriptions
Notifications to remind users of upcoming payments

If you’d like me to write a part two covering these features, let me know in the comments!

Source code

Seed MongoDB (mongoose-seed)

Adeeyo Temitayo — Tue, 19 Nov 2019 09:06:37 +0000

Firstly What is database seeding?

Seeding a database is a process in which an initial set of data is provided to a database when it is being installed. It is especially useful when we want to populate the database with data we want to develop in future.

Now that we know what database seeding is let write some code,I believe you are familiar with Nodejs and MongoDB, so set up your Nodejs server. then create a product.model.js file and write the following:

Create product.controller.js file and write the following to create a product:

Now create a product.route.js file and write the following:

Now let create our seed.js file and write the following :

In your package.json add a seed script:

now run

npm run seed

to seed data to MongoDB

to read more on mongoose-seed

Enjoy!!!

Upload Multiple images to cloudinary Node, MongoDB, Express

Adeeyo Temitayo — Tue, 19 Nov 2019 08:38:42 +0000

Hello there
In this post we are going to create a backend Node JS server that uses the cloudinary library to upload multiple images at once because cloudinary doesn't support multiple images by default so we are going to find a way around it. Brace yourselves, I hope you are excited as I am.

Requirements

We will need the following installed on our machines to get started;

Node JS
MongoDB
Cloudinary account Click here

Let get started.

First, we create our project folder and also initialize our project using the following.

mkdir cloud_mutilple_image
cd cloud_mutilple_image
npm inti

which would create a package.json file for us.

PROJECT STRUCTURE

Next, we would structure our project, in the root folder we would need to create a server.js file, which would be the main entry point of our application, then we will need a helper folder to contain our application helper.js file. Our project structure would look like this.

package.json:

Server.js file Where we will be starting our development server

helper.js file where will have our upload (helper) function

Now let create a user folder where we will have Our user.controller.js, user.model.js and user.route.js

user.model.js

user.controller.js

find all created user:

user.route.js

Now let test our endpoints:

create endpoint:

find endpoint:

Click Here to Get source code

Build An Authentication system with node, express, and MongoDB

Adeeyo Temitayo — Tue, 19 Nov 2019 08:37:50 +0000

Over the years, I have been able to adopt an interesting approach to register a user as well as log in the user. Am delighted to share a few decision that has worked for me and I find useful and worthwhile. And I hope to get comments and more insight from you guys to further help me learn and become better. Yes, we are all learning.

What we want to do.

I will assume you have an existing understanding of javascript, node js, express, and MongoDB. we want to set up a platform whereby a user can register as well as login to there account

Main Dependencies

Nodejs must be installed
Mongo DB
Passport
Babel
JSON WEB TOKEN

Overview of dependencies, project structuring.

The src folder contains the source file of the project. the purpose of each of the subfolders will be explained subsequently.

The package.json file and the basic dependencies

A config folder to help specify variables required click here to have a better understanding of how the environment variables are loaded. here is the default config file.

Server.js file
Where we will be starting our development server

On a successful server setup in your console, you should have this logged.

Now that the server is up and running let write some code, let create a register model (create a register.model .js file) and put in the following

Now let create our register controller (create a register.controller.js file)

Now let create our route

Guys, we are still on track now that we have a registered user let create our Login controller and route (create a login.controller.js file)

Let create our login route(create a login.route.js file)

Guys now that we are done let test what we've done so far :
Using Postman (Create a user).

Let try to login with our Email and password :

Wow we finally built An Authentication system with node, express, and MongoDB thank you for your patience
Source code