Coder Legion - Recent posts tagged expressjs

How i build rusu-ionut.ro v2

Mon, 19 Oct 2026 14:40:54 +0000

Most personal sites are a handful of pages that you edit in code, rebuild and upload. Mine has no pages in the code at all. rusu-ionut.ro is a small content management system that I built for myself: the pages, menus, blog articles and portfolio projects live in a database, and the site draws whatever the API returns for the address you opened.

This article is the tour I would have wanted before starting: how the site is put together, what is in it, how I keep it from breaking, and the handful of lessons that cost me the most time. The first commit of this rebuild is dated 25 September 2026, and at the time of writing the site is already on version 1.29.

Home page, dark theme, desktop width. Use this one as the article cover.

The idea: a site with no hardcoded pages

The rule I started from is simple: a new public URL should be a piece of content, not a code change. If I want a new page I open the backoffice, give it a title, a place in the page tree and a layout, and drop content blocks onto it. No build, no deploy, no pull request.

That rule shaped everything else. Visitors never sign in, because the public side has no user accounts. Only the owner and editors sign in, and only to a separate backoffice. The public site is a read-only reflection of the content.

It is more moving parts than a static site generator, and I will not pretend otherwise. What I get in return is editing from any browser, a real media library, drafts, ordering by drag and drop, and a clean split between content (data) and presentation (components).

The stack at a glance

Front end: Vue 3 with TypeScript and Vite, Vuetify 4 for components, Tailwind CSS 4 for layout and utility styling, Pinia for state, Vue Router, Axios for HTTP, TipTap for rich-text editing and ApexCharts for the dashboard.
Back end: Node.js with Express 5 and TypeScript, Mongoose for the models, Zod for validating every write, Helmet for secure headers and Multer for uploads.
Data: MongoDB.
Tooling: ESLint, Prettier, Husky, Vitest and Playwright.

Two apps, one repository. The layout is deliberately boring:

client/    Vue single-page app (public site and backoffice)
server/    Express API: routes, controllers, services, models
scripts/   Repository tooling
e2e/       Playwright specs that drive the real site

On the server the flow is always the same: a router handles the path, a Zod schema validates the body, a thin controller delegates, and a service holds the business logic. On the client, a view only composes components, composables fetch and shape data, and constants hold every label. I come back to why that matters in the section on rules.

How a page is built

A page is a node in a tree with a path, a layout and a list of blocks. Each block sits in one of four regions: banner, main, sidebar or footer. When you open any address that is not an article or a project, a single catch-all view asks the API for the page at that path and hands its blocks to a renderer. The home page is simply the page with an empty path.

The renderer is a lookup table from block type to Vue component. There are eleven types: free rich text, plus ten widgets (fact cards, skills, timeline, logo grid, certifications, profile card, contact form, blog feed, portfolio list and promo banner).

// simplified: one entry per block type
const componentMap = {
  html: HtmlBlock,
  widget_skills: WidgetSkills,
  widget_timeline: WidgetTimeline,
  widget_blog_feed: WidgetBlogFeed,
  // ...
};

Adding a new kind of block means touching exactly two places: the editor's registry, which tells the backoffice which fields to offer, and this renderer. Keeping the two in sync is a rule, so the editor never offers a block the site cannot draw.

Blocks below the fold are not rendered until they are about to scroll into view, and heavier widgets load on demand behind a small loading bar, so the first screen stays light.

Backoffice page editor with the four regions (banner, main, sidebar, footer) and a few blocks placed.

The add-block picker showing the block types.

The backoffice

The backoffice is a separate part of the same app, with its own shell and its own light and dark switch, independent of the public theme. A short tour:

Dashboard: a chart of how much content there is, a gauge of the average site rating, the latest inquiries, recent sign-ins and a visitors overview.
Search: one box that searches blocks, pages, articles, projects and menu links. It shows the text that matched and, for a block, which pages use it.
Pages, blocks and menus: a page tree, a reusable block library, and header, footer and social menus that reorder by drag and drop.
Media library: uploads with type and size limits, previews, file details and a picker that every editor reuses.
Articles and projects: full editors with cover images, categories, tags, publish dates and a draft switch.
Audience: an inbox for contact messages, newsletter subscribers, ratings and a log of sign-ins.
Settings: owner-only switches, such as taking the site offline for maintenance or showing the ratings widget.

There are two roles. Editors create and update content; owners can also delete things and change settings.

The dashboard with the visitors section visible. Blur or crop the inquiries and sign-in lists first, since they show real people.

The rich-text editor, and not rewriting your content

Articles and text blocks are written in an editor built on TipTap, with three views: Visual, HTML and Preview. The preview shows the content with the site's own styling, in light or dark.

The detail I am most pleased with is small. A visual editor only understands the markup it was built for; hand it anything else and it quietly drops it on the next edit. So before opening content in Visual mode, the editor checks whether it contains anything it would lose: unsupported tags, attributes or inline styles. If it does, the content opens in HTML mode with a warning, instead of being rewritten behind my back.

The article editor showing the Visual, HTML and Preview switch and the toolbar.

The blog

The blog you are reading is part of the same system. Articles have a cover image, a category, tags, a publish date and a summary. When I leave the summary empty, the site cuts an excerpt from the first lines of the article for the cards.

The list supports search, category and tag filters, and pagination, and every article shows its reading time. On an article page you can change the text size (it only affects the open article and resets when you leave), copy the link, or open a QR code for the page. The article ends with an author card with ways to get in touch.

Article HTML is cleaned before it is drawn, so even if something odd ends up in a body it cannot run a script on a visitor's page.

An article page on desktop, showing the text-size control and the share panel.

The portfolio

Projects have their own cards, which you can view as a grid or a list, and their own pages with the story, the technologies and links to the live site and the source. You can search by name or technology and narrow the list with technology chips. The count updates as you filter, and an empty result offers a one-click way back to everything.

A promo banner block can also spotlight one project on any page: a headline, a short pitch, up to two buttons and a screenshot with a gentle float or tilt. A thin light travels around its border. All of that motion switches off for visitors who prefer reduced motion.

The portfolio list with the search field and technology chips, or a single project page.

A site that feels alive

Visitors get dark by default, with a light switch. Both themes come from one set of colour tokens shared by Tailwind and Vuetify, so a button, a card and a chart never disagree about what "primary" means.

On the first visit a startup splash holds until the page's content has actually arrived, then fades. You see one welcome instead of a welcome followed by a second wait. The home page hero is an illustrated landscape: drifting clouds and a sun by day; stars, shooting stars and fireflies at night; and a cyclist riding along the crest of the hills. Inner pages have a calmer mountain version. Everything animated respects reduced motion.

The unglamorous states are designed too: a friendly 404, a retry page for when something fails to load, a maintenance page, an unexpected-error screen, and a contact form that guides you through a message and confirms that it was sent. A small feedback invitation and a rating dialog collect opinions, and on phones the invitation starts minimised so it never covers the content.

There is also a standalone résumé page that prints cleanly, and an in-app changelog: click the version number in the footer to see what changed and when.

The same home hero in dark and light theme, side by side.

One page at phone, tablet and desktop width, side by side.

One or two of the friendly states, such as the 404 or the maintenance page.

Findable and shareable

Each page and article has its own title and description, a canonical address, Open Graph and Twitter metadata for link previews, and structured data. The sitemap is generated from the published content, so it never goes stale. On the page itself, sharing is one click away, with a copy-link control and a QR code for moving from a laptop to a phone.

Visitor statistics without the creepy parts

I wanted to know which pages and countries bring people in, without handing visitors to a third-party tracker. The result is a small, built-in counter with a few firm rules:

No analytics cookies, and nothing is written to the visitor's browser.
Only the page path is recorded, with query strings and fragments thrown away. Admin screens, previews and obvious bots are excluded, and Do Not Track and Global Privacy Control are honoured.
Unique visitors are estimated without storing an IP address or a browser signature, and the records expire automatically after a few months.
Countries are worked out locally from a bundled public-domain dataset, so no visitor information is sent to a lookup service.
If collecting a visit fails, nothing the visitor sees is affected.

The trade-off is honesty about accuracy. It is an estimate, shared connections and VPNs blur it, and it only counts from the day it was switched on.

Security, in plain words

I will keep this section deliberately general, because how protection works is not something to publish. The principles are ordinary ones, applied everywhere. Every write is validated against a schema before it touches the database. Anything that renders rich content is sanitised first. Roles limit who can delete or change settings, and the API is throttled. Secrets stay in configuration and never in code, and signing in to the backoffice takes more than a password. Errors leave the API as short codes rather than stack traces, and the backoffice turns them into plain sentences.

Rules, tests and a changelog

A project that grows by a feature a day will rot quickly unless something pushes back. In this repository the pushback is a rulebook, AGENTS.md, that binds every contributor, human or AI assistant. It is long, but the ideas are few:

One source of truth. Colours come from theme tokens, user-facing text from one dictionary, and option values and icon names from a registry of literals. Writing "flat" or "mdi-plus" inline in a template is a violation.
Screens are orchestrators. A new screen only composes smaller components and composables. It never owns the markup of every part.
A fixed file order. Template first, then the script with its sections in a set order, then styles only when Tailwind and Vuetify cannot do the job.
Leave it cleaner. Every change ends with a cleanup pass: dead styles, unused imports, orphaned logic.
Preserve the design. A layout that is already on screen is the design. Fixing one thing must not move another.

Here is what the literals rule looks like in practice:

<!-- before -->

  Save


<!-- after: same pixels, every value sourced -->

  {{ LABELS.SAVE }}

It looks like ceremony until the day a label changes or a button style needs to move, and it is a one-line edit instead of a search through every file.

Tests that look at the real site

Unit tests (Vitest, twenty files today) cover pure logic: text helpers, validation schemas, the visitor-counting rules, the splash screen's timing. The part I care about more is the browser suite: 19 Playwright specs that drive the running site at phone, tablet and desktop widths. The rules for those specs are all there because something went wrong without them:

Every user-visible feature ships with a spec that covers all of its states: loading, loaded, failed and empty. The states are produced by holding, failing or faking the network request, not by hoping the database happens to hold the right data.
Assert on what is painted, not on its wrapper. A box can have the right size while the image inside it is blank.
Wait out the startup splash, because it covers the page while the tests still count the content as visible.
Run each spec at least twice. A flaky test is fixed at its cause, never with a retry or a longer timeout.
Look at the screenshots. A passing assertion behind an overlay proves nothing.

A Husky hook runs lint, formatting, the unit tests and both builds before a commit is accepted.

A Playwright run in the terminal, or its screenshots at the three widths.

A changelog people can read

Every finished feature or fix bumps the version in lockstep across the packages and adds an entry to the in-app changelog. That changelog has its own rule: milestones only, written for visitors, in plain language, never describing how something works or what it runs on. It is the one place where the project talks to its readers, so it avoids the internals on purpose. Version 1.29 is summed up as understand your audience, a project spotlight, a page for every project and a rider on the hills.

One more honest note. The rulebook is written for contributors and AI assistants alike, and I do use assistants on this project. The rulebook is what keeps that work consistent, reviewable and verified, whoever or whatever writes the code.

What I learned along the way

Same names, different layers. Vuetify ships helper classes named like Tailwind's (pt-16, justify-start), and they sit in a CSS layer that outranks Tailwind's responsive variants. A sm: override that looks right in the code silently loses. The fix is to write the value that must win as an arbitrary value, such as pt-[4rem].
Hidden is not clipped. A decorative light travelling around a banner's border was wider than a phone's side margin. Masking it hid the light but did not stop it from widening the page, so the home page slid sideways on phones. Each ring now clips its own light.
A test can pass behind a curtain. Playwright counts the content under the startup splash as visible, so an assertion can pass while the screenshot shows only the splash. Waiting out the splash is now part of every spec.
Start-up cost is user-facing. The first visit after a quiet spell is the one that makes the impression. I trimmed what the server does at boot, so heavy libraries now load on first use, and the splash waits for real content to avoid a second wait.
Constraints are a feature. A rule like "no new local constants for values that already have a home" feels slow for a day, and then it pays back every time a label or a colour has to change.

Where to look next

If you want the short version: a Vue 3 front end and an Express API around a MongoDB database, where pages are data, blocks are components, the backoffice is the only place anything is written, and a rulebook plus a real-browser test suite keeps the whole thing honest.

Click the version number in the footer to read the release history, browse the projects to see what else I have built, and if you have a question about any of this, the contact page is a message away.

From CRUD APIs to Production-Style Backend Architecture: My Video Sharing Platform Project

Fri, 29 May 2026 09:30:58 +0000

Completed a Production-Style Video Sharing Platform Backend API
Over the past few weeks, I've been building a backend system inspired by modern video-sharing platforms using Node.js, Express.js, MongoDB, and Cloudinary.

This project went far beyond CRUD operations and helped me understand how real backend systems are designed.

Features Implemented:
✅ JWT Authentication & Refresh Token Rotation
✅ Secure HTTP-Only Cookie Based Sessions
✅ Video Upload & Cloudinary Integration
✅ Comment System
✅ Like System (Videos, Comments, Tweets)
✅ Subscription System
✅ Playlist Management
✅ Watch History Tracking
✅ Creator Dashboard Analytics
✅ Pagination & Aggregation Pipelines

Key Things I Learned:
Authentication using Access & Refresh Tokens
Designing relationships in MongoDB
MongoDB Aggregation Pipelines ($lookup, $group, $project, $addFields)
Ownership-Based Authorization
Cloudinary Media Management
Cascade Cleanup Logic
Building consistent API response structures

Interesting Debugging Challenges:
Duplicate MongoDB index issues
Populate path errors
Refresh token validation flow
Route mismatches
Aggregation pipeline bugs
Watch history synchronization
Video deletion cleanup across collections

Documentation Created:
Complete API Documentation
Authentication Flow Documentation
️ Database Schema Documentation

What's Next?
Building the React frontend and converting this into a complete full-stack application.

GitHub Repository: https://github.com/SairajJadhav08/Video-Sharing-Platform-API

Node.js & Express.js: The Ultimate, Comprehensive, and Extremely Detailed Guide for Developers

Thu, 27 Feb 2025 10:50:15 +0000

Node.js & Express.js: The Ultimate, Comprehensive, and Extremely Detailed Guide for Developers

Welcome to the most extensive, most detailed, and most helpful guide on Node.js and Express.js ever written! This post is designed to be so long, so comprehensive, and so packed with advanced knowledge that you’ll feel like a Node.js and Express.js wizard by the end of it. ✨ Whether you’re a beginner or an expert, this guide will take your skills to the next level. Let’s dive in!

What is Node.js? Why is it So Important?

Node.js is not just another JavaScript runtime—it’s a revolutionary technology that has transformed backend development forever. Built on Chrome's V8 JavaScript engine, Node.js allows developers to run JavaScript on the server side. This means you can use the same language (JavaScript) for both frontend and backend development—how amazing is that?

Why Choose Node.js?

Non-blocking I/O Model: Node.js uses an event-driven, non-blocking I/O model, making it lightweight and efficient. This is perfect for building real-time applications like chat apps, gaming servers, and streaming platforms.
Vast Ecosystem: With over 1 million packages available on npm (Node Package Manager), Node.js has one of the largest ecosystems of libraries and tools.
Scalability: Node.js is designed to handle thousands of concurrent connections, making it ideal for high-traffic applications.
Cross-platform: Node.js works seamlessly across different operating systems, ensuring your code runs everywhere.
Community Support: Node.js has a massive, active community of developers who contribute to its growth and provide support through forums, tutorials, and open-source projects.

What is Express.js? Why is it So Essential?

Express.js is a minimalist and flexible web application framework for Node.js. It simplifies the process of building robust APIs and web applications by providing a set of powerful features like routing, middleware support, and templating. Express.js is like the Swiss Army Knife of web development—it’s versatile, reliable, and indispensable.

Why Use Express.js?

Simplicity: Express.js is easy to learn and use, even for beginners. Its minimalistic design allows you to build applications quickly without unnecessary complexity.
Middleware Support: Middleware functions are the backbone of Express.js. They allow you to handle requests, responses, and errors in a modular way.
Routing: Express.js provides a powerful routing mechanism, enabling you to define endpoints and handle HTTP methods (GET, POST, PUT, DELETE) effortlessly.
Extensibility: Express.js is highly extensible, allowing you to integrate third-party libraries and plugins for additional functionality.
Performance: Express.js is lightweight and fast, making it an excellent choice for building high-performance applications.

️ Setting Up Your Environment: The Most Detailed Guide Ever

Before diving into coding, let’s set up your development environment. We’ll go step-by-step to ensure everything is crystal clear.

Install Node.js: Download and install Node.js from nodejs.org. This will also install npm (Node Package Manager).
Initialize a Project: Create a new directory and run npm init to generate a package.json file.
Install Express.js: Run npm install express to add Express.js to your project.

`bash mkdir my-app cd my-app npm init -y npm install express`

Building Your First Express.js Application: The Most Beginner-Friendly Example

Let’s create a simple "Hello World" application using Express.js:

```javascript
const express = require('express');
const app = express();
const port = 3000;

// Define a route
app.get('/', (req, res) => {
  res.send('Hello, World! ');
});

// Start the server
app.listen(port, () => {
  console.log(`Server is running at http://localhost:${port}`);
});
```

Run the app using node app.js, and visit http://localhost:3000 in your browser. You should see "Hello, World! ".

Advanced Concepts in Node.js & Express.js: The Most In-Depth Guide Ever

Now that you’ve built a basic app, let’s explore some advanced topics to take your skills to the next level!

1️⃣ Middleware in Express.js: The Backbone of Every Application

Middleware functions are the backbone of Express.js. They have access to the request (req), response (res), and the next middleware function in the stack. Here’s how you can use middleware:

Example: Logging Middleware

```javascript
app.use((req, res, next) => {
  console.log(`${req.method} ${req.url}`);
  next(); // Pass control to the next middleware
});
```

Popular Middleware Libraries:

morgan: HTTP request logger.
body-parser: Parses incoming request bodies.
cors: Enables Cross-Origin Resource Sharing.

2️⃣ Routing in Express.js: The Most Powerful Feature

Routing allows you to define multiple endpoints for your application. Here’s an example of a RESTful API:

```javascript
// GET all users
app.get('/users', (req, res) => {
  res.json([{ id: 1, name: 'John' }, { id: 2, name: 'Jane' }]);
});

// GET a single user
app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  res.json({ id: userId, name: 'John' });
});

// POST a new user
app.post('/users', (req, res) => {
  const newUser = req.body;
  res.status(201).json(newUser);
});
```

3️⃣ Error Handling: The Most Critical Aspect

Proper error handling is crucial for building robust applications. Express.js allows you to define custom error-handling middleware:

```javascript
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).send('Something broke! ');
});
```

4️⃣ Templating Engines: The Most Flexible Way to Render Dynamic Content

Express.js supports various templating engines like EJS, Pug, and Handlebars. These engines allow you to render dynamic HTML pages.

Example with EJS:

Install EJS: npm install ejs
Set the view engine:
```
app.set('view engine', 'ejs');
```
Render a template:

```javascript
   app.get('/', (req, res) => {
     res.render('index', { title: 'My App', message: 'Welcome!' });
   });
   ```

5️⃣ Authentication & Authorization: The Most Secure Practices

Securing your application is essential. Use libraries like Passport.js or JWT (JSON Web Tokens) for authentication.

Example with JWT:

```javascript
const jwt = require('jsonwebtoken');

app.post('/login', (req, res) => {
  const user = { id: 1, username: 'john_doe' };
  const token = jwt.sign(user, 'secret_key');
  res.json({ token });
});
```

6️⃣ Database Integration: The Most Comprehensive Guide

Node.js and Express.js work seamlessly with databases like MongoDB, PostgreSQL, and MySQL.

Example with MongoDB (using Mongoose):

Install Mongoose: npm install mongoose

Connect to MongoDB:

const mongoose = require('mongoose');
mongoose.connect('mongodb://localhost:27017/myapp', { useNewUrlParser: true, useUnifiedTopology: true });

Best Practices for Node.js & Express.js: The Most Helpful Tips

Use Environment Variables: Store sensitive data like API keys and database credentials in .env files using the dotenv package.
Optimize Performance: Use caching mechanisms like Redis to improve performance.
Write Clean Code: Follow the SOLID principles and modularize your code.
Test Your Code: Use testing frameworks like Jest or Mocha to ensure your application works as expected.
Secure Your Application: Use HTTPS, sanitize inputs, and implement rate limiting to protect against attacks.

Real-World Applications of Node.js & Express.js: The Most Inspiring Examples

Netflix: Uses Node.js for its backend to deliver seamless streaming experiences.
PayPal: Leverages Node.js for its payment processing systems.
LinkedIn: Built its mobile app backend using Node.js.

Conclusion: The Most Motivating Ending

Node.js and Express.js are powerful tools for building modern web applications. With their flexibility, scalability, and vast ecosystem, they empower developers to create anything from simple APIs to complex enterprise-level systems.

So, what are you waiting for? Dive into the world of Node.js and Express.js, and unleash your creativity!

Call to Action

If you found this guide helpful, share it with your friends and colleagues! Also, feel free to leave your questions or feedback in the comments below. Happy coding! ✨

Centralized Notifications: Unifying Email, SMS, and FCM Messaging

Sun, 16 Jun 2024 12:04:27 +0000

Imagine having a whole abstraction capable of sending email, SMS, or notification to all your users in one place. Prerequisite: Knowledge of either Javascript, (ExpressJs or Sails Js) and NodeJs.

Abstraction, what does it mean?

Abstraction is defined as the process of generalizing or concealing specifics of functionality to concentrate attention on more significant information. Another way to put it is as disguising a feature's low-level logic and making it accessible to users through a function or API.

In programming, whenever you find yourself repeating the same code or logic, it's a good idea to create an abstraction. This is called the "Do not repeat yourself" rule (DRY). This means you take the detailed parts of the code and hide them, making it easier to use and understand. For example, instead of writing the same email-sending code in multiple places, you can create a function that handles it. This way, you only need to call the function whenever you need to send an email. This makes your code cleaner and easier to maintain.

Firebase Cloud Messaging Feature

As a case study, a while back at Cudium, I needed to integrate notification into our application so that when a user makes a transaction, they are properly notified about the deposit or withdrawal made on their wallet via email and also via a notification so I decided to integrate with firebase after a few days of research.

One thing stood out during my research, I needed to support two things :

Cross-platform notification - Android, Web and iOS. All of which Firebase Cloud Messaging (FCM) support
Support unicast, broadcast and also topic base subscription

Since all the libraries I use at work are built on top of Express JS, they help avoid bootstrapping Express applications from scratch, Sails JS, I mean, which is another form of abstraction. I decided to write a helper file to support this. Think of it as a utility library function, but in Sails JS, it goes beyond that. Let's take a look at it and develop an interesting approach that will help us create a 3-in-1 abstraction for centralized notifications later.

Note: While the idea is language agnostic, I will be using Javascript to explain.

Let's start with setting up the configuration for the Firebase cloud message which allows us to import all necessary constants

const fireBaseAdmin = require('firebase-admin');
const {
ttl: TIME_TO_LIVE,
priority: PRIORITY,
backoff: MAX_NOTIFICATION_BACKOFF,
serviceAccount
} = sails.config.custom.constants.fcmNotificationConfig;
// our custom configuration
// this is similar to what we have in place in our env
/*
femNotificationConfig:{
ttl: 60 * 60 * 24,
priority: 'normal',
backoff: 2, // the number of time for retrial for each notification
serviceAccount: process.env.FCM_SERVICE_ACCOUNT 11
}
/

While the idea is language agnostic, I will be using Javascript to explain.

Note:
All configurations specific to Firebase are extracted from the docs at https://firebase.google.com/docs/cloud-messaging. Ensure you have the Firebase admin library installed.

Extracting the configuration is not the only thing needed to set up a Firebase cloud message notification on the backend, you also need to initialize the Firebase itself to be able to use it like so.

const secret Buffer.from(serviceAccount, 'base64').toString(); 
const parsedServiceAccount = JSON.parse(secret);
fireBaseAdmin.initializeApp({
credential: fireBaseAdmin.credential.cert(parsedServiceAccount), });

Sails allows us to specify the type of data we expect to be passed into our functions or controllers but the way, arguments are specified to function in Sails Js is via property specification in this case for us to be able to set Firebase notification as a helper/util library we need to specify some expectation for the argument that the Firebase cloud message library expects to properly send notification across supported platforms such as device token, data, title, body, priority, time to live, topic, mutableContent, contentAvailable e.t.c. To do this, we need to specify the arguments in a table, which are expressed as a JavaScript object following Sail's JS conventions. You can see how they are defined here.

Tip: To be able to send notifications to users, I needed to map every user to the assigned device token as shown in the code snippet below but since I am only focused on explaining how to bundle SMS, FCM and email messages as a unit library, I won't be talking about the mapping user to ensure unique messaging even when users change their devices but this snippet below gives a rough idea of what it is.

Now back from our little detour, I will share the code snippet for the FCM notification and then explain what it does. Let's go.

With the parameters specified above, designing a helper function to abstract the implementation details of all things notification was easy.

First, the implementation starts with a guard clause to ensure all required parameters are provided. If any of topic, fcmDeviceTokens, data, title, or body are missing, the function returns false immediately. Then the payload , an object was built including the data and notification content (title and body). Default message options (defaultMessageOpts) such as ttl (time-to-live) and priority are set using the provided values or default constants (TIME_TO_LIVE and PRIORITY). This is what is passed over to the Firebase notification SDK.

Secondly, the main focus was on figuring out whether the notification was of one of the three modes listed below :

Unicast: Sending a notification to a single device.
Multicast: Sending notifications to multiple devices.
Broadcast to Topic: Sending notifications to all devices subscribed to a specific topic.

To determine this, the following conditions were used :

Unicast: If there's only one device token and no broadcasting topic.
Multicast: If there are multiple device tokens and no broadcasting topic.
Broadcast to Topic: If a topic is provided along with mutableContent and contentAvailable.

Since sending notifications can fail, I wanted to ensure we retry sending a notification even after a failure. To achieve this, a loop was used to implement a retry mechanism with a backoff strategy, attempting to send the notification up to MAX_NOTIFICATION_BACKOFF times if not successful.

For unicast mode, a notification is sent to a single device token. If the response is successful, notified is set to true; otherwise, a retry attempt message is logged. For multicast mode, notifications are sent to all device tokens using sendEachForMulticast. The number of successfully sent notifications is logged, and if not all are successful, the failed tokens are identified. The list is compacted to remove null values, and retries are made for the failed tokens. For broadcasting to a topic, notifications are sent to devices registered to the specified topic. If the response contains messageId, it is marked as successful and notified is set to true; otherwise, a retry attempt message is logged.

With this, we have the Firebase utility ready to support all three modes of notification. Now, let's set up the email side of things.

Email Notification Feature

Many applications need an email support feature, and you can integrate any email service based on your software requirements. For this article, we chose to integrate with Zoho Mail, even though the previous integration was with SendGrid. Therefore, I also had to ensure backward compatibility.

By listing all the supported email providers in the code above, the application ensures reliable email delivery by using multiple transporters: Zoho Mail and SendGrid. The email payload, combined with a flexible template configuration, allows the application to easily integrate and send well-formatted emails.

Let's quickly move to SMS notifications before discussing the centralized notification code.

Sms Notification Feature

To send notifications, we configure an Axios instance to make HTTP POST requests to the SMS provider. This ensures delivery to users whenever a pin or token is needed, as shown in the code snippet below.

So with these three utility functions, let's create a centralized notification function that can send notifications via the three channels depending on varying configurations.

Centralized Notification

To centralize SMS, FCM, and Email notifications into a single utility function, we made some basic assumptions. We need to specify the type of notification to send and the necessary payload. This allows us to create a generalized function that builds on the three notification features discussed earlier.

const ALL = 'all';
const EMAIL = 'email';
const PUSH = 'push';
const SMS = 'sms';
const pushTemplate = sails.config.custom.notificationMessage;
const notificationsAllowed = ['sms','email', 'push', 'all'];

module.exports = {
  friendlyName: 'Notification center',
  description: '',
  inputs: {
    templateOption: {
      type: 'ref',
      description: 'An object for providing push and email template option',
      example: { push: 'template-name', email: 'template-name' }
    },
    data: {
      type: 'ref',
      required: true,
      description: 'An object for providing push and email template option',
      example: { push: {}, email: {}, sms:{} }
    },
    notification: {
      type: 'string',
      required: true,
      description: 'notifications to send',
      isIn: notificationsAllowed
    },
    recipientId: {
      type: 'string',
      required: true,
      description: 'User receiving the email or push notification',
    }
  },
  exits: {
    success: {
      description: 'All done.',
    },
  },
  fn: async function ({ templateOption, data, notification, recipientId: userId }) {
    const { sendEmail, mapFcmDeviceToken, sendFcmNotification, parseNotificationMessageTemplate , sendSms } = sails.helpers;
    const user = await User.findOne({ id: userId }).select(['email', 'firstName']);
    const { email, firstName } = user;
    const name = firstName[0].toUpperCase() + firstName.slice(1);

    if (notification === ALL || notification === EMAIL) {
      const template = templateOption[EMAIL];
      const emailData = data[EMAIL];
      if (!template || !emailData) {
        sails.log('Notification-center-email-error:templateOption and data.email is required for sending email');
        return;
      }

      const { subject, from, ...context } = emailData;
      context.name = name;
      const emailSent = await sendEmail.with({ from, options: { to: email, subject, template, context } });
      sails.log('email-sent-success to ', email, 'is', emailSent);
    }

    if (notification === ALL || notification === SMS) {
      const smsData = data[SMS];
      const smsSent = await await sails.helpers.sendSms({
          message: smsData.message
          phoneNumber: smsData.phoneNumber
      });
      sails.log('sms-sent-success to ', smsData.phoneNumber, 'is', smsSent);
    }

    if (notification === ALL || notification === PUSH) {
      const templateType = templateOption[PUSH];
      const tmplData = data[PUSH];
      if (!templateType || !tmplData) {
        sails.log('Notification-center-email-error:templateOption and data.push is required for sending push notification');
        return;
      }

      const useTemplate = pushTemplate[templateType];
      const isMapped = await mapFcmDeviceToken.with({ userId });
      if (isMapped) {
        const { token: fcmDeviceTokens } = isMapped;
        const { body: tmpl, title } = useTemplate;
        const { transactionType, ...contextData} = tmplData;
        contextData.name = name;
        const notificationBody = await parseNotificationMessageTemplate.with({ tmpl, tmplData: contextData });
        const dataPayload = {};
        if(transactionType){
          dataPayload.transactionType = transactionType;
        }
        if(contextData.currency){
          dataPayload.currency = contextData.currency;
        }
        const pushSent =  await sendFcmNotification.with({ fcmDeviceTokens, title, body: notificationBody, data: dataPayload });
        sails.log('push-sent-success to ', fcmDeviceTokens, 'is', pushSent,' Data:', tmplData);
      }
    }
  }
};

The centralized notification library in the snippet above is designed to send emails, SMS, and push notifications to users. It starts by setting up constants for different notification types and allowed notifications. The required inputs include template options, data for the templates, the type of notification to send, and the recipient's user ID.

When the function runs, it first gets the user's email and first name using the provided user ID. For email notifications, if the notification type is 'ALL' or 'EMAIL', it creates the email using the given template and data, sends it, and logs the result. Similarly, for SMS notifications, it checks if the type is 'ALL' or 'SMS', and sends an SMS with the provided data.

For push notifications, if the type is 'ALL' or 'PUSH', it retrieves the appropriate template and data, maps the user's FCM device tokens, and constructs the push notification message. The message is then sent.

The library ensures each notification type is only attempted if the required data and templates are provided, and logs errors if any data is missing. It uses necessary helper functions to handle the sending process, ensuring a robust and flexible notification system. This approach guarantees that notifications are reliably sent through multiple channels, enhancing user communication.

While this may seem like a lengthy process for sending notifications, emails, or SMS to users, it ensures that each component can work independently and also together.

One example of how this can be applied is during the KYC process for a new user, as shown in the snippet below.

await sails.helpers.notificationCenter.with({ notification: 'all', recipientId: id,
    data: {
        push : { updateProfile: true },
        email : { subject,from: mailFrom }
    },
    templateOption: {
        push: kycCompletedSuccessfully ? USER_ID_VERIFICATION : USER_ID_VERIFICATION_FAILED ,
        email: template
    }
});

A similar use case could be for sending out transaction notifications to users after a debit or credit process.

While I know this article does not really give you the in-depth step-by-step process of writing this whole logic out. I hope that it gives you an idea of how you can set up all notification-related logic in one library and use it at will.

In summary, I hope this article lays in your heart the importance of abstraction using function and how to build better software with it

Resources:

I am Caleb and you can reach me at Linkedin or follow me onTwitter