And honestly? It was a fair point. You'd write the contract — the interface, the abstract class, the protocol — and then write the implementation. Two files where one would do. That's more surface area, more indirection, and more to maintain.

The Ruby and Rails communities built an entire philosophy around this: convention over configuration, less ceremony, fewer keystrokes. If the framework could infer your intent, why spell it out?

Then AI happened.

I was recently chatting with a CEO about what current-generation software engineers get wrong, and he put it cleanly:

"Abstract interfaces were challenging a few months ago just because it required twice as much code. But with AI, lines of code are free. The reason we still need such constructs is because at some point a human still needs to look at the code. Interfaces reduce the cognitive load."

That framing stuck with me. The cost of writing code has collapsed. The cost of reading it hasn't moved. And that asymmetry changes everything about how you should think about abstraction.

Here's what I mean.

Table of Contents

• Your Brain Is the Bottleneck

• The Greats Already Knew This

• The Economics Have Flipped

• The Data Backs It Up

• The Contrarian Case (And Why It Actually Agrees)

• What This Means for You

• References

Your Brain Is the Bottleneck

This isn't a vibes argument. There's actual neuroscience behind why interfaces help.

In 1988, educational psychologist John Sweller introduced Cognitive Load Theory. A 2022 ACM review covers how it's been applied to computing education since.

The short version: your brain juggles three types of load when processing information. Intrinsic load is the inherent difficulty of the problem itself. Extraneous load is the noise — poorly organized information, unnecessary details, bad naming. Germane load is the good stuff — the mental effort you spend building useful mental models.

Here's the kicker: your working memory can only hold a handful of chunks of information at a time — cognitive scientists typically estimate somewhere between 2 and 6. Not 2 to 6 files, or 2 to 6 classes — 2 to 6 things.

Felienne Hermans explores this in The Programmer's Brain (2021), arguing that design patterns act as chunking aids. When you recognize a Strategy pattern, your brain collapses an entire class hierarchy into a single cognitive unit. The word "Strategy" replaces five classes and their relationships. That's not hand-waving about clean code — that's how human memory actually works.

And we can literally see it on brain scans. In 2021, a team led by Norman Peitek and Janet Siegmund published an fMRI study on program comprehension that won the ACM SIGSOFT Distinguished Paper Award at ICSE.

They put developers in brain scanners and watched what happened when they read code. The finding: semantic-level comprehension — understanding what code does — required measurably less neural activation than bottom-up syntactic parsing — tracing how it does it.

An interface lets you comprehend at the semantic level. UserRepository.findById(id) tells you everything you need to know without opening the implementation. Your brain doesn't need to hold the SQL query, the connection pool logic, the error handling, and the result mapping in working memory simultaneously. The interface compresses all of that into one chunk.

That's not elegance. That's neuroscience.

The Greats Already Knew This

The case for abstraction isn't new. The people who built the foundations of computer science were making this argument before most of us were born.

Dijkstra said it with precision:

"The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."

Abstraction isn't about hiding things from people who can't handle complexity. It's about creating a level of discourse where you can reason clearly.

David Parnas formalized information hiding in his 1972 ACM paper: "Every module is characterized by its knowledge of a design decision which it hides from all others." He proved that decomposing systems by design decisions (rather than processing steps) produced modules that were both more flexible and easier to understand. Comprehensibility wasn't a bonus — it was the design criterion.

Tony Hoare argued that abstraction is the most powerful tool available to the human intellect — a way to manage complexity by focusing on what matters and ignoring what doesn't. Martin Fowler brought it down to earth:

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

And then there's John Ousterhout, whose book A Philosophy of Software Design (2018) makes the connection to cognitive load explicit. His central argument: more lines of code can actually be simpler if they reduce cognitive load.

His concept of deep modules — simple interfaces hiding complex implementations — is essentially the argument that interfaces are worth their weight in code. The Unix file system API (open, close, read, write, lseek) is five functions hiding an enormous amount of complexity. That's a deep module. That's the goal.

The Gang of Four put it first in their book for a reason. Page one: "Program to an interface, not an implementation."

None of this is controversial. But it's easy to forget when your AI tool just generated 200 lines of perfectly functional inline code in three seconds.

The Economics Have Flipped

Here's where the CEO's insight becomes an economic argument.

The historical case against interfaces was always about writing cost. Interfaces meant more code to write, more files to create, more boilerplate to maintain. The entire dynamic typing movement — Python, Ruby, JavaScript — was partly a reaction to the ceremony that languages like Java imposed. Convention over configuration. Don't Repeat Yourself. Less is more.

But ask yourself: what exactly is the cost of writing boilerplate now?

GitHub's 2022 controlled study found that developers using Copilot completed tasks 55% faster. The boilerplate that used to justify skipping interfaces — the extra file, the type definitions, the method signatures — takes seconds to generate. The writing cost of an interface has effectively collapsed to zero.

But again, the reading cost hasn't budged.

Robert C. Martin argued in Clean Code (2008) that developers spend far more time reading code than writing it — an observation he framed as a ratio of 10 to 1.

You can quibble with the exact number (it's anecdotal), but the direction is consistent across studies. A large-scale field study tracking 78 professional developers across 3,148 working hours found they spend roughly 58% of their time on program comprehension alone. New developer onboarding averages six weeks — most of which is spent understanding existing systems, not producing new ones.

Addy Osmani named this asymmetry perfectly. In a March 2026 piece, he described comprehension debt:

"When a developer on your team writes code, the human review process has always been a bottleneck — but a productive and educational one. Reading their PR forces comprehension. AI-generated code breaks that feedback loop. The volume is too high."

The output looks clean, passes linting, follows conventions — precisely the signals that historically triggered merge confidence. But comprehension debt is distinct from technical debt because it accumulates invisibly — your velocity metrics, your DORA scores, your PR counts all look fine while your team's actual understanding of the codebase quietly erodes.

So here's the math: AI reduced the cost of writing abstractions to near zero. The cost of not having them — in human reading time, onboarding friction, and comprehension debt — hasn't changed at all. The break-even point for "is this interface worth it?" just shifted massively in favor of "yes."

The Data Backs It Up

This isn't theoretical. We have data on what happens when AI generates code without good abstractions.

GitClear analyzed 211 million changed lines of code between 2020 and 2024. Their findings: code churn — lines reverted or updated within two weeks — doubled compared to the pre-AI baseline. Copy-pasted code blocks rose from 8.3% to 12.3%. And refactoring-associated changes dropped from 25% to under 10%.

AI-generated code, as they put it, "resembles an itinerant contributor, prone to violate the DRY-ness of the repos visited."

The METR study (2025) found something even more striking. Experienced open-source developers predicted AI would make them 24% faster. They perceived being 20% faster while using it. They were actually 19% slower. The perception gap is the story — you feel productive while generating code that creates more work downstream.

And then there's a study from Anthropic (yes, the company that makes Claude — full disclosure). They observed 52 software engineers learning a new library. The AI-assisted group completed tasks at the same speed, but scored 17% lower on comprehension quizzes afterward — 50% versus 67%. The biggest declines were in debugging ability. You can ship code you don't understand. You can't debug code you don't understand.

Kent Beck put it bluntly: "The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x." What that remaining 10% is, he leaves deliberately open — but it's hard to read that and not think about system design.

The Contrarian Case (And Why It Actually Agrees)

I'd be dishonest if I didn't address the people who argue against abstraction. And some of them are very smart.

Casey Muratori's "Clean Code, Horrible Performance" demonstrated that polymorphism and virtual dispatch can make code 10 to 15 times slower than straightforward procedural alternatives.

His benchmark is real. If you're writing a game engine or a high-frequency trading system, abstract interfaces on your hot path will cost you.

Dan Abramov wrote "Goodbye, Clean Code" after watching a premature abstraction make his codebase harder to modify:

"My code traded the ability to change requirements for reduced duplication, and it was not a good trade."

Sandi Metz put it more sharply: "Duplication is far cheaper than the wrong abstraction."

And Rich Hickey, in his talk "Simple Made Easy", draws the critical distinction: simple (not intertwined) is not the same as easy (familiar). Wrong abstractions complect — they braid concerns together rather than separating them.

Here's the thing: none of these are arguments against abstraction. They're arguments against bad abstraction.

Muratori's performance argument applies to hot paths in performance-critical systems — not to your REST API's service layer. Abramov and Metz argue against premature abstraction — pulling patterns out before you understand the domain. And Hickey's entire talk is a case for the right abstractions, the ones that genuinely decompose rather than complect.

The irony is that in an AI-assisted world, these arguments are easier to address. You can generate the explicit, unabstracted version first. Let it stabilize. Watch the patterns emerge. Then extract the abstraction — with AI handling the mechanical refactoring. The cost of the "duplicate first, abstract later" approach just dropped to near zero.

What This Means for You

If you're writing code with AI tools — and at this point, most of us are — the temptation is to let the AI produce whatever it produces and move on. It works. It passes the tests. Ship it.

But "it works" is table stakes. The harder question is: can the next person who opens this code understand it in under five minutes? Can you understand it in six months?

Interfaces aren't about making code prettier or satisfying some abstract (pun intended) design principle. They're compression algorithms for human cognition. They let your brain operate at the semantic level instead of the syntactic level. And now that AI has eliminated the only real cost of creating them — the boilerplate — there's no economic argument left for skipping them.

The rules haven't changed. The excuse has just expired.

References

Academic Papers

• Duran, R., Zavgorodniaia, A., & Sorva, J. (2022). "Cognitive Load Theory in Computing Education Research: A Review." ACM Transactions on Computing Education, 22(4), Article 40.

• Parnas, D.L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM, 15(12), 1053–1058.

• Peitek, N., Apel, S., Parnin, C., Brechmann, A., & Siegmund, J. (2021). "Program Comprehension and Code Complexity Metrics: An fMRI Study." ICSE 2021. ACM SIGSOFT Distinguished Paper Award.

• Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." arXiv:2302.06590.

• Shen, J.H. & Tamkin, A. (2026). "How AI Impacts Skill Formation." arXiv:2601.20245.

• Xia, X., Bao, L., Lo, D., Xing, Z., Hassan, A.E., & Li, S. (2018). "Measuring Program Comprehension: A Large-Scale Field Study with Professionals." IEEE Transactions on Software Engineering, 44(10), 951–976.

• METR. (2025). "Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity." metr.org.

Talks and Blog Posts

• Hickey, R. (2011). "Simple Made Easy." Strange Loop Conference.

• Beck, K. (2023). "90% of My Skills Are Now Worth $0." Tidy First? Substack.

• Osmani, A. (2026). "Comprehension Debt: The Hidden Cost of AI-Generated Code." addyosmani.com.

• Muratori, C. (2023). "Clean Code, Horrible Performance." Computer Enhance.

• Abramov, D. (2020). "Goodbye, Clean Code." overreacted.io.

• Metz, S. (2016). "The Wrong Abstraction." sandimetz.com.

• GitClear. (2025). "AI Assistant Code Quality in 2025." gitclear.com.

If you haven’t heard about what’s going on:

GitHub is struggling to contain an ongoing attack that’s flooding the site with with millions of code repositories. These repositories contain obfuscated malware that steals passwords and cryptocurrency from developer devices. … The result is millions of forks with names identical to the original one.

– Dan Goodin, Ars technica

Because search engines and GitHub’s own search rankings favor recent activity, these cloned repositories often float to the top – then they lure unsuspecting developers into pulling code that may contain malware.

One of my repositories has been targeted by such an attack, prompting me to monitor it closely. This guide offers tips to spot malicious repository clones before they catch you off guard.

Table of Contents

1. What is a Repository Confusion Attack?

   • Supply Chain Attacks

2. 🛡️ Basic Mitigation Strategies

   • Verify the contributors profiles

   • Search for clone repositories

   • Examine the commit pattern

   • Examine the commit history

   • Examine the commit contents

   • Compare the concerned files

   • Some information about the malware

3. Action Time

4. Conclusion

5. More Resources

What is a Repository Confusion Attack?

A repository confusion attack involves:

• Cloning legitimate repositories.

• Injecting malicious code into the clone.

• Uploading the clone.

• Spreading through various unaware actors.

Supply Chain Attacks

If you search for repository confusion on the internet, you'll find out it's a type of supply chain attack.

A supply chain attack is an indirect threat where hackers try infiltrating a system by targeting a trusted third-party or software component, rather than attacking the primary target directly.

It's not the first time this has happened. Before GitHub was targeted, PyPI was attacked in 2023 with fake packages posing as legitimate. These packages lured negligent pip users into downloading malicious payloads (containing in most cases infostealer malware).

🛡️ Basic Mitigation Strategies

Before using any repository, make sure you follow these steps and take these precautions.

Verify the contributors profiles

That's a first check: if you see a rather empty GitHub profile – one without reputation that contains just one repository but with a lot of daily commits to it – well, that's a bit suspicious.

In the fake repository, the original author will be listed as a contributor, too. Check that profile. You should be able to find the legitimate repository and do some comparisons.

In the above screenshot you can see solotech143, my evil doppelgänger (he’s been taken down since).

Search for clone repositories

You can do a GitHub search by repository name and sort the results by most recent first. Malicious repositories tend to appear at the top of the search results because they are updated more frequently. The original repository might be hidden deeper in the search results.

It’s like clone wars.

This is where it’s dangerous: users generally click on the first few search results, and in that type of attack, you’re almost guaranteed to see the attacker’s fake repository at the top of the results. The attacker achieves that by giving the fake repository regular fresh commits (and sometimes even a few stars!).

In my case, the original repository is a submission for the HackaViz 2025 competition. Hackathons offer a good attack surface because, beyond the fact they draw niche communities, they are also time sensitive.

Now, let’s move forward a year and imagine Hackaviz 2026 is starting soon. The attacker has easily outranked the untouched original submission. Which repository is most likely to be visited when future competitors – unaware of the scam – will look for the previous submissions?

Examine the commit pattern

Here’s when things take a weird turn. Malicious clones are run by automated agents, so the commit history fits a pattern that is rather unusual for a human. Of course, you can automate for many legitimate reasons but… this will always follow a clear goal and there will always be a human-touch at some point. In this case, commits are not adding up.

Let's see how that looks in the screenshots below:

Regular like a clock...

... and hyperactive!

Examine the commit history

You can’t! And that's the weird part. You're just able to see the last and the initial commit. So why is it hiding all of them? Do you like it when someone hide things from you?

For July 10th, we should be able to see 11 commits, where are the ten others?

Well, you can only check the first and last commit. That is not a lot for a repository that has more than 2000 commits registered.

Examine the commit contents

Well, since I can always check the last commit, I checked some of them. They share the same pattern: the bot is constantly looping over the README file doing the same modifications. As you can see in the screenshot below, it’s updating the file with links to an infected release.

Above you can see an AI agent stuck in the Readme loop of change.

Human edits are more varied. In a human-driven project, you will see a large mix of commits: feature commits, exploratory experiments, bug fixes, styling tweaks, and sometimes reverts. A bot clone will often just overwrite files, bump versions, or re-inject the same malicious payload repeatedly with no real contribution to the codebase.

Compare the concerned files

This is where common sense comes handy. So, you have two README's:

1. The first consists of AI-generated content that is cluttered with emojis and low-value information. It is designed solely to entice you into clicking the download link of the release.

2. The other follows best practices for creating a good README file. It is accurate and well-structured and functions as a valuable helper and explainer to the code. It also goes deep into the most important aspects of the project. This is usually a good sign that a repository is organic and genuine.

Some information about the malware

What do we have so far? Well, a suspicious link in a phishy, AI-generated README file that is consistent with a very suspicious pattern in the commit history.

Now, let’s have a closer look at that dubious release and let’s see what an online antivirus scanner might reveal about it.

The malware is packed only in the miniature-fortnight-v1.7.6.zip release.

Above you can see the result of a scan with an online scanner.

The .zip file contains only four files:

• config.txt

• launch.bat

• lua51.dll

• luajit.exe

These files are totally unrelated to the source project (a Python data science project with Jupyter notebooks combined to a React app using three.js).

I will not go into the detail in this article. But for the curious ones, it's an infostealer malware (a malware that will exfiltrate your credentials and other precious information about your configuration) similar to the one described in detail here.

Action Time

If you discover a potentially malicious repository, here are some steps you can take:

1. Document some evidence.

2. Notify the original repository maintainers.

3. Report the malicious clone to GitHub.

Reporting a repository or a profile on GitHub is easy and fast. Go to the user’s profile page, click “Block or report” in the left sidebar and choose “Report abuse” in the pop-up. You will have to complete a short contact form with some details about the behavior before submitting. If needed, you can find more information on GitHub.

Conclusion

This is a description of just one attack, from the perspective of someone who found out that one of his repository had been targeted. There are likely cases of more sophisticated attacks. But the clone repository flood we can see on GitHuB is definitely massive low quality automation. Quantity over quality.
To be honest, I'm quite surprised algorithms crafted at GitHub didn't manage to spot this one.

This also raises questions related to AI.

• What happens when LLMs are trained on malicious content? That’s a more general question about AI poisoning.

• A human might easily spot the patterns and the low quality content for now. But..

  • Imagine you are using coding agents, many of them. Will the agents pick-up the malicious clone instead of the original one? How to distinguish the repositories from an automaton's perspective?

  • The attackers will refine their tactics, making the clones more human-like and therefore luring us more easily into their traps.

• This is really a situation that makes me wonder about the early days of Google. Back then, the company had to fight huge amounts of spam due to keyword stuffing and manipulative SEO tactics. Will big tech companies have to go through a Florida update moment to face the rise of AI generated spam ?

More Resources

• A detailed description of the attack

• Complete safety recommendations

Stay Informed, Stay Secure!

A cheat-sheet is also available on my GitHub. Feel free to contribute to it!

In this guide, you'll build a complete Task Manager app with user authentication, protected routes, and full CRUD functionality, built with React on the frontend and Express/MongoDB on the backend.

This article will serve as your hands-on, code-first guide to building, securing, and deploying a MERN application, drawing from my own practical experience. Every section has code you can run, and I’ll give concise explanations along the way.

It doesn’t matter if you're just getting started with MERN or looking to level up your architecture and production deployment knowledge – this article is designed to get you from zero to production with confidence.

Table of Contents

• Prerequisites

  • Tools & Tech Stack

  • Skills & Setup

• Project Setup: Laying the Groundwork

  • Project Structure

  • Code Quality: Linting and Formatting

• Testing: Ensuring Robustness

  • Backend Testing (Node.js/Express.js)

  • Frontend Testing (React Testing Library + Cypress)

• How to Build the Task Manager

  • Backend Implementation (Node.js/Express.js)

  • Frontend Implementation (React)

• Deployment: From Localhost to Live

  • Backend Deployment (Node.js/Express.js)

  • Frontend Deployment (React)

  • Database Deployment (MongoDB Atlas)

  • 1. .env Configuration Example

  • 2. Connect to MongoDB in app.js

  • Other Deployment Options

• Security Best Practices: Fortifying Your Application

  • Setup Input Validation and Sanitization

  • Add Authentication and Authorization

  • Implement Rate Limiting

  • Setup CORS Configuration (Cross-Origin Resource Sharing)

  • Use Environment Variables

• Monitoring and Logging with Winston and Morgan

  • Frontend Error Monitoring (Sentry)

• Conclusion

Prerequisites

Before jumping in the project, here’s what you’ll need to get the most out of this tutorial:

Tools & Tech Stack

You’ll be using the following technologies throughout the project:

• Node.js & npm – Backend runtime and package manager

• Express.js – Web framework for Node

• MongoDB Atlas – Cloud-hosted NoSQL database

• Mongoose – ODM for MongoDB

• React – Frontend UI library

• React Router – For client-side routing

• Axios – For making API requests

• Jest & Supertest – For backend tests

• React Testing Library & Cypress – For Frontend unit and E2E tests

• ESLint + Prettier – For code formatting, linting

• Husky – To setup pre-commit hooks

• Helmet, Joi, express-rate-limit, cors – For security, validation, and best practices

• PM2 & NGINX – For backend deployment

• Sentry – For error monitoring

Skills & Setup

• Basic knowledge of JavaScript, React, and Node.js

• Familiarity with REST APIs and HTTP request/response flows

• Git and a GitHub account for version control

• A free MongoDB Atlas account

• Node.js and npm installed locally (Node 18+ recommended)

Project Setup: Laying the Groundwork

A well-structured project is crucial for maintainability. We'll adopt a clear separation between the front end and the back end here.

Project Structure

This structure clearly separates the React front end (client/) from the Node.js/Express.js back end (server/), promoting modularity and easier management.

my-mern-app/                # Root folder
├── client/                 # React frontend
│   ├── public/
│   ├── src/
│   │   ├── components/
│   │   ├── pages/
│   │   ├── App.js
│   │   └── index.js
│   └── package.json
├── server/                 # Node.js/Express.js backend
│   ├── config/
│   ├── controllers/
│   ├── models/
│   ├── routes/
│   ├── services/
│   ├── app.js
│   └── package.json

Code Quality: Linting and Formatting

Consistency is key when you’re building a production-grad application like this one. We'll use ESLint with Airbnb style and Prettier for automated code quality and formatting.

To install these tools, run this in your terminal:

npm install --save-dev eslint prettier eslint-config-airbnb-base eslint-plugin-prettier

And here are some setups with their recommended configurations:

This configuration sets up ESLint for a Node.js project using the Airbnb and Prettier style guides, with custom rules to relax strict linting constraints like allowing console.log and disabling mandatory function names.

.eslintrc.js (server-side example)

module.exports = {

  env: {

    node: true,

    commonjs: true,

    es2021: true,

  },

  extends: ["airbnb-base", "prettier"],

  plugins: ["prettier"],

  parserOptions: {

    ecmaVersion: 12,

  },

  rules: {

    "prettier/prettier": "error",

    "no-console": "off",

    "func-names": "off",

    "no-process-exit": "off",

    "class-methods-use-this": "off",

    "import/no-extraneous-dependencies": "off",

  },

};

.prettierrc

This config enforces consistent formatting: add semicolons, use trailing commas where valid, and prefer single quotes for strings.

{

  "semi": true,

  "trailingComma": "all",

  "singleQuote": true

}

Version Control: Git Essentials

Git is indispensable. You can use feature branches and pull requests for collaborative development, making it easier to work on large projects with coworkers. Consider using Husky for pre-commit hooks to enforce linting and testing.

Install Husky:

Install Husky to easily manage Git hooks, allowing you to automate tasks like linting and testing before commits.

npm install husky --save-dev

package.json (add script)

This package.json file sets up a Node.js project named my-mern-app, and configures a prepare script to install Git hooks using Husky (v7). It's ready for adding pre-commit automation, such as linting or testing.

{

  "name": "my-mern-app",

  "version": "1.0.0",

  "description": "",

  "main": "index.js",

  "scripts": {

    "prepare": "husky install"

  },

  "keywords": [],

  "author": "",

  "license": "ISC",

  "devDependencies": {

    "husky": "^7.0.0"

  }

}

Create a pre-commit hook

The below command sets up a pre-commit hook that automatically runs your tests and linter before each commit, ensuring code quality and preventing errors from entering your codebase.

npx husky add .husky/pre-commit "npm test && npm run lint"

Testing: Ensuring Robustness

Automated testing is vital. We'll cover unit, integration, and end-to-end testing in this guide.

Backend Testing (Node.js/Express.js)

You’ll use Jest for unit testing and Supertest for API integration tests.

Install them like this:

npm install --save-dev jest supertest

You’ll use Jest to write unit tests for your JavaScript code and Supertest to test HTTP requests against your Express.js API.

Example Test (server/tests/auth.test.js):

This test suite uses Supertest to simulate API calls for user registration and login, asserting that the responses have the expected status codes and properties.

const request = require('supertest');

const app = require('../app'); // Your Express app instance

describe('Auth API', () => {

  it('should register a new user', async () => {

    const res = await request(app)

      .post('/api/auth/register')

      .send({

        username: 'testuser',

        email: 'test@example.com',

        password: 'password123',

      });

    expect(res.statusCode).toEqual(201);

    expect(res.body).toHaveProperty('_id');

  });


  it('should login an existing user', async () => {

    const res = await request(app)

      .post('/api/auth/login')

      .send({

        email: 'test@example.com',

        password: 'password123',

      });

    expect(res.statusCode).toEqual(200);

    expect(res.headers['set-cookie']).toBeDefined();

  });

});

Frontend Testing (React Testing Library + Cypress)

You’ll use Jest and the React Testing Library for unit/integration tests, and Cypress for E2E tests.

You can install these like this:

npm install --save-dev @testing-library/react @testing-library/jest-dom jest cypress

React Testing Library will help you test your React components, and Cypress will provide comprehensive end-to-end testing of your frontend application.

Example Component Test (client/src/components/Button.test.js):

This unit test uses the React Testing Library to render a Button component and verifies that the specified text content is present in the rendered output.

import React from 'react';

import { render, screen } from '@testing-library/react';

import Button from './Button';


test('renders button with text', () => {

  render(<Button>Click Me</Button>);

  const buttonElement = screen.getByText(/Click Me/i);

  expect(buttonElement).toBeInTheDocument();

});

The following Cypress test simulates a complete user authentication flow, from registration to login and logout, asserting expected URL changes and page content.

Example E2E Test (cypress/e2e/auth.cy.js)

describe('Authentication Flow', () => {

  it('should allow a user to register and login', () => {

    cy.visit('/register');

    cy.get('input[name="username"]').type('e2euser');

    cy.get('input[name="email"]').type('e2e@example.com');

    cy.get('input[name="password"]').type('password123');

    cy.get('button[type="submit"]').click();

    cy.url().should('include', '/dashboard');

    cy.contains('Welcome, e2euser');

    cy.get('button').contains('Logout').click();

    cy.url().should('include', '/login');

    cy.get('input[name="email"]').type('e2e@example.com');

    cy.get('input[name="password"]').type('password123');

    cy.get('button[type="submit"]').click();

    cy.url().should('include', '/dashboard');

  });

});

How to Build the Task Manager

We'll build a simple Task Manager with user authentication and CRUD operations for tasks so you can see how the whole thing comes together.

Backend Implementation (Node.js/Express.js)

Dependencies

Start by installing our core backend libraries: Express for routing, Mongoose for MongoDB interactions, dotenv for environment variables, bcrypt/jsonwebtoken/cookie-parser for secure authentication, and helmet for setting secure HTTP headers:

npm install express mongoose dotenv bcryptjs jsonwebtoken cookie-parser

server/app.js (Entry Point)

Next, we’ll set up the first or the main entry point for the backend. This is the main Express.js application file, which configures middleware, establishes a MongoDB connection, and sets up API routes for authentication and task management.

const express = require('express');

const mongoose = require('mongoose');

const dotenv = require('dotenv');

const cookieParser = require('cookie-parser');

const helmet = require('helmet');

const authRoutes = require('./routes/authRoutes');

const taskRoutes = require('./routes/taskRoutes');

const { notFound, errorHandler } = require('./middleware/errorMiddleware');

dotenv.config();


const app = express();

app.use(helmet());

app.use(express.json());

app.use(cookieParser());


mongoose.connect(process.env.MONGO_URI)

  .then(() => console.log('MongoDB connected!'))

  .catch(err => console.error('MongoDB connection error:', err));


app.use('/api/auth', authRoutes);

app.use('/api/tasks', taskRoutes);


app.get('/', (req, res) => {

  res.send('MERN Task Manager API is running!');

});


app.use(notFound);

app.use(errorHandler);


const PORT = process.env.PORT || 5000;

app.listen(PORT, () => {

  console.log(`Server running on port ${PORT}`);

});

server/.env

To avoid hardcoding secrets, we’ll add a .env file where we can securely store environment variables, such as our database URI and JWT secret. This file stores sensitive environment variables such as your MongoDB connection string, server port, and JWT secret, keeping them secure and separate from your codebase.

MONGO_URI=your_mongodb_connection_string_here

PORT=5000

JWT_SECRET=supersecretjwtkey

server/models/User.js

Now, let’s define our User model using MongoDB. This schema includes fields for username, email, and password, with pre-save hooks for password hashing and a method for password comparison.

const mongoose = require('mongoose');

const bcrypt = require('bcryptjs');


const UserSchema = new mongoose.Schema({

  username: {

    type: String,

    required: true,

    unique: true,

  },

  email: {

    type: String,

    required: true,

    unique: true,

  },

  password: {

    type: String,

    required: true,

  },

});

UserSchema.pre('save', async function (next) {

  if (!this.isModified('password')) {

    next();

  }

  const salt = await bcrypt.genSalt(10);

  this.password = await bcrypt.hash(this.password, salt);

});


UserSchema.methods.matchPassword = async function (enteredPassword) {

  return await bcrypt.compare(enteredPassword, this.password);

};


module.exports = mongoose.model('User', UserSchema);

server/models/Task.js

Next, we’ll create the Task model. This schema defines the Task model, which links each task to a user and includes fields for title, description, completion status, and creation timestamp.

const mongoose = require('mongoose');


const TaskSchema = new mongoose.Schema({

  user: {

    type: mongoose.Schema.Types.ObjectId,

    ref: 'User',

    required: true,

  },

  title: {

    type: String,

    required: true,

    trim: true,

  },

  description: {

    type: String,

    trim: true,

  },

  completed: {

    type: Boolean,

    default: false,

  },

  createdAt: {

    type: Date,

    default: Date.now,

  },

});


module.exports = mongoose.model('Task', TaskSchema);

server/controllers/authController.js

Let’s build out the authentication controller. This controller handles user authentication flows, including registration, login, logout, and fetching user profiles, using JWTs and secure HTTP-only cookies.

const User = require('../models/User');

const jwt = require('jsonwebtoken');

const generateToken = (id) => {

  return jwt.sign({ id }, process.env.JWT_SECRET, {

    expiresIn: '1h',

  });

};

exports.registerUser = async (req, res) => {

  const { username, email, password } = req.body;

  try {

    const userExists = await User.findOne({ email });

    if (userExists) return res.status(400).json({ message: 'User already exists' });

    const user = await User.create({ username, email, password });

    if (user) {

      const token = generateToken(user._id);

      res.cookie('token', token, { httpOnly: true, secure: process.env.NODE_ENV === 'production', maxAge: 3600000 });

      res.status(201).json({ id: user.id, username: user.username, email: user.email });

    } else {

      res.status(400).json({ message: 'Invalid user data' });

    }

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};


exports.loginUser = async (req, res) => {

  const { email, password } = req.body;

  try {

    const user = await User.findOne({ email });

    if (user && (await user.matchPassword(password))) {

      const token = generateToken(user._id);

      res.cookie('token', token, { httpOnly: true, secure: process.env.NODE_ENV === 'production', maxAge: 3600000 });

      res.json({ id: user.id, username: user.username, email: user.email });

    } else {

      res.status(401).json({ message: 'Invalid email or password' });

    }

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};


exports.logoutUser = (req, res) => {

  res.cookie('token', '', { httpOnly: true, expires: new Date(0) });

  res.status(200).json({ message: 'Logged out successfully' });

};


exports.getUserProfile = async (req, res) => {

  try {

    const user = await User.findById(req.user._id).select('-password');

    if (user) {

      res.json(user);

    } else {

      res.status(404).json({ message: 'User not found' });

    }

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};

server/controllers/taskController.js

Now it’s time to implement the task controller. This controller provides the logic for fetching, creating, updating, and deleting tasks, ensuring that users can only interact with their tasks.

const Task = require('../models/Task');


exports.getTasks = async (req, res) => {

  try {

    const tasks = await Task.find({ user: req.user._id });

    res.status(200).json(tasks);

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};


exports.createTask = async (req, res) => {

  const { title, description } = req.body;

  if (!title) return res.status(400).json({ message: 'Please add a title' });

  try {

    const task = await Task.create({ title, description, user: req.user._id });

    res.status(201).json(task);

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};


exports.updateTask = async (req, res) => {

  try {

    const task = await Task.findById(req.params.id);

    if (!task) return res.status(404).json({ message: 'Task not found' });

    if (task.user.toString() !== req.user._id.toString()) return res.status(401).json({ message: 'Not authorized' });


    const updatedTask = await Task.findByIdAndUpdate(req.params.id, req.body, { new: true, runValidators: true });

    res.status(200).json(updatedTask);

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};


exports.deleteTask = async (req, res) => {

  try {

    const task = await Task.findById(req.params.id);

    if (!task) return res.status(404).json({ message: 'Task not found' });

    if (task.user.toString() !== req.user._id.toString()) return res.status(401).json({ message: 'Not authorized' });


    await Task.deleteOne({ _id: req.params.id });

    res.status(200).json({ message: 'Task removed' });

  } catch (error) {

    res.status(500).json({ message: error.message });

  }

};

server/middleware/authMiddleware.js

To protect private routes, we will create a middleware that verifies the JWT from the request's cookies, ensuring that only authenticated users can access specific endpoints.

const jwt = require('jsonwebtoken');

const User = require('../models/User');

exports.protect = async (req, res, next) => {

  let token;

  if (req.cookies.token) {

    try {

      token = req.cookies.token;

      const decoded = jwt.verify(token, process.env.JWT_SECRET);

      req.user = await User.findById(decoded.id).select('-password');

      next();

    } catch (error) {

      res.status(401).json({ message: 'Not authorized, token failed' });

    }

  } else {

    res.status(401).json({ message: 'Not authorized, no token' });

  }

};

server/middleware/errorMiddleware.js

To handle errors cleanly across our backend, we’ll add global error-handling middleware that can handle 404 Not Found errors and provide a centralized error-handling mechanism for consistent API error responses.

exports.notFound = (req, res, next) => {

  const error = new Error(`Not Found - ${req.originalUrl}`);

  res.status(404);

  next(error);

};


exports.errorHandler = (err, req, res, next) => {

  const statusCode = res.statusCode === 200 ? 500 : res.statusCode;

  res.status(statusCode);

  res.json({

    message: err.message,

    stack: process.env.NODE_ENV === 'production' ? null : err.stack,

  });

};

server/routes/authRoutes.js

Next, let’s define our authentication routes. These endpoints enable user authentication and map HTTP methods to their corresponding controller functions.

const express = require('express');

const { registerUser, loginUser, logoutUser, getUserProfile } = require('../controllers/authController');

const { protect } = require('../middleware/authMiddleware');


const router = express.Router();


router.post('/register', registerUser);

router.post('/login', loginUser);

router.get('/logout', logoutUser);

router.get('/profile', protect, getUserProfile);


module.exports = router;

server/routes/taskRoutes.js

Now we’ll add the routes for task operations. This file defines the API routes for task management, applying the protect middleware to secure all task-related operations.

const express = require('express');

const { getTasks, createTask, updateTask, deleteTask } = require('../controllers/taskController');

const { protect } = require('../middleware/authMiddleware');

const router = express.Router();

router.route('/').get(protect, getTasks).post(protect, createTask);

router.route('/:id').put(protect, updateTask).delete(protect, deleteTask);

module.exports = router;

Frontend Implementation (React)

Dependencies

Now, you’ll need to initialize a new React project and install your essential libraries: Axios for HTTP requests, React Router for navigation, and React Toastify for displaying notifications.

npm install axios react-router-dom react-toastify

client/src/index.js

Let’s start the frontend by setting up the entry point. Here we are rendering the main App component and wrapping it with AuthProvider to provide authentication context globally.

import React from 'react';

import ReactDOM from 'react-dom/client';

import './index.css';

import App from './App';

import { AuthProvider } from './context/AuthContext';


const root = ReactDOM.createRoot(document.getElementById('root'));

root.render(

  <React.StrictMode>

    <AuthProvider>

      <App />

    </AuthProvider>

  </React.StrictMode>

);

client/src/App.js

Next, we’ll define our main App component. This sets up the client-side routing for the application, and defines public and private routes, and includes a navigation bar and toast notification system.

import React from 'react';

import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';

import { ToastContainer } from 'react-toastify';

import 'react-toastify/dist/ReactToastify.css';


import Navbar from './components/Navbar';

import Register from './pages/Register';

import Login from './pages/Login';

import Dashboard from './pages/Dashboard';

import PrivateRoute from './components/PrivateRoute';


function App() {

  return (

    <Router>

      <Navbar />

      <ToastContainer />

      <div className="container">

        <Routes>

          <Route path="/register" element={<Register />} />

          <Route path="/login" element={<Login />} />

          <Route path="/dashboard" element={<PrivateRoute />}>

            <Route index element={<Dashboard />} />

          </Route>

          <Route path="/" element={<h1>Welcome to Task Manager!</h1>} />

        </Routes>

      </div>

    </Router>

  );

}

export default App;

client/src/context/AuthContext.js

We’ll create an authentication context that manages the global authentication state. It provides functions for user login, registration, and logout, and automatically loads user data on component mount.

import React, { createContext, useState, useEffect } from 'react';

import axios from 'axios';

const AuthContext = createContext();

export const AuthProvider = ({ children }) => {

  const [user, setUser] = useState(null);

  const [loading, setLoading] = useState(true);


  useEffect(() => {

    const loadUser = async () => {

      try {

        const res = await axios.get('/api/auth/profile');

        setUser(res.data);

      } catch (err) {

        setUser(null);

      } finally {

        setLoading(false);

      }

    };

    loadUser();

  }, []);


  const login = async (email, password) => {

    try {

      const res = await axios.post('/api/auth/login', { email, password });

      setUser(res.data);

      return true;

    } catch (err) {

      console.error(err.response.data.message);

      return false;

    }

  };


  const register = async (username, email, password) => {

    try {

      const res = await axios.post('/api/auth/register', { username, email, password });

      setUser(res.data);

      return true;

    } catch (err) {

      console.error(err.response.data.message);

      return false;

    }

  };


  const logout = async () => {

    try {

      await axios.get('/api/auth/logout');

      setUser(null);

    } catch (err) {

      console.error(err);

    }

  };


  return (

    <AuthContext.Provider value={{ user, loading, login, register, logout }}>

      {children}

    </AuthContext.Provider>

  );

};


export default AuthContext;

client/src/components/Navbar.js

Here’s a dynamic navigation bar component that dynamically displays links based on the user's authentication status, showing either login/register options or a welcome message and logout button.

import React, { useContext } from 'react';

import { Link } from 'react-router-dom';

import AuthContext from '../context/AuthContext';


const Navbar = () => {

  const { user, logout } = useContext(AuthContext);


  return (

    <nav>

      <h1>Task Manager</h1>

      <div>

        {user ? (

          <>

            <span>Welcome, {user.username}</span>

            <button onClick={logout}>Logout</button>

            <Link to="/dashboard">Dashboard</Link>

          </>

        ) : (

          <>

            <Link to="/login">Login</Link>

            <Link to="/register">Register</Link>

          </>

        )}

      </div>

    </nav>

  );

};


export default Navbar;

client/src/components/PrivateRoute.js

To protect certain pages, we can create a Private Route component. This will be a guard for private routes, ensuring that only authenticated users can access them and redirecting unauthenticated users to the login page.

import React, { useContext } from 'react';

import { Navigate, Outlet } from 'react-router-dom';

import AuthContext from '../context/AuthContext';


const PrivateRoute = () => {

  const { user, loading } = useContext(AuthContext);


  if (loading) {

    return <div>Loading...</div>; // Or a spinner

  }


  return user ? <Outlet /> : <Navigate to="/login" replace />;

};

export default PrivateRoute;

client/src/pages/Register.js

Now, let’s create the Register component, which provides a user registration form, handles input state and form submission, and displays success or error messages using toast notifications.

import React, { useState, useContext } from 'react';

import { useNavigate } from 'react-router-dom';

import { toast } from 'react-toastify';

import AuthContext from '../context/AuthContext';


const Register = () => {

  const [username, setUsername] = useState('');

  const [email, setEmail] = useState('');

  const [password, setPassword] = useState('');

  const { register } = useContext(AuthContext);

  const navigate = useNavigate();


  const handleSubmit = async (e) => {

    e.preventDefault();

    const success = await register(username, email, password);

    if (success) {

      toast.success('Registration successful!');

      navigate('/dashboard');

    } else {

      toast.error('Registration failed. Please try again.');

    }

  };


  return (

    <div>

      <h2>Register</h2>

      <form onSubmit={handleSubmit}>

        <div>

          <label>Username:</label>

          <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} required />

        </div>

        <div>

          <label>Email:</label>

          <input type="email" value={email} onChange={(e) => setEmail(e.target.value)} required />

        </div>

        <div>

          <label>Password:</label>

          <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} required />

        </div>

        <button type="submit">Register</button>

      </form>

    </div>

  );

};


export default Register;

client/src/pages/Login.js

Now, for the login form, it works similarly to the register page but logs users into the system instead. This page manages input fields, handles form submissions, and provides feedback via toast notifications.

import React, { useState, useContext } from 'react';

import { useNavigate } from 'react-router-dom';

import { toast } from 'react-toastify';

import AuthContext from '../context/AuthContext';


const Login = () => {

  const [email, setEmail] = useState('');

  const [password, setPassword] = useState('');

  const { login } = useContext(AuthContext);

  const navigate = useNavigate();


  const handleSubmit = async (e) => {

    e.preventDefault();

    const success = await login(email, password);

    if (success) {

      toast.success('Login successful!');

      navigate('/dashboard');

    } else {

      toast.error('Login failed. Invalid credentials.');

    }

  };


  return (

    <div>

      <h2>Login</h2>

      <form onSubmit={handleSubmit}>

        <div>

          <label>Email:</label>

          <input type="email" value={email} onChange={(e) => setEmail(e.target.value)} required />

        </div>

        <div>

          <label>Password:</label>

          <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} required />

        </div>

        <button type="submit">Login</button>

      </form>

    </div>

  );

};


export default Login;

client/src/pages/Dashboard.js

Finally, we’ll build the Dashboard page. This dashboard component displays a user's tasks, allowing them to create new tasks, mark tasks as complete or incomplete, and delete tasks, with real-time updates.

import React, { useState, useEffect, useContext } from 'react';

import axios from 'axios';

import { toast } from 'react-toastify';

import AuthContext from '../context/AuthContext';


const Dashboard = () => {

  const { user } = useContext(AuthContext);

  const [tasks, setTasks] = useState([]);

  const [newTaskTitle, setNewTaskTitle] = useState('');

  const [newTaskDescription, setNewTaskDescription] = useState('');


  useEffect(() => {

    if (user) {

      fetchTasks();

    }

  }, [user]);


  const fetchTasks = async () => {

    try {

      const res = await axios.get('/api/tasks');

      setTasks(res.data);

    } catch (err) {

      toast.error('Failed to fetch tasks.');

      console.error(err);

    }

  };


  const handleCreateTask = async (e) => {

    e.preventDefault();

    try {

      await axios.post('/api/tasks', { title: newTaskTitle, description: newTaskDescription });

      setNewTaskTitle('');

      setNewTaskDescription('');

      toast.success('Task created successfully!');

      fetchTasks();

    } catch (err) {

      toast.error('Failed to create task.');

      console.error(err);

    }

  };


  const handleUpdateTask = async (id, completed) => {

    try {

      await axios.put(`/api/tasks/${id}`, { completed });

      toast.success('Task updated successfully!');

      fetchTasks();

    } catch (err) {

      toast.error('Failed to update task.');

      console.error(err);

    }

  };


  const handleDeleteTask = async (id) => {

    try {

      await axios.delete(`/api/tasks/${id}`);

      toast.success('Task deleted successfully!');

      fetchTasks();

    } catch (err) {

      toast.error('Failed to delete task.');

      console.error(err);

    }

  };


  return (

    <div>

      <h2>Welcome, {user ? user.username : 'Guest'}!</h2>

      <h3>Your Tasks</h3>

      <form onSubmit={handleCreateTask}>

        <input

          type="text"

          placeholder="New Task Title"

          value={newTaskTitle}

          onChange={(e) => setNewTaskTitle(e.target.value)}

          required

        />

        <input

          type="text"

          placeholder="Description (optional)"

          value={newTaskDescription}

          onChange={(e) => setNewTaskDescription(e.target.value)}

        />

        <button type="submit">Add Task</button>

      </form>

      <ul>

        {tasks.map((task) => (

          <li key={task._id}>

            <span style={{ textDecoration: task.completed ? 'line-through' : 'none' }}>

              {task.title}: {task.description}

            </span>

            <button onClick={() => handleUpdateTask(task._id, !task.completed)}>

              {task.completed ? 'Mark Incomplete' : 'Mark Complete'}

            </button>

            <button onClick={() => handleDeleteTask(task._id)}>Delete</button>

          </li>

        ))}

      </ul>

    </div>

  );

};


export default Dashboard;

Deployment: From Localhost to Live

Deploying a MERN stack application involves deploying the backend API and the frontend React application separately.

Let’s talk about why we do it separately. As you have seen from above, in a MERN stack app, the frontend and backend are separate by design. React handles the UI, while Express and Node handle server logic and API calls. Because they serve different roles, you'll need to deploy them separately.

The backend runs on a Node.js compatible server, which connects to a database such as MongoDB Atlas. The frontend, once it is built, becomes static files that can be hosted from anywhere, from NGINX to hosting platforms like Netlify or Vercel.

This separation provides you with flexibility and improved scalability. Let’s walk through how to deploy each part.

Backend Deployment (Node.js/Express.js)

For backend deployment, platforms like Heroku, Render, or AWS EC2 are common choices. Here, I’ll outline a general approach for a cloud VM on AWS EC2

1. Prepare for Production

To start, set the environment to production and install only the dependencies your app needs to run, optimizing your application's performance. Skipping devDependencies helps reduce its footprint.

export NODE_ENV=production

npm install --production

2. Process Manager (PM2)

Next, we’ll set up a process manager to keep our backend server running reliably. PM2 is a popular tool that handles automatic restarts if your Node.js application crashes, manages multiple app instances, and also helps ensure high availability in production environments.

npm install -g pm2

pm2 start server/app.js --name mern-api

pm2 save

pm2 startup

3. NGINX as a Reverse Proxy

Now that our backend is running with PM2, we need a way to handle incoming web traffic. That’s where NGINX comes in. We'll install NGINX to serve as a high-performance reverse proxy directing incoming web traffic to your Node.js backend and serving static frontend files.

sudo apt update

sudo apt install nginx

Once NGINX is installed, it’s time to configure it (/etc/nginx/sites-available/default or a new config file). We’ll set it up to forward API requests to the backend and serve the React app, acting as the single entry point. You can update the default configuration file or create a new one:

# /etc/nginx/sites-available/default
server {

    listen 80;

    server_name your_domain_or_ip;


    location /api/ {

        proxy_pass http://localhost:5000;

        proxy_http_version 1.1;

        proxy_set_header Upgrade $http_upgrade;

        proxy_set_header Connection 'upgrade';

        proxy_set_header Host $host;

        proxy_cache_bypass $http_upgrade;

    }


    location / {

        root /var/www/my-mern-app/client/build; # Path to your React build folder

        try_files $uri /index.html;

    }

}

With the NGINX configuration created, we’ll enable it and restart the service to apply the changes, making your application go live:

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/

sudo systemctl restart nginx

4. HTTPS with Certbot (Let's Encrypt)

To secure your app with HTTPS, we can install Certbot and use it to automatically obtain and configure a free SSL/TLS certificate from Let’s Encrypt, enabling secure HTTPS connections for your domain.

sudo snap install --classic certbot

sudo certbot --nginx -d your_domain_or_ip

Frontend Deployment (React)

With the backend deployed, let’s move to the frontend. For the React frontend, we’ll build the application and serve the static files via NGINX (as shown above) or a dedicated static site hosted on platforms like Netlify, Vercel, or AWS S3 + CloudFront.

Build the React App

This command compiles and optimizes your React application into a build folder containing static assets, ready for efficient deployment to any web server or static hosting service.

cd client

npm run build

Database Deployment (MongoDB Atlas)

For production, we’ll use a managed MongoDB service like MongoDB Atlas. It handles replication, sharding, and backups, simplifying database management significantly.

Create a Cluster on MongoDB Atlas

• Sign up/Log in to MongoDB Atlas.

• Create a new cluster (choose a cloud provider and region).

• Set up a database user with appropriate permissions.

• Configure network access (allow connections from your server's IP address).

• Get your connection string and update MONGO_URI in your server/.env file.

1. .env Configuration Example

After creating the cluster and user in MongoDB Atlas, you’ll receive a connection string. You need to update your .env file with it

# server/.env
MONGO_URI=mongodb+srv://yourUser:yourPassword@cluster0.mongodb.net/yourDBName
JWT_SECRET=your_secret_jwt_key
NODE_ENV=production

2. Connect to MongoDB in app.js

Next, in the server/app.js file, make sure you're using the connection string from the environment variable:

const mongoose = require('mongoose');
const dotenv = require('dotenv');
dotenv.config();

mongoose.connect(process.env.MONGO_URI)
  .then(() => console.log('MongoDB connected!'))
  .catch((err) => console.error('Connection error:', err));

Other Deployment Options

While this article drives you through manual deployment with EC2 and NGINX, other platforms can simplify the process:

• Render, Railway, and Heroku offer easy full-stack deployment with GitHub integration.

• Vercel and Netlify are ideal for hosting the React frontend.

• You may consider using Docker to maintain consistent environments across development and production.

• For CI/CD, Linting, Testing, & Deployment can be automated on every push using tools like GitHub Actions

There is no right or wrong choice here. Select the setup that best suits your project’s scale, team experience, and desired level of control.

Security Best Practices: Fortifying Your Application

Security is paramount. You can implement these best practices to protect your MERN application.

Setup Input Validation and Sanitization

Always validate and sanitize input on the server side. You can use libraries like Joi or Zod to make this process easier.

Example with Joi:

To validate and sanitize incoming data on the server, we will utilize Joi, a powerful library for defining schemas and enforcing input rules.

npm install joi

Now that we’ve installed Joi, we will use it to define strict validation rules for user registration and login inputs. This ensures data quality and prevents common injection attacks.

// server/validators/authValidator.js

const Joi = require('joi');


const registerSchema = Joi.object({

  username: Joi.string().min(3).max(30).required(),

  email: Joi.string().email().required(),

  password: Joi.string().min(6).required(),

});


const loginSchema = Joi.object({

  email: Joi.string().email().required(),

  password: Joi.string().required(),

});


module.exports = { registerSchema, loginSchema };

Next, we’ll integrate these schemas directly into our authentication controller to automatically validate incoming request bodies against predefined schemas.

// server/controllers/authController.js (snippet)

const { registerSchema, loginSchema } = require('../validators/authValidator');


exports.registerUser = async (req, res) => {

  const { error } = registerSchema.validate(req.body);

  if (error) return res.status(400).json({ message: error.details[0].message });

  // ... rest of the registration logic

};


exports.loginUser = async (req, res) => {

  const { error } = loginSchema.validate(req.body);

  if (error) return res.status(400).json({ message: error.details[0].message });

  // ... rest of the login logic

};

Add Authentication and Authorization

You can use JWTs for authentication and implement middleware for protected routes.

JWT Implementation (covered in authController.js and authMiddleware.js above)

Key aspects:

• HttpOnly Cookies: Store JWTs in HttpOnly cookies to prevent client-side JavaScript access, mitigating XSS attacks.

• Secure Flag: Use secure: true in production to ensure cookies are only sent over HTTPS.

These practices ensure that authentication tokens are securely transmitted and stored, protecting against common web vulnerabilities like Cross-Site Scripting (XSS).

Implement Rate Limiting

To protect our API from abuse and malicious intent, we will implement basic rate limiting. This helps protect against brute-force login attempts and DDoS attacks.

Installation

We will install express-rate-limit package for it

npm install express-rate-limit

server/app.js (snippet)

Once it is installed, let’s configure the rate limiter and apply it to all incoming requests. This ensures that no single IP can overwhelm your server with repeated calls. The following middleware limits each IP address to 200 requests within a 15-minute window.

const rateLimit = require('express-rate-limit');

const limiter = rateLimit({

  windowMs: 15 * 60 * 1000, // 15 minutes

  max: 200, // Limit each IP to 200 requests per windowMs

  message: 'Too many requests from this IP, please try again after 15 minutes',

});

app.use(limiter); // Apply to all requests

Setup CORS Configuration (Cross-Origin Resource Sharing)

Next, we move our focus to enable secure communication between your frontend and backend. By default, all browsers block cross-origin requests, so we need to configure CORS (Cross-Origin Resource Sharing) to permit the React app to communicate with the Express API.

Installation

npm install cors

server/app.js (snippet)

Once installed, we can configure CORS for our Express application, specifying allowed origins and enabling credential sharing for secure cross-origin requests. Remember to replace the origin with your actual production URL when deploying.

const cors = require('cors');

app.use(cors({

  origin: 'http://localhost:3000', // Replace with your frontend URL in production

  credentials: true,

}));

Use Environment Variables

To keep sensitive information secure and out of your codebase, we will use environment variables. This allows us to efficiently manage secrets, such as database connection strings and JWT keys, without hardcoding them or including them in the source code.

Create a .env file in your server/ directory:

.env (example)

This .env file stores sensitive configuration details like database connection strings and API keys

MONGO_URI=your_mongodb_connection_string

JWT_SECRET=your_super_secret_jwt_key

NODE_ENV=production

Monitoring and Logging with Winston and Morgan

Once the application is live, it's critical to monitor the behavior and catch issues promptly. Monitoring and logging help you measure performance, find bugs, and keep a log of all server activity.

We’ll use Morgan for logging HTTP requests and Winston for more general-purpose application logging.

Installation

We will install Morgan for logging HTTP requests and Winston for comprehensive and customizable application logging.

npm install morgan winston

server/config/logger.js

Next, let’s configure Winston to handle our application logs. This will output logs to the console by default, with options to enable file-based logging for errors and general information.

const winston = require('winston');

const logger = winston.createLogger({

  level: 'info',

  format: winston.format.combine(

    winston.format.timestamp(),

    winston.format.json()

  ),

  transports: [

    new winston.transports.Console(),

    // new winston.transports.File({ filename: 'error.log', level: 'error' }),

    // new winston.transports.File({ filename: 'combined.log', level: 'info' }),

  ],

});

module.exports = logger;

server/app.js (snippet)

With Winston and Morgan set up, now let’s integrate them into our app.js file. We’ll use Morgan for request logging during development and replace standard console.log calls with Winston logs for structured and configurable application logging.

const morgan = require('morgan');

const logger = require('./config/logger');

if (process.env.NODE_ENV === 'development') {

  app.use(morgan('dev'));

}

// Replace console.log with logger.info for database connection

mongoose.connect(process.env.MONGO_URI)

  .then(() => logger.info('MongoDB connected!'))

  .catch(err => logger.error('MongoDB connection error:', err));


// Replace console.log in app.listen

app.listen(PORT, () => {

  logger.info(`Server running on port ${PORT}`);

});

Frontend Error Monitoring (Sentry)

To monitor errors in the frontend, we’ll integrate Sentry. It’s a fantastic tool for tracking exceptions and performance issues in real time. It helps us capture and report client-side errors.

Installation

npm install @sentry/react @sentry/tracing

client/src/index.js (snippet)

After installation, let’s initialize Sentry in the React application so that it can automatically capture errors and performance data. We’ll add this to our index.js file.

import * as Sentry from '@sentry/react';

import { BrowserTracing } from '@sentry/tracing';


Sentry.init({

  dsn: "YOUR_SENTRY_DSN", // Replace with your Sentry DSN

  integrations: [new BrowserTracing()],

  tracesSampleRate: 1.0,

  environment: process.env.NODE_ENV,

});

And that’s it! Congratulations on building and deploying a full-stack MERN app.

Conclusion

This article provided a code-first walkthrough of building, securing, and deploying a MERN stack application. By focusing on practical code examples and essential configurations, you now have a solid foundation for your MERN projects.

Remember, continuous learning and adaptation are key in the ever-evolving world of web development. Happy coding!

When code becomes difficult to read or change, it slows down progress and can even cause bugs. To keep a codebase healthy and easy to work with, you’ll need to take care of it.

Improving and organizing old code can feel like a big task, but there are tools and methods that can make it easier. This guide will show how to refresh your codebase step by step which will make it simpler to work with and less likely to cause issues.

Table of Contents

1. How to Review Your Code Effectively

2. How to Identify Technical Debt and Problem Areas in Code

3. How to Measure Code Quality with Code Analysis Tools

4. AI Tools to Help You Improve Your Code

5. Version Control Best Practices for Code Changes

6. Conclusion

How to Review Your Code Effectively

Code reviews are essential for catching issues early, improving readability, and ensuring long-term maintainability. Reviewing your own code or someone else’s involves more than just scanning for errors – you’ll also want to make sure each part is clear, efficient, and follows good practices.

Here’s a step-by-step approach to help you review code effectively, with practical strategies, tools, and what to look for during the process.

Strategies for Effective Code Review

1. Break Down the Review Process: Reviewing code all at once can be overwhelming, especially in large projects. Focus on small sections of the codebase at a time, such as individual functions or modules. This approach helps you examine each part closely and avoids missing issues that could be overlooked in a quick scan.

2. Review for Clarity and Simplicity: Good code should be easy to read and understand. When reading through the code:

   • Variable and Function Names: Are variable names descriptive enough to convey their purpose? Long, unclear names make code harder to follow.

   • Function Length: Keep functions short and focused on one task. Long functions are harder to debug and maintain.

   • Comments and Documentation: Comments should explain why something is done rather than what is happening, which should be clear from the code itself. For instance, avoid excessive commenting on trivial lines and focus on complex logic or business rules.

3. Check for Code Reusability and Modularity: Look for repeated code or functions performing multiple tasks. By modularizing code, you make it easier to test, update, and reuse. In a review, look for:

   • Duplicate Code: Repeated code can often be refactored into a function.

   • Single Responsibility: Each function should handle one task, making it easier to maintain and update.

4. Examine Error Handling and Edge Cases: Robust code should handle unexpected inputs or errors gracefully. During a review, think about potential edge cases that could break the code:

   • Null or Undefined Values: Does the code check for undefined values where needed?

   • Out-of-Range Errors: Ensure array indexes and calculations won’t produce errors with edge cases.

   • Error Messages: Make sure error handling is meaningful, with clear error messages where applicable.

5. Look for Performance Issues: Performance may not always be critical, but it’s good to check for potential bottlenecks. Look for:

   • Loop Optimization: Avoid deeply nested loops or repeated work inside loops.

   • Database Queries: Minimize unnecessary database calls.

   • Heavy Computation in the Main Thread: Move any heavy processing outside the main application thread if possible.

6. Ensure Consistency with Coding Standards: Following a consistent coding style improves readability across the team. Many teams use linters or style guides to enforce these standards. Look for:

   • Code Format: Consistent indentation, spacing, and use of braces.

   • Naming Conventions: Follow agreed naming conventions (camelCase, snake_case, and so on) consistently.

Tools to Assist with Code Reviews

There are a number of tools out there that can help streamline your code reviews, whether you’re checking your own code or collaborating with others:

1. Linters (like ESLint and Pylint)

Linters check for syntax errors, code smells, and style guide violations. They are especially useful for catching minor issues, like inconsistent formatting or unused variables. We will discuss ESLint more in an upcoming section.

# Example: Run ESLint on a JavaScript project
npx eslint src/

2. Static Analysis Tools (like SonarQube)

These tools analyze code for deeper issues like security vulnerabilities, code duplication, and complex functions that might need refactoring.

# Configuring SonarQube to scan a project
sonar.projectKey=my_project
sonar.sources=src
sonar.host.url=http://localhost:9000
sonar.login=my_token

3. Automated Testing Tools

Running tests can verify that code changes don’t introduce new bugs. Use testing frameworks like Jest for JavaScript, PyTest for Python, or JUnit for Java to confirm your code behaves as expected.

Example of Refactoring During Code Review

Let’s say you encounter a long function with multiple responsibilities. The goal is to split it into smaller, focused functions. Here’s how you can do that:

// Original: A single function that handles everything
function processOrder(order) {
    // Calculate total price
    let total = 0;
    order.items.forEach(item => {
        total += item.price * item.quantity;
    });

    // Apply discount
    if (order.discountCode) {
        total = total * 0.9; // 10% discount
    }

    // Send order confirmation email
    sendEmail(order.customerEmail, 'Order Confirmation', 'Your order total is ' + total);
}

// Improved: Break into smaller functions for readability and reusability
function calculateTotal(order) {
    return order.items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

function applyDiscount(total, discountCode) {
    return discountCode ? total * 0.9 : total;
}

function sendConfirmationEmail(email, total) {
    sendEmail(email, 'Order Confirmation', 'Your order total is ' + total);
}

function processOrder(order) {
    let total = calculateTotal(order);
    total = applyDiscount(total, order.discountCode);
    sendConfirmationEmail(order.customerEmail, total);
}

Breaking down the process into smaller functions makes the code cleaner, more readable, and easier to test. Each function now has a single responsibility, which helps reduce bugs and makes future updates simpler.

How to Identify Technical Debt and Problem Areas in Code

Technical debt refers to the accumulation of issues within a codebase that arise when development shortcuts are taken, often to meet tight deadlines or speed up releases. While these shortcuts may enable quicker progress initially, they lead to complications down the line.

Technical debt requires proactive management. If you leave it unchecked, it can reduce productivity, create bugs, and slow down development.

Think of technical debt like financial debt: taking on debt can be helpful in the short term, but failing to address it or pay it down will lead to greater challenges.

Common causes of technical debt include:

• Rushed development cycles: When teams prioritize quick delivery over thorough design and testing, they may produce incomplete or hastily written code.

• Lack of planning for future changes: Sometimes, code is written without accounting for scalability, leading to issues as the project grows.

• Insufficient documentation or testing: Without proper documentation and test coverage, codebases become difficult to understand and validate over time.

• Outdated frameworks and dependencies: When frameworks or libraries aren’t updated, they can become incompatible with newer components or security standards, introducing risk and hindering future updates.

Types of Technical Debt

Technical debt manifests in different ways. Here are some common examples:

1. Code Duplication:

Repeated code across multiple places within a project can lead to inconsistencies, as fixing an issue or updating a feature in one area may not carry over to others. Refactoring duplicate code into reusable functions or components is an effective way to reduce this debt.

Example: In a web application, you might find similar code for user authentication scattered across different modules. Instead, centralizing this logic into a single authentication module ensures consistent updates.

2. Outdated Dependencies and Frameworks:

Using old libraries or frameworks can slow down development and introduce security vulnerabilities. Over time, dependencies may lose support or become incompatible with new features, making them costly to maintain.

Solution: Regularly update libraries and frameworks, and monitor for deprecations or vulnerabilities. This can be streamlined by using dependency managers, which help check for updates and security patches.

3. Complex, Long Functions with Multiple Responsibilities:

Large, complex functions that handle multiple tasks are difficult to understand, test, and modify. Known as “God functions,” these make debugging cumbersome and increase the risk of introducing new bugs.

Solution: Follow the Single Responsibility Principle (SRP). This means that each function or method should accomplish one task. Breaking down large functions into smaller, focused units makes the code easier to read and test.

Example: Instead of having a single processUserRequest function that handles authentication, logging, and database queries, split it into three functions: authenticateUser, logRequest, and queryDatabase.

4. Insufficient Error Handling:

Code that lacks proper error handling can lead to bugs and unexpected behavior, especially in larger systems. Without clear error messages, diagnosing and fixing issues can be challenging.

Solution: Include comprehensive error handling and ensure that meaningful error messages are displayed. Log errors in a way that helps developers track and diagnose issues.

5. Hardcoded Values:

Hardcoding values directly into code makes it difficult to adjust settings without modifying the source code. For example, using fixed URLs or credentials directly in the codebase can create security risks and maintenance headaches.

Solution: Use configuration files or environment variables to store values that might change. This improves security and allows for easy updates.

6. Lack of Documentation and Testing:

Documentation and testing are often neglected when time is short. But without proper documentation and test coverage, the code becomes challenging to understand and validate, slowing down development and increasing the risk of bugs.

Solution: Implement test-driven development (TDD) or include time in the development cycle for creating documentation and writing tests. Aim for at least basic test coverage for critical paths and functions.

How to Identify and Manage Technical Debt

Identifying technical debt is crucial if you want to address and improve it. Here are some strategies you can follow:

1. Code Reviews: Regular peer reviews help uncover areas of potential debt. In reviews, team members can flag complex code, lack of tests, or unclear logic, helping address these issues early.

2. Automated Static Code Analysis: Tools like SonarQube, Code Climate, and ESLint (for JavaScript) analyze codebases for code smells, vulnerabilities, and complexity. They’re effective for spotting issues like duplicate code, long functions, and outdated dependencies.

3. Regular Refactoring Sessions: Scheduling dedicated time for refactoring allows the team to improve existing code quality. During these sessions, focus on simplifying code, breaking down large functions, and removing duplicates.

4. Technical Debt Backlog: Track technical debt items in a backlog, prioritizing them alongside feature development. This backlog helps balance feature work with debt reduction and keeps everyone aware of existing debt.

How to Deal with Technical Debt in Code

Here’s a practical example to demonstrate how refactoring can help address technical debt, specifically by removing code duplication.

Example: Removing Duplicate Code

Let’s say we have two functions that send different types of emails but use repeated code:

# Duplicate code example
def send_welcome_email(user):
    send_email(user.email, "Welcome!", "Thanks for joining!")

def send_password_reset_email(user):
    send_email(user.email, "Password Reset", "Click here to reset your password.")

Each function has a similar structure, so refactoring can make the code cleaner and reduce duplication.

# Refactored code
def send_email_to_user(user, subject, message):
    send_email(user.email, subject, message)

# Use the refactored function
send_email_to_user(new_user, "Welcome!", "Thanks for joining!")
send_email_to_user(existing_user, "Password Reset", "Click here to reset your password.")

This example demonstrates how consolidation can reduce repetition and make the code more flexible.

How to Avoid Technical Debt

Proactively managing technical debt helps reduce it over time. Here are ways to avoid accumulating more debt:

• Establish Code Standards: Create and enforce coding standards within the team. Consistent practices reduce complexity, improve readability, and make it easier to identify issues early.

• Refactor Regularly: Rather than waiting for debt to accumulate, make minor improvements during routine work. A “leave it better than you found it” approach ensures code quality remains high over time.

• Encourage Thorough Testing: Strong test coverage identifies potential problems early, reducing the likelihood of code with hidden issues. Testing tools like Jest for JavaScript or PyTest for Python make it easy to add tests to each function and module.

• Plan for Scalability: Think about future needs when designing code. Avoid shortcuts that might restrict scalability and performance as the application grows.

• Limit Workarounds and Temporary Fixes: If temporary fixes are necessary, document them and prioritize removing them as soon as possible. Keeping track of these “quick fixes” ensures they don’t become long-term issues.

How to Measure Code Quality with Code Analysis Tools

Code quality tools can help you find issues that might not be obvious. They can point out things like unused variables, code that’s hard to read, or security problems. Popular tools include ESLint for JavaScript, Pylint for Python, and SonarQube for different programming languages.

Here’s how to set up a simple code check with ESLint:

1. Install ESLint:

    npm install eslint --save-dev
   

2. Initialize ESLint:

    npx eslint --init
   

   This command will prompt you to answer a few configuration questions. You can choose your preferred style guide and select a few options about your environment and file format.

3. Example Code with Issues

   Here’s a sample JavaScript file (example.js) with a few common issues:

    // example.js
   
    var x = 10;   // Unused variable
    let y = 5;
    const z = 'Hello World'
   
    function calculateSum(a, b) {
        return a + b
    }
   
    calculateSum(3, 4);
   
    // Missing semicolon and inconsistent indentation
    if(y > 3){
        console.log("Y is greater than 3")
    }
   

4. Run ESLint:

    npx eslint example.js
   

   After running this command, ESLint will analyze example.js and report any issues based on the configured rules.

5. ESLint Output

   ESLint provides detailed feedback about the issues it detects:

    /path/to/example.js
      1:5  warning  'x' is assigned a value but never used          no-unused-vars
      3:12  error    Missing semicolon                               semi
      6:25  error    Missing semicolon                               semi
      10:1  error    Expected indentation of 4 spaces but found 3    indent
      11:26 error    Missing semicolon                               semi
   
    ✖ 5 problems (4 errors, 1 warning)
   

   Here’s a breakdown of each issue detected by ESLint:

   • Unused Variable: ESLint identifies that x is declared but never used (no-unused-vars rule).

   • Missing Semicolons: ESLint flags lines where semicolons are missing at the end of statements (semi rule).

   • Inconsistent Indentation: ESLint notices that line 10 doesn’t follow consistent indentation (indent rule).

6. Fixing the Code

   Based on ESLint’s feedback, here’s the corrected code:

    // example.js
   
    let y = 5;
    const z = 'Hello World';
   
    function calculateSum(a, b) {
        return a + b;
    }
   
    calculateSum(3, 4);
   
    if (y > 3) {
        console.log("Y is greater than 3");
    }
   

   • We removed the unused variable x.

   • We added missing semicolons.

   • And we adjusted indentation for consistent spacing.

7. Re-run ESLint to Verify Fixes

   After making these changes, you can run npx eslint example.js again to confirm that there are no remaining issues. ESLint will return no output if everything is now clean, confirming that the code adheres to the configured standards.

Additional Tip: Auto-Fixing with ESLint

ESLint can automatically fix some issues for you. To do this, use the --fix flag:

npx eslint example.js --fix

This command will automatically correct issues like indentation, unused variables, and missing semicolons where possible. But it’s important to review the changes to ensure they align with your intended functionality.

Reviewing code, spotting technical debt, and using quality tools help keep the codebase healthy. If you follow these steps, your project will be easier to manage and less likely to break.

AI Tools to Help You Improve Your Code

Using AI tools to restructure code makes improving code quality much faster and easier. These tools help find issues, suggest changes, and can even automate some parts of the refactoring process.

I'll share some AI tools that can help you with code analysis, refactoring, and dependency management, based on my own experience and what I've found useful.

Best AI Tools for Code Restructuring

AI-powered tools are becoming more common, and they offer different ways to boost code quality and simplify refactoring. Here are some I've found helpful:

1. GitHub Copilot

GitHub Copilot is like a coding assistant that provides smart suggestions as you write code. It can complete code snippets, suggest new functions, and help rework existing code to make it more efficient. I’ve found it useful for writing repetitive code blocks or coming up with quick refactorings.

For example, let’s say you need to rewrite a function to be more efficient:

# Original function that checks if a number is prime
def is_prime(n):
    if n < 2:
        return False
    for i in range(2, n):
        if n % i == 0:
            return False
    return True

GitHub Copilot might suggest optimizing the function like this:

# Optimized version suggested by Copilot
def is_prime(n):
    if n < 2:
        return False
    for i in range(2, int(n**0.5) + 1):
        if n % i == 0:
            return False
    return True

The updated version checks factors only up to the square root of n, making it faster for large numbers.

2. QodoGen

QodoGen provides automated suggestions for refactoring and can detect common code issues, like unused variables or large functions doing too many tasks. It also helps split complex code into smaller, more manageable pieces and can explain sections of the code base or the entire codebase which will facilitate the restructuring process.

This tool is capable of doing this because, unlike other AI assistants and general purpose code generation tools, Qodo focuses on code integrity, while generating tests that help you understand how your code behaves. This can help you discover edge cases and suspicious behaviors, and make your code more robust.

For example, if you have a function handling multiple tasks, QodoGen might suggest breaking it down:

# Before refactoring
def handle_user_data(user_data):
    validate_data(user_data)
    save_to_database(user_data)
    send_welcome_email(user_data)

# After refactoring
def handle_user_data(user_data):
    validated_data = validate_data(user_data)
    save_data(validated_data)
    notify_user(validated_data)

Separating the steps makes the code easier to maintain and test.

3. ChatGPT for Code Assistance

ChatGPT can act as a helpful companion when working on code restructuring tasks. Arguably the most used coding assistant, it provides advice on refactoring strategies, explains how to implement changes, or offers example snippets. It’s like having an expert to consult whenever you need guidance or ideas.

For instance, if you’re unsure how to optimize a function or restructure a class, ChatGPT can provide sample code or describe best practices. You can also ask it for help with understanding errors or fixing specific problems in your code.

Just make sure you double-check the code it provides (same goes for all these AI assistants) as it can hallucinate and make mistakes.

Automated Tools for Refactoring and Analysis

AI tools not only assist with writing code but also with analyzing it for quality improvements:

1. SonarQube

SonarQube scans the code to detect bugs, vulnerabilities, and code smells. It generates reports with suggestions on what to fix, helping maintain a healthy codebase.

# Sample SonarQube configuration
sonar.projectKey=my_project
sonar.sources=src
sonar.host.url=http://localhost:9000
sonar.login=my_token

2. ReSharper

This tool integrates with Visual Studio and offers automatic refactoring options. It highlights code that can be simplified or cleaned up and suggests ways to optimize the codebase.

3. DepCheck for Dependency Management

AI tools like DepCheck help find unused dependencies in JavaScript projects, keeping package files clean.

# Running DepCheck to find unused dependencies
npx depcheck

How These Tools Help with Code Restructuring

Using AI tools like GitHub Copilot, QodoGen, and ChatGPT speeds up the process of code restructuring. They provide suggestions that save time and catch issues early, making the code easier to maintain.

Combining these tools with automated analysis tools like SonarQube and ReSharper ensures all aspects of the codebase are covered, from quality checks to refactoring.

These AI tools have other features that facilitate this process: for example, they all have a chat feature that lets you ask questions and get replies about your code and any best practices you should be following. Also, QodoGen allows you to add parts of or the whole codebase for context with the click of a button, along with other features for test generation and pull request reviews.

When restructuring your codebase, having a variety of AI tools can make the process smoother and more efficient. This is AI usage at its best.

Version Control Best Practices for Code Changes

Version control keeps track of code changes, making it easier to manage updates, collaborate with others, and fix issues. Following some best practices can help maintain a clean and organized codebase.

Let’s look at how to manage code changes, track updates, and ensure quality through code reviews.

Using Git Branching Strategies to Manage Code Changes

Git branching helps keep different versions of the code separate, allowing multiple developers to work without affecting the main codebase. Here are some common strategies:

1. Feature Branching

Feature branches allow developers to work on a new feature without changing the main codebase. Each feature gets its own branch, and once complete, it can be merged into the main branch.

# Creating a new feature branch
git checkout -b feature/new-login-page

# Working on the new feature and then committing changes
git add .
git commit -m "Added login page UI"

# Merging the feature branch into the main branch
git checkout main
git merge feature/new-login-page

2. GitFlow Strategy

This strategy involves using multiple branches for different stages of development, such as feature, develop, and release. It separates development work and allows smoother integration and deployment.

• Main Branch: Contains production-ready code.

• Develop Branch: Holds the latest completed work, ready for the next release.

• Feature Branches: Created from the develop branch for new features.

Example:

# Switch to the develop branch
git checkout develop

# Create a new branch for a feature
git checkout -b feature/upgrade-search

# Commit changes and push the feature branch
git add .
git commit -m "Improved search feature"
git push origin feature/upgrade-search

How to Track and Document Code Updates

Documenting code changes helps keep the team informed and makes it easier to understand what was done later. Here are some tips for tracking updates:

1. Writing Clear Commit Messages

Commit messages should explain what was changed and why. A clear message helps others know the purpose of each update.

Example:

# Good commit message
git commit -m "Fixed bug that caused login failure on mobile devices"

# Bad commit message
git commit -m "Fixed bug"

2. Using Tags to Mark Releases

Tags can be used to label important points in the project’s history, such as release versions. This makes it easier to find stable versions of the code.

# Create a tag for version 1.0
git tag v1.0

# Push the tag to the remote repository
git push origin v1.0

3. Creating and Using Changelogs

A changelog lists the changes made in each version, helping developers and users see what was updated or fixed.

Example format for a changelog:

## [1.0.1] - 2024-10-01
### Added
- New login feature

### Fixed
- Resolved search issue on homepage

### Changed
- Updated user dashboard layout

Importance of Code Reviews in Maintaining Code Quality

Code reviews help catch errors, share knowledge, and ensure code stays clean and maintainable. Here are some practices to follow for effective code reviews:

1. Keep Code Changes Small

Smaller changes are easier to review, making it more likely to spot mistakes. Large changes can be broken down into smaller parts.

2. Use Pull Requests for Reviews

Pull requests create a space for discussion around changes. Team members can review the changes, suggest improvements, and approve the updates.

# Push the feature branch to the remote repository
git push origin feature/new-feature

# Create a pull request on GitHub, GitLab, or Bitbucket

3. Provide Constructive Feedback

Code reviews should aim to improve the code without discouraging the developer. Suggest better ways to solve problems and explain the reasoning.

Example comments during a code review:

• "Consider using a list instead of a dictionary for this data structure, as it simplifies the code."

• "This function is doing multiple tasks. It might be clearer if we split it into two separate functions."

Using these practices helps ensure code changes are managed effectively, updates are well-documented, and the quality of the codebase remains high. Regular code reviews and proper branching strategies make it easier for teams to collaborate and keep the project on track.

Conclusion

Reviving and restructuring a codebase can seem like a big task, but taking small, planned steps makes it manageable. Start by checking the current state of the code and making a list of areas that need work. Set clear goals and create a plan to improve the code, step by step.

Using the tools we discussed here can help find issues, suggest changes, and even automate some tasks. Version control practices, such as branching strategies and code reviews, keep changes organized and ensure the quality stays high.

With a solid approach, even the messiest codebase can become clean, efficient, and easier to work with.

Resources

• AI tools have been developed to assist with the Git branching, Pull Request reviews and approval. Check out this article to read more on one of my favorites.

• If you want a step by step tutorial on how to revive and refactor your code, check out this youtube video.

• Check out this freecodecamp article on code restructuring to dive deeper.

Connect with me on LinkedIn, Twitter, and my peronal blog if you found this helpful.

In a previous article, I talked about various React Hooks and how they work along with code samples and detailed explanations.

In this guide, I’m going to talk about some important things that I’ve learned while developing React apps. And these learnings are optimized based on using React Hooks. We’ll debunk some common myths, simplify common concepts, and optimize your code for the best performance.

What we’ll cover:

• How Will This Guide Benefit You?

• Prerequisites

• React State Must Be Immutable

• Don't Use State for Everything

• Derive Values Without State

• Compute Values Without Effects

• Keys Should Be Unique

• Use useEffect Last

• Conclusion:

How Will This Guide Benefit You?

Let’s say you have a knife and I ask you to cut out some shapes from a piece of cloth. You could do it, but it would take a while and be challenging using a knife. Instead, what if I gave you a pair of really sharp scissors and then asked you to cut out the patterns? It’d be much easier, right?

This guide is like that optimised approach of cutting cloth with scissors instead of a knife. I’ll teach you how to use React more easily, without as much struggle. We’ll discuss the important aspects of how React Hooks work, and we’ll also cover some do’s & don’ts.

Prerequisites

There is only one main prerequisite for following this guide: you should have used React hooks at least once. And by this I mean developed an application with React that leverages the power of hooks.

This article is for everyone who wishes to use React hooks to their full potential.

React State Must Be Immutable

Have you ever wondered why React makes such a fuss about immutability? 🤔 As a newbie, you might think that JavaScript's mutations are perfectly fine. After all, we add or remove properties from objects and manipulate arrays with ease.

But here's the twist: in React, immutability isn't about never changing state, it's about ensuring consistency.

When you mutate state directly, React can’t detect changes reliably. This means your UI might not update as expected. The trick? Replace old data with new copies.

For instance, if you need to add a user, you should create a new array with the new user included, rather than pushing directly into the existing array.

const updatedUsers = [...users, newUser];

The code const updatedUsers = [...users, newUser]; uses the spread operator to create a new array, updatedUsers, which combines the existing users with newUser.

This approach maintains immutability in React by not modifying the original users array. Instead, it creates a new state representation, allowing React to optimize rendering and ensure predictable state changes. When you update the state using setUsers(updatedUsers);, React re-renders the component based on this new array, adhering to best practices for state management.

This ensures React detects the change and re-renders your component smoothly.

Don't Use useState for Everything

Confession time: I used to throw everything into useState without thinking twice. 🚀 But here's the scoop: not everything needs to be in state. The state is powerful, but overusing it can lead to complex and inefficient code.

Consider alternatives like server state, URL state, or local storage. For server data, libraries like React Query are a game changer. They handle fetching and caching so you don’t have to manage it manually. For URL state, leverage hooks like useLocation from React Router or Next.js’s built-in methods.

Checklist before using useState:

• Is this value simple and derivable during render?

• Does a library already manage this state?

• Does it need to trigger a re-render?

• If you answer “no” to all, you might not need useState at all.

Derive Values Without State

Here’s a little-known trick: Derived values don't need to live in state. 🚀 If your data can be computed from existing states or props, calculate it directly during render.

For example, formatting a date can be done on the fly without additional hooks:

const formattedDate = new Date(date).toLocaleDateString();

The code const formattedDate = new Date(date).toLocaleDateString(); derives a formatted date string from a given date input without storing it in the component's state. By creating formattedDate as a constant, it calculates the value on the fly each time it's called, reflecting the current state of date.

This approach avoids unnecessary state management, simplifies rendering logic, and keeps the component efficient, as derived values are recalculated only when the underlying data changes. Thus, it promotes a clean, functional style of programming in React

This keeps your components clean and avoids unnecessary state updates.

Compute Values Without Effects

Stop using useEffect for simple computations! 🛑 If your value can be calculated directly from state or props and doesn’t involve side effects, do it during render. For expensive computations, wrap them in useMemo to optimize performance:

const expensiveValue = useMemo(() => computeExpensiveValue(data), [data]);This reduces the complexity of your code and keeps your components focused.

The code const expensiveValue = useMemo(() => computeExpensiveValue(data), [data]); uses the useMemo hook to compute a value (expensiveValue) based on the data input without triggering side effects.

It memoizes the result of computeExpensiveValue(data), recalculating it only when data changes. This approach prevents unnecessary recalculations on every render, enhancing performance for expensive computations.

By relying on useMemo, the component efficiently derives the value based on its current props or state, keeping the rendering process efficient and focused on the latest data.

Keys Should Be Unique

Guilty as charged: I’ve used array indexes as keys in lists before. 😅 But did you know this can lead to bugs? React relies on unique keys to identify items, and using non-unique values can mess things up.

Generate unique IDs using crypto.randomUUID() but make sure to do it only when your state updates, not on every render. For objects, consider adding an id property:

const itemWithId = items.map(item => ({ ...item, id: generateUniqueId() }));

The code const itemWithId = items.map(item => ({ ...item, id: generateUniqueId() })); creates a new array, itemWithId, where each item in the items array is augmented with a unique id.

The spread operator (...item) copies the properties of each item, while generateUniqueId() generates a new, unique identifier. This ensures that each item has a distinct key, which is crucial for React components when rendering lists.

Unique keys help React efficiently manage updates, identify changes, and optimize rendering performance by distinguishing between different list items.

Don't Leave Out Dependencies

One of React’s cruel quirks: Forgetting dependencies in useEffect can lead to stale closures. 😱 For example, if you useEffect doesn’t include the dependencies it needs, it might not update as expected.

Always double-check your dependency arrays:

useEffect(() => {// Effect logic}, [dependency]);

The code useEffect(() => { /* Effect logic */ }, [dependency]); defines a side effect in a React component that runs when the specified dependency changes. It's essential to include all relevant dependencies in the dependency array to ensure that the effect behaves correctly.

Omitting dependencies can lead to stale or incorrect values being used in the effect, as React may not re-run it when needed. Including all dependencies helps maintain synchronization between the component's state and the effect, ensuring predictable behaviour and preventing potential bugs related to missed updates.

If your UI isn’t updating correctly, this is often the culprit.

Use useEffect Last

Here’s a pro tip: Don’t rush to use useEffect. 🙅‍♂️ It’s powerful but can lead to messy code if overused. React frameworks provide solutions to manage side effects more elegantly. For data fetching, consider libraries like TanStack Query or SWR that handle requests and caching efficiently, leading to a better user experience.

Alternative strategies:

• Derive values directly.

• Respond to events with handlers.

Fetch data on the server or with dedicated libraries.

Conclusion

React is a robust library, but knowing how to use it effectively can make all the difference. These lessons are just the beginning.

Having an in-depth idea about in and outs of any technology helps you during development and optimization.

React Js is the perfect library for modern development it has everything to offer for development and optimization

Thanks for reading, and happy coding! 🎉

• Follow Me on X: Prankur's Twitter

• Follow me on LinkedIn: Prankur's Linkedin

• Look at my Portfolio here: Prankur's Portfolio

But as this happens, questions arise, such as who supports these applications? And who will make the updates if there is a feature request or bug?

Many low-code applications are often created by a single developer, inherently leading to a single point of failure.

And don't let the advertised simplicity of low-code trick you into thinking anyone can edit the app, fix any issues, and add new features. Low code can still contain complexity, and complex solutions can quickly become a problem for organizations and teams that leverage dozens, if not hundreds, of other low- or non-low-code dependencies.

This doesn't mean that organizations should strictly restrict who can create these applications. Doing so would contradict the very purpose of low code. It's a model that empowers stakeholders themselves to rapidly prototype ideas and develop low-cost solutions to problems that, in traditional development, might cost millions of dollars.

In this low-code world, both organizations and developers need a plan. Developers, specifically, should have a plan to transfer knowledge of their products, whether working in a team or independently.

How to Simplify Complexity

Our relatively small team has created numerous low-code solutions, primarily leveraging Microsoft's suite of products. Some of these solutions are simple low-code canvas apps, while others contain hundreds of dependencies that are anything but low-code.

We've learned, sometimes the hard way, the importance of ensuring maintainability in our development. This means supporting the applications we build and enabling existing and new team members to support them in the future.

Initially, we found ourselves drawn to the premise of being able to create products that solve problems quickly. Before we knew it, we had our own problem: how do we support the array of these products, ensuring that not just us but new team members could do so as well?

Slow Down to Speed Up

This might sound contrary to the low-code paradigm, but taking frequent pauses to consider the long-term impacts of your decisions is critical to ensuring the tools you build today can be supported tomorrow.

This does not mean reverting back to the speeds of traditional software development, but you should not consider building low-code products as a race to the finish line.

Pair Programming

Incorporating traditional software development practices can significantly benefit the low-code movement. Even if your applications involve little to no conventional code, concepts like pair programming can be effectively applied when building low-code products.

Take, for example, the process of building a Power App. Traditionally, only one person could edit an app at a time. Although that limitation has changed—multiple people can now edit an app simultaneously—defining a collaborative process remains crucial.

Our team often employs a primary "driver" approach, where one member leads the development while another observes, providing real-time feedback and suggestions.

This method keeps everyone engaged and helps mitigate the effects of tunnel vision on the product. And this collaborative approach is especially valuable for more complex aspects of the application.

For more straightforward tasks, we often work in parallel but stay closely connected via Teams or Zoom, ready to coordinate and ensure each different component is part of a cohesive whole.

Application/Code Reviews

Low code doesn't mean no code. It is challenging to create robust applications with drag-and-drop alone. Even something like Power Apps has its own language called Power FX.

Schedule time each week to walk through or review others' applications to become familiar with their creations. Look for places where things can be improved, and be ready to accept feedback on your creations, too.

If you're using traditional code in your project, some of this can be accomplished with PRs. For purely low-code implementations, keep a document of changes and have a sign-off process to ensure other team members can access new changes.

For example, imagine adding a new screen to a Canvas app, allowing users to update personal settings. That change should be documented as unreviewed until at least one other team member has reviewed and signed off on this new feature.

Get Other Team Members Involved

If you're on a team, each product should involve at least two people to avoid single points of failure. Ensure each product has a primary and secondary developer or product owner. For larger teams, allow that secondary role to rotate, ensuring each member is more intimately involved with the team's products.

One way to get others involved and up to speed is to have other team members add new features or fix bugs in existing products under the guidance of the primary or lead developer. This knowledge transfer will help cultivate ownership in the various products your team supports, leading to higher engagement and motivation.

Additionally, as the workload is distributed more evenly across the team, bottlenecks are reduced, allowing for more expeditious handling of fixing bugs and enhancing products.

When a Hands-On-Approach isn't Possible...

Much of what I describe above is an attempt to get others involved with projects. The more we touch these things, the better we will understand them.

Inevitably, however, when this hands-on experience isn't possible, it is essential to have practices that can mitigate the effects of isolated development—that is, a development done by one or just a few people.

The two most important things we can do are create and maintain comprehensive documentation about our products and use standard practices as much as possible. We'll talk about documentation first.

Document, Document, Document

As you've probably experienced, the low-code movement allows applications to be created quickly. The more applications exist, the fewer touchpoints we have with older ones. While those touchpoints are critical to the knowledge transfer process, relying on them alone isn't enough.

Whether you're on a team or a solo developer, creating documentation that describes each aspect of your products is critical. For small projects, this may be a simple text document. For larger projects, you could utilize a SharePoint site. Of course, as products become even more complex, the various dependencies will likely have their own documentation (for example, Git repositories).

Here is an example of how you might document a product you are building:

Let's say you have an application that allows users to reserve a conference room for meetings. That application consists of a user interface (such as a Canvas app) and custom code that creates a follow-up reminder for the person who reserved the meeting a day before. This reminder could send an email to remind the user about the meeting, and if the meeting is no longer occurring, encourage them to cancel the reservation. Finally, this product could also have a reporting element, where administrators can see conference room utilization over time to better understand demand.

Here is how you might document this project:

1. Establish a single source of truth about this project, such as a SharePoint page.

2. This page briefly describes the project, the product owners, and the lead developers.

3. The page would also briefly describe this project's components (Canvas app, custom code, and reporting dashboard).

4. Finally, you would include documentation on any easy-to-overlook aspects or non-standard project implementations (more on standardization later).

The SharePoint page handles the high-level overview of the project and gets you pointed in the right direction. Regarding the individual components, the Canvas app will include comments and notes in the version history, and your custom code will leverage Git and often include a detailed readme.

Documentation can be challenging, but it is critical. While documentation should be comprehensive, it should complement the hands-on knowledge transfer techniques described above.

Standardize as Much as Possible

Whether it is low-code or traditional development, it is important to have standard practices. This is even more important when talking about low code because of the speed at which things can be developed and potentially get out of control.

From project planning, design, development, and testing to cross training team members, make time to create standard practices for each phase.

Standardization shouldn't be considered a way to eliminate the need for cross-training and documentation but rather a way to complement those stages and reduce the time needed in those areas.

If you can approach a problem the same way every time, you can spend time discussing those non-standard and easy-to-forget parts of what you're building.

Here are some questions to get you started:

1. What big-picture steps will each application require? Who will be involved in those steps?

2. What tools will you use? (for example, Power Apps, Appian, Pega)

3. Can you support traditional development? If so, how will that look?

4. What is your philosophical approach to development? For example, should you design the user interface or business logic first? What database will you use? (for example, SharePoint or Dataverse)

5. What conventions will you use in your code? (for example, naming conventions for screens and variables)

6. What does this knowledge transfer or cross-training process look like? Do you have dedicated times each week to review each other's work?

Of course, this list goes on. The more you learn, the more you'll realize what needs to be discussed. Get started by creating a Standard Operating Procedure (SOP), and be prepared to edit it early and often.

What if I am a Solo Developer?

If you're a solo developer, it may be easy to think that the recommendations above don't apply. But this couldn't be further from the truth. Creating and maintaining a knowledge-transfer framework is even more critical as a solo developer. While co-developing and pair programming are not directly applicable, the concepts still apply.

For example, take time to meet other developers and ask for feedback. At a minimum, it will be an excellent way to meet other people doing the same thing. And, of course, with AI taking a front row in programming, you can always leverage AI to help you learn new techniques and optimize the things you are building.

Finally, documentation and standard practices are just as necessary for the individual developer. First, if you ever work with others, you'll have a reference for your work. Second, these things will act as an external reminder of how you intend to solve development-related problems in the future.

Conclusion

While low-code platforms offer incredible speed and flexibility, they can also introduce challenges when it comes to maintenance. Rapid development, if not managed carefully, can lead to issues that undermine the long-term success of your applications.

But by intentionally slowing down and establishing a clear plan for knowledge transfer, you can safeguard the future of your critical products. This approach ensures that applications remain supported and sustainable, both now and for years to come.

Stay curious.

Found this helpful? I write about practical automation, productivity systems, and building smarter workflows — without the jargon. Visit me at brandonwoz.com.

Unique identifiers (UIDs) are crucial components in software engineering and data management. They serve as distinct references for entities within a system and ensure that each item – whether a database record, a user, or a file – can be uniquely identified and accessed.

UIDs are critical for maintaining data, enabling efficient search and retrieval, and supporting large-scale operations in distributed systems. As data volumes and system complexities grow, the need for scalable UID solutions becomes increasingly important.

In this article, you'll learn all about the history of unique identifiers, as well as how some modern solutions work.

Table of Contents:

• Introduction to Unique Identifiers 🪪

  • The Historical Context of Identifiers

  • Government Management of Unique Identifiers

  • Structure of Social Security Numbers

• Scalability in Government Systems

  • Tech Companies and Their Scale

  • Meta (Facebook)

  • X (Twitter)

  • Telegram

• The Role of Auto-increment IDs and Their Scalability Issues

• Sequence Numbers and Their Advantages Over Auto-increment IDs

• UUIDs: Overview and Usage

  • What's so great about UUIDs?

  • UUID Version 1

  • UUID Version 4

  • UUID Version 5

  • UUID Version 7

  • UUID Version 2, 3, and 6

• Snowflake ID

  • "The Problem" stated by twitter:

  • Finding Tweet Timestamps

The Historical Context of Identifiers

The concept of unique identifiers has enveloped significantly over time, reflecting the growing complexity and scale of human societies and technological systems. To understand why unique identifiers are so important today, let’s look at how we've historically managed identification and how it was developed.

In early human societies, individuals were often identified by a single name. This was usually sufficient in small communities where everyone knew each other personally. But as populations grew, it became necessary to distinguish between individuals who shared the same first name. This led to the adoption of surnames.

For example, in Armenia 🇦🇲, surnames are used to identify individuals by their family or ancestry. Take the example of a person named Gor. In a small group of up to 50 people, let's say, identifying Gor by his first name alone is easy.

But as the group grows to a larger community of, say, 500 people, additional identifiers become necessary. Gor will be identified as Gor Grigoryan, indicating that he belongs to the Grigoryan family/ancestry. This surname provides a clearer identification and connects Gor to his family's lineage.

As societies continued to expand and bureaucratic systems became more complex, even surnames proved not enough for uniquely identifying individuals. This was especially true in larger cities and for the administration of government services. The need for more robust identification methods became apparent.

Government Management of Unique Identifiers

The introduction of passports in the early 20th century marked a significant step in this direction. Passports included unique personal identifiers, such as passport numbers, to distinguish between individuals clearly. These unique IDs ensured that each person could be accurately identified, regardless of name similarities or other ambiguities.

Several countries pioneered the use of unique personal identification numbers to address this need:

• Germany 🇩🇪: In the 19th century, Germany implemented a system for tracking individuals for social welfare and military conscription purposes.

• Sweden 🇸🇪: Sweden began issuing personal identification numbers (Personnummer) in the 1940s, providing each citizen with a unique identifier for use in various administrative processes.

• France 🇫🇷: France introduced the National Identification Number (Numéro de Sécurité Sociale) in the mid-20th century to streamline social security administration and other government services.

• United States 🇺🇸: The USA followed with the introduction of Social Security Numbers (SSNs) in 1936 as part of the Social Security Act. This approach to unique identification has since been adopted worldwide, with countries issuing national identification numbers to their citizens.

Information page, Edwin James Tharp’s passport, March 27, 1936, Robert and Eva Tharp Collection.

As illustrated in the example image, the 1936 UK 🇬🇧 passport included detailed personal information such as eye color, hair color, profession, height, and information about the holder’s spouse and children.

Structure of Social Security Numbers

A Social Security Number (SSN) in the United States is a nine-digit number formatted as "AAA-GG-SSSS". Each part of the SSN has historically carried specific information:

1. Area Number (AAA): Originally, the first three digits, known as the area number, represented the geographical region where the SSN was issued. This regional assignment helped to ensure a systematic distribution of numbers across the country.

2. Group Number (GG): The middle two digits, called the group number, were used to organize the numbers within a given area. The group numbers ranged from 01 to 99 and were issued in a specific order to prevent duplicate numbers within the same area.

3. Serial Number (SSSS): The last four digits are the serial number, which sequentially identifies each individual within a group. This part of the SSN ensures that even if the area and group numbers are the same, the overall SSN remains unique.

The Social Security Administration (SSA) has implemented several measures to ensure that each SSN is unique for the entire USA population (341.9 million people).

Governments around the world manage unique identifiers primarily for administrative purposes, such as social security, taxation, and national identification. These systems are designed to handle large populations and ensure that every citizen has a unique identifier for official records.

For example, the United States 🇺🇸 Social Security Administration (SSA) manages Social Security Numbers (SSNs) for over 330 million people. Similarly, the Indian 🇮🇳 government has issued Aadhaar numbers, a 12-digit unique identifier, to over 1.3 billion citizens. These identifiers are crucial for accessing government services, benefits, and other official processes.

Aadhaar is the world's largest biometric ID system described as "the most sophisticated ID program in the world".

Scalability in Government Systems

While government systems are large, they generally do not face the same scalability challenges as tech companies. Government databases are often centralized, and the rate at which new identifiers are issued is relatively steady and predictable. Also, the frequency of updates and interactions with these identifiers is lower compared to the dynamic environment of tech companies.

Tech companies, especially social media giants, operate on an entirely different scale. These companies manage billions of users and generate vast amounts of data daily. For instance, Meta (formerly Facebook) has over 3 billion monthly active users across its platforms, including Facebook, Instagram, and WhatsApp.

Tech Companies and Their Scale

Let's take a few examples:

Meta (Facebook)

1. User Base: With over 3 billion monthly active users, Meta needs a robust system to ensure that each user is uniquely identified.

2. Posts and Interactions: Facebook alone sees approximately 350 million new posts daily. Each of these posts, along with comments, likes, and shares require a unique identifier to manage interactions efficiently.

3. Messages: WhatsApp users send around 100 billion messages every day, each needing a unique identifier to ensure messages are correctly routed and stored.

4. Unique Data Rows: With the combination of user profiles, posts, comments, likes, and messages, Meta likely manages over 10+ trillion unique data rows. (If the global population is approximately 8 billion people, then 10 trillion people would be about 1,250 times the current global population).

X (Twitter)

Twitter, another social media giant, has about 450 million monthly active users. On average, users send around 500 million tweets per day. Each tweet, reply, and retweet needs a unique identifier to maintain the platform's integrity and usability.

Telegram

Telegram is known for its high-traffic and robust messaging platform. With over 700 million monthly active users, Telegram experiences particularly high traffic spikes during events like New Year's Eve, where users send billions of messages within a short timeframe.

On a typical day, Telegram handles over 70 billion messages. Each message, channel post, and group interaction requires a unique identifier to ensure proper delivery and organization.

The scale at which tech companies operate requires sophisticated and highly scalable unique identifier systems. These systems must handle high concurrency, support distributed architectures, and ensure low latency.

The Role of Auto-increment IDs and Their Scalability Issues

Auto-increment IDs are a common method for generating unique identifiers in relational databases. When a new record is added to a table, the database automatically assigns the next available integer value to the ID field. This method is straightforward and ensures that each record within a table has a unique identifier without requiring any manual intervention.

Consider a table for storing user information in a relational database. When the first user is added, they might be assigned an ID of 1. The second user would receive an ID of 2, and so on.

While auto-increment IDs are simple and effective for small-scale applications, they face significant challenges in larger, distributed systems.

1. Concurrency Issues: In high-traffic applications, multiple transactions might attempt to insert records simultaneously. Ensuring that each transaction receives a unique auto-increment ID can lead to performance bottlenecks and require complex locking mechanisms.

2. Distributed Systems: In distributed databases, where data is spread across multiple servers, maintaining a global sequence for auto-increment IDs becomes problematic. Each server would need to coordinate with others to avoid generating duplicate IDs, which can significantly impact performance and reliability.

3. Single Point of Failure: Relying on a central authority to generate auto-increment IDs introduces a single point of failure. If the server responsible for assigning IDs goes down, the entire system might be unable to add new records.

4. Predictability: Auto-increment IDs are predictable. If someone knows the ID of one record, they can infer the IDs of subsequent records. This predictability can be a security concern in certain applications, such as those involving financial transactions or sensitive user data.

CREATE TABLE Admins (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

CREATE TABLE Users (
    Id SERIAL PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

INSERT INTO Admins (Name)
VALUES ('GorGrigoryan'),
       ('GorGrigoryan2');

SELECT * FROM Admins;


-- +----+---------------+
-- | Id | Name          |
-- +----+---------------+
-- | 1  | GorGrigoryan  |
-- +----+---------------+
-- | 2  | GorGrigoryan2 |
-- +----+---------------+

Sequence Numbers and Their Advantages Over Auto-increment IDs

Sequence numbers are a method of generating unique identifiers by maintaining a counter that is incremented with each new record. Unlike auto-increment IDs, which are typically limited to a single database instance, sequence numbers can be designed to work across distributed systems, addressing some of the scalability and concurrency issues associated with auto-increment IDs.

How sequence numbers work:

1. Centralized Sequence Generators: A central service or database table generates and manages the sequence numbers. Each request for a new identifier increments the counter and returns the next value.

2. Distributed Sequence Generators: In a distributed environment, sequence numbers can be generated by dividing the range of possible values among different nodes or using more complex algorithms to ensure uniqueness without central coordination.

Consider a distributed database system with multiple nodes, each responsible for generating unique sequence numbers. The system might allocate ranges of sequence numbers to each node, ensuring that they can generate identifiers independently:

• Node 1: Allocated sequence numbers 1,000,000 to 1,999,999

• Node 2: Allocated sequence numbers 2,000,000 to 2,999,999

• Node 3: Allocated sequence numbers 3,000,000 to 3,999,999

Each node can now generate up to one million unique identifiers without needing to communicate with a central server. This approach improves scalability and performance, particularly in environments with high write loads.

CREATE SEQUENCE UserIdentifier
INCREMENT 1
START 1;

CREATE TABLE Admins (
    Id INT PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);

CREATE TABLE Users (
    Id INT PRIMARY KEY,
    Name VARCHAR(255) NOT NULL
);


INSERT INTO Admins (Id, Name)
VALUES(nextval('UserIdentifier'), 'GorGrigoryan'),
(nextval('UserIdentifier'), 'GorGrigoryan2');

INSERT INTO Users (Id, Name)
VALUES(nextval('UserIdentifier'), 'UserGorGrigoryan'),
(nextval('UserIdentifier'), 'UserGorGrigoryan2');


SELECT * FROM Admins;

-- +----+---------------+
-- | Id | Name          |
-- +----+---------------+
-- | 1  | GorGrigoryan  |
-- +----+---------------+
-- | 2  | GorGrigoryan2 |
-- +----+---------------+

SELECT * FROM Users;

-- +----+---------------+
-- | Id | Name          |
-- +----+---------------+
-- | 3  | GorGrigoryan  |
-- +----+---------------+
-- | 4  | GorGrigoryan2 |
-- +----+---------------+

Another advantage of using sequence numbers is that you can obtain the ID of the entity before it is inserted into the database.

In the case of auto-increment IDs, this assignment is typically handled by the database upon insertion, which can limit flexibility. With sequence numbers, you can easily generate the ID on the application side, which can be an easy task when using some ORMs e.g the EF Core ORM in C#

Check out sequence numbers on the SQL server here.

UUIDs: Overview and Usage

GUIDs (Globally Unique Identifiers), also known as UUIDs (Universally Unique Identifiers), are 128-bit identifiers designed to be globally unique. A typical UUID is displayed in a 32-character hexadecimal string, divided into five groups separated by hyphens. For example: 126e3456-e89b-12d3-a456-426614174000.

What's so great about UUIDs?

One of the standout features of GUIDs is their huge capacity for uniqueness. With a 128-bit structure, the total number of possible GUIDs is very large: Specifically, there are 340,282,366,920,938,463,463,374,607,431,770,000,000 GUIDs available. To put that into perspective, let's compare it with something tangible.

Did you know that scientists have attempted to calculate the number of grains of sand on Earth? Science writer David Blatner, in his book Spectrums, mentions that a group of researchers at the University of Hawaii tried to estimate this number. They determined that Earth has roughly (and we are speaking very roughly) 7.5 x 10¹⁸ grains of sand, or seven quintillion, five hundred quadrillion grains. For more, consider reading the article titled: "Which Is Greater, The Number Of Sand Grains On Earth Or Stars In The Sky?"

Now, to compare those numbers:

| GUIDs available | 340,282,366,920,938,463,463,374,607,431,770,000,000
| Sand grains     | 75,000,000,000,000,000,000

If you decided to create an application to track every grain of sand on Earth and assign each a unique identifier, you could easily do that using GUIDs. The fun part is that you could actually repeat this process 4,537,098,225,612,512,846 times over without running out of unique GUIDs! 🤯

UUID Version 1

UUID Version 1 generates unique identifiers based on the current timestamp, clock sequence, and node identifier (typically the MAC address of the machine generating the UUID).

According to RFC 4122, the timestamp is the number of nanoseconds since October 15, 1582, at midnight UTC. Most computers do not have a clock that ticks fast enough to measure time in nanoseconds. Instead, a random number is often used to fill in timestamp digits beyond the computer's measurement accuracy.

When multiple version-1 UUIDs are generated in a single API call, the random portion may be incremented rather than regenerated for each UUID. This ensures uniqueness and is faster to generate.

UUID v1 also has the mac address attached to it. By including a MAC address in the UUID, you can be sure that two different computers will never generate the same UUID. Because MAC addresses are globally unique, but also note that version-1 UUIDs can be traced back to the computer that generated them.

This ensures that the UUID is unique across both time and space. It is suitable when the generation time and machine uniqueness are important. It is often used in systems where the timestamp of creation is relevant or needed.

(Image from here)

UUID Version 4

UUID Version 4 generates identifiers using random or pseudo-random numbers. This method ensures a high probability of uniqueness due to the vast number of possible GUIDs. This is the most common UUID version.

There are 2 main variants of UUID:

• Variant 1: Minecraft UUID, also called Timestamp-first UUIDs

• Variant 2: "GUID"

(Image from here)

GUID is entirely random, making it simple to generate and ensuring that each identifier is unique with a very high probability. The unique identifiers are made up of 128 bits. They are written as 32 characters using numbers (0-9) and letters (A-F). The characters are grouped in a specific format: 8-4-4-4-12, separated by hyphens, like this: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.

The great thing about GUIDs is that you don’t need a central system to create them. Anyone can generate a GUID using an algorithm, and it will still be unique across different systems and applications. They are designed to be used nearly everywhere a unique identifier is needed. Here are some usage examples:

• Windows: Uses GUIDs to generate unique product keys

• Microsoft SQL Server: Uses GUIDs as primary keys to ensure global uniqueness across distributed databases

• AWS: Uses GUIDs for uniquely identifying resources in their cloud infrastructure, such as EC2 instances and S3 objects

• eBay: Uses GUIDs to identify listings, transactions, and users

UUID Version 5

UUID Version 5 generates unique identifiers based on a namespace identifier and a name. The namespace and name are combined and hashed using SHA-1 to produce the UUID. This ensures that the same namespace and name combination will always produce the same UUID. In UUID, the namespace must be a UUID, and the name can be anything.

UUID V5 is useful for generating consistent unique identifiers for the same input data across different systems and contexts. Let's say we want to generate a user id based on their username. Here’s how you can achieve this in C#:

Here the UUID Version 5 solves several important problems, particularly when you need a consistent and unique identifier based on a given input.

For instance, consider a scenario where you need a user ID to make an API call (or anything else), but in your code, you only have the username accessible. How would the problem be solved if we were using UUID Version 4 (GUIDs)? Most likely, it would work something like this:

/* When using GUID (UUID v4) */

var userName = "bob"; // Lets assume we only have username
// API call or DB call to get the user id using name
var userId = await userService.GetUserIdAsync(userName);

await userService.ChangeUserNameAsync(userId, "bob-2");

By using UUID Version 5 with a shared namespace across all your projects, you can easily generate the user ID from the username without making any additional API calls. So the same code would look like this:

/* When using UUID v5 */

// From some shared code
var userNamespace = SharedConstants.UserNamespace;

var userName = "bob"; // Lets assume we only have username

//Generate the user id in place, without additional call
var userId = Uuid.NewNameBased(userNamespace, userName);

await userService.ChangeUserNameAsync(userId, "bob-2");

This approach eliminates the need for redundant API calls. In a distributed system, making an API call to fetch a user ID every time you need it can be inefficient and slow. With UUID Version 5, you can locally generate the user ID from the username (or any other input), reducing the need for network requests and significantly improving the efficiency of your application.

What kind of problem have we solved with UUID v5? Let's say you need a user ID to make an API call but in your code, you have only a username, if you have the namespace shared across all your projects. Then you can easily get the user id using a username, without making any API call. That's because UUID v5 always reproduces the same UUID for the same input.

Also, UUID Version 5 ensures uniqueness and consistency across different systems. When integrating multiple systems or microservices, it can be challenging to keep user IDs consistent across various services. By using the same namespace and the same input (such as a username), UUID Version 5 guarantees that the generated IDs are unique and consistent across all systems, facilitating smoother integration and data consistency.

UUID Version 7

GUID Version 7 is a proposed new version that aims to combine the strengths of both timestamp-based and random-based GUIDs.

Problems with UUID v4 (GUID)

UUID Version 4 generates non-time-ordered values, meaning the identifiers created are not sequential. Since these values are randomly generated, they won't be clustered together in a database index. Instead, inserts will occur at random locations, which can negatively impact the performance of common index data structures, such as B-trees and their variants.

In a scenario where your product requires frequent access to recent data, non-sequential identifiers create a significant challenge.

With UUID Version 4, the most recent data will be inserted randomly throughout the index, lacking clustering. As a result, retrieving the most recent data from a large dataset requires traversing numerous database index pages.

In contrast, using sequential identifiers ensures that the latest data is logically arranged at the right-most part of the index, making it much more cache-friendly. This organization allows for faster and more efficient retrieval of recent data, as it minimizes the number of index pages that need to be accessed which is a lack in UUID v4.

The solution with UUID v7

UUID v7 is designed to provide unique and sortable identifiers that are both easy to generate and useful for distributed systems. It uses a combination of timestamps and random data to ensure both uniqueness and temporal order.

The first part of the UUID is a timestamp that provides a chronological component, ensuring that UUIDs generated close together in time are also close together in value. The remaining part is filled with random data, ensuring the uniqueness of each identifier.

Buildkite post about migrating to UUID v7

UUID Versions 2, 3, and 6

You may have noticed that our discussion focuses on UUID Versions 1, 4, 5, and 7, and skips over Versions 2, 3, and 6. Here's why:

• UUID Version 2: This version is rarely used in modern applications. It’s similar to Version 1 but includes additional fields for things like domain information (such as POSIX UID or GID). It was mainly used in legacy systems and is now considered largely obsolete.

• UUID Version 3: This version is based on a name and a namespace, similar to Version 5. The main difference is that Version 3 uses the MD5 hashing algorithm, which is less secure and less efficient than the SHA-1 algorithm used in Version 5. Version 5 is generally preferred because SHA-1 is more robust.

• UUID Version 6: Version 6 is still under draft as a proposed standard. It is meant to provide a time-ordered UUID with better performance for distributed systems, but since it hasn't been fully adopted yet, we focus on Version 7, which offers similar features and has more momentum.

Snowflake ID

Snowflake ID is a unique identifier generation system developed by Twitter to address the challenges of generating unique, sequential, and distributed identifiers in a highly scalable and efficient manner.

Unlike GUIDs, which are often non-sequential and can cause performance issues in database indexing, Snowflake IDs are designed to be both time-ordered and globally unique, making them ideal for distributed systems and databases where sequential order is important.

A Snowflake ID is a 64-bit integer composed of several distinct parts:

1. Timestamp (41 bits): The largest portion of the Snowflake ID is the timestamp, which records the number of milliseconds since a custom epoch (often set to the date when the system was first deployed). This ensures that IDs are time-ordered and can be easily sorted based on their creation time.

2. Datacenter ID (5 bits): This part of the ID identifies the datacenter where the ID was generated, allowing the system to generate unique IDs across multiple data centers without conflicts.

3. Machine ID (5 bits): Similar to the datacenter ID, the machine ID identifies the specific server or machine within the datacenter that generated the ID. This ensures that even within the same data center, IDs remain unique.

4. Sequence Number (12 bits): The sequence number is used to differentiate between multiple IDs generated within the same millisecond by the same machine. With 12 bits, up to 4,096 unique IDs can be generated per machine per millisecond.

The format was created by Twitter (now X) and is used for the IDs of tweets. It is popularly believed that every snowflake has a unique structure, so they took the name "snowflake ID". The format has been adopted by other companies, including Discord and Instagram. The Mastodon social network uses a modified version.

The format was first announced by X/Twitter in June 2010. Due to implementation challenges, they waited until later in the year to roll out the update.

• X uses snowflake IDs for posts, direct messages, users, lists, and all other objects available over the API.

• Discord also uses snowflakes, with their epoch set to the first second of the year 2015.

• Instagram uses a modified version of the format, with 41 bits for a timestamp, and 10 bits for a sequence number.

• Mastodon's modified format has 48 bits for a millisecond-level timestamp, as it uses the UNIX epoch. The remaining 16 bits are for sequence data.

"The Problem" stated by Twitter:

We currently use MySQL to store most of our online data. In the beginning, the data was in one small database instance which in turn became one large database instance and eventually many large database clusters. For various reasons, the details of which merit a whole blog post, we’re working to replace many of these systems with the Cassandra distributed database or horizontally sharded MySQL (using gizzard).

Unlike MySQL, Cassandra has no built-in way of generating unique ids – nor should it, since at the scale where Cassandra becomes interesting, it would be difficult to provide a one-size-fits-all solution for ids. Same goes for sharded MySQL. We needed something that could generate tens of thousands of ids per second in a highly available manner.

This naturally led us to choose an uncoordinated approach. These ids need to be roughly sortable, meaning that if tweets A and B are posted around the same time, they should have ids in close proximity to one another since this is how we and most Twitter clients sort tweets.

Additionally, these numbers have to fit into 64 bits. We’ve been through the painful process of growing the number of bits used to store tweet ids before. It’s unsurprisingly hard to do when you have over 100,000 different codebases involved.

Check out here for more information

Finding Tweet Timestamps

We all know that deleting a tweet isn't truly possible—once it's out there, it's how Twitter is designed. However, Twitter's use of Snowflake IDs adds an interesting twist to this narrative. Snowflake IDs are designed to be unique and time-ordered, which makes them not just identifiers but also a trail that can be tracked.

On May 11, 2019, Derek Willis from Politwoops uncovered a list of deleted tweet IDs. By using the Snowflake structure, he was able to extract the timestamps from these IDs, and discovered the 107 missing tweets. This finding inspired the creation of TweetedAt, a tool designed to accurately retrieve timestamps from Snowflake IDs and estimate the timing of tweets generated before Snowflake was in use.

Check out here.

Wrapping Up

Unique identifiers play a critical role in software engineering, ensuring data integrity and enabling efficient data management across distributed systems.

From traditional GUIDs to modern solutions like Snowflake IDs, each identifier system offers distinct advantages tailored to specific use cases.

As technology evolves, understanding these systems and their implementations becomes increasingly important for scaling applications effectively. By exploring the various versions and alternatives, we can make informed decisions that best suit our needs in managing data at scale.

Cover image: A 2017 post celebrating Facebook reaching 2 billion users.

But it can be hard to understand exactly how to do this. So I built this tutorial and this personal security/privacy assessment, based on what I've learned building Loki Privacy. These resources sum up thousands of hours of practice and research into five impactful (and largely free) steps.

By following these guidelines, you can really increase your digital security and privacy, and perhaps help mitigate a devastating hack of your personal finances or data.

Here's What We'll Cover:

1. Use Credentials Wisely
2. Choose Your Browser Wisely
3. Understand Encryption and What it Means
4. How You Spend Your Money Digitally Leaves a Trace
5. The Devices You Use Do Matter for Privacy and Security

1: Use Credentials Wisely

The first step is to properly manage your passwords, and add a layer of security with two-factor authentication.

Nowadays, digital passwords control an immense amount of power and personal information. You might access your bank and/or life savings with them, or critical and personal medical information about yourself. With great power as an Internet user comes great responsibility – and this is true of using modern passwords.

Use a Password Manager

Ideally, password managers are the best system to manage your credentials. They offer encryption and security to prevent undesired access, and they're able to give two critical properties to good passwords.

• First, they give you the ability to auto-generate passwords and login with the password manager if chosen. This helps avoid the cardinal sin of personal security on the web: password reuse across multiple services. If one service gets hacked with your password and you're reusing it across the web, hackers will try your login/password across the web, potentially turning one hack into multiple.
• Second is that password managers allow you to more easily create longer and more complex passwords.

Good options are services like 1Password and BitWarden. You can host your own version of BitWarden on your own server with something like StartOS and the open source implementation of BitWarden, Vaultwarden.

Use a Strong Password

The number and type of characters in your password can prevent people brute-force attacking you – that is, using machines to guess letter combos. Password strength is very dependent on character length. If you use 14-16 characters or more, it'll take a machine centuries to try to guess the password. But if you use 6 or fewer characters, it's likely your password can be cracked in seconds.

Your password strength can also improve if you add special characters, vary the case from uppercase to lowercase, and add numbers – anything that throws off machines that are going through character combinations by rote, hoping to get lucky.

Examples of strong passwords:

• 32-strings of random characters, ideally including numbers and special characters
• Multiple words strung together with some numbers/special characters to make it easy to work manually

Examples of weak passwords:

• Commonly used and reused word + number combos, like hello12
• Shorter strings like 342yf – the shorter your combination even if seemingly random, the easier to brute force
• Passwords you use across multiple services no matter their strength (if one of the passwords gets leaked, that will be attempted with all of your services).

Setup Two-Factor Authentication

You should also add two-factor authentication throughout your devices, and ideally the strongest versions of these. That way, even if one of your passwords gets cracked, it won't matter – because attackers won't have access to a second factor that allows them into your account.

You'll also want to get notifications for failed login attempts. That way you'll know if somebody has cracked your password (and you'll want to remove that password from any online services you currently use.).

Normally, this would be a combination of what's called HOTP and TOTP two-factor authentication.

HOTP and TOTP are both different one-time password schemes used by either hardware security keys or 2FA apps like Google Authenticator. You'll have seen it in action if you use a tool like Aegis or Raivo where you get resetting passcodes that you copy and paste into your browser every 30 seconds.

The difference between the two is that the HOTP code scheme tends to be used with hardware security keys and increments per use. But this leaves a longer time window where an attacker can breach the code.

Time-based systems only give you between 30 seconds to 60 seconds to login with the code, but the user is given enough time to retry codes given such a short window. Some of the most secure elements combine both HOTP and a time-based window.

Takeaway: Probably the best things you can do for your digital security right now are:

• Have a password manager system that allows you to avoid password reuse
• Have two-factor authentication either through an app (such as Aegis or Raivo) or if you're willing to invest, a hardware security key like a Yubico.

2: Choose Your Browser Wisely

Next, you'll want to think about the browser you’re using and what data you're revealing about yourself.

Use a Security-focused Browser

The browser you use to access the Internet stores data about you and shares data about who you are and what your interests are. Your choice of browser and the extensions you load will determine how much ad tracking you allow through, as well as the number of cookies.

A default installation of Firefox, Chrome, or Safari won't have much in the way of privacy-preserving features. But you can download extensions such as Privacy Badger, https everywhere, and uBlock Origin to help you better defend your online privacy and security.

These tools will serve as script-blockers and ad-blockers, as well as a guarantee that you'll be browsing sites where your data is encrypted – an important consideration when we get to point 3.

Consider using a VPN

Also, if you're using your regular Internet without a VPN or without using a service like Tor, you're likely revealing your IP address and your MAC address.

The IP address is malleable, but can reveal roughly where you are. IPInfo, for example, shows that you can tie an IP address to your location with the latitude and longitude represented, the company providing your Internet, and perhaps the business that owns the IP address.

Your MAC address is tied to your device and is relatively static. When you put on a VPN or use Tor, you can show a different IP address than the one tied to your home network or insecure open networks like the Wifi at your local coffee shop. But depending on the VPN you use, you could be giving them access to every site you visit – so it's important to ensure that you work with a provider that has a no-logs policy such as MullvadVPN.

Takeaway: If you're concerned about digital privacy and security, use a privacy-focused browser variant either on desktop or mobile. This could be something like Librewolf and Duckduckgo on mobile.

Your default search engine should not be Google. It should be Duckduckgo or a more privacy-focused variant (though note that Duckduckgo will still serve ads through Microsoft's ad exchange).

You should also understand the implications of giving off your IP address and MAC address. Make sure you evaluate whether or not using Tor or a VPN makes sense for you. Consider carefully the VPN you choose.

3: Understand Encryption and What it Means

The term "Encryption" is often bandied about. But you might be wondering how it really matters to you.

Well, when it comes to digital privacy and security, understanding the difference between https:// and http://, cleartext vs. hashed text, and end-to-end encryption matters a lot.

HTTP vs HTTPS

Let's start with https:// over http://. Why does it matter what type of site you're browsing?

HTTP powers the web. Essentially, when you're browsing the Internet, under the hood your device is making a series of HTTP requests to servers you direct it to. With regular http:// traffic, however, anytime somebody sees HTTP requests and communications, they can see the text within. This means that if you were sending passwords, credit card information, or other sensitive communications, it would be trivial to intercept those messages.

HTTPS, on the other hand, signs HTTP with encryption keys using a method called TLS. The short of it is that if you're using https:// and browsing sites everywhere with https:// (which an extension like HTTPs Everywhere can help force), that you're less likely to leak your data to attackers.

Cleartext vs Hashed Text

You'll often hear about cleartext vs hashed text when it comes to explaining a password breach. Cleartext means that if an attacker gets ahold of password data, they have your password in its full-text form. If it's hashed, that means the attacker will get a bunch of symbols that aren't your password but perhaps with some work, they can get to your password in plaintext.

If a website is storing your passwords in plaintext, it means that attackers that get a database full of passwords will be able to easily use that stash right away. A cleartext/plaintext leak means that you need to immediately change your passwords with much more urgency, though even if a password is hashed, you should still switch it over.

Services like haveibeenpwned.com will help you determine which password leaks apply to an email – and it's good to check every once in a while to see if you have any compromised credentials (some password managers will automatically check this for you as well.).

End-to-end encryption is a technical term that seems complex but delivers a simple promise: within the codebase, only the sender and receiver of a message will be able to see and decrypt the original message. This means that the service the messages are hosted on can't see what is being transmitted, and therefore can't send over that information to anybody.

Services like Signal offer end-to-end encryption by default (including in group chats) and are seen as the gold standard. WhatsApp also offers end-to-end encryption by default, though its association with Meta sometimes gets privacy advocates wary.

Other services offer variants, but you have to trigger them – for example, Telegram has end-to-end encryption for "Secret chats", but not group chats and non-secret private chats.

Takeaway: Make sure you're browsing on https:// sites with a browser extension (HTTPs Everywhere). Also, check to see if your passwords have been compromised and how they've been compromised with HaveIBeenPwned.com. And stick to end-to-end encryption on chat and communications if you want to make sure the people you want to see your communications are the only ones that do.

4: How You Spend Your Money Digitally Leaves a Trace

Online, one frontier for digital privacy is how you spend and own money. In the analog world, you can spend cash and rest assured that it is unlikely that your transaction will be traced back to you.

In the digital world, however, you have the burden of a credit card or debit card linked back to your address and names for every transaction you do. While online security has been developed to ensure that these don't leak (though they still can and have), there are also new ways to transact online with a (relatively) privacy-preserving option: Bitcoin, Lightning Network.

Lightning Network is a second layer technology built on Bitcoin that doesn't record its transactional flow between nodes on-chain, but rather settles channel opens/closes on it. This allows you to transact Bitcoin rapidly, without a fee, and not have your each transaction show up on the Bitcoin chain.

Now, the nuances of how to use tools like Lightning Network and Bitcoin in a way that preserves privacy merits a much fuller discussion – but be aware that a tradeoff now exists.

Yes, using Bitcoin will expose you to broadcasting your transactions over a public ledger, one scanned by perhaps millions of people. But it will also allow you to transact with the IP address of your choice, the device of your choice, and the identity of your choice. It's up to you to do the legwork and determine if that's a tradeoff worth having.

Takeaway: Be aware that there are alternatives to using a credit card or debit card online for all of your payments that are closer to how you might use cash in the analog world.

5: The Devices You Use Do Matter for Privacy and Security

Lastly, the devices you're using do matter for privacy and security. The Internet is a tradeoff: you get access to many different services, but you subject the devices you're using to access these services to giving off and receiving data.

Most of the commercialized laptops and phones out there have privacy and security features built in. An example of this is hardware changes that make recent iPhones more resilient, or frequent security updates for the operating system in question, from Linux, Microsoft, to Mac, to iOS and Android.

The tradeoff with devices, though, tends to be the expense, cost, and maintenance. In theory, having a second device on both laptop and mobile (for travel purposes, for example, to avoid border seizures) is ideal. And you may want to experiment with different operating systems – for example, the privacy-focused GrapheneOS for mobile, and System76 or Pinebooks for Linux-based laptops.

You might even go further and decide to experiment with home-based servers to run your own services.

Ultimately, the choice is yours: the cost of experimentation here can be high in terms of time and money spent, but can be well-worth it to maintain control over your own devices and data.

Takeaway: Consider the devices you use. Make sure you're on top of security updates, and determine how and which devices you want to use going forward.

Wrapping Up

If you're interested in learning a bit more about how your digital security and privacy stacks up, this assessment will help you determine your level and give you specific recommendations.

The most important thing about digital security and privacy is to be mindful of the tradeoffs, and to consider and often re-evaluate best practices in an actively evolving ecosystem.

Database management is a critical skill a developer must possess in building scalable applications that have a high level of efficiency. If not handled properly, it can result in data loss and mismanagement on the part of the database developer.

Hence, databases must be structured and built with the users in mind and built utilizing the best practices available.

This article aims to highlight general principles of database best practices and also explain each peculiarity. But before we discuss that in detail, let’s review what database transactions are all about.

What are Database Transactions?

Database transactions are simply groups of operations which can be termed as a unit of a work process performed on a database within a database management system.

It encompasses basic operations such as CRUD operations to more advanced operations such as database indexing, caching, and normalization.

With so many users performing many transactions at the same time, it’s important to ensure that the database is concurrency-enabled to prevent data interference between two or more users accessing the same resource.

Hence, there is the need for the ACID principle. What then does ACID represent?

• Atomicity
• Consistency
• Isolation
• Durability

Subsequently, we will be discussing each point in detail. First on our list is atomicity.

What is the Database Atomicity Principle?

What does database atomicity entail? The atomicity of a database simply means that a database operation can’t be broken down further as a unit. This means that the database operation or transactions gets executed completely, and in case any error comes up during the execution process, the entire operation gets completely cancelled, preventing room for partial operation execution.

If the database isn’t atomic, this can result in the provision of misleading incomplete data and ultimately result in entire system chaos. How does the database ensure atomicity? It does this by creating a copy of the existing database before the operation gets executed and then initiates a crash recovery and backup restoration operation in the event of an operation failure.

It is also important to note that other database principles such as consistency and durability rely on the need for the database to be atomic to be truly fulfilled.

Having discussed this, let’s move on to the database consistency principle.

What is the Database Consistency Principle?

This principle entails that the database has certain constraints, cascades, triggers and other requirements in place, which needs to be fulfilled while making changes to an established database. Failure to fulfill this requirement will lead to consistency errors, returning the database to its previous stable state.

Also, consistency as a principle ensures that the data updated by a user is made available as the latest version of the data in the database to all users who desire to read the database. Having this in place eliminates the occurrence of inconsistencies and aids faster information retrieval.

Understanding what it means for a database to be consistent involves ensuring the operation performed on the database passes the integrity check before being successfully executed. Having exhausted this in detail, let's discuss the database isolation principle.

What is the Database Isolation Principle?

Why should we isolate a database and how does one make a database operation independent from other database operations?

Isolation is necessary in a database management system to ensure that the user's access to information on the database is not interfered with by other concurrent transactions undertaken by other users on the database. To enforce this, the use of isolation levels in each database operation helps to preserve information integrity.

To effectively guarantee the database integrity, specific database isolation levels must be used. Here are some of the isolation levels ranked in order of hierarchy:

• Read uncommitted
• Read committed
• Repeatable read
• Serializability

Read Uncommitted Isolation Level

The read uncommitted database isolation level allows other users to have access to read current database transactions which has not yet been completely or successfully executed. It allows access to read what is being referred to as dirty read, which is one of the data inconsistencies that can be seen. This level of data isolation isn’t advised.

Read Committed Isolation Level

This database isolation level disallows other users to read or have access to a database transaction that has not yet been committed. Hence it prevents other users from seeing, updating or overwriting it until it has been completely executed.

Repeatable Read Isolation Level

This isolation level exclusively isolates a transaction from other transactions occurring concurrently, preventing other users access to read and update the transactions.

Serializability Isolation Level

This is the highest level of data isolation and is referred to as the strictest level. It isolates the multiple transactions performed concurrently and executes them efficiently as they are executed serially. It also prevents database inconsistencies.

Without these levels in place, inconsistent database mishaps such as dirty reads, non-repeatable reads, phantom reads and many others may be experienced. With this, let's move on to the last point about database durability and discuss it in detail.

What is the Database Durability Principle?

What does it imply when we describe a database as durable and how do we ensure the durability of a database? Durability as it sounds is a principle which ensures that databases have a high level of immortality.

Irrespective of any adverse outcomes that the database management system might face such as outages and crashes, there shouldn't be any loss of database information.

How do databases try to achieve this? The database creates a transactional log that contains the recorded data before any new operation gets executed. In the event of any of these adverse events, the transaction log serves as the backup store, ensuring that the database info is well preserved up to the point before the operation occurred, thereby mitigating against data breaches and loss.

We'll also highlight other helpful database operations best practices that can also be implemented.

Other Database Operations Best Practices

The BASE principle, which is more suited for NoSQL databases such as MongoDB, Redis, and Cassandra, and so on. It entails a database to be:

• Basically available
• Existing in a soft state
• And be eventually consistent.

Basically Available

This entails that the database prioritizes the availability of the database operations over consistency and concurrency. This is quite applicable to distributed systems which rely on a high level of efficiency to function effectively.

Soft State

This ensures easy flexibility of the database, allowing for size scaling, operations and increased concurrency for optimal database performance at all times. This allows the data to maintain resiliency.

Eventually Consistent

This entails that, irrespective of how the transactions get executed in the sequences, it eventually achieves efficient consistency. This is achieved by conflict resolution and reconciliation. This eventually contributes to the building of a resilient data system.

Conclusion

With this, we have come to the end of the tutorial. We hope you’ve learned essentially about optimizing database operations and their efficiency using the ACID principle and other best practices available.

Feel free to drop comments and questions in the box below, and also check out my other articles here. Till next time, keep on coding!

Web accessibility aims to make it possible for anyone to access web content. There are common accessibility best practices for designers, developers, and writers. This article will cover some best practices for creating technical content.‌

What is Web Accessibility?

Web accessibility is the practice of making it possible for anyone to consume or create content on the web, regardless of any health, economic, geographic, or language challenges they may have.

Why is Web Accessibility Important?

It is important to apply web accessibility best practices in your projects for a number of reasons.

First, it'll help you reach a wider audience. When a person who may have different abilities comes across some data on the web – say on your website – they'll want to learn more or use the data. But if they are not able to access it, you will not be happy or have a good experience.

Imagine how many people are unable to utilize the web because they are not considered when devs and designers are making decisions about how the product, website, or tool will be built.

Another important thing about accessibility is that it improves your brand's quality. Letting people know you are an accessibility-oriented person or company by implementing it in your work shows that you want your information to be available t everyone. It also displays your versatility in your craft and your ability to improve and adapt with changing times and trends.

Also, as an individual, applying accessibility best practices benefits you as well. There are possible employment opportunities for developers and designers with great accessibility skills.

Good accessibility practices mean good SEO practices too, which can result in more visibility for your work.

Finally, accessibility is enforced by law in certain countries around the world, and web accessibility strategies are implemented by certain countries. There could be legal consequences if you overlook accessibility on your websites and apps.

How to Write Accessible Technical Documentation

Software engineers have a key role in making the web accessible. But when it comes to writing documentation, technical writers also have a role to play in improving web accessibility.

Technical writers help write various types of content, like user guides, tutorials, API references, code documentation, and so on.

Now, let's look at some of the best practices for implementing web accessibility in technical writing. These strategies will help improve your documentation and make it more user-friendly and accessible to everyone.

Use clear headings and paragraphs

When writing content, you should make sure to use headings – along with the proper heading hierarchy (H1 for the title of the page/article, H2 for major headings, H3 for subheadings, and so on).

Also, make sure to break your content up into paragraphs so it's easier to read and understand.

When you introduce a new topic, use a heading to call that out. When you talk about smaller topics within that section, use subheadings to alert the reader.

Headings are also important to help screen readers understand a page's contents and how to navigate through them. So use headings to help guide readers through the text in a logical manner.

You denote headings in markdown with hashes. Here's an example of headings in hierarchical order.‌

# Use H1 for the page title

## Use H2 for major headings 
This heading is a main heading for the main section content. 

### Use H3 for subheadings 
This heading is a subheading that goes deeper into one of the main section's points.

Make your content clear and concise

Overall, try to keep your sentences quite short in your docs. This makes them easier to read and understand (for everyone). You can also use images or videos to provide more details if needed.

Make sure you give the full meanings of any acronyms you are using for the first time. Also, always use simple sentences, and try not to use ambiguous words.

Here's an example of an overly complex, long sentence with difficult vocabulary:

The web3 running on the Blockchain structure which is transparent, secure, immutable, decentralized would require the processes of artificial intelligence, where it would read data, process, and store information.

This is better:

Web3 is built on the transparent, secure, unchangable, and decentralized structure of the blockchain. It uses artificial intelligence processes to read, process, and store information.

Your content should contain the main points you're trying to make, removing all forms of ambiguity.‌ ‌

Use informative link text

All your in-line links should use clear, detailed, and descriptive text. You can describe the link's purpose or the company's name if it is a brand, for example.

Links are important for improving the ranking of a page. And using links like "Click here" or "Read More" is not all that helpful, as they don't tell the reader much about what they'll find at that link.

For instance, if I wanted to link a W3C (World Wide Web Consortium) accessibility tutorial to this article, I could use the following format: Check out these resources for content writers by W3C.

Add alt text and captions to media content

Images

Adding descriptive text to the alt text attribute allows screen readers to be able to read out the alt text associated with an image. Alt text also helps search engine bots that crawl the page know how to classify that content.

When you're adding alt text, describe the purpose of the image and not what the image is. For instance, let's say you're using an image that shows some shipping containers in a section that is about containerization.‌

Various containers on a ship in motion to illustrate the packaging structure and process of a digital container.

Instead of writing alt text like "various containers on a ship in motion", you could write "various containers on a ship in motion to illustrate the packaging structure and process of a digital container."

While alt text serves as an alternative for the image, captions give more details about the image. You can use HTML to insert image captions. Markdown does not support image captions, but markdown documentation sites usually have a way around it (for example, through plugins – ReadTheDocs, MkDocs – or inserting HTML via a custom component –Docusaurus).

As an example, I'll show you how to add image captions in Docusaurus.

How to add image captions in a Docusaurus .md file:

• Create a folder components in the src folder.

• Create a file named figure.jsx.

• Add this line of code to it:

import React from "react"; 
import useBaseUrl from "@docusaurus/useBaseUrl"; 
export default function Figure({ src, caption }) {
  return ( 
  <figure> <img src={useBaseUrl(src)} alt={caption} /> 
  <figcaption>{`Figure: ${caption}`}</figcaption> </figure> 
  ); 
}

• Go to the .md file where you have the image and import the code.

import Figure from '@site/src/components/figure'; 
import figure1 from 'path-to-image';

• Add it to the file.

<Figure caption="This is a caption for the image" alt="This is alt text" src={figure1} />

The image will now display with a caption.

A screenshot example of image caption

‌Videos

To caption videos, HTML is a great option. But if you are using markdown, you can embed videos from YouTube and Vimeo using the <iframe> tag. These apps offer in-built caption support so you can enable captions before adding the embed code.

You could also install third-party plugins for this purpose.

Here's another tip: avoid flashing content in your videos as it could lead to seizure triggers. If your video has flashing bright colours, ensure that it does not exceed two times within a second.

Add transcripts to audios and videos

It's a good idea to add transcripts to your audio and video content. Not everyone will want to watch or listen to the content. But they may be curious to know what it is about.

By adding a transcript, you make it easier for anyone to navigate through the content and get the information that they need.

Transcript for audio

For audio content, you can insert transcripts using HTML. Here's an example:

<audio controls muted><!--Always set your audios to muted--> 
    <source src="ringtone.mp3" type="audio/mpeg"></source> 
</audio> 
<code> 
    <p>Here is a transcription of the text</p> 
    00:03 = I am going to be productive today<br><br> 
    00:05 = I am going to be productive today<br><br> 
    00:08 = I am going to be productive today<br><br> 
    00:10 = I need to be productive today<br><br> 
    00:11 = I have to be productive today<br><br> 
    00:13 = I should be productive today<br><br> 
    00:16 = I am going to be productive today<br><br> 
    00:18 = I ought to be productive today<br><br> 
    00:21 = I have to be productive today<br><br> 
    00:23 = Productivity matters to me <br><br> 
</code>

For markdown documentation sites like Docusaurus, you can create a custom component.‌

• In your src/components folder, create a file named transcript.jsx.

• Insert this code:

import React, { useState } from 'react'; 
export default function Transcript({ }) { 
  const [showTranscript, setShowTranscript] = useState(false); 
  const toggleTranscript = () => { 
    setShowTranscript(!showTranscript); 
  }; 
  return ( 
    <div> <a href="#" onClick={toggleTranscript}> { 
    showTranscript ? 'Hide transcript' : 'View transcript'
    } 
    </a> {showTranscript && ( <div id="transcriptText"> (insert your transcript text here) </div> )} 
    </div> 
  ); 
}

• Go to your markdown file and import it.

import Transcript from '@site/src/components/transcript'; 

<Transcript />

‌

A screenshot of the audio transcript output

‌Note: I added some tweaks to the code to make transcript display optional. You can edit it if you want the transcript to show as the page loads.

Transcript for video

Now for videos, YouTube is a great option. It provides inbuilt transcripts for your videos. So, you can always embed YouTube videos in your docs.

The transcript is in the video description after the main details. The transcript will display with the timestamps when you click the "Show Transcript" button.

Add code snippets and use the colour contrast technique

How to add code snippets

Use code blocks within the text to explain code instead of images. You could also use code snippets to showcase the output of your code. Unless it is necessary to add an image, you should use code snippets.

For instance,

index.html

<!DOCTYPE html> 
<html> 
    <head> 
        <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>A calculator app</title> 
        <link rel="stylesheet" href="styles.css"/> 
    </head> 
    <body> 
    </body> 
</html>

This will allow screen readers to read through the code, which they are not able to do with screenshots.

A screenshot of the above code

Colour contrast technique

The colour contrast technique implies using colours that are opposite or heavily contrasting.

For example, using black text on a white background has a high contrast, as opposed to using light brown text on a brown background.

When combining colours, you could use an accessible colour palette like Color Safe.‌

Using a pale white colour on a green background gotten from Color Safe

Add translation options

There are documentation sites that provide translation options where you can build your docs in multiple languages, websites like Jekyll. This is an example.

Docusaurus is also another doc site that provides multilingual options using Crowdin or Git.

• Follow through this guide to set up translation and localization on Docusaurus using Git.

• Follow through this guide to set up translation and localization on Docusaurus using Crowdin.‌

Use accessibility testing tools

There are tools you can use to check for errors in accessibility in your docs. Some examples are WAVE (Web Accessibility Evaluation Tool) and AXE (Accessibility Engine).

Also, you can get the NVDA(NonVisual Desktop Access) screen reader to test out your content. This software will let you know how the content of your documentation will be perceived by a user using a screen reader.‌

Set up an improvement or suggestion box

Finally, it may not be possible to cover the needs of every user. So you could add a suggestion or improvement box, allowing users to send feedback about how you could further improve the content. Hearing firsthand from users can help you know how best to make the docs accessible for them.

To add an improvement box, you could use an external form link that stores the users' inputs or you could set up the suggestion box in the docs.

How to add an external form link in Docusaurus

You would need to create a custom component for that.

• Go to src/components folder and create a file feedback.jsx.

• Add this code:

import React from 'react'; 

export default function FeedbackButton({ href }) {
  return ( <a href={href} target="_blank" rel="noopener noreferrer" > Give Feedback </a> ); 
};

• In your markdown file import it:

import FeedbackButton from '@site/src/components/feedbackbutton';

• Insert the link

<FeedbackButton href="https://forms.google.com" />

When you run it on your docs, it should showcase a link to Google forms. Google Forms is an example, you could add the link to your company website or server. Here's what it'll look like:

A feedback link for suggestion in a docs site

Summary

To follow and implement these accessibility best practices, you can consider creating or using an already made style guide. This can help you consistently implement these practices and make it easier for you and other technical writers on your team.

There are style guides focused on accessibility for technical writers, such as the following:

1. Accessibility style guide by Heyawhite

2. Write accessible documentation by Google for developers

3. Writing for Accessibility by MailChimp content style guide

That sums up my tips about web accessibility practices in writing. I'm a technical writer, and you can reach out to me on Instagram or hire me via Upwork. Thank you for reading.‌

Imagine writing a program that needs to react instantly to changes—whether that's user inputs, messages from other systems, or live data feeds. That's where reactive programming shines, making it a cornerstone of modern software development, especially for web and mobile applications.

Let's draw a simple parallel to everyday life to bring this concept closer to home. Consider a bus station, a familiar sight where people queue up, waiting for their ride. Each bus arrival is an event, and the passengers' response—to board the bus—is an action triggered by this event.

Reactive programming works similarly. It deals with data streams (like the schedule of arriving buses) and the propagation of change (a new bus arriving), enabling applications to respond in real-time (just as passengers react by boarding the bus). Sound familiar?

In this article, we'll dive into the essence of reactive programming, focusing on its implementation using JavaScript/TypeScript within the Node.js environment. We'll also keep an eye on a global context that applies to many programming languages and frameworks.

We'll keep things straightforward and engaging, using simple language and practical examples. By the end of this guide, you'll have a solid foundation in reactive programming concepts and hands-on experience building a real-time notification system.

Whether you are new to the concept or looking to refine your skills, this guide is crafted to demystify reactive programming and show you its power in action. Let's get started on this exciting journey together!

What We'll Cover:

1. Understanding Streams and Observables
2. Reactive Programming in JavaScript/TypeScript and Beyond
3. How to Build a Real-Time Notification System with Node.js
   – Introduction to the Notification System
   – Project Setup: Getting Started with Node.js and TypeScript
   – How to Implement the Core Features
4. Best Practices and Common Pitfalls
5. Conclusion
6. Resources

Understanding Streams and Observables

Let's dive into the heart of reactive programming: streams and observables. These concepts are the building blocks of reactive applications, enabling them to process data dynamically and reactively. To understand their significance, let's revisit our bus station analogy.

Imagine the bus station being equipped with a digital display showing real-time updates of bus arrivals, departures, and delays. This display is constantly receiving data about buses - this flow of information is what we call a "stream." Each piece of new data (like the arrival of a bus) can be seen as an "event" in this stream.

Streams: The Flow of Data

In programming, a stream is a sequence of ongoing data made available over time. Streams can be anything: mouse movements, keystrokes, tweets, or even real-time stock market updates. They're not so different from the bus station's digital display, which receives a continuous flow of information about buses.

In short, a stream is a collection of values pushed over time, the interval between two different values can be controlled (scheduled streams) or random (we never know when someone will send us a message right?).

Streams can emit three different things: a value (of some type), an error, or a "completed" signal. Let’s think of a notification system, for example. On one end we have a client (mobile app, web app, and so on) that has subscribed to a WhatsApp group. Whenever there is a new message in that group, the application will react by sending a push notification to the user–but we never know when those messages are coming.

Figure 1 below shows an illustration of what can be considered as a stream. After some time, the value can change, notifying every client that subscribed to the stream that a new value is available. It gives clients the possibility to unsubscribe at any time they want.

Figure 1: Illustration of what is a stream, subscription, and unsubscription

As you can see from the image above, from the moment a client unsubscribes, they stop getting new values from the stream.

Observables: Reacting to Data

An observable is a type of stream that you can observe, enabling you to listen for and react to incoming data.

To illustrate, consider the digital display at a bus station as the stream. As you eagerly wait and watch for information about your bus's arrival, you are akin to an observable. When your bus's arrival is displayed (an event), you react by preparing to board it.

Observables are characterized by the following three aspects:

1. Data Lifecycle: An observable is a primitive type that can contain zero or multiple values. These values are pushed over any duration, determining the lifecycle of the stream.
2. Cancellable: Observables can be cancelled at any time. By informing the producer that you no longer require updates, you can cancel a subscription to an observable.
3. Lazy Evaluation: Observables are lazy, meaning that they do not perform any actions until you subscribe to them. Similarly, they cease operations when unsubscribed. This stands in contrast to Promises, which are eager and must be settled each time they are invoked before further processing occurs.

Why Streams and Observables are Important

Streams and observables are crucial in reactive programming because they allow applications to handle data that changes over time—just like the constantly updating information on the bus station display.

They make it possible for apps to react instantly to new data, from a user clicking a button to receiving messages from a web service.

Operators

Streams alone are useful, as they allow multiple Observers to subscribe to it for their updates. Things start to get more enjoyable when you want to manipulate a stream. Streams can be transformed and even combined, using operators.

RxJS itself for example contain hundreds of operators inspired by some well-known JavaScript's arrays’ methods like map, filter, reduce, etc.

Operators are simply functions that take an observable and return an observable with some operation applied to it.

Let's look at two essential operations: mapping and filtering. Take a look at the following animation:

Figure 2: operators on an observable - source

In Figure 2 above, for the map operator, when the input observable emits a value, it is being processed by the isEven function and the resulting value is emitted as a value for the output observable.

For the filter operator, when the input stream emits a value, it is given to the same function, which emits a value for the output observable when it fulfills the condition. Otherwise, it is ignored. The input is an observable, and the operator returns another observable.

Reactive Programming in JavaScript/TypeScript and Beyond

In the world of JavaScript and TypeScript, particularly in the Node.js environment, streams and observables are crafted with both grace and effectiveness.

Node.js offers built-in support for streams, enabling powerful data handling capabilities for server-side applications. Also, libraries and frameworks built on top of the reactive programming paradigm, such as RxJS for JavaScript/TypeScript, provide developers with powerful tools to create reactive applications.

RxJS, for instance, is a library specifically designed for reactive programming in JavaScript/TypeScript. It provides a vast collection of operators to create, combine, and manipulate observables. With RxJS, developers can handle complex data flow scenarios with ease, thanks to its intuitive API and extensive operator set.

But reactive programming is not limited to JavaScript/TypeScript and Node.js. Many other programming languages have their own implementations of reactive programming paradigms and libraries.

For example, languages like Java have RxJava, Kotlin has RxKotlin, and Swift has RxSwift. These libraries offer similar functionalities to RxJS but are tailored to their respective language ecosystems.

Regardless of the programming language you're using, the principles of reactive programming remain applicable. Whether you're working in JavaScript, Java, Kotlin, Swift, or any other language, you can leverage reactive programming to build responsive, scalable, and maintainable applications.

The concepts of streams, observables, and operators transcend language barriers, providing developers with a powerful toolkit for handling asynchronous data flows and creating dynamic user experiences.

Putting It All Together

Imagine we're developing a feature for our bus station app that notifies users when their bus is approaching. Using RxJS, we can create an observable that represents the stream of bus arrival data. Each time a bus's status is updated—say, when it's 10 minutes away—the observable emits an event. Our app can subscribe to these events (observe them) and react by sending a notification to the user: "Your bus is on its way!"

This scenario showcases the power of reactive programming with streams and observables. Not only does it allow for real-time responsiveness, but it also simplifies the handling of asynchronous data flows, making our code cleaner and more intuitive.

This fundamental understanding of streams and observables is your first step into the world of reactive programming. As we move forward, remember the bus station's digital display and how it continuously updates. Our applications, much like an attentive traveler, has to be ready to respond to these updates as efficiently as possible.

With RxJS and the concepts of streams and observables, we're equipped to tackle these challenges head-on, creating applications that not only meet but exceed user expectations in terms of responsiveness and performance.

Engaging with these concepts is not just about understanding theory – it's about seeing the immense potential they unlock for developing dynamic, user-centric applications. As we dive deeper into practical examples, keep the bus station analogy in mind—it will help you grasp the more complex aspects of reactive programming in a relatable and straightforward way.

How to Build a Real-Time Notification System with Node.js

In this section, we'll embark on a journey to create a real-time notification system using Node.js. Imagine a scenario where users of a web application need to receive instant updates on various events, such as new messages, notifications, or system alerts.

Our goal is to build a robust and efficient system that delivers these notifications seamlessly in real-time.

Introduction to the Notification System

Before diving into the technical implementation, let's envision how our real-time notification system will function. Users will interact with the system through a web interface, where they'll be able to subscribe to different types of notifications based on their preferences.

These notifications could include new messages in a chat room, updates on shared documents, or alerts for important system events. We will try to keep it very simple, since the goal is really getting started with the paradigm.

Key Interactions with the System

1. User Subscription: Users will have the option to subscribe to specific types of notifications, tailoring their experience to their preferences and needs.
2. Real-Time Delivery: Once subscribed, users will receive notifications instantly as they occur, ensuring timely communication and responsiveness.
3. Actionable Notifications: Notifications will be actionable, allowing users to interact with them directly from the interface. For example, clicking on a notification might open the corresponding chat room or document.

With this vision in mind, let's proceed to set up our Node.js project and lay the foundation for our real-time notification system. We'll start by configuring the project environment and installing the necessary dependencies, including RxJS, to power our reactive programming implementation.

Project Setup: Getting Started with Node.js and TypeScript

Before we can dive into implementing our real-time notification system, we need to set up our Node.js project environment. This involves configuring TypeScript for enhanced type checking and enabling RxJS to harness the power of reactive programming.

Let's walk through the steps to get our project up and running:

Step #1 – Initialize a New Node.js Project

Start by creating a new directory for your project and navigate into it:

$ mkdir real-time-notification-system
$ cd real-time-notification-system

Next, initialize a new Node.js project using npm or yarn:

$ npm init -y

or

$ yarn init -y

Step #2 – Install Dependencies

Now, let's install the necessary dependencies for our project. We'll need TypeScript for type checking and compilation, as well as RxJS for reactive programming:

$ npm install typescript rxjs

or

$ yarn add typescript rxjs

Step #3 – Configure TypeScript

Create a tsconfig.json file in the root of your project to configure TypeScript:

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "CommonJS",
    "outDir": "./dist",
    "strict": true},
  "include": ["src/**/*"]
}

This configuration sets the compilation target to ESNext, enables strict type checking, and specifies the output directory for compiled TypeScript files.

Step #4 – Set Up Project Structure

Create a src directory to store your TypeScript source files:

$ mkdir src

Your project structure should now look like this:

real-time-notification-system/
├── src/
├── node_modules/
├── package.json
└── tsconfig.json

Now, create a sample TypeScript file in the src directory to verify that TypeScript is working correctly:

// src/index.ts
const message: string = 'Hello, world!';
console.log(message);

To run the file, you can either use Node, or any other JS runtime like Bun, using the following command:

# make sure bun is installed with bun -v command
# then run
$ bun run src/index.ts

Make sure you get the “Hello, world” in the console before you proceed to the next step

Step #5 – Compile TypeScript

Compile your TypeScript code by running:

# then compile the project 
$ npx tsc

This will generate JavaScript files in the dist directory according to the configuration specified in tsconfig.json.

With our project set up and TypeScript configured, we're ready to start implementing the core features of our real-time notification system.

Let's move on to creating observables, applying operators, and handling real-time notifications in our application.

How to Implement the Core Features: Building a Real-Time Notification System

Now, let's dive into implementing the core features of our real-time notification system. We'll create observables to represent different types of events, apply operators to filter and transform these event streams, and finally subscribe to these observables to handle real-time notifications effectively.

How to Create Observables – Modeling Event Streams

In our notification system, we'll have various event streams representing different types of notifications. These could include new messages, user mentions, system alerts, and more.

Remember, everything can be observable, as this is very important when building reactive programs. Using RxJS (https://rxjs.dev/guide/overview), you can manipulate any kind of stream in an observable way.

Before we get started, let’s see what I mean by that.

Given a button listening to a click event, JavaScript you can capture the event like this:

<button id='btn'>Click Me</button>

// in js file
const btn = document.getElementById("btn");
btn.addEventListener("click", (event) => {
  console.log('Button clicked');
});

While this works perfectly fine, it’s not reactive. What if you want to combine the click event with another event, such as a timer or an HTTP request? This is where reactive programming comes in.

With reactive programming, you can treat all of these events as streams of data and combine them in a declarative and composable way.

Imagine a scenario where we need to print a message when two click events that happen in within a 5 seconds interval, or print a message with an array of positions the mouse occupied on the browser between two click events. Or to print a message when the user clicks on the button and the enter keyword within a 2 seconds interval.

All these scenarios are possible with usual imperative programming but may require more tricky code, and thinking reactively may become a must.

Let's try to build the first scenario in a usual way, then we 'll see how reactive programming can help us to make it more readable and maintainable.

const btn = document.getElementById("btn");

let clickCount = 0;
let lastClickTime = 0;

btn.addEventListener("click", (event) => {
  clickCount++;
  if (clickCount === 1) {
    lastClickTime = new Date().getTime();
  } else if (clickCount === 2) {
    if (new Date().getTime() - lastClickTime < 5000) {
      console.log('Two clicks in less than 5 seconds');
    }
    clickCount = 0;
  }
});

Now let's see how we can achieve the same result using a reactive programming approach with rxjs in the following code snippet:

import { fromEvent } from 'rxjs';
import { buffer, debounceTime, filter } from 'rxjs/operators';

const btn = document.getElementById("btn");
const btnClick$ = fromEvent(btn, 'click');
btnClick$.pipe(
  buffer(btnClick$.pipe(debounceTime(5000))),
  filter(clickArray => clickArray.length === 2)
).subscribe(() => {
  console.log('Two clicks in less than 5 seconds');
});

In the code above, we used the fromEvent function from rxjs (https://rxjs.dev/api/index/function/fromEventPattern) to create an observable from the click event on the button. We then used the buffer and debounceTime operators to buffer the click events and filter out the ones that occurred within 5 seconds.

This allowed us to easily handle the scenario of two clicks occurring within 5 seconds, all in a declarative and composable way. The $ symbol is a common notation to identify a stream, while fully optional, you may need to use it when working on a collaborative project, since it’s very common to see it.

As you can see, the reactive programming approach is much more declarative and composable, maybe not intuitive when using it the first time, but making it easier to understand and maintain. This is a very basic example, but it shows the power of reactive programming when dealing with complex event combinations.

Reactive programming allows you to treat all events as streams of data and manipulate them in a declarative and composable way, making it easier to handle complex scenarios and maintainable code.

⚒️ Hands on exercise: To get more familiar, try to build the second scenario using both ways and see how you can do some complex event management using very few lines of code

Now that you have an idea of how you can turn almost anything to an observable, let’s get our hands dirty and code our sample notification system. This will be a very basic example, the goal is to show how you can benefit from reactive programming when dealing with a complex combination of events or a stream of intensive data in your future applications.

Let's start by creating observables to represent these event streams:

// src/observables.ts
import { Observable } from 'rxjs';

// Observable for new messages
export const newMessage$ = new Observable<string>((subscriber) => {
  // Simulate receiving new messages
  setInterval(() => {
    subscriber.next('New message received');
  }, 3000);
});

// Observable for user mentions
export const userMentions$ = new Observable<string>((subscriber) => {
  // Simulate user mentions
  setInterval(() => {
    subscriber.next('You were mentioned in a message');
  }, 5000);
});

// Observable for system alerts
export const systemAlerts$ = new Observable<string>((subscriber) => {
  // Simulate system alerts
  setInterval(() => {
    subscriber.next('System alert: Server down');
  }, 10000);
});

In the code above, we have created three observables using the Observable class from rxjs (https://rxjs.dev/guide/observable): newMessage$, userMentions$, and systemAlerts$.

Each of these observables emit a new value at different intervals. The newMessage$ observable emits a new message every 3 seconds, the userMentions$ observable emits a new message every 5 seconds, and the systemAlerts$ observable emits a new message every 10 seconds. Now that we have our observables set up, we can subscribe to them and handle the emitted values in our application.

How to Apply Operators – Transforming Event Streams

Next, let's apply operators to filter and transform our event streams to generate actionable notifications. We'll use operators like filter, map, and merge to process incoming data streams and generate meaningful notifications:

// src/operators.ts
import { newMessage$, userMentions$, systemAlerts$ } from './observables';
import { merge, map, filter } from 'rxjs';

// Combine multiple event streams into one
export const combinedNotifications$ = merge(
  newMessage$.pipe(map(message => `New message: ${message}`)),
  userMentions$.pipe(map(mention => `You were mentioned: ${mention}`)),
  systemAlerts$.pipe(map(alert => `System alert: ${alert}`))
);

// Filter notifications based on user preferences
export const filteredNotifications$ = combinedNotifications$.pipe(
  filter(notification => notification.startsWith('New message'))
);

In the code above, we have created three observables: newMessage$, userMentions$, and systemAlerts$. Each of these observables emit a new value at different intervals. The newMessage$ observable emits a new message every 3 seconds, the userMentions$ observable emits a new message every 5 seconds, and the systemAlerts$ observable emits a new message every 10 seconds.

How to Handle Real-Time Notifications – Subscribing to Observables

Finally, let's subscribe to our observables to handle real-time notifications in our application. We'll subscribe to the combined notifications stream and display notifications to the user in a simulated client interface:

// src/index.ts
import { combinedNotifications$, filteredNotifications$ } from './operators';

// Subscribe to combined notifications and display them in the UI
combinedNotifications$.subscribe(notification => {
  // Simulate displaying notifications in the UI
  console.log('Displaying notification:', notification);
});

// Subscribe to filtered notifications based on user preferences
filteredNotifications$.subscribe(notification => {
  // Simulate displaying filtered notifications in the UI
  console.log('Displaying filtered notification:', notification);
});

In the code snippet above, we have created two observables: combinedNotifications$ and filteredNotifications$. The first one combines multiple event streams into one using the merge operator. The second one filters notifications based on user preferences using the filter operator. We then subscribe to these observables and display the notifications in the UI.

Let’s test things out again using bun:

$ bun run src/index.ts

You should have the following output:

Figure 3: terminal output when running the project

As you can see, the notifications are being displayed in the UI as expected, and they keep coming in as new events are emitted, untill the program is stopped.

Another way to stop getting notifications is to unsubscribe from the observables, adding a condition that will execute the following block:

combinedNotifications$.unsubscribe();

⚒️ Over to you:
Feel free to interact with the code and explore how observables and operators work together to handle real-time notifications effectively. Experiment with different event streams and filters to tailor the notifications to your preferences, making sure you get to use as more RxJS operators as possible. As you code along, consider real-world use cases and how this notification system can be applied to various applications.

You can find the full source code for this article at the following GitHub repo: https://github.com/pacyL2K19/rx-programming-real-time-sample. Kindly leave a star if you find it helpful.

Best Practices and Common Pitfalls

Reactive programming is a powerful paradigm, but it comes with its own set of best practices and potential pitfalls.

Let's explore some key considerations when working with reactive programming in real-world applications:

Best Practices:

Here are are some of the best practices you need to follow when building application in a reactive way:

• Declarative and Composable: Leverage the declarative and composable nature of reactive programming to handle complex event streams and data flows. Use operators to transform and combine observables in a clear and maintainable way.
• Error Handling: Implement robust error handling mechanisms to manage exceptions or failures in your event streams. Use operators like catchError (https://rxjs.dev/api/operators/catchError) or retryWhen (https://rxjs.dev/api/index/function/retryWhen) to handle errors gracefully.
• Memory Management: Be mindful of memory management when working with observables. Unsubscribe from observables when they are no longer needed to avoid memory leaks and unnecessary resource consumption.
• Testing: Write comprehensive unit tests for your observables and operators to ensure they behave as expected. Use testing libraries like Jest or Mocha to test your reactive code.

Common Pitfalls:

• Overusing Operators: Avoid overusing operators, especially in complex event streams. While managing complex data/event streams can lead to using more than one operator, an overuse of operators can lead to code that is difficult to understand and maintain, always seek for an optimal use of operators.
• Complexity: Be cautious of overly complex event streams and data flows. Strive to keep your reactive codebase simple and intuitive to avoid confusion and bugs.
• Performance: Keep an eye on performance when working with reactive programming. Intensive data processing and complex event combinations can impact performance if not managed carefully, especially knowing when to subscribe and when to unsubscribe from observables, making sure the resources are used optimally.

By following best practices and being aware of common pitfalls, you can harness the full potential of reactive programming while ensuring the maintainability and performance of your applications.

Conclusion

Reactive programming is a transformative paradigm that empowers developers to build responsive, scalable, and efficient applications. By leveraging the principles of streams, observables, and operators, developers can handle complex data flows and asynchronous operations with ease.

Whether you're building real-time dashboards, IoT applications, or financial trading platforms, reactive programming provides a versatile and powerful toolkit for handling dynamic data streams. As you continue your journey with reactive programming, remember the core concepts of streams and observables.

Embrace the declarative and composable nature of reactive programming, and explore the vast array of operators available to transform and combine observables. By doing so, you'll unlock the full potential of reactive programming and create applications that meet the demands of modern software development.

Resources

• Reactive programming and its effect on performance and the development process By Gustav Hochbergs
• The introduction to Reactive Programming you've been missing By André Staltz
• The fight for performance By Arne Limburg
• Introduction to reactive programming by IBM

They can be anything from simple buttons to complex forms.

Why Use Reusable Components?

As your website grows, you can easily add new features by combining existing components. This makes your code more scalable and adaptable.

You can use your reusable code in future projects without writing it again from scratch.

🏭 How to Make Reusable React Components

Illustration credit: Shahan

Here are the two most important things to keep in mind when creating reusable React components:

1. 🩼Avoid Side Effects

Don't put logic that interacts with external data (like making API calls) directly inside a reusable component. Instead, pass this logic as props to the component.

For example, if a button does more than just looking pretty, like fetching data from the internet, it might not be reusable.

This is a reusable button component. But it lacks best practices. I will show you why in the example section.

// This is a reusable button component (bad practice!)
const Button = () => {
  return (
    <button> Click Me </button>
  );
}

2. 🗃️ Use Props

Props are arguments you pass to a component to customize its behavior and appearance. This allows you to use the same component for different purposes.

// This is a button component that can change its color
const Button = ({ color }) => {
  return (
    <button style={{ backgroundColor: color }}> Click Here </button>
  );
}

This is still a bad practice because you have a fixed label called "Click Here". If you want to change the text on your button to, let's say: "Sign Up", then you would have to go back to the button component and make that change.

That means every time you want to use a different text, we'd have to go back and edit the code. In other words, it's no longer reusable.

💪 Challenge: So what's the solution?

You already have the answer. But if you don't, I am going to show you in the example section.

🌴 Hint: Think about how you might want to use the component in different situations and design it to be flexible and adaptable.

🍃Examples of Reusable React Components

Here are some common examples of reusable React components, along with some code examples to get you started:

Buttons

Basic buttons with different styles and functionalities.

// Button component
import React from "react";

const Button = ({ color, label, onClick }) => {
  return (
    <button
      className={`padding-2 shadow-none hover:shadow background-light-${color} hover:background-dark-${color}`}
      onClick={onClick}
    >
      {label}
    </button>
  );
};

export default Button;

// Using the Button component
<Button color="blue" label="Click Here" onClick={() => console.log("Button clicked!")} />

As you can see, I did not write "Click Here" in the button component. I want to make my button reusable, and thus it doesn't know anything about custom styles or texts.

So, I passed them as props (i.e., color, label, and onClick) to change them in the future without touching the original button components. Hope that makes it clear.

🪜Solution: You need to pass each functionality as props in the reusable component.

Navbars

Navigation bars that provide consistent navigation across your website.

// Navbar component
import React from "react";

const Navbar = ({ isLoggedIn }) => {
  return (
    <div className="navbar">
      <div className="navbar-container">
        <div className="navbar-logo">
          <img src={logo} alt="logo" />
        </div>
        <div className="navbar-links">
          <a href="/">Home</a>
          <a href="/about">About</a>
          <a href="/contact">Contact</a>
          {isLoggedIn ? (
            <a href="/profile">Profile</a>
          ) : (
            <a href="/login">Login</a>
          )}
        </div>
      </div>
    </div>
  );
};

export default Navbar;

// Using the Navbar component
<Navbar isLoggedIn={true} />

As you can see, I passed <Navbar isLoggedIn={true} />

This line utilizes the Navbar component and passes the isLoggedIn prop with a value of true, indicating the user is logged in. This will display the "Profile" link and hide the "Login" link.

Similar to the button component, the Navbar component is reusable and accepts props to customize its behavior. Perfect!

Why API Calls in a Button Component is a Bad Practice

Now, you understand everything about reusable components in React.

Let's dig deeper by solving a complex problem.

Consider the scenario where you have a button that does an API call. The code for the button component can be the following:

import React from "react"; 
import doAPICall from "../api"

const SaveButton  = () => {
  return (
    <button
      onClick={() => {
        doAPICall();
      }}
    >
      Save
    </button>
  );
}

export default SaveButton

It is quite clear that you can’t reuse the above button in multiple places as this button component contains a side-effect (doAPICall()) inside it.

You can make this component reusable. First, you'll have to extract out the side-effect and pass that as a prop to the button component like this:

const App = () =>  {
  function doAPICall() {
    // Does an API call to save the current state of the app.
  }

  return (
    <div>
      <SaveButton onClick={doAPICall}/>
    </div>
  )
}

The button component should look like this:

const SaveButton  = ({
  onClick
}) => {
  return (
    <button
      onClick={onClick}
    >
      Save
    </button>
  );
}

As you can see, the above button can now be reused anywhere you want to save data with the click of a button. The button can now be used like this in multiple places:

const App = () =>  {
  function saveUser() {
    // Does an API call to save the user.
  }

  function saveProject() {
    // Does an API call to save the project.
  }

  return (
    <div>
      <SaveButton onClick={saveUser}/>
      <SaveButton onClick={saveProject}/>
    </div>
  )
}

You can also make the button component more reusable by using a prop to control the label:

const App = () =>  {
  function saveUser() {
    // Does an API call to save the user.
  }

  function saveProject() {
    // Does an API call to save the project.
  }

  return (
    <div>
      <SaveButton onClick={saveUser} label="Save user"  />
      <SaveButton onClick={saveProject} label="Save project" />
    </div>
  )
}

The button component should look like this:

const SaveButton  = ({
  onClick,
  label
}) => {
  return (
    <button
      onClick={onClick}
    >
      {label}
    </button>
  );
}

👏Conclusion

Congratulations! You've successfully learned how to build reusable React components.

Remember, reusable components are the building blocks of robust React development. By practicing reusable components, you can build cleaner, more efficient, and more maintainable React applications.

The more you practice, the better you'll become at identifying opportunities to use them in your projects!

Read More: The Future of Frontend Development

Thank you for taking the time to read this article. Until next time.. Keep learning and you can follow me on 𝕏 for latest updates on programming and productivity.

That's what we'll cover in this article. I'll discuss some important best practices so that you can manipulate the DOM with confidence.

Table of Contents

• Introduction

• Use the DOMContentLoaded Event

• Cache Selected Elements

• Query Parent Instead of Document

• Use CSS Classes to Style Elements

• Use innerHTML With Caution

• Write Readable Event Listeners

• Use Event Delegation to Handle DOM Events

• Batch DOM Updates With Fragment

• Use the stopPropagation Method

• Test your DOM Manipulation code

• Conclusion

User the DOMContentLoaded Event

The DOMContentLoaded event is fired when the HTML document is fully loaded. Using this event ensures that your DOM manipulation code runs only after the document is fully loaded.

To use the DOMContentLoaded, add an event listener to the document and listen for the DOMContentLoaded event. This helps prevent any issues that may come up when you try to manipulate elements that are yet to be rendered.

Example:

document.addEventListener('DOMContentLoaded', function() {
  // Your DOM manipulation code goes here...
})

Cache Selected Elements

When you have frequently used elements, querying the DOM for the same element anytime over and over is inefficient. It's better to query the DOM once and store the result in variables.

const cachedElement = document.getElementById('exampleId')

This way you can reference the variables anytime you want to use them. This helps improve performance as it reduces unnecessary work.

Query Parent Elements Instead of Document

When you cache an element, you can also query it to select any of its descendants. This can help improve performance because it limits the scope of the query and reduces the number of times the entire document is queried.

Example:

<div id="parent">
    <p id="child">Example paragraph</p>
</div>

const parentElement = document.getElementById('parent')

// Options 1: Querying entire document ❌
const childFromDocument = document.getElementById('child') 

// Options 2: Query the parent element ✅
const childFromParent = parentElement.querySelector('#child')

In the example above is a simple markup containing a #parent div and .child paragraph. Then there are two options for selecting the child element.

Technically, both options are correct and will select the same element. But the difference is in the scope of the query.

Example 1 queries (or searches) the entire document to find and select the child. This is less performant and not even necessary because the parent of the element you intend to select is already cached.

Example 2 narrows the scope of the query (or search) by querying only the parent element and not the whole document. That's why it's preferred because it's more performant – especially when the document is large.

Also, note that the method used for querying the parent is querySelector. Using getElementById to query the parent won't work and will result in an error.

Use CSS Classes to Style Elements

It's best to use CSS classes to style elements instead of using inline styles. Classes are easy to maintain compared to inline styles which can be hard to manage.

The classList property has useful properties like add, remove, toggle, and others that makes it easy to modify styles.

Example:

.styledClass {
  color: red;
}

element.classList.add('styledClass')

This example uses the .add property of classList to add the styledClass to the element. Assuming you wanted to remove the class from the element, you can easily do so using the .remove property in place of add.

Use innerHTML with Caution

The innerHTML property reads and parses HTML markup that you pass to it. This means it can read and run code in a script tag passed to it. And this can pose a security risk to your application.

Where possible, use the innerText or textContent property to render strings. But if you need to use innerHTML, be sure you're using it to insert content from trusted sources. Or sanitize and validate the provided content with a library like DOMPurify.

You can read this freeCodeCamp article to learn more about innerHTML.

Write Readable Event Listeners

Often you will pass two arguments to event listeners. The first is the event you're listening to and the second is the event handler (the function that fires when the event occurs).

To make your code easy to read and maintain, you can define the event handler function outside of the event listener. Then you can call it within the even listener, like in example 1 below:

Example 1 ✅

MyElement.addEventListener('click', handleClick) 

function handleClick() { 
    // your logic goes here.. 
} 

// Example 2 ❌ 

myElement.addEventListener('click', function() { 
    // your logic goes here... 
})

Both are technically correct and will do the same thing. But example 1 is preferred because it's easier to read. Also, you can reuse the handleClick function if you need to. This helps you observe the DRY (Don't Repeat Yourself) principle.

Use Event Delegation to Handle DOM Events

Event delegation is when you attach an event listener on a parent element to listen to events on its descendants. With this technique, you can reduce the number of event listeners to include in your code.

For example, assume you have five buttons inside a parent div:

<div id="parent"> 
    <button id="btn-1">1st Button</button> 
    <button id="btn-2">2nd Button</button> 
    <button id="btn-3">3rd Button</button> 
    <button id="btn-4">4th Button</button> 
    <button id="btn-5">5th Button</button> 
</div>

You can add an event listener to each of the five buttons to listen to a click. Or using event delegation, you can a single event on only the parent div:

const parentElement = document.getElementById('parent') 

parentElement.addEventListener('click', handleClick) 

function handleClick(event) { 
  alert(event.target.id) 
}

In this example, the event to delegated to the parent element. And we're using event.target.id to get the actual button the user clicked. If you are curious, you can run the code on Stackblitz to see how it works.

Event delegation help saves time improve performance. Imagine how this technique can come in handy when dealing with a large amount of dynamic content.

Batch DOM Updates With Fragment

Frequent updates to the DOM can affect the performance of your application. Try to reduce the number of updates where possible.

A useful feature you can use to batch updates is the .createDocumentFragment property. It allows you to group multiple updates before inserting them into the document. This reduces reflows and makes your code more effecient.

Example without Fragment:

const container = document.getElementById('container')

for (let i = 0; i < 1000; i++) { 
    const listItem = document.createElement('li')
    listItem.textContent = `Item ${i}`
    container.appendChild(listItem) 
}

This code updates with each iteration of the loop. That means the DOM will be update 1,000 times. There is a more efficient way of doing this with the code below that uses fragment.

Example with fragment:

const container = document.getElementById('container') 
const fragment = document.createDocumentFragment()

// Add multiple list items to the fragment 
for (let i = 0; i < 1000; i++) { 
    const listItem = document.createElement('li') 
    listItem.textContent = `Item ${i}` 
    fragment.appendChild(listItem)
} 

container.appendChild(fragment)

The code above appends the listItem to the fragment with each iteration of the loop. It only appends the child to the container element after the loop is done running. This means the DOM is updated only once instead of 1,000 times like before.

Use the stopPropagation Method

The stopPropagation method controls the flow of events in the DOM. By default, when an event occurs on an element, it bubbles (propagates) through its ancestors.

This event propagating behaviour can sometimes lead to unintended results. The stopPropagation method provides a way to stop the event from propagating to the parent and other ancestors.

Let's take a situation where you have a button inside a parent div. And you want to handle a click event on the button without registering the click on the div:

<div id="container">
    <button id="button">Click me</button>
</div>

const containerDiv = document.getElementById('container')
const buttonElement = document.getElementById('button')

containerDiv.addEventListener('click', handleDivClick)
buttonElement.addEventListener('click', handleBtnClick)

function handleDivClick() { 
    console.log('Div clicked')
} 

function handleBtnClick(event) { 
    event.stopPropagation()
    console.log('Button clicked')
}

Without using the stopPropagation method, a click event on the button will also trigger a click event on the parent div. This means both event handlers will run.

But the event.stopPropagation() line in the code will prevent the handleDivClick function from running when a user clicks the button.

You can run the code on Stackblitz to see how it works. Comment out the line with the stopPropagation method and see the difference.

Test Your DOM Manipulation Code

When you write tests, you create scenarios that mimic user interactions or application states. You also verify that your application gives you the expected outcomes.

Testing your DOM manipulation code is a best practice because it will make your code reliable and easy to maintain. It also gives you confidence that your code behaves as expected, even as it evolves over time when you make changes and add features.

You can use testing frameworks and libraries available for JavaScript, such as Jest, Mocha, Jasmine, and others to automate testing your apps.

The following example uses the Jest framework to test DOM Manipulation code for adding a class to an element.

test('Adding a highlight class changes text color to red', () => {
    myElement.classList.add('highlight');
    expect(getComputedStyle(myElement).color).toBe('red');
});

Adding the highlight class is expected to change the text color to red. If the test passes, it means your DOM manipulation code works as expected. If not, you will need to figure out what figure out what's wrong and fix the issue.

Conclusion

In this article you've learned ten best practices to keep in mind when working with the DOM. Some of them are general while others are situation specific. By using these best practices in your workflow, you will be building your web applications with a code base that is easy to maintain.

If you want to dive deep into DOM manipulation, I wrote a whole handbook that covers the subject in depth.

Thanks for reading. And happy coding! For more in-depth tutorials, feel free to subscribe to my YouTube channel

Web accessibility ensures that everyone, regardless of their abilities, can perceive, understand, navigate, and interact with the web. This inclusivity not only broadens your audience but also reflects social responsibility and compliance with legal standards.

Here's what we'll cover:

1. What is Web Accessibility?
2. Best Practices for Web Accessibility
   – Use semantic HTML
   – Use sufficient contrast
   – Make all functionality keyboard accessible
   – Provide alt text for images
   – Use ARIA roles when necessary
   – Ensure forms are accessible
   – Caption and transcribe audio and video
   – Design consistent, predictable navigation
3. Automation Tools for Accessibility Testing
4. Wrapping Up

What is Web Accessibility?

Accessibility in web design means creating web pages that can be used by people with a wide range of abilities and disabilities. This encompasses auditory, cognitive, neurological, physical, speech, and visual impairments.

Key Principles of Accessibility

The Web Content Accessibility Guidelines (WCAG) provide a framework for making web content more accessible to people with a wide range of abilities and disabilities. These guidelines are based on four key principles, often summarized as POUR, each crucial for creating a universally accessible web.

Here's a deeper look into what these principles mean in practice:

1. Perceivable: Information and user interface components must be presented in ways that all users can perceive. This means providing text alternatives for non-text content (like images), creating content that can be presented in different ways without losing information (such as using a simpler layout), and making it easier for users to see and hear content.
   Example: Providing alt text for images. Alt text allows screen reader users to understand the content and context of the images, making visual content accessible.
2. Operable: User interface components and navigation must be operable by everyone. This includes ensuring all functionalities are accessible via keyboard, giving users enough time to read and use content, and not designing content in a way that is known to cause seizures.
   Example: Implementing keyboard navigation. All interactive elements like links, buttons, and form fields should be accessible using a keyboard, making them accessible to users who cannot use a mouse.
3. Understandable: Information and operation of the user interface must be understandable. This means making text readable and understandable, and ensuring that web pages appear and operate in predictable ways.
   Example: Using consistent navigation menus. Keeping navigation menus consistent across a website helps users with cognitive disabilities learn and remember how to navigate.
4. Robust: Content must be robust enough to be reliably interpreted by a wide variety of user agents, including assistive technologies. This includes ensuring compatibility with current and future user tools.
   Example: Using clean, validated HTML. Well-structured and standard-compliant HTML ensures content can be interpreted by different browsers and assistive technologies.

By integrating these principles into web design, developers and designers can create more accessible and inclusive digital environments. Each principle plays a crucial role in ensuring that the web is a space for everyone, regardless of their abilities or disabilities.

Best Practices for Web Accessibility

Use Semantic HTML

Semantic HTML involves using HTML elements according to their intended purpose rather than just for presentation. It's about structuring your website with elements that describe their meaning and role in the document structure.

This practice is crucial for assistive technologies, like screen readers, which rely on this structure to interpret and navigate content.

How to implement semantic HTML

Consider a typical webpage layout comprising a header, main content, a navigation menu, and a footer. Instead of using non-semantic <div> tags for these sections, you should use the semantic elements <header>, <main>, <nav>, and <footer> respectively.

Here's an example:

<header>
  <!-- Site logo, header content -->
</header>
<nav>
  <!-- Navigation links -->
</nav>
<main>
  <!-- Main content -->
</main>
<footer>
  <!-- Footer content -->
</footer>

Why semantic HTML is useful:

1. Accessibility: Screen readers can easily navigate and interpret the content. For example, a user can skip directly to the main content or easily find the navigation menu.
2. SEO benefits: Search engines favor well-structured content. Semantic elements make it easier for search engine bots to understand the content of a webpage, potentially improving search rankings.
3. Maintainability: Semantic HTML leads to cleaner, more readable code, making it easier for developers to understand and maintain.

Using semantic HTML is the foundation of web accessibility, ensuring content is accessible and meaningful to all users, including those using assistive technologies.

Use Sufficient Contrast

Contrast refers to the difference in color and brightness between the text and its background. Ensuring sufficient contrast is vital for readability, especially for users with visual impairments like color blindness or low vision. High contrast between text and background makes it easier for these users to read and understand content.

How to implement good contrast

Imagine a webpage with light gray text on a white background. This combination might look aesthetically pleasing but can be hard to read for many users.

To improve contrast, you could change the text color to a much darker shade, like black or dark gray.

/* Low contrast example */
.low-contrast-text {
  color: #757575; /* Light gray */
  background-color: #fff; /* White */
}

/* Improved contrast */
.high-contrast-text {
  color: #000; /* Black */
  background-color: #fff; /* White */
}

Why contrast is useful:

1. Enhanced readability: High contrast makes the text legible to users with visual impairments and those reading under challenging lighting conditions.
2. Inclusivity: It caters to a wider audience, including users with deteriorating vision and those with temporary or situational impairments.
3. Legal compliance: Many regions have regulations requiring accessible web content, and sufficient contrast is a common requirement.

Tools like the WebAIM Contrast Checker can help you evaluate your color choices, ensuring they meet accessibility standards like WCAG. By ensuring sufficient contrast, you not only make your website more accessible but also improve the overall user experience.

Make All Functionality Keyboard Accessible

Ensuring that all functionalities on a website are accessible via keyboard is essential for users who cannot use a mouse due to physical disabilities, temporary injuries, or personal preference. This includes navigating menus, activating buttons and links, filling out forms, and using interactive widgets.

How to make content keyboard accessible

Consider a dropdown menu on a website. Typically, users hover over the menu with a mouse to view the options.

To make this keyboard-accessible, you need to ensure that users can navigate to the menu using the Tab key and expand the menu using the Enter or Space key.

<ul>
  <li tabindex="0">Menu Item 1
    <ul class="dropdown-content">
      <li tabindex="0">Sub Item 1</li>
      <li tabindex="0">Sub Item 2</li>
    </ul>
  </li>
  <li tabindex="0">Menu Item 2</li>
</ul>

document.querySelectorAll('li[tabindex="0"]').forEach(item => {
  item.addEventListener('keypress', function(e) {
    if (e.key === 'Enter' || e.key === ' ') {
      // Code to toggle dropdown
    }
  });
});

Why keyboard navigation is useful:

1. Accessibility for all: Keyboard accessibility ensures that users with motor disabilities or those who prefer keyboard navigation can use the website effectively.
2. Enhanced usability: Keyboard shortcuts can speed up navigation, offering an enhanced experience even for users who can use a mouse.
3. Compliance with accessibility standards: Adhering to standards like WCAG and ADA (Americans with Disabilities Act) often requires keyboard accessibility.

In practice, keyboard accessibility may involve more than just basic navigation. It also includes managing focus, creating keyboard shortcuts for complex actions, and ensuring custom widgets are keyboard-friendly. By prioritizing keyboard accessibility, you make your website more inclusive and user-friendly.

Provide Alt Text for Images

Alt text (alternative text) is a concise description of an image's content and function. It's crucial for visually impaired users who rely on screen readers to understand image content. Alt text ensures that even if users can't see the images on a web page, their purpose and message can still be conveyed.

How to add alt text to images

Suppose your website has an image of a company logo. The alt text should describe the logo, not just state "logo". For instance, alt="FreeCodeCamp's campfire Logo".

<img src="freecodecamp-logo.png" alt="FreeCodeCamp's campfire Logo">

For purely decorative images that don't add informational content, use an empty alt attribute (alt="") to indicate that they can be skipped by screen readers.

Why alt text is useful:

1. Accessibility Compliance: Providing alt text is a fundamental aspect of web accessibility, required under WCAG guidelines.
2. SEO Benefits: Alt text improves SEO by providing better image context/descriptions, helping search engines index an image properly.
3. Fallback Content: If an image fails to load, the alt text will be displayed, helping all users understand what was supposed to be there.

Properly implemented alt text makes your website more accessible and inclusive, ensuring that all users, regardless of their ability to see, have access to the information conveyed by images. It's a simple yet impactful practice that enhances the overall user experience.

Use ARIA (Accessible Rich Internet Applications) Roles When Necessary

ARIA roles and attributes enhance the accessibility of web content, particularly for dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies. ARIA helps make web content and web applications more accessible to people with disabilities, especially when HTML can't accomplish it alone.

How to implement ARIA roles and attributes

Consider a web application with a dynamic content update section, such as a live news feed. Standard HTML alone may not be able to convey the dynamic nature of this content to screen readers.

By using ARIA roles, you can make it clear to assistive technologies that this section of the page is a live region and its updates are important. For instance:

<div aria-live="polite" aria-atomic="true">
  <!-- Dynamic content here, like live news updates -->
</div>

In this example, aria-live="polite" indicates that updates to this region should be announced by screen readers, but not interrupt the current task, while aria-atomic="true" ensures that the entire region is read as a whole, not just the updated part.

Why ARIA is useful:

1. Enhanced screen reader experience: ARIA roles provide screen reader users with a more comprehensive understanding of what's happening on the page, particularly for dynamic and complex content.
2. Greater interactivity: ARIA can make web applications more interactive and usable for people with disabilities, facilitating operations that standard HTML can't handle.
3. Custom widget accessibility: For custom widgets that lack semantic HTML equivalents, ARIA roles can define the widget's function, making it accessible.

While ARIA is powerful, it's important to use it only when necessary. Native HTML elements should be the first choice as they inherently carry semantic meaning and accessibility features. ARIA should be used as a supplement to enhance accessibility when HTML's semantics don't suffice.

Ensure Forms are Accessible

Accessible forms are vital for users with disabilities to interact with a site, input data, and utilize services. Ensuring that form elements are accessible means they can be easily navigated, understood, and filled out by everyone, including those using screen readers or keyboard navigation.

How to make forms accessible

Imagine a simple contact form with fields for name, email, and a message. For each form element, use a <label> tag to provide a clear description. Ensure that each <label> is associated with its respective form control using the for attribute, which matches the id of the input element. This is crucial for screen reader users to understand what each field represents.

<form>
  <label for="name">Name:</label>
  <input type="text" id="name" name="name">

  <label for="email">Email:</label>
  <input type="email" id="email" name="email">

  <label for="message">Message:</label>
  <textarea id="message" name="message"></textarea>

  <button type="submit">Submit</button>
</form>

Why accessible forms are useful:

1. Clarity and context: Labels provide context to users, especially those using screen readers, about what type of information is expected in each field.
2. Error handling: Accessible forms should also handle errors clearly, informing users about what went wrong and how to fix it. This can include real-time validation feedback and error messages that are announced by screen readers.
3. Keyboard navigation: All form controls should be navigable using the keyboard, allowing users who can't use a mouse to interact fully with the form.

Accessible forms not only comply with accessibility standards but also enhance the overall user experience, making your website more inclusive and user-friendly.

Caption and Transcribe Audio and Video

Providing captions for video content and transcriptions for audio is crucial for accessibility. Captions and transcriptions ensure that deaf or hard-of-hearing users, as well as those who prefer reading to listening, can access audio and video content.

How to make audio and video content accessible

For a video on your website, include closed captioning that accurately reflects the spoken content and other auditory cues. You can use HTML5's <track> element to specify caption files. Similarly, for audio content like podcasts or interviews, provide a text transcription.

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track src="captions_en.vtt" kind="captions" srclang="en" label="English">
</video>

In this example, a WebVTT (.vtt) file is used for captions. Ensure the captions are synchronized with the audio and include descriptions of relevant non-speech audio.

Why captions and transcriptions are useful

1. Accessibility for hearing impaired: Captions and transcriptions are essential for users who are deaf or hard of hearing, enabling them to access content that would otherwise be inaccessible.
2. Enhanced comprehension: They also benefit users who are not fluent in the language of the video or have difficulty understanding the speech.
3. Flexible viewing: Captions allow content to be consumed in sound-sensitive environments, like workplaces or libraries.

Remember to regularly check the accuracy and readability of your captions and transcriptions. Well-implemented captions and transcriptions not only make your audio and video content accessible but also enhance the overall engagement and reach of your content.

Design Consistent, Predictable Navigation

Designing a website with consistent and predictable navigation is key to accessibility. It allows users, especially those with cognitive disabilities, to learn the navigation pattern quickly, enhancing their ability to find information and navigate your site effectively.

How to design effective navigation

Consider a website with a top navigation menu. The menu items should be in a logical order and remain consistent across all pages. Avoid changing the order of menu items or their location on different pages.

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About Us</a></li>
    <li><a href="/services">Services</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

In this example, the navigation structure is simple and straightforward. It's important to maintain this structure and order consistently throughout the website.

Why good navigation is useful:

1. Ease of use: A consistent navigation structure helps users understand and remember how to interact with your website, reducing confusion and frustration.
2. Improved orientation: Users can better orient themselves and understand their current location within the website.
3. Support for assistive technologies: Consistent navigation is easier for screen readers and other assistive technologies to interpret, providing a smoother browsing experience for users relying on these tools.

By ensuring that your website's navigation is consistent and predictable, you enhance the usability for all users, making your website more accessible and user-friendly.

Automation Tools for Accessibility Testing

Incorporating automation tools into the accessibility testing process can significantly enhance efficiency and coverage. These tools can swiftly identify areas of non-compliance, allowing for prompt rectifications.

Below are some key tools with link to their websites if you want to explore more:

1. Axe Accessibility Checker

Axe is a versatile browser extension and testing tool available for Chrome, Firefox, and Edge. It provides reliable and detailed issue reporting, making it ideal for quick checks and in-depth analysis.

2. WAVE (Web Accessibility Evaluation Tool)

WAVE, offered as a browser extension, visually represents potential accessibility problems on web pages, helping to pinpoint issues with color contrast, alt text, and ARIA roles.

3. Google Lighthouse

Integrated into Google Chrome's Developer Tools, Lighthouse features an accessibility audit tool that highlights issues and provides actionable recommendations.

4. Tenon.io

Tenon.io is a comprehensive web-based tool for detailed accessibility testing. It can be integrated into development workflows for automated testing during the build process.

5. JAWS Inspect

JAWS Inspect translates screen reader outputs into a visual format, aiding in the testing of screen reader compatibility and navigability.

6. Color Contrast Analyzer

This tool assists in evaluating the contrast between text and its background, ensuring readability for users with visual impairments.

7. Accessibility Insights

Developed by Microsoft, Accessibility Insights offers a suite of tools, including a web tool for Chrome and Edge, to guide manual testing alongside automated checks.

8. Pa11y

Pa11y is a command-line tool that runs automated accessibility tests on web pages, customizable for integration into development processes.

By leveraging these tools, developers and designers can ensure their websites meet accessibility standards, providing an inclusive experience for all users. Regular use, combined with manual testing and user feedback, creates a comprehensive approach to maintaining and enhancing web accessibility.

Embrace Accessibility as a Cornerstone of Web Development

In conclusion, the integration of web accessibility best practices is not just a matter of compliance but a commitment to inclusivity and universal design. The digital world is for everyone, and ensuring that web content is accessible to all, including those with disabilities, is a fundamental responsibility of web developers and designers.

Utilizing tools like Axe, WAVE, Google Lighthouse, and others, combined with manual testing and adherence to guidelines like WCAG, can significantly improve the accessibility of web content. By doing so, we open up our digital spaces to a wider audience, enhance user experience, and foster an environment of inclusivity.

Accessible web design benefits everyone, not just those with disabilities. It leads to cleaner code, better SEO, and a more flexible and resilient website. As the web continues to evolve, prioritizing accessibility will be crucial in creating a more connected and inclusive world. Remember, when we design for accessibility, we improve the web for everyone.

In this article, I will explain the significance of commenting your code, best practices to follow, and examples showcasing effective commenting in JavaScript.

Why Comments are Important in JavaScript

They enhance code readability:

Comments provide clarity to code, making it easier for developers to understand the code's purpose and functionality. Comments act as a guide, especially when you need to revisit older code after a period of time.

Consider this un-commented code:

function calculateTotal(price, quantity) {
    return price * quantity;
}

let totalPrice = calculateTotal(25, 5);
console.log(totalPrice); // Output: 125

It is quite difficult for us to understand what the code does, right? Now, let's add comments for clarity:

// Calculates the total cost by multiplying the price per item with the quantity
function calculateTotal(price, quantity) {
    return price * quantity;
}

// Example usage: Calculates the total price for 5 items at $25 each by multiplying the price per item ($25) with the quantity (5), and stores the result in the totalPrice variable.
let totalPrice = calculateTotal(25, 5);
console.log(totalPrice); // Output: 125

With comments, it is quite understandable what each part of the code does, and it also enhances its readability.

They facilitate collaboration:

In a team environment, comments aid collaboration by allowing developers to comprehend each other's code, making it easier to work together on projects.

Imagine working in a team where different developers handle various parts of a project. Clear comments aid in understanding each other's code. Here's an example:

// Validates the format of the provided email address using a regular expression, which checks for the presence of "@" symbol, domain name, and top-level domain (TLD) in the email
function validateEmail(email) {
    // Regular expression pattern to match the standard email format
    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    return emailRegex.test(email);
}

In a collaborative setting, another developer can quickly comprehend the purpose of the validateEmail function due to the comment, enabling smoother teamwork. This would've been very difficult without the comments indicating what the code block does.

They make maintenance and debugging easier:

Well-commented code simplifies maintenance and debugging. Comments can highlight potential issues, outline the reasoning behind specific solutions, and aid in locating bugs.

Comments assist in debugging and maintaining code. Consider the following commented code:

// Finds the maximum number between num1 and num2 using a ternary operator for comparison and returns the larger number
function findMax(num1, num2) {
    /* Using ternary operator to compare num1 and num2
       and return the larger number */
    return (num1 > num2) ? num1 : num2;
}

If a bug arises or modifications are needed, the comment clarifies the logic used, aiding in swift debugging or updates.

Best Practices for Commenting in JavaScript

Use descriptive comments:

Explain the purpose of functions, variables, or complex logic using descriptive comments. This helps other developers, including your future self, understand the code's intention.

// Calculates the area of a circle using the provided radius by multiplying the square of the radius by the mathematical constant π (pi)
function calculateCircleArea(radius) {
    return Math.PI * radius * radius;
}

Descriptive comments like this explain the purpose of functions or operations, aiding in understanding the code's intention.

Avoid over-commenting:

While comments are beneficial, excessive commenting can clutter the code. Aim for a balance where comments add value without stating the obvious.

// Variable to store user data
let userData = fetchUserData(); // Fetch user data from the server

In this case, the comment merely reiterates what the code already expresses clearly. Avoiding over-commenting maintains code clarity.

Update comments regularly:

As code evolves, ensure comments remain accurate and aligned with the code changes. Outdated comments can lead to confusion.

// Function to calculate the area of a rectangle
function calculateRectangleArea(length, width) {
    return length * width;
    // Updated comment: Area calculated by multiplying length and width
}

Ensuring that comments align with the current functionality or logic of the code is vital for accurate documentation.

Comment complex sections:

When dealing with intricate algorithms or unconventional solutions, detailed comments explaining the logic can be immensely helpful.

// Performs a complex calculation on the provided data, involving multiple steps including data preprocessing, calculation based on preprocessed data, and returning the final result
function performComplexCalculation(data) {
    /* 
        Complex logic involving multiple steps:
        - Step 1: Data preprocessing
        - Step 2: Calculation based on preprocessed data
        - Step 3: Final result
    */
    // ... complex calculation logic
}

For intricate algorithms or multi-step processes, detailed comments explaining each step can immensely aid in understanding.

Types of Comments in JavaScript

Single-line comments:

In JavaScript, single-line comments start with //. They're suitable for brief explanations or annotating specific lines. Keep in mind that the two forward slashes don't have any spaces between them.

Example:

// This function calculates the square of a number
function square(number) {
    return number * number;
}

Multi-line comments:

Multi-line comments begin with /* and end with /. They are useful for commenting out blocks of code or providing longer explanations. Keep in mind that the forward slash and the asterisk (*) don't have any spaces between them.

Example:

/*
    This block of code finds the maximum of two numbers
    and returns the larger number.
*/
function findMax(num1, num2) {
    // Logic to find the maximum
    return (num1 > num2) ? num1 : num2;
}

JSDoc comments:

JSDoc is a convention for adding comments to JavaScript code that enables the automatic generation of documentation. It uses a specific syntax to describe functions, parameters, return values, and so on.

Example:

/**
 * Calculates the area of a rectangle
 * @param {number} length - The length of the rectangle
 * @param {number} width - The width of the rectangle
 * @returns {number} - The area of the rectangle
 */
function calculateArea(length, width) {
    return length * width;
}

Practice Commenting Your Code 📝✍️

Learning without practicing is an incomplete process. So here's a learning challenge from the freeCodeCamp Certification Course where you will learn how comments work in JavaScript, and how you can use them in your code.

In this challenge, you will try to understand how single-line comments and multiline comments work.

I've included the solution next in case you can't solve the challenge yourself.

If you'd like to watch a video on this topic as well, you can find it here:

The Solution to the Challenge

Make sure that you have tried to solve this challenge on your own before checking my solution.

Alright, if you're ready...here it is:

// Fahim

/*
My
Name
Is
Fahim
*/

The first one is the single-line comment, and the second one is the multi-line comment.

Conclusion

Commenting on JavaScript code is an essential practice in software development. It improves code comprehension, aids collaboration, and facilitates maintenance and debugging.

By following best practices and using various comment types, we can create codebases that are easier to understand, maintain, and build upon.

I hope you have gained some valuable insights from the article.

If you have enjoyed the procedures step-by-step, then don't forget to let me know on Twitter/X or LinkedIn.

You can follow me on GitHub as well if you are interested in open source. Make sure to check my website (https://fahimbinamin.com/) as well!

If you like to watch programming and technology-related videos, then you can check my YouTube channel, too. You can also check my other writings on Dev.to.

All the best for your programming and development journey. 😊

You can do it! Don't give up, never! ❤️