DEV Community: Caleb Nkunze

MarketMail

Caleb Nkunze — Tue, 27 May 2025 21:37:12 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built 🚀

MarketMail – a crowdsourced produce‑price exchange for Uganda & East Africa that runs entirely by e‑mail.

Farmers or enumerators send a simple price list to prices@your-domain.com; Postmark’s inbound webhook feeds the data into a Node.js API, which:

Parses and validates the e‑mail (body or CSV/XLSX attachment).
Normalises units/currency and stores records in MongoDB.
Calculates daily deltas and 7‑day averages.
Sends the sender an automated market‑trend report.
Publishes an open JSON API and a React dashboard so anyone can view live prices.

The flow works from any basic e‑mail client, so even users on feature phones with intermittent data can contribute and benefit.

Demo 📹

Live URL: https://marketmail.vercel.app

Test: e‑mail the sample below to send@marketmail.canktech.com.

Country: Uganda
Market: Nakasero
Date: 2025‑05‑28
Maize (kg): 1850
Beans (kg): 2950
Tomatoes (crate): 9800

You’ll receive a reply within ~10 s containing a cleaned table and a mini market report. The dashboard at https://marketmail.vercel.app/dashboard?market=Nakasero will update automatically.

Code Repository 🗄️

https://github.com/Cank256/market-mail (MIT licence)

How I Built It 🔧

Email layer: Postmark inbound/outbound (signature verification, bounce hooks).
Backend: Node.js 20, Express, TypeScript, Zod validation.
Parsing: RegEx + optional OpenAI for fuzzy headers; papaparse / xlsx for attachments.
Data: MongoDB Atlas (MarketPrice schema, aggregation pipelines).
Front‑end: React 18 + Vite, Recharts, Tailwind CSS + shadcn/ui.
CI/CD: GitHub Actions → Vercel.
Accessibility: Plain‑text fallbacks, semantic HTML, dashboard passes WCAG 2.1 AA.
Dev‑experience: Detailed PROJECT.md, Jest tests cover parser & API routes.

Team: solo submission — Caleb Nkunze @cank256.

Exploring Flix256: A Journey into Multimedia Content Discovery

Caleb Nkunze — Tue, 20 Feb 2024 16:35:41 +0000

Screenshot of Flix256 homepage header

Introduction

Flix256 is an innovative platform designed to revolutionize the way users explore and engage with multimedia content, including movies and TV shows. Over the course of a few weeks, I meticulously crafted Flix256 with the goal of providing users with an intuitive and immersive entertainment experience. The project targets movie enthusiasts, TV show aficionados, and anyone seeking quality entertainment options.

A Personal Connection to Flix256

My wife would always want me to search and update her of the upcoming, new and popular movies and TV shows (believe me it was one of my superpowers that I would put in play). That coupled with my personal desire for the same desire to always be updated of the great moving pictures that studios around the world had to offer ignited my interest in creating a platform like Flix256, where users can discover and enjoy captivating content effortlessly. My journey from avid viewer to project contributor has been shaped by a deep appreciation for the transformative power of multimedia entertainment.

Project Accomplishments

Flix256 boasts a robust architecture designed to streamline content discovery and enhance user engagement.

Flix256 Architecture

Leveraging cutting-edge technologies such as Vue.js for frontend development and Flask for backend operations, the platform delivers a seamless browsing experience across devices. Key features include personalized recommendations, advanced search functionality, and interactive user profiles. My commitment to innovation and user-centric design sets Flix256 apart as a premier destination for multimedia enthusiasts.

Technical Challenges

One of the most exhilarating aspects of this project’s journey was navigating the integration of Flask and Nuxt.js, two powerful technologies that form the backbone of our application. Flask, with its flexibility and robustness in backend development, presented mewith a myriad of opportunities to build scalable and efficient APIs to handle various functionalities. On the other hand, delving into the world of Nuxt.js for frontend development introduced me to a plethora of modern JavaScript concepts and Vue.js magic, enriching my understanding of client-side rendering and state management (Pinia).

However, the real test came with the deployment phase, where I aimed to deploy Flask on Heroku for backend hosting and Nuxt.js on Netlify for frontend deployment. While both platforms offer seamless deployment experiences, configuring each to work harmoniously with our specific tech stack posed a formidable challenge. I encountered hurdles in setting up environment variables, managing dependencies, and ensuring smooth integration between the backend and frontend layers.

Despite the complexities, I approached each challenge with determination. Through meticulous troubleshooting, strategic collaboration, and leveraging online resources and community support, I successfully overcame these obstacles and achieved a seamless deployment of the Flask backend on Heroku and Nuxt.js frontend on Netlify. This experience not only enriched my technical acumen but also reinforced the importance of adaptability and resilience in navigating the ever-evolving landscape of web development.

Lessons Learned and Future Endeavors

Through the development of Flix256, I gained invaluable insights into frontend development, backend operations, and project management. Looking ahead, I aspire to further refine my technical skills and explore emerging technologies to drive innovation in the field of multimedia content discovery. This project has reaffirmed my passion for creating impactful solutions that resonate with users and elevate their digital experiences.

About Me

I am Nkunze Caleb, a dedicated software engineer with a passion for leveraging technology to solve real-world challenges. My GitHub profile showcases my contributions to various projects, including Flix256. Feel free to explore the deployed project page and visit our landing page to experience Flix256 firsthand. Let’s connect on LinkedIn to explore potential collaborations and share insights into the ever-evolving world of software development.

GitHub: Link to GitHub
Deployed Project: Flix256 — Explore Now
Landing Page: Discover Flix256
LinkedIn: Connect on LinkedIn

Thank you for joining me on this journey through Flix256, your spot for movies and TV shows!

The Day the Web Stood Still: A Firewall Configuration Catastrophe

Caleb Nkunze — Wed, 17 Jan 2024 17:56:41 +0000

World Wide Where (thanks to DALL-E)

“Welcome to the Great Firewall Fiasco of 2024 , where our beloved website transformed from the ‘World Wide Web’ into the ‘World Wide Where?’. On a seemingly ordinary Tuesday morning — or as we now refer to it, ‘The Day of Digital Silence’ — our team found itself in an unexpected game of digital hide-and-seek with our own website. The culprit? A mischievous firewall rule that decided to play the overzealous bouncer, turning away all the Internet traffic like unwanted party crashers.

Imagine this: One minute, you’re sipping your artisan coffee, basking in the glow of your smoothly running website. The next minute, you’re staring into the abyss of a 500 error, wondering if the Internet gods have forsaken you. Yes, folks, we had successfully turned our website into the world’s most exclusive online club — so exclusive that no one could get in, not even ourselves!

Join me on this epic tale of confusion, revelation, and redemption as we unravel the mystery behind the digital blackout that left 70% of our users pondering if our website had taken an impromptu vacation. Spoiler alert: It involves a firewall rule with a mind of its own and a team of IT detectives who’ve watched one too many episodes of ‘Sherlock’.”

Issue Summary

Outage Duration: January 10, 2024, 10:00 AM — 11:30 AM UTC
Impact: The main website was down, resulting in a complete service outage. Approximately 70% of our users were unable to access our services.
Root Cause: A misconfigured firewall rule blocked incoming traffic to the web server.

Firewall Stop (Thanks to DALL-E)

Timeline

10:00 AM: Issue detected by our monitoring system alert.
10:05 AM: Initial investigation by the IT team suggested a server overload.
10:20 AM: Further analysis revealed normal server loads and memory usage.
10:35 AM: Customer support reported multiple user complaints.
10:50 AM: Network team joined the investigation, suspecting network issues.
11:00 AM: Discovered a recent firewall rule update was incorrectly applied.
11:15 AM: Firewall rule corrected to allow web traffic.
11:30 AM: Service fully restored; monitoring confirmed.

I.T Team work (Thanks to DALL-E)

Root Cause and Resolution

Root Cause: The outage was caused by a new firewall rule that inadvertently blocked incoming HTTP and HTTPS traffic to our web server.
Resolution: The firewall rule was corrected to allow traffic on ports 80 and 443, restoring normal service.

Corrective and Preventative Measures

Improvements:

Implement a review process for all firewall rule changes.
Enhance monitoring to include network-level checks.

Tasks:

Task 1: Update the firewall management procedure to require peer review.
Task 2: Configure additional network traffic monitoring on firewall.
Task 3: Conduct a team training session on network security best practices.

In the end, our computer whizzes fixed the grumpy firewall with some quick finger-tapping and teamwork. The internet started working again, and all the little data bits went zooming through happily. It just goes to show, a few laughs and some good friends make even the biggest computer boo-boos better!

NodeJS Gateway — Part 4: Controllers Take the Stage!

Caleb Nkunze — Fri, 15 Dec 2023 18:09:51 +0000

NodeJS Gateway — Part 4: Controllers Take the Stage!

Photo by Isis França on Unsplash

In our previous posts, we’ve built a solid foundation for our payment gateway using JavaScript and NodeJS. We set up the gateway itself, established communication with MongoDB, and even created routes and middleware to handle requests. Now, it’s time to introduce the superstars of the show — controllers!

Imagine controllers as the conductors of our payment gateway orchestra. They receive instructions from the routes, interpret them, and delegate tasks to other parts of the system like models and services. In essence, they handle the business logic of our application, keeping the routes clean and focused on traffic management.

So, what can controllers do? Let’s take a look:

Process payment requests: When a user initiates a payment through the “collect” endpoint, the controller receives the request, validates the data, and calls the appropriate service to process the transaction. It could involve communicating with payment providers, updating databases, and sending confirmation messages.
Manage user accounts: Controllers handle user registration, login, and other account-related actions. They interact with the user model to store and retrieve data, ensuring secure authentication and authorization.
Orchestrate complex workflows: Payment gateways often involve intricate processes with multiple steps. Controllers act as the glue, coordinating the flow of data between different components and ensuring everything runs smoothly.
Handle errors gracefully: When something goes wrong, controllers catch the errors, log them appropriately, and provide informative responses to the users or APIs making the request.

Here’s an example of how a controller might handle the “collect” request:


export async function collect(data:any, res:any){
    // Validate type and amount from request body
    const { type, amount } = data;
    if (!type || !amount) {
        return res.status(400).json({
        error: "Missing required fields",
        });
    }

    // Process payment based on type
    try {
        if (type === "mobile_money") {
            // Call a controller or service that handles mobile money payments
            // Send confirmation message and status
            res.status(200).json({
                message: "Mobile Money Payment initiated successfully",
                status: "pending",
            });
        } else if (type === "card_payment") {
            // Call a controller or service that handles card payments
            // Send confirmation message and status
            res.status(200).json({
                message: "Card Payment initiated successfully",
                status: "pending",
            });
        } else {
            return res.status(400).json({
                error: "Invalid payment type",
            });
        }
    } catch (error) {
        // Handle and log errors
        console.error(error);
        res.status(500).json({
            error: "Internal server error",
        });
    }
}

As you can see, the controller takes care of the entire payment flow, from validation to service calls and response generation. When we run our previous collect route we get the response as shown below.

Response from collect route handled by the collect controller

Using controllers brings several benefits:

Improved code organization: Code is divided into clear, reusable modules, making it easier to understand, maintain, and test.
Reduced redundancy: Logic is centralized in controllers, preventing duplication across routes and other components.
Enhanced flexibility: New features and functionalities can be easily implemented by adding new controllers or modifying existing ones.

By leveraging the power of controllers, you can build a robust and scalable payment gateway that can handle complex transactions with ease. Stay tuned for the next part, where we’ll dive deeper into specific controller implementations and explore how they interact with other parts of the system!

Next we will look at services to further handle our controller functionalities, then we will also look at practices that we can use to make our code better including logging methods, migrations, setup and handling scripts among others. And in case if you want to view the code you can always check it below.

Until the next blog, happy coding.

GitHub - Cank256/payie: A payment solution project

Navigating the Web: The Symphony of a Web Request

Caleb Nkunze — Mon, 11 Dec 2023 05:24:23 +0000

Photo by Lars Kienle on Unsplash

Ever wondered about the intricate dance of technology that unfolds when you type “https://www.google.com" into your browser and press Enter? Join me on a journey through the web’s inner workings as we unravel the orchestration of DNS requests, TCP/IP, firewalls, HTTPS/SSL, load-balancers, web servers, application servers, databases, and the final leg — your client device.

DNS Request : The journey begins with a DNS (Domain Name System) request. Your browser sends a query to translate the human-readable “www.google.com" into an IP address. The DNS server, acting as a digital phone book, responds with the corresponding IP address, allowing your browser to locate Google’s servers on the internet.
TCP/IP: With the IP address in hand, your browser initiates a TCP (Transmission Control Protocol) connection with Google’s server. TCP ensures a reliable and ordered exchange of data, breaking it into packets and managing their secure transmission between your device and Google’s servers.
Firewall: As the request reaches Google’s servers, it encounters a firewall — a digital guardian protecting against unauthorized access. The firewall evaluates the incoming traffic, allowing or denying access based on predefined security rules. This layer of defense ensures the integrity and security of Google’s infrastructure.
HTTPS/SSL: To secure the data exchange between your browser and Google’s servers, the connection transitions to HTTPS (Hypertext Transfer Protocol Secure) using SSL (Secure Sockets Layer) or TLS (Transport Layer Security). This encryption safeguards your information from potential eavesdropping and tampering during transit.
Load-Balancer: Google manages a colossal amount of traffic, and a load-balancer steps in to distribute this load efficiently. It directs your request to an optimized server, ensuring even resource utilization, preventing overload, and enhancing the overall reliability and performance of the service.
Web Server: Once the load-balancer selects a server, the web server takes center stage. Google employs highly efficient web servers like Google Frontend, responsible for handling static content, processing your request, and returning the initial HTML page of the Google search.
Application Server: For dynamic content, your request is handed over to an application server. Google’s sophisticated applications execute server-side code, interact with databases, and generate dynamic content based on your search query. This stage adds the intelligence and personalization that make Google searches so powerful.
Database: Behind every search result is a database. Google’s databases store and manage vast amounts of information, delivering relevant search results rapidly. The application server communicates with the database server to retrieve the requested information, completing the intricate dance.
Client: The journey concludes as the response, now containing search results and dynamic content, travels back to your client device. Your browser renders the HTML page, fetching additional resources like images and scripts. You now interact with the familiar Google search interface, clicking links and exploring the web, all facilitated by the seamless technology symphony.

Caleb N — Gliffy

Conclusion: From DNS requests to client rendering, the journey of typing “https://www.google.com" into your browser is a fascinating orchestration of technology. Each component, from firewalls to load-balancers, contributes to the seamless, secure, and lightning-fast experience we’ve come to expect from the world’s most popular search engine. Understanding this intricate process enhances our appreciation for the sophisticated infrastructure that powers our interactions with the digital world.

NodeJS Gateway — Part 3: Routes and Middleware

Caleb Nkunze — Sun, 05 Feb 2023 12:52:32 +0000

NodeJS Gateway — Part 3: Routes and Middleware

Photo by Bogdan Karlenko on Unsplash

This is part of the Building a payment gateway using JavaScript series. You can check out the previous parts below;

Intro: How I built a Payment Gateway using JavaScript

Part 1: Initial Setup

Part 2: Setting Up our Database (MongoDB)

Part 3 (Here): Routes and Middleware

Routes

With NodeJS, comes the popular Express JS which is an open-source Node.js framework for building web applications. It provides a simple and flexible way to create server-side applications, handling HTTP requests and responses, routing, middleware, and more. Express makes it easy to build fast and scalable APIs, as well as dynamic web pages, and has a large community of developers who contribute to its development and offer support. With Express, developers can build robust and reliable web applications with a minimum of code and effort.

We can now go ahead and install Express in our application using the command below in our terminal.

npm install express --save

Great now we can create our routes. Since we are creating a payment gateway, lets use 2 endpoints that is status and collect.

For the endpoint responses you can have any data that you believe will be helpful to the API consumer, therefore, our responses will have a JSON structure as below.

{
  "code": 200,
  "status": "success",
  "data": {}
}

From the above the code value can be any HTTP status code according to the action carried out and the status value has to correspond with the code.

You can learn more about the HTTP status codes below.

HTTP response status codes - HTTP | MDN

And from the introduction of these series, we are going to follow RESTFul API practices. To know more about these you can visit the sites below.

Alright, let’s go ahead and create our 2 endpoints under api routes as below.

First we have the status endpoint:

//This is in the index.ts file under the routes folder
import express from 'express'
const router = express.Router();
const transactions = require('./transactions');

router.use(transactions);

router.get("/status", (req, res) => {
    console.log('here');
    res.status(200).json({
        code: 200,
        status: "success",
        data: {
            app: "Gateway",
            msg: "You are welcome to my amazing payment gateway"
        }
    })
});

export default router;

From the above you can see that we imported the transaction routes that we used in our last step in to the index file of the routes, this can be helpful in organising our code so that we can just import only the index file in the app.ts file of the gateway.

When we start the Node server (refer to previous steps), we will get the response for this endpoint similar to the one below.

Response from the status endpoint.

Now let’s move to the collect endpoint. This will be the one used to initiate or complete payments. And our endpoint will look as below.

import express from 'express'
const router = express.Router();
import { collect } from '../controllers/collect'

router.post("/collect", (req, res) => {
    //call the collection function from the controller
    collect(req.body, res)

});

export default router;

Looking at our code, you can see that we imported the collect function from the collect controller (we will be looking at controllers in our next step) and we called it in the endpoint function. This means that when when we request to collect payment, the endpoint will relay our request and data over to the collect function to be processed as desired. We can also see that our endpoint uses the POST method and not the GET method like for our status.

A simple way of explaining how to use the 2 methods is, the GET method carries parameters appended in the URL for example an ID for a transaction whose status you can to get while to the POST method the parameters are carried in the body of the request.

Middleware

This refers to functions that have access to the request and response objects, and can perform actions such as parsing incoming requests, adding headers, or performing authentication and authorization. Middleware functions in web development can be thought of as “glue” that ties together different parts of an application and allows them to work together.

In frameworks such as Express.js, middleware is an important concept that allows developers to extend the functionality of their application by adding custom logic to the request/response cycle. Middleware functions can be added to an Express application by using the app.use() method, and they are executed in the order they are defined. This makes it easy to add or modify the behavior of an application, and can help to keep code clean and organized. If you have been following, we added our routes via app.use() in the app.ts file. In the Initial Step of these series we also looked at how the body-parser middleware was added using the same method.

You can also create a customised middleware according to what your desire is. They can be added in the app.ts file to work globally or for a specific function or even route. For example we can to pass a collection type value in the body of our collect request.

We can create a middleware that returns a error if the type value is not passed in the request body. For this we can use body which is a function provided by a NodeJS package called express-validator, and we are going to use it to check if type is available and not null in the request body of the collect endpoint.

First we install express-validator

npm install express-validator --save

We can now implement it in our collect endpoint to check the body for a value of type.

//This is in the collect router file
import express from 'express'
const router = express.Router();
const { body, validationResult } = require('express-validator');
import { collect } from '../controllers/collect'

router.get("/collect", body('type').not().isEmpty(), (req, res) => {
    //Use Middleware to check if required values are available
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
        return res.status(400).json({ 
            code: 400,
            status: "error",
            data: errors.array() 
        });
    }

    //call the collection function from the controller
    collect(req.body, res)

});

export default router;

In the above, we are checking if the type value in the body is not Empty, and to pass on the request to the controller if provided or return an error response if null.

Below is a response we get if we do not provide a value for type.

Error response from middleware.

Below is the response we get if we provide the type value in the request body.

Success Response

The middleware can be customised further to help in securing the API access by checking for Authorisation headers, and sanitising the request for proper processing. There also other important middleware tat you can use in your project for example helmet (configure HTTP headers), cors (for Cross-Origin Resource Sharing configs) etc.

You can see the final code using the link below, otherwise let’s catchup in the next step talking about controllers.

GitHub - Cank256/payie: A payment solution project

NodeJS Gateway — Part 2: Setting Up our Database (MongoDB)

Caleb Nkunze — Tue, 30 Aug 2022 20:51:56 +0000

NodeJS Gateway — Part 2: Setting Up our Database (MongoDB)

Photo by Rubaitul Azad on Unsplash

NoSQL databases make it easy to start developing your project or application with basic schemas, and since consistency can be jumped over with this type of database, expansion becomes easy as our variables and interactions increase and this is why we are using MongoDB for our gateway. This is also because the API application (refer to the link below about the project we are building) will be the one holding all the final transactional or interaction data (Postgres).

Just in case you are confused of what we are developing, please visit the link below:

How I built a Payment Gateway using Javascript.

In the previous post (Part 1), we were able to add the mongodb and mongoose npm modules to our gateway. In this post, we are going to concentrate on creating collections’ schemas, saving, retrieving, updating and deleting data from our database collections.

If you are wondering what collections are, you can relate them to tables or relations in SQL databases. Since the NoSQL databases are non-tabular databases which consist of JSON-like documents types of databases among other of which MongoDB is part. Therefore, the records (in SQL databases) or entries are documents in NoSQL, and a collection is a group of documents (records). I hope that is not confusing. You check out more broad explanations here NoSQL Explained, TechTarget and NoSQL Databases.

We are going to look at inserting data for a basic demo internal (app) transfer transaction having transaction_id transaction_type sender_account_id recipient_account_id amount currency transaction_note then date_time .

First, we will start with creating a schema which in simple terms is the format of the data that is to be saved in the database. Let’s go ahead and create a model file transactionModel.ts for our transaction data and add the following code.

https://medium.com/media/af9a5e596d29b884536a4a9890ee1185/href

From the code, we see that all inputs are required apart from the transaction note which is optional. After defining the schema transactionSchema we create the transactionModel as on line 13 which will be used in searching, saving and retrieving transaction related data. Remember, this is basic and we will add on more values or variables as we go on.

Let’s go ahead and test our model to see if we can save and retrieve data from the database. And to do this, we are going to create 3 routes for saving and retrieving our transaction data.

POST /api/transaction Create a transaction
GET /api/transaction/:id Get transaction data for a single transaction
GET /api/transactions Get All transactions

This part is more about database so we will not go deeper into routes. For now we can have basic routing to test our schema. For this, we are going to add a body-parser module that will help us make a middleware to convert our requests data to JSON format for storing. Use the command below.

npm install body-parser --save

Now we can add the code below to our app.ts file

const bodyParser = require('body-parser');

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

So that we have the app.ts looking like this

https://medium.com/media/cf24dbf144c37c944e8402a9ebda76d1/href

We then create a transactions route file transactions.ts in the routes folder. Finally we add the code below to it:

https://medium.com/media/0259d5c56c2d71226309875d23263120/href

You can run npm run start to build and start our server.

From the above code save the transaction created by calling the mongoose start() function on the request body data received, and this sends back a response to the client when the saving process is successful or not. See the screenshot below from postman.

The POST request for saving the transaction details (Successful)

To get one transaction, we pass the id parameter in the route which is used to search for the transaction similar to the transactionId that it was generated during the transaction creation. See the screenshot below from postman.

The GET request to retrieve a single transaction (Successful)

Then we can also query for all transactions to be returned by passing no argument in the find() function of mongoose. See the screenshot below from postman.

The GET request to retrieve all transactions (Successful)

A failed action will look as below in postman.

A failed GET request for retrieval of a single transaction.

Well done for coming all this way, we have seen how we will be interacting with our database, and in other parts we will be looking at modifications and deleting of our data from the database.

I would like to thank you again for finishing this post, you can clap or even follow me for more posts like this as I traverse through my journey of creating a payment gateway. Please be free to rectify me on where I went wrong. Learning is the way to Go.

Next we will be looking at routes, middleware and hopefully controllers. I try to make these as short as possible to avoid having a full text book in one go 🤩.

In case you want to see the finished code (up-to-this stage), you can get it from the repo using the link below.

GitHub - Cank256/payie: A payment solution project

Till next post 😎.

NodeJS Gateway — Part 1: Initial Setup

Caleb Nkunze — Tue, 23 Aug 2022 17:58:16 +0000

Photo by Ferenc Almasi on Unsplash

It’s been a little over 3 months since my last post about building a payment solution using Javascript.

How I built a Payment Gateway using Javascript.

Yes, it can be overwhelming at times with a 9–5, am glad was able to finally do part of the would be series of how to build a payment gateway or solution using Javascript.

In the last post I talked about why I chose JavaScript which I will not be repeating here, however, I have come to realise that using other frameworks (not for Javascript) or languages can also give you a a pretty good and robust solution as well. Therefore, I will in the future share about using other languages (PHP and Python) and frameworks (Laravel and Django) to come up with similar or even better solutions. It all comes to which one you’re well conversant about.

Alright enough of that, let’s dive into the Gateway (JavaScript — NodeJS).

The Start

With this, we will be using TypeScript which I believe is an advantage over using just JavaScript to avoid errors that may have sneaked through to the runtime. You see, basic JavaScript is dynamic and weak-typed which can bring up challenges in managing a growing code base while TypeScript which is a super-set of JavaScript has strong static typing, compilation, and object oriented programming characteristics which come in handy when looking at large code projects or ever growing code bases like a payment gateway (from the previous blog, you will see that we are looking at having Mobile money integrations, VISA and MasterCard, SMS, Email and other billing and security features that tend to keep changing overtime)

Since we have that out of the way let’s start with setup our gateway with TypeScript, Express and MongoDB.

Step 1

We will create our folder and move into it:

$ mkdir gateway
$ cd gateway

Then we can go ahead and initialise our npm project:

$ npm init

You can use the -y flag to use defaults of npm init by automatically saying yes. However, for me I love to make it personal 😎 so I came up with something like this:

https://medium.com/media/aec0d90a82cc171eb8bd709a864bd13f/href

Step 2 - Add and Configure TypeScript

After initialising our project, next is adding and configuring TypeScript. Remember that this is done inside our gateway folder.

First we install TypeSript as below:

$ npm install --save-dev typescript

We then add a tsconfig.json file to the root directory gatewaywhich is used to configure the compilation options of TypeScript.

$ nano tsconfig.json

Then insert the code below:

https://medium.com/media/cd67a9205e7ff6e03b178482657424d2/href

Looking at the snippet above, here is simple explanation for the variables we have used:

module: Specifies the module code generation method. Node uses commonjs.
esModuleInterop :Enables interoperability between CommonJS and ES modules during imports.
target: Specifies the output language level (we are using ES6).
moduleResolution: This helps the compiler figure out what an import refers to. The value node mimics the Node module resolution mechanism.
sourceMap : Creates respective .map file for allowing debuggers and other tools to display the original TypeScript source code when working with the emitted JavaScript files.
outDir: This is the location to output .js files after compilation. In our project we will use thedistfolder.

Read more about this here TypeScript Compiler options

Step 3 - Add and Configure Express server

Let’s start by installing express:

$ npm install --save express
$ npm install -save-dev @types/express

//We use the @types/express package for TypeScript to know about the types of Express classes.

Then we create the src folder in our gateway folder to hold our TypeScript files which have a .ts extension:

$ mkdir src

Then we add a file called app.ts which will act as our main project app which we will later add the respective transpiled app.js file in the package.json to run as the main file instead of index.js :

$ nano src/app.ts

Add the code below to create a minimalistic express server:

https://medium.com/media/993302f8d71d9e291686e1c329801959/href

The above code creates an express server that runs on port 3000 . Let’s go ahead and compile, then run our server to test if everything works fine. To compile, we run the command below in the terminal:

$ npx tsc

The above uses the configuration options in tsconfig.json to generate .js files in the dist folder which we will use in running the app as below:

$ node dist/app.js

For a successful run we will have the output below:

Express is listening at [http://localhost:3000](http://localhost:3000)

You can open the link in the browser and you should be able to see Hello World! in the browser. Hurayyyy!! You have setup and configure your express server. You can open the dist/app.js and see how it looks like. Below is a snippet.

https://medium.com/media/d0578224bb3e187f6d6f5ef265e25588/href

Finally, let’s install and configure MongoDB.

Step 4 - Add and Configure MongoDB

First, you need to make sure that you have MongoDB installed and running on your machine, you can use the links below for instructions to install, run and create a database (for our case it should be gateway)according to the operating system you have.

On MacOS https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-os-x/
On Linux https://www.mongodb.com/docs/manual/administration/install-on-linux/
On Windows https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-windows/

We can go ahead and add mongodband mongoose to our project using the command below:

$ npm install mongodb mongoose
$ npm install -save-dev [@types/mongodb](http://twitter.com/types/mongodb) @types/mongoose

Next we are going to connect to our database that we created by updating our app.ts code as below:

https://medium.com/media/d2c6d70197c8fab90cbf22b1e11ebda2/href

We have imported the mongoose module and used it to connect to our database which uses the url mongodb://localhost:27017/gateway. On a successful db connection the express server will be started and you will get the output below:

Express is listening at [http://localhost:3000](http://localhost:3000)

Wow! It has been a long thread but I am thankful that you took time to go through it all. It will be great if you give a clap or even follow me for future posts in this series and other topics. Next we will be looking at database actions.

In case you want the code used in this post, you can use the link below:

GitHub - Cank256/payie: A payment solution project

How I built a Payment Gateway using Javascript.

Caleb Nkunze — Tue, 17 May 2022 10:34:00 +0000

Photo by Pankaj Patel on Unsplash

After my University studies (about 5 years back), I had a desire to build a project not only to generate income, but to enable other people and teams generate and manage their income as well.

Despite my studies Information Technology, I had acquired little knowledge in JAVA and C/C++ languages and could hardly create any application using any of them yet they are amazing development languages. I ventured out in to easy-to-learn languages like Javascript, Python and PHP (Yess… I know what is running through your mind, but PHP seemed way easy for me). I was able to use their respective frameworks in different working environments like NodeJS and VueJS (for Javascript), Django (for Python) and CodeIgniter, Symfony, Laravel (for PHP).

The project

Finally, the time came for me to get back on course of creating my own project. I had thinking sessions and research for problems I could solve. I decided to look first into the challenges faced in generating and managing income in my country and region Uganda (East Africa), thus coming up with an idea of developing a simple yet robust payment platform to serve individuals, companies/organisations and other developers to integrate the available payment methods (Mobile Money and Card payments) in to their day to day transactions activities.

The platform was to have the Gateway which would communicate directly with the Third-Party service providers like mobile money networks, the api (backend) which will serve the frontend and also help developers integrate the platform’s functionalities into their own apps and a user interface for users to manage their transactions (Wallet) and carry out other payments like top up airtime, data bundles and so on. And later a mobile app to complement the web app.

The structure

When it came to choosing the language and/or framework to use, I decided to go for Javascript. This is because out of all the languages, I wanted to use one that I have better experience with and can provide me with capabilities to create the front and backend with one language since it was a one-man team for the start.

The Gateway

The gateway uses NodeJS, and with it’s single-thread model and good performance, I believe that this will provide a good start off as monitoring is being done to see if we need changes as users and request increase. The database of choice is MongoDB which provides fast read and write capabilities to log transaction statuses which will be used to update the the api part of the project. This will store the data for a short period of time using the TTL collection feature of MongoDB, and most or all the data will be stored by the API.

The API

The API also uses NodeJS as well and the database of choice was Postgres over MySQL because of it’s provision of a variety of datatypes as I will be using unique datatypes from the basic character and numeric datatypes, and it’s effective ability to easily expand into enterprise level with complex queries and frequent write operations. The API will be able to serve the Dashboard (WebApp/frontend), the developer API and the Mobile App.

There are a number of NodeJS api boilerplate projects that you can take advantage of to quick start your development, below are some of the ones I took inspiration from:

The Frontend (Dashboard)

The dashboard will enable the users to collect, self-deposit and withdraw money, check their balances, and carry out other transactions like top up data bundles. This will use VueJS framework and NuxtJS for the User Interfaces and handling notifications and alerts for the different activities done by the user.

I will be sharing more in the next post the breakdown of the above 3 components of this projects for example the authentication, authorisation, request, response and error handling among others.

Thanks for the read.

More NodeJS api boiler plate projects:

GitHub - kunalkapadia/express-mongoose-es6-rest-api: A boilerplate application for building RESTful APIs Microservice in Node.js using express and mongoose in ES6 with code coverage and JsonWebToken Authentication