DEV Community: Saumya Agrawal

MongoDB is Great. Mongoose Makes it Better.

Saumya Agrawal — Fri, 24 Apr 2026 19:50:00 +0000

When I first started learning backend development, the database question came up almost immediately. Everyone has an opinion. SQL people will tell you it is the only correct way to store data. NoSQL people will tell you SQL is legacy thinking. I got confused fast, and honestly I am glad to have started with MongoDB.

MongoDB is not always the right choice, but for a JavaScript developer learning backend for the first time, the mental model clicks in a way that SQL tables do not. Your data looks like objects. Your queries feel like JavaScript. You do not have to learn an entirely separate language just to get something saved and retrieved. You write code that looks like this:

const user = {
  name: "Abc",
  email: "abc@example.com",
  age: 28
}

And that is also, more or less, exactly what gets stored. There is no translation layer in your head where you have to think "okay, this object maps to these columns in this table with these foreign keys." It is just data, shaped the way you already think about data in JavaScript.

That familiarity is MongoDB's biggest advantage when you are starting out. It gets out of your way.

What is MongoDB

MongoDB is a database, but it stores data differently from databases like MySQL or PostgreSQL. Those are relational databases that store data in tables with rows and columns, like a spreadsheet. MongoDB is a document database. It stores data as documents, which are essentially JSON objects, and groups them into collections instead of tables.

So instead of a users table where every row has the same columns, you have a users collection where each document can have a slightly different shape. One user might have a phone field, another might not. One might have a nested address object, another might not. MongoDB simply save the data into the fields as it receives.

Each document automatically gets a unique _id field. MongoDB generates this as an ObjectId, unique across the entire database. _id is used to fetch specific documents.

The flexibility is real when your application is young and you are still figuring out what data you actually need. You can add a field to some documents without running a migration script. You can change your mind about the shape of your data without a painful database alteration. When you are building version one of something and requirements are shifting every week, this matters.

That said, the flexibility has a cost. Nothing stops two developers on your team from storing the same concept under different field names. Nothing stops your code from saving a string where a number was expected. MongoDB will happily store anything, and you find out something was wrong not when you save the data, but when you try to read it three weeks later and it comes back in an unexpected shape.

This problem gets solved by Mongoose.

Why you cannot just use MongoDB directly in your Node app

Technically, you can. MongoDB has an official Node.js driver that lets you connect and run queries without any extra library. But the raw driver gives you back plain JavaScript objects with no type information. Your editor cannot autocomplete field names. If you make a typo, nothing warns you. If someone saves { eMail: "..." } instead of { email: "..." }, the database accepts it without complaint.

For a small personal project, that is probably fine. For anything with more than one developer, or anything you want to maintain six months from now, you start wanting structure.

Mongoose is a library that sits between your Node.js code and MongoDB. It is often called an ODM (Object Document Mapper), which is the document database equivalent of an ORM. You define the shape of your data in code, and the library makes sure anything going to the database matches that shape. You get schemas, validation, methods on documents, hooks that run before or after operations, and a proper query API.

Setting up the connection

Before any schema work, you connect. Mongoose wraps MongoDB's connection handling so you do it once and every model you define automatically uses that connection.

// db.js
import mongoose from 'mongoose';

async function connectDB() {
  try {
    await mongoose.connect(process.env.MONGO_URI);
    console.log('Connected to MongoDB');
  } catch (err) {
    console.error('MongoDB connection failed:', err);
    process.exit(1);
  }
}

export default connectDB;

// server.js
import 'dotenv/config';
import connectDB from './db.js';

async function startServer(){
    await connectDB();
}

The connection string points to your MongoDB instance and names the database. For a local setup it looks like mongodb://localhost:27017/foodapp. For MongoDB Atlas, it comes from the dashboard and works identically. Always store it in a .env file. Hardcoding it is fine while learning but you should not commit credentials to Git.

Writing a schema

A Mongoose schema is where you tell your application what a document is supposed to look like. You create one with new mongoose.Schema({}), passing an object where each key is a field name and the value describes the expected type.

We will build a food delivery app through this post. The user schema starts simple:

// user/user.model.js
import { Schema, model } from 'mongoose';

const userSchema = new Schema({
  name:     String,
  email:    String,
  phone:    String,
  age:      Number,
  role:     String,
  isActive: Boolean,
});

export const User = model('User', userSchema);

The model() call is what turns a schema into something you can actually use. The name you pass, 'User', determines the MongoDB collection name. Mongoose lowercases and pluralizes it automatically, so documents land in a collection called users.

Using the model looks exactly like working with a class:

import { User } from './models/User.js';

async function createUser() {
  const user = new User({
    name:  'John Doe',
    email: 'john@example.com',
    phone: '9999999999',
    age:   25,
  });

  await user.save();
  console.log(user._id); // MongoDB auto-generates a unique ID
}

createUser();

This works, but the schema above does not enforce much. You can save a user with no email, an age of -500, or a role called 'supervillain'. Mongoose lets it all through because you only told it the type, not the rules. For that, you need constraints.

Adding constraints

Constraints are what make a schema actually useful. Instead of just passing a type, you pass an object with the type and whatever rules you want enforced.

const userSchema = new Schema({
  name: {
    type:      String,
    required:  [true, 'Name is required'],
    trim:      true,
    minlength: [2,  'Name must be at least 2 characters'],
    maxlength: [60, 'Name cannot exceed 60 characters'],
  },
  email: {
    type:      String,
    required:  [true, 'Email is required'],
    unique:    true,
    lowercase: true,
    trim:      true,
    match:     [/^\S+@\S+\.\S+$/, 'Please enter a valid email'],
  },
  phone: {
    type:  String,
    match: [/^[6-9]\d{9}$/, 'Enter a valid 10-digit mobile number'], // Regex for Indian phone no.
  },
  age: {
    type: Number,
    min:  [16, 'Must be at least 16 to order'],
    max:  [120, 'Please enter a valid age'],
  },
  role: {
    type:    String,
    enum:    ['customer', 'rider', 'admin'],
    default: 'customer',
  },
  isActive: {
    type:    Boolean,
    default: true,
  },
}, {
  timestamps: true,
});

The timestamps: true option automatically adds createdAt and updatedAt fields to every document and keeps updatedAt current on every save, without you having to remember to do it manually.

When validation fails, Mongoose throws a ValidationError before the document reaches MongoDB. The error includes your custom message, so you can send it directly back to the user:

try {
  const bad = new User({ name: 'A', email: 'notanemail' });
  await bad.save();
} catch (err) {
  console.log(err.errors.name.message);
  // "Name must be at least 2 characters"
  console.log(err.errors.email.message);
  // "Please enter a valid email"
}

One thing worth knowing about unique: true: it creates a database level index in MongoDB rather than running a Mongoose check. The error looks different, instead of a ValidationError you get an error with err.code === 11000.

Sometimes the built-in options are not enough. You can pass a custom validator function for any field:

deliveryPincode: {
  type: String,
  validate: {
    validator: function(v) {
      return /^\d{6}$/.test(v); 
    },
    message: (props) => `${props.value} is not a valid pincode`,
  },
},

Nested objects and references

Data in real applications is never straightforward. A user has an address. An order has multiple items. Mongoose gives you two ways to handle this: embed the related data directly inside the document, or store a reference to another document by its _id and look it up separately.

For an address, embedding makes sense. You would never want to fetch an address without the user it belongs to, and an address has no meaning outside of that context. The schema looks like a nested object:

address: {
  street:  { type: String, trim: true },
  city:    { type: String, trim: true },
  pincode: {
    type:  String,
    match: [/^\d{6}$/, 'Invalid pincode'],
  },
},

You read it by chaining dots: user.address.city.

For an order that belongs to a user, a reference makes more sense. A user exists independently and appears in many places. You store the user's _id in the order:

// models/order.model.js
const orderSchema = new Schema({
  user: {
    type: mongoose.Schema.Types.ObjectId,
    ref:  'User',
    required: true,
  },
  restaurant: {
    type: mongoose.Schema.Types.ObjectId,
    ref:  'Restaurant',
    required: true,
  },
  items: [{
    name:     { type: String, required: true },
    quantity: { type: Number, min: 1, default: 1 },
    price:    { type: Number, required: true, min: 0 },
  }],
  totalAmount: { type: Number, required: true },
  status: {
    type:    String,
    enum:    ['placed', 'confirmed', 'out_for_delivery', 'delivered', 'cancelled'],
    default: 'placed',
  },
}, { timestamps: true });

The ref: 'User' tells Mongoose which model to look up when you call .populate():

const order = await Order
  .findById(orderId)
  .populate('user', 'name email')
  .populate('restaurant', 'name address');

console.log(order.user.name); // Prints the name of the user of the particular id

Without populate(), order.user is just an ID string. With it, Mongoose runs the extra lookup and replaces the ID with the actual document. The rule for choosing is simpler than it sounds: if the data only makes sense alongside its parent and will always be read together with it, embed it. If the data exists on its own and gets used from multiple places, reference it.

Virtual fields

A virtual is a field that does not get saved to the database. It is computed from other fields whenever you read the document. For the food delivery app, a displayAddress virtual combines the separate address fields into one readable string:

userSchema.virtual('displayAddress').get(function() {
  if (!this.address?.city) return 'No address saved';
  return `${this.address.street}, ${this.address.city} - ${this.address.pincode}`;
});

const user = await User.findOne({ email: 'john@example.com' });
console.log(user.displayAddress);
// example:"Civil Lines, Delhi - 110054"

Virtuals do not appear in JSON.stringify() output by default, which means they will not show up in API responses unless you enable them. Add toJSON: { virtuals: true } to the schema options:

const userSchema = new Schema({ /* fields */ }, {
  timestamps: true,
  toJSON:   { virtuals: true },
  toObject: { virtuals: true },
});

Use regular functions, not arrow functions, for virtuals and hooks. Arrow functions do not have their own this, so this.address inside an arrow function refers to nothing useful. Mongoose passes the document as this, and a regular function is what receives it correctly.

Hooks

A hook is a function that runs automatically before or after a database operation.

The most important hook in almost every app is hashing a password before saving it. You should never store plain text passwords in a database:

import bcrypt from 'bcryptjs';

// Mongoose handles the promise through async; hence next() is not required
// if async absent, use next()
userSchema.pre('save', async function() {

  if (!this.isModified('password')) return;

  this.password = await bcrypt.hash(this.password, 12);
});
// 12 is Cost Factor; Number of iterations for hashing

The isModified('password') check is necessary. Without it, every time you update any field on a user, the hook would rehash an already hashed password. Checking isModified means the hook only runs when the password field actually changed.

Post hooks run after the operation completes:

// send welcome email to new users
userSchema.post('save', async function (doc) {
  if (doc._wasNew) {
    try {
      await sendWelcomeEmail(doc.email, doc.name);
    } catch (err) {
      console.error("Email failed to send:", err);
    }
  }
});

There is a gotcha with update operations. When you use findByIdAndUpdate(), the pre('save') hook does not fire. Mongoose treats updates differently from saves. If you want validation to run on updates too:

userSchema.pre('findOneAndUpdate', function() {
  this.setOptions({ runValidators: true });
});

Instance methods and static methods

Instance methods run on individual documents. Static methods run on the model class itself.

The most common instance method is password comparison for login:

userSchema.methods.comparePassword = async function(plainTextPassword) {
  return bcrypt.compare(plainTextPassword, this.password);
};

// in your login route:
const user = await User.findOne({ email: req.body.email }).select('+password');
const match = await user.comparePassword(req.body.password);
if (!match) return res.status(401).json({ error: 'Wrong password' });

Use .select('+password') when you mark a field with select: false in the schema, Mongoose leaves it out of all query results by default. The +password syntax opts it back in for this one query where you actually need it.

Static methods are good for reusable query logic that belongs on the model itself:

userSchema.statics.findActiveRiders = async function(city) {
  return this.find({
    role: 'rider',
    isActive: true,
    'address.city': city,
  });
};

const riders = await User.findActiveRiders('Mumbai');

Querying

Mongoose wraps MongoDB's query system in a clean API. These operations cover almost everything you will need day to day:

// all customers
const users = await User.find({ role: 'customer' });

// find one by email
const user = await User.findOne({ email: 'john@example.com' });

// find by MongoDB _id
const user = await User.findById(userId);

// update and get back the updated version
const updated = await User.findByIdAndUpdate(
  userId,
  { isActive: false },
  { new: true } // this returns the document after change
);

// delete
await User.findByIdAndDelete(userId);

// pick specific fields, sort, paginate
const page2 = await User
  .find({ role: 'customer' })
  .select('name email')
  .sort({ createdAt: -1 })
  .skip(10)
  .limit(10);

.select() is worth understanding early. Controlling which fields come back is how you avoid accidentally sending password hashes to the frontend.

Indexes

Indexes were one concept that took me a while to wrap my head around. Without indexes, MongoDB reads every document in a collection one by one to find a match. That is fine for a hundred documents. At a hundred thousand, a query that took 2ms starts taking seconds. The culprit is almost always a missing index.

An index is a separate, sorted data structure that MongoDB maintains alongside your collection. When you query a field that has an index, MongoDB looks up the value in that structure instead of scanning every document. The difference in speed can be several orders of magnitude.

You add indexes inside the schema in Mongoose. unique: true on the email field already creates one automatically. For other fields, you either add index: true on the field definition or call schema.index() directly:

// option 1: inline on the field
email: { type: String, unique: true }, // index created automatically
role:  { type: String, index: true  }, // single-field index

// option 2: schema.index() for more control
userSchema.index({ role: 1, isActive: 1 });    // compound index
userSchema.index({ 'address.city': 1 });       // index on a nested field
userSchema.index({ createdAt: -1 });           // -1 = descending order

The 1 means ascending order, -1 means descending. For most lookups the direction does not matter much, but for sorted queries it can. A compound index covers queries that filter by multiple fields together. If your app frequently fetches active riders in a specific city, an index on { role: 1, isActive: 1, 'address.city': 1 } will serve that query far faster than three separate single-field indexes.

There is a tradeoff. Indexes speed up find() but slightly slow down save(), because MongoDB has to update every index whenever a document changes. For most applications this is completely fine. The read speedup far outweighs the write cost. But indexing every field by default is not a good habit. Add indexes for fields you actually filter or sort by. Also, if you're adding an index to a live database with millions of records, do it during off-peak hours. Building an index on a massive active collection can lock the collection or spike CPU usage, leading to a temporary slowdown for your users.

A special case worth knowing is the TTL (Time To Live) index. It automatically deletes documents after a certain amount of time. This is perfect for email verification tokens, password reset links, or session records that should expire on their own:

const tokenSchema = new Schema({
  userId:    { type: mongoose.Schema.Types.ObjectId, required: true },
  token:     { type: String, required: true },
  createdAt: { type: Date, default: Date.now },
});

// MongoDB automatically deletes these documents 1 hour after createdAt
tokenSchema.index({ createdAt: 1 }, { expireAfterSeconds: 3600 });

MongoDB handles the deletion automatically without a cleanup script.

Error handling

MongoDB and Mongoose throw different types of errors, and you need to handle them differently. Bundling all errors into a single catch block and returning a 500 response is a pattern that makes debugging very frustrating.

There are three categories you will encounter regularly. The first is a ValidationError from Mongoose, which fires when a document fails schema constraint checks. The second is error code 11000 from MongoDB itself, which fires when a unique constraint is violated at the database level. The third is a CastError, which fires when you pass something to findById() that is not a valid MongoDB ObjectId format.

// a reusable error handler you can drop into any project
function handleMongooseError(err) {
  // validation failed before reaching the database
  if (err.name === 'ValidationError') {
    const messages = Object.values(err.errors).map(e => e.message);
    return { status: 400, message: messages.join(', ') };
  }

  // duplicate key: unique constraint violated
  if (err.code === 11000) {
    const field = Object.keys(err.keyValue)[0];
    return { status: 409, message: `${field} already exists` };
  }

  // invalid ObjectId format passed to findById or similar
  if (err.name === 'CastError') {
    return { status: 400, message: 'Invalid ID format' };
  }

  return { status: 500, message: 'An unexpected error occurred on the server.' };
}

If your route receives an id parameter from a URL and that parameter is not a valid ObjectId, calling User.findById(id) throws before even hitting the database. Without handling it, that becomes an unhandled exception. With it, you return a clean 400 response.

Using this in a route looks like:

app.post('/users', async (req, res) => {
  try {
    const user = await User.create(req.body);
    res.status(201).json(user);
  } catch (err) {
    const { status, message } = handleMongooseError(err);
    res.status(status).json({ error: message });
  }
});

Aggregation pipelines

Once your data is in MongoDB and you understand basic querying, you will eventually need to answer questions like: what is the total revenue per restaurant this month, how many orders has each rider completed, what is the average order value by city. Basic find() queries cannot answer these. Aggregation pipelines can.

An aggregation pipeline is a sequence of stages that transform documents. Each stage takes documents in, does something to them, and passes the result to the next stage. Think of it like an assembly line for your data.

const revenueByRestaurant = await Order.aggregate([
  // stage 1: only delivered orders from this month
  {
    $match: {
      status:    'delivered',
      createdAt: { $gte: new Date('2024-12-01') },
    }
  },
  // stage 2: group by restaurant and sum totals
  {
    $group: {
      _id:          '$restaurant',
      totalRevenue: { $sum: '$totalAmount' },
      orderCount:   { $sum: 1 },
    }
  },
  // stage 3: sort by revenue, highest first
  {
    $sort: { totalRevenue: -1 }
  },
  // stage 4: join with restaurants to get the name
  {
    $lookup: {
      from:         'restaurants',
      localField:   '_id',
      foreignField: '_id',
      as:           'restaurantInfo',
    }
  },
  // stage 5: reshape the output
  {
    $project: {
      restaurantName: { $arrayElemAt: ['$restaurantInfo.name', 0] },
      totalRevenue:   1,
      orderCount:     1,
    }
  }
]);

$match is like a find() filter. Put it as early as possible in the pipeline so you are working with fewer documents in the stages that follow. $group is how you aggregate: you specify a _id to group by and then use accumulator operators like $sum, $avg, $min, and $max to compute values. $lookup is MongoDB's join equivalent. It pulls in documents from another collection and attaches them to the current documents. $project controls which fields appear in the output, similar to .select() on a regular query.

These four stages cover the vast majority of reporting and analytics work you will do in a real application.

Transactions

By default, a MongoDB write either succeeds or fails on its own. That is fine most of the time. But sometimes you have an operation that involves multiple writes that must all succeed together or all fail together. Charging a user for an order and creating the order record is the classic example. If the charge succeeds but the order creation fails, the user paid for something that does not exist. That is a bad place to be.

Mongoose exposes them through sessions:

const session = await mongoose.startSession();

try {
  session.startTransaction();

  // both of these run inside the same transaction
  const order = await Order.create([{
    user:        userId,
    restaurant:  restaurantId,
    items:       cartItems,
    totalAmount: total,
    status:      'placed',
  }], { session });

  await User.findByIdAndUpdate(
    userId,
    { $inc: { orderCount: 1 } },
    { session }
  );

  await session.commitTransaction();
  return order[0];

} catch (err) {
  // if anything fails, roll back both writes
  await session.abortTransaction();
  throw err;

} finally {
  session.endSession();
}

The key is passing { session } to every operation inside the transaction. Without it, that operation runs outside the transaction and will not be rolled back if something fails. The finally block ensures the session is always closed, even when an error is thrown.

The complete schema

Pulling it all together, here is the full User model with constraints, a nested address, a virtual, the password hook, the login method, and indexes:

// models/user.model.js
import { Schema, model } from 'mongoose';
import bcrypt from 'bcryptjs';

const userSchema = new Schema({
  name: {
    type:      String,
    required:  [true, 'Name is required'],
    trim:      true,
    minlength: [2,  'Name must be at least 2 characters'],
    maxlength: [60, 'Name cannot exceed 60 characters'],
  },
  email: {
    type:      String,
    required:  [true, 'Email is required'],
    unique:    true,
    lowercase: true,
    trim:      true,
    match:     [/^\S+@\S+\.\S+$/, 'Please enter a valid email'],
  },
  password: {
    type:      String,
    required:  [true, 'Password is required'],
    minlength: [8, 'Password must be at least 8 characters'],
    select:    false,
  },
  phone: {
    type:  String,
    match: [/^[6-9]\d{9}$/, 'Enter a valid 10-digit mobile number'],
  },
  address: {
    street:  { type: String, trim: true },
    city:    { type: String, trim: true },
    pincode: { type: String, match: [/^\d{6}$/, 'Invalid pincode'] },
  },
  role: {
    type:    String,
    enum:    ['customer', 'rider', 'admin'],
    default: 'customer',
  },
  isActive: { type: Boolean, default: true },
}, {
  timestamps: true,
  toJSON:   { virtuals: true },
  toObject: { virtuals: true },
});

// indexes
userSchema.index({ role: 1, isActive: 1 });
userSchema.index({ 'address.city': 1 });

// virtual
userSchema.virtual('displayAddress').get(function() {
  if (!this.address?.city) return 'No address saved';
  return `${this.address.street}, ${this.address.city} - ${this.address.pincode}`;
});

// hooks
userSchema.pre('save', async function() {
  if (!this.isModified('password')) return;
  this.password = await bcrypt.hash(this.password, 12);
});

userSchema.pre('findOneAndUpdate', function() {
  this.setOptions({ runValidators: true });
});

// instance method
userSchema.methods.comparePassword = async function(candidate) {
  return bcrypt.compare(candidate, this.password);
};

export const User = model('User', userSchema);

How it all fits together

It helps to see the full picture in one place. Your application code talks to Mongoose. Mongoose talks to MongoDB. The schema sits in the middle describing what is allowed, what gets validated, what runs automatically, and how queries behave.

Your route calls a method on the model. The model checks the schema constraints. Any matching pre-hooks run. The data goes to MongoDB. Post-hooks run. The result comes back as a typed Mongoose document with your virtual fields and methods attached.

MongoDB is a genuinely good place to start. The document model matches how JavaScript developers already think about data, the queries are readable, and you can get something working quickly without a lot of infrastructure. Mongoose adds the structure that MongoDB lacks on its own, which is the right tradeoff for most Node.js projects.

References

The "Everything is a File" Tour of Linux

Saumya Agrawal — Wed, 22 Apr 2026 13:48:08 +0000

I wanted to overcome my command line phobia and join the 4% club of human bots who don't panic when they see the terminal, typing away in their plain terminal. I wanted to feel like a hacker. Not the movie kind with three keyboards and cascading green text, but the kind who actually understands what their computer is doing. So I googled "How to learn Linux" and landed on the most mundane, beige documentation website I have ever seen in my life. I dropped into forums next, expecting a more human approach. The first post I found had someone saying "just build your own kernel." I just wanted to learn things, not go on a spiritual journey.

People told me Linux had a learning curve. Except this curve was a cliff.

If you want a 12-minute brush through Linux basics before diving into the weird stuff, Fireship made a video for exactly that.

Before we go into a rabbit hole, I will suggest to try all of this on a VPS, a VM, or a Docker container. Not your main machine. The reason is simple: some of what I will show you involves deliberately breaking things. Try to understand the command before copying, because imagine copying rm -rf /. But if you are HIM, nobody is stopping you. On a throwaway container? You type exit, spin up a fresh one, and try again. Freedom to destroy without consequences is genuinely how you learn Linux fastest.

Two tools that will save you more than any tutorial

Before anything else: man and tldr. These are your cheat codes.

man is the built-in Linux manual. Every command, every system file, every config format has one. When you wonder what a flag does or what a file is for, man has the answer written by the people who built the thing.

man ls
man chmod
man 5 passwd      # the 5 means file format manual, not the command
man resolv.conf   # the config file itself has a man page

The problem with man is density. It was written by engineers for engineers. Enter tldr, a community-written alternative that gives you just the practical common cases.

apt install tldr
tldr ls
tldr chmod

tldr gives you five useful examples instead of fifty pages of specification. Use tldr when you want to quickly understand what something does. Use man when you need the full picture. If man is the textbook, tldr is the cheat sheet your classmate scribbled the night before the exam.

One more habit worth building early: when something fails, read the actual error message before googling. "Permission denied" means permissions. "No such file or directory" means the path is wrong or the file doesn't exist. "Command not found" means it is not installed or not in your PATH. Linux error messages are not trying to confuse you. They are telling you what happened.

What even is `/etc`

/etc is where Linux keeps its brain. Configuration for almost everything the system does lives here in plain text files you can open with any editor. I spent the first hour just running ls /etc and opening random files, and breaking things up. That felt like finding an unlocked door in a building I thought was sealed.

DNS redirection or how I broke Google with one line

The one thing I tried in /etc was /etc/hosts. I wanted to reach my local dev server by a name instead of 127.0.0.1:3000. Opening the file:

nano /etc/hosts

127.0.0.1   localhost
::1         localhost ip6-localhost

I added one line at the bottom and saved:

127.0.0.1   myapp.local

It worked immediately. No restart, no daemon reload. The file is read fresh on every single lookup because this check happens before Linux even thinks about asking a DNS server anything.

Then I had an idea. What if I pointed instagram.com at localhost?

nano /etc/hosts
# add: 127.0.0.1   instagram.com

ping instagram.com

PING instagram.com (127.0.0.1) 56 bytes of data.

This is poor man's parental control. All of Meta's infrastructure, the entire DNS system, bypassed by one line in a text file on your machine. The whole internet is the fallback. This file runs first.

Imagine making your friend slowly lose their mind on a shared Linux machine, redirect their most visited sites to 127.0.0.1 in /etc/hosts. They will restart their wifi three times, blame their ISP, factory reset their router, and spend an hour in a chat with customer support before anyone thinks to check a text file.

`/etc/resolv.conf`: the file that keeps rewriting itself

Once I understood /etc/hosts, I wanted to know what happened when a hostname was not found there. That fallback is /etc/resolv.conf, which holds the actual DNS server address the system asks.

cat /etc/resolv.conf

# This file is managed by man:systemd-resolved(8). Do not edit.
nameserver 127.0.0.53

I had edited this on my machine and my changes kept vanishing. Now I understood why. systemd-resolved is a local DNS middleman running at 127.0.0.53. It manages this file and rewrites it whenever it restarts.

Let's break the internet:

echo "nameserver 0.0.0.0" > /etc/resolv.conf
ping google.com

ping: google.com: Temporary failure in name resolution

The machine is still connected to the network. It just cannot resolve any names because it is asking a DNS server that does not exist. apt update fails, curl fails, package installs fail. The network is fine, only name resolution is dead. This is what a misconfigured DNS server looks like from the inside.

# Fix it immediately
echo "nameserver 8.8.8.8" > /etc/resolv.conf

The permanent fix without the file fighting back is editing systemd-resolved's own config:

nano /etc/systemd/resolved.conf
# under [Resolve]:
# DNS=1.1.1.1
# FallbackDNS=8.8.8.8
systemctl restart systemd-resolved

`/etc/passwd` and `/etc/shadow`: the user accounts are just a text file

I heard that everything in Linux is treated as a file, from hardware device to system configurations, just a file. This in itself was surprising to me, till I started exploring it through /etc/passwd

cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
saumya:x:1001:1001::/home/saumya:/bin/bash

# the above is in the form of name:password:UID:GID:GECOS:directory:shell (root:x:0:0:root:/root:/bin/bash)

Seven colon-separated fields per line: username, password placeholder, user ID, group ID, comment, home directory, login shell. The x in the second field means the actual password hash is stored in /etc/shadow, which only root can read.

sudo cat /etc/shadow | grep saumya

saumya:$6$rounds=4096$saltstring$hashedpassword:19820:0:99999:7:::

# 9 fields separated by ':'

The 9 fields are username, encrypted password, last change, minimum age, maximum age, warning, activity, expiration and reserved.

$6$ means SHA-512. The rounds=4096 deliberately makes hashing slow. Slow hashing means brute-force attacks take longer. Your password is protected partly by intentional computational expense.

Now the interesting part. Every account with /usr/sbin/nologin as its login shell cannot open an interactive session. Try to SSH in as www-data and the connection closes immediately. No password prompt, no shell, nothing. These accounts exist only so the processes running as them have a numeric user identity for permissions. They are not meant for humans to log into.

Now, i wanted to try breaking it and hence, changed my login shell to /bin/false in /etc/passwd.

nano /etc/passwd

# find your line, change /bin/bash to /bin/false

When i tried to connect in a new terminal, the session closes the instant the shell starts because /bin/false exits immediately with a failure code. My account exists, password is correct, the SSH connection succeeds, but I am immediately disconnected. I have locked yourself out without deleting the account or changing the password.

I fixed the current session by changing /bin/false back to /bin/bash.

`/etc/ssh/sshd_config`: watching bots try your front door

On any internet-facing VPS, run this after it has been up for a day:

grep "Failed password" /var/log/auth.log | wc -l

On a fresh VPS after few hours, that number is usually in the thousands. Automated bots scan every IP address on the internet looking for open port 22 and trying common username and password combinations. root, admin, ubuntu, 123456. Constantly, from everywhere.

All SSH behavior is controlled by /etc/ssh/sshd_config:

nano /etc/ssh/sshd_config

You would see a file with multiple lines with Port info, permits and authentications. Two lines that matter immediately:

PasswordAuthentication no
PermitRootLogin no

Setting PasswordAuthentication no means SSH only accepts key-based authentication. The bots still knock but there is nothing to brute-force. No password means no attack surface. PermitRootLogin no means even with valid root credentials, nobody SSHs directly into root.

Want to watch the bots in real time:

tail -f /var/log/auth.log

Run that for five minutes on a fresh VPS. The attempts come in constantly from IP addresses across dozens of countries. It is mildly unsettling and also clarifying. This is just what the internet is like all the time.

After disabling passwords:

systemctl restart sshd
grep "Failed password" /var/log/auth.log | tail -5
# bots still try, still fail, but now they fail faster

Whenever the bots try a password, the server tells them 'NO', not even letting them trying the password to authenticate.

`/etc/fstab`: the file that can stop your machine from booting

/etc/fstab is read at boot. Linux mounts everything listed here. USB drives, additional partitions, network shares. Get an entry wrong and the machine may not boot.

cat /etc/fstab

# in the order
# file system, mount point, type, options, dump and pass


UUID=abc123   /        ext4    defaults    0 1
UUID=def456   /boot    ext4    defaults    0 2
tmpfs         /tmp     tmpfs   defaults    0 0

UUID is used instead of the device name because the name might change but the UUID won't. This acts as the Aadhar Number of the device.

The experiment:

nano /etc/fstab
# add at the bottom:
broken-entry-here

'broken-entry-here' is a string of text without the columns. When the mount command encounters it, it has no idea what the device is, and where it should be mounted.

Now test without rebooting:

mount -a

This command is essentially the dry run of the boot process.

mount: /: can't find broken-entry-here.

Error. Exactly what you would get on boot if you saved this and restarted. Fix it by removing or commenting out the broken line, then run mount -a again to confirm it passes.

The rule: always test with mount -a before rebooting when you touch /etc/fstab. Always. A bad fstab entry drops you into recovery mode or an emergency shell with no obvious explanation. Keep a mental note that this file exists and kills boots if you get it wrong.

`/proc`: the folder that is not actually on disk

/proc is a virtual filesystem. There are no files here stored on disk anywhere. When you read something from /proc, the kernel generates the content on the spot from its own live internal data. It is a window into running system state, not stored data.

cat /proc/meminfo

Run it twice, ten seconds apart. The numbers change. Because it is live.

cat /proc/cpuinfo | grep "flags" | head -1

The flags like vmx, aes and sse which details the CPU capability the processor supports. vmx means hardware virtualization is available. If you try to run KVM and it refuses, check for this flag. aes means the CPU has built-in AES hardware acceleration. Disk encryption and TLS are genuinely faster because of this single flag. sse/avx means CPU has Streaming SIMD Extensions which can boost performance for heavy computations, and video encoding.

The per-process data is where things get interesting. Every running process gets its own directory:

# Find something running
ps aux | grep nginx
# Say it's PID 1234

ls /proc/1234/

cmdline  cwd  environ  exe  fd  maps  mem  net  status

fd/ lists every file descriptor the process has open right now. Log files, sockets, pipes, all of it as symlinks. environ has the exact environment variables the process launched with. cmdline shows the full command that started it. status has memory use, current state, which user it runs as.

cat /proc/1234/cmdline | tr '\0' ' '
ls -la /proc/1234/fd/

The kernel stores command arguments separated by null bytes (\0) to avoid confusion with spaces inside arguments. tr swaps those null spaces to make it readable.

When you delete a file while a process holds it open, the data stays on disk. The file is gone from ls but the space is allocated until the process releases its file descriptor. In Linux, file is a link to a block of data, you are only removing the name. If the process has file descriptor open, data block will be kept alive. By redirecting to the FD in /proc, you're telling the kernel to wipe the actual data blocks while leaving the 'ghost' handle intact.

Find these with lsof | grep deleted. Fix without restarting the process:

> /proc/1234/fd/4

That truncates the held-open file to zero bytes through the process's own descriptor. Disk space reclaimed, process uninterrupted.

Routing: where packets actually go

The routing table is what your machine consults before sending any packet. It decides which network interface and which gateway to use.

ip route show

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.100 metric 100
# local lane
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

The default line handles everything. It says "for any destination I don't have a specific rule for, send it to 192.168.1.1." That is your router. Every internet-bound packet passes through that rule.

Delete it and watch what happens:

ip route del default
ping google.com

connect: Network is unreachable

The machine is still on the network. It just cannot reach anything outside the local subnet because there is no default route. This is one of the first things to check when a server cannot reach the internet. The default route may simply not exist, perhaps because a VPN misconfigured it, or because someone ran ip route flush without knowing what it did.

ip route add default via 192.168.1.1   
# put it back

# Most useful debugging command for routing
ip route get 8.8.8.8

8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100

One line is the complete answer about which interface and gateway any packet would use to reach any destination.

`/dev`: the devices that are not devices

/dev/null, /dev/zero, /dev/random all live in the same directory as actual hardware. They have the same character device type marker. None of them are physical hardware.

/dev/null is a black hole. Write anything to it, and it is gone silently. Read from it, you get immediate end-of-file. This is what command > /dev/null 2>&1 does: stdout goes to the black hole, 2>&1 sends stderr to wherever stdout is going (also the black hole).

The numbers represent 'streams.' 1 is standard output (normal text), and 2 is standard error. 2>&1 means, take all the errors and send them into the same pipe where the normal text is going. Since that pipe leads to /dev/null, the command becomes perfectly silent.

# Silence all output but still check if it worked
some_noisy_command > /dev/null 2>&1
echo $?     # 0 means success, anything else means it failed

/dev/zero produces infinite zero bytes. Good for filling disks or creating blank test files:

fallocate -l 500M bigfile   # faster for large files
# or the /dev/zero version:
dd if=/dev/zero of=bigfile bs=1M count=500

df -h    # watch disk fill up
rm bigfile

fallocate is instant because it just tells the filesystem to reserve the space without actually writing anything to the disk. dd if=/dev/zero forces the CPU to actually churn out millions of zeros and write them one by one.

/dev/urandom produces cryptographically random bytes collected from hardware entropy:

cat /dev/urandom | tr -dc 'a-zA-Z0-9' | head -c 24
echo
# or the cleaner version:
openssl rand -base64 18

The thing that made this concrete for me: the same read() system call your code uses to open a text file reads random bytes from /dev/urandom. Same interface but completely different behavior underneath. That is the "everything is a file" idea became real.

`/boot`: where the kernel lives

ls /boot

vmlinuz-5.15.0-91-generic
initrd.img-5.15.0-91-generic
grub/
config-5.15.0-91-generic

vmlinuz is the compressed Linux kernel (vm = virtual machine, z- compressed like .zip). The actual operating system, stored as a file. initrd.img is a temporary RAM filesystem that acts as a bridge, which loads before the real filesystem mounts at boot. grub/ has the bootloader that lets you choose between operating systems.

cat /boot/config-$(uname -r) | grep CONFIG_EXT4

CONFIG_EXT4_FS=y

That file is the kernel build configuration. Every driver, every feature, listed. Most of it is cryptic without context but searching it teaches you what the kernel actually supports.

The only advice here: do not delete anything from /boot. Deleting vmlinuz means the computer cannot boot at all. Recovery requires a live USB. This is the one folder in the filesystem where curiosity should not turn into experiments.

Consider /etc is the brain and /proc is the nervous system, /boot is the heart of Linux.

`/var/log`: the system's diary

/var/log is where the machine writes what happened. Everything.

ls /var/log

auth.log    syslog    kern.log    dpkg.log
nginx/      apt/      journal/

auth.log records every login, failed or successful. syslog is the general system log. kern.log has kernel messages. dpkg.log records every package installed or removed and when.

Some logs are plain text files you can cat like syslog, while others live in the journal/ directory stores logs in a binary format to make them searchable and faster to filter. The journalctl command is used to read these binary logs.

tail -f /var/log/syslog           # live system events
journalctl -u nginx -f            # live logs for a specific service
journalctl -xe                    # recent journal with explanations
journalctl --since "1 hour ago"   # last hour of everything

When something breaks, look for the log file for the specific thing that broke. It almost always contains the exact error. If logs kept growing forever, they’d fill your entire disk. Linux uses a tool called logrotate that periodically takes the old log, compresses it in the .gz files, and eventually deletes it

`/etc/systemd/system/` writing a service that survives crashes

Systemd starts everything on boot and manages services. Unit files in /etc/systemd/system/ tell it what to run.

I wanted a script running on boot that restarted if it crashed. Cron can run on boot with @reboot but has no crash recovery. A service file does:

nano /etc/systemd/system/myapp.service

[Unit]
Description=My app
After=network.target

[Service]
Type=simple
User=saumya
WorkingDirectory=/home/saumya/app
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

After=network.target line is a safety check that tells Linux to not start this app until the network is actually up.

By default, system services want to run as root and can be a security risk. If the app gets hacked, User= makes sure the attacker is trapped in the user account and doesn't get access to keys. WorkingDirectory ensures that if the code looks for a file in ./config, it's looking in the right folder.

systemctl daemon-reload
systemctl enable myapp
systemctl start myapp
systemctl status myapp

Restart=on-failure is the important line. The process crashes, it comes back in 5 seconds because of RestartSec=5 which can be adjusted. You stop it with systemctl stop. The distinction between a crash and an intentional stop is handled automatically.

Logs for this service:

journalctl -u myapp -f

`PATH` why commands vanish when you break one variable

PATH tells the shell where to look for executables. When you type ls, the shell searches every directory in PATH until it finds a file named ls. If PATH is wrong, every command fails.

export PATH=""
ls

bash: ls: command not found

Everything is gone. The binaries still exist on disk but the shell just lost its map. It can be fixed with:

export PATH=/usr/bin:/bin:/usr/sbin:/sbin
ls    # back

Why this matters beyond the experiment: cron jobs run with a stripped PATH by default. If your script calls something in /usr/local/bin and cron's PATH does not include that directory, the cron job silently fails with "command not found" while the exact same script works fine in your terminal. Set PATH explicitly in your crontab:

PATH=/usr/local/bin:/usr/bin:/bin
* * * * * /home/saumya/myscript.sh

If you’re ever unsure where a command is actually coming from, use which. Running which ls shows the exact path the shell found. It also helps to verify if the map is working.

Permissions

Permissions in theory is chmod, rwx, octal numbers. In practice I kept getting them wrong until I broke something on purpose.

echo '#!/bin/bash
echo "this ran"' > myscript.sh
./myscript.sh

bash: ./myscript.sh: Permission denied

The file exists and the content is correct, but newly created files have no execute permission. Check with:

ls -la myscript.sh
# -rw-r--r-- 1 saumya saumya 30 myscript.sh

No x anywhere. Add it:

chmod +x myscript.sh
./myscript.sh
# this ran

Now the more interesting break. Remove execute from ls itself:

chmod -x /bin/ls
ls

bash: /bin/ls: Permission denied

ls still exists on disk. It just cannot be executed. From the shell's perspective it might as well not be there. Fix:

chmod +x /bin/ls

The three positions: owner, group, others mean the same permissions behave differently depending on who runs the command. When your web server returns 403 errors and logs say "permission denied," this is why. The files exist, the server is running, but www-data does not have the permission to read them.

chown -R www-data:www-data /var/www/html
chmod -R 755 /var/www/html

For a file: +x means you can run it; But for a directory: +x means you can view it using cd.

Linux works on Principle of Least Privilege(PoLP), hence avoid the temptation to run chmod 777.

Environment variables

A friend set a variable in ~/.bashrc. It worked in his terminal. His systemd service couldn't see it which is followed by hours of debugging.

Every process inherits environment variables from its parent. The terminal is started by the login process, which sources ~/.bashrc, which sets your variables. Systemd (PID 1) starts services. Systemd never read your ~/.bashrc. The variables your terminal has, the service has never heard of.

Your terminal reads ~/.bashrc and /etc/profile and has everything you configured. A cron job reads almost nothing. PATH is /usr/bin:/bin. Your tools in /usr/local/bin are invisible. A systemd service reads only what you explicitly declare in its unit file under [Service].

For services, declare variables in the unit file:

[Service]
Environment=NODE_ENV=production
EnvironmentFile=/etc/myapp/.env

For cron, set PATH at the top of the crontab or use absolute paths everywhere. For your own sessions, ~/.bashrc works. The confusion only happens when you expect one environment to be visible in another. In Linux, explicit is better than implicit. If a service needs a variable, tell the service directly.

Terminal shortcuts worth memorizing now

Ctrl+R searches command history interactively. Start typing any part of a command you ran before. This is faster than retyping long paths.

cd - goes to the last directory you were in. Jump between two locations without retyping either path.

!! repeats the last command. The classic use is sudo !! when you forgot sudo.

Ctrl+A and Ctrl+E jump to the start and end of the current line. Ctrl+W deletes the last word backwards. These three reduce terminal frustration noticeably.

When a config file edit breaks something and you want to know exactly what changed: diff /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf. Keep backups before editing important files. cp nginx.conf nginx.conf.bak takes two seconds.

I found two resources that can be helpful in the learning curve of Linux:

Linux Journey : This has organized learning path that breaks down the complexities of the Linux operating system into digestible stages.
Bandit : It is wargame designed to teach the fundamentals of the Linux command line. Visually looks boring, but is really interesting to follow through.

References

Fireship: Linux in 100 Seconds : start here if you haven't
Linux man pages : every file and command has one
tldr pages : install with apt install tldr, use it for every new command
Arch Wiki : the best Linux documentation on the internet, works for all distros regardless of what you're running
explainshell.com : paste any command and it breaks down every flag visually
The filesystem docs : official kernel documentation

Beyond window: Understanding global and globalThis in JavaScript

Saumya Agrawal — Fri, 13 Mar 2026 08:50:15 +0000

When you wrote your first code in Node.js, you used console and setTimeout without the need for import or declaration. They are present in your IDE, ready to be used. Have you ever wondered where they came from?

It is all the work of global, an object that Node.js creates way before the code even starts to run. An object that holds everything the runtime gives you for free.

JavaScript then introduced globalThis, which is a story in itself about the growth of Node.js.

What Is Node.js?

Before we dive into global, let's understand what Node.js is.

JavaScript was initially intended for browsers to run inside Chrome, Firefox, and Safari. The browsers provided a runtime, an engine to execute the code, along with a set of built-in tools like document, window, and fetch.

Node.js wanted to take the JavaScript engine, V8, out of the browser and make it run anywhere.

The same language running on a different environment, but they have their own version of an object that holds everything a code needs without the need to import.

In the browser: the object is window.

In Node.js: the object is called global.

`global`: The Node.js Global Object

When Node.js starts, it creates a global object and provides it with every tool the code needs.

// When the code is written:
console.log("I am global");
setTimeout(() => {}, 1000);

// Javascript does this in the background:
global.console.log("I am global");
global.setTimeout(() => {}, 1000);

But Node.js allows us to skip adding global every time, and looks things up on global automatically.

console.log(global.console === console);       // true
console.log(global.setTimeout === setTimeout); // true

They are the same objects, global is where they are stored.

What lives on `global`

`this` in Node.js

// At the top of a Node.js file:
console.log(this);          
console.log(this === global);

By looking at the code above, you might expect this to be global. Surprisingly, it is not. The output of console.log(this) is {} which is not global.

Node.js wraps every single file in a function before running it:

//  Node.js silently wraps your file in this
(function(exports, require, module,                     
            __filename, __dirname) {                      

    // everything you write goes in here                  

  });

The code is not at the true top level, but it is inside a function. And this inside that function points to module.exports (which starts as {}), not to global.

console.log(this); // {}
console.log(this === global); // false
console.log(this === module.exports); // true

In Node.js, this returns global when a function is called.

function test() {
  console.log(this);    // Object [global].... (in not-strict mode)
}

test();

// in browser
console.log(this); // window
console.log(this === window); // true

this reference note:

Where code runs	What `this` becomes
Browser top-level	`window`
Node top level	`module.exports`
Function call (non-strict)	`global` object
Strict mode function	`undefined`
Method call	the object
Every environment global	`globalThis`

The Problem That Needed Solving

For years, Node.js developers just used global and browser developers used window. The problem here was the need to access global object in both environments. If you build a utility library that formats dates, handles errors, or adds a bit of logging, and publish it on npm so both browser apps and Node.js apps can use it, it would be difficult because of the different global object.

// This crashes in Node.js as window does not exist here
console.log(window.Math);
// ReferenceError: window is not defined

// This crashes in a browser as global does not exist here
console.log(global.Math);
// ReferenceError: global is not defined

Neither name works in both places. So developers started writing workarounds:

// The only solution was:
const globalObject =
  typeof window !== "undefined" ? window :
  typeof global !== "undefined" ? global :
  typeof self   !== "undefined" ? self   :
  null;

This solved the problem of global. Hence, there came a need to introduce a fix.

`globalThis`

ES2020 introduced globalThis as the standard, universal way to access the global object in any JavaScript environment.

// Works in Node.js:
console.log(globalThis === global); // true

// Works in a browser:
console.log(globalThis === window); // true

// Works in a Web Worker:
console.log(globalThis === self);   // true

Hence, the solution the devs used was replaced by a single line of code

const globalObject = globalThis;

globalThis did not replace global in Node.js. global is still there and valid Node.js code. But globalThis is now the recommended way, especially in the code that might run outside of Node.js.

`global` vs `globalThis`

// These do exactly the same thing in Node.js
console.log(global.Math.PI);      // 3.141592653589793
console.log(globalThis.Math.PI);  // 3.141592653589793

// These are the same object
console.log(global === globalThis); // true

// Both let you access anything on the global scope
console.log(global.setTimeout === setTimeout);      // true
console.log(globalThis.setTimeout === setTimeout);  // true

The difference is:

	`global` works	`globalThis` works
Node.js	Yes	Yes
Browser	No	Yes
Workers	No	Yes
Deno	No	Yes

globalThis is used when a package, utility, or library is created that is meant to be shared.

Do Not Add Things to `global` Yourself

Node.js will not stop you from putting your own values on global. However, it is not recommended to use them, and the following example illustrates why.

If you had a small application that required a username and were about to use that username in multiple files throughout the application, you might think that it would be beneficial to place the username into a global variable so that you can reference it throughout the entire application.

// app.js — your main file
global.username = "User";

console.log("App started");


// greet.js — a separate file
function greet() {
  console.log("Hello, " + username); // no import, just works
}

greet(); // "Hello, User"

As your application grows and you eventually have ten files, then there is a potential that after months of work on your application, you will have a situation wherein you will have printed a username incorrectly and upon opening the file where the erroneous user name was printed (greet.js), you would notice there was no import statement for this username, thus you would be required to search through all of the files to locate the source of the incorrect username.

This is what makes variables defined as global variables invisible, and therefore, there is no trail leading to their origin.

When done correctly:

// user.js: one place where username lives
const username = "User";

module.exports = username;

// greet.js: it's clear exactly where username comes from
const username = require("./user");

function greet() {
  console.log("Hello, " + username);
}

greet(); // "Hello, User"

Hence, if instead of globally defining your username, you had created an import statement for the username and used the import in greet.js to define the username, then anyone who looks at greet.js immediately sees where the username is declared, and there is no need to search. This type of coding is much easier to work with, especially when the size of your application increases, or someone new to the project is introduced.

JavaScript was originally designed to run on the browser. However, Node.js took it outside the browser environment and runs JavaScript without the need for a browser.

The way to access that global object was through the variable global. Likewise, browsers have a built-in global variable called window and Web Workers have a built-in global variable called self, which performs the same function as the global variable.

As JavaScript expanded into other environments, developers wanted to write code that worked across all of those environments, like Node.js, Windows, etc., with fewer modifications. However, because there was no consistent name for the global object, this was difficult for developers.

Fortunately, ES2020 introduced the globalThis variable as the global reference for JavaScript in all environments, it will point to the same object no matter what environment your JavaScript code runs in.

In the case of Node.js, global and globalThis both point to the same place. You would use global if you wanted to write code that was specific to Node.js and you want to explicitly reference global. You would use globalThis if you needed to write code that may eventually run in a different environment.

References

Understanding JavaScript Variables and Data Types Through Game Design

Saumya Agrawal — Sun, 08 Mar 2026 04:19:29 +0000

Whenever you start learning a programming language, be it Python, Java, C++, or JavaScript, one concept is common to all of them: variables and data types. Variables and Data Types are the building blocks of a programming language. Variables solve a simple yet important problem: the memory. When a user types their name into a login form, your code needs to hold onto that name long enough to display it, validate it, or send it to a server. When a game tracks your score, it stores that number somewhere so it can update it every time you earn points. Without variables, every piece of data would vanish the moment it appeared. Your program would have no memory, no state, and no way to make decisions based on what happened before.

But storing data is only half the story. A program also needs to understand what kind of data it is working with. This is where data types come in. Imagine storing the value 50. Is it a number representing age? A score in a game? Or is it the string "50" typed by a user in a form? The program needs to know this difference because it determines what operations can be performed on that value. Numbers can be added, divided, or compared mathematically, while strings are treated as text that can be concatenated, sliced, or formatted. Data types give meaning and structure to the values stored in variables.

Let's explore the two with the concept of games.

Variables: The Save File

Imagine playing an RPG with no save files. Whenever you launch the game, your character is gone, the item in your bag disappears, your world resets. The world has no idea who you are in every single run.

That would be unbearable, exactly what code would be like without variables.

A variable is JavaScript's save file. It's a named space in memory where your program stores a piece of information and can look it up later by that name.

💡 A variable is a named save slot in memory that can store values, so it can be used later.

Hence, every RPG has a save file, where the game save your progress, the character name, the inventory, current HP, upgrades, map, level, character progression. Later when you load your save file, you start from where you left off.

Variable Mapping of Save File

fileName	Store	JS Syntax	Data Type
playerName	Caraxes	let playerName = 'Caraxes'	String
health	70	let health = 70	Number
BOSS_LEVEL	14	const BOSS_LEVEL = 14	Number
swordAcquired	false	let swordAcquired = false	Boolean

In JavaScript code

// Creating save file for a game character
let playerName = "Caraxes";        // slot: name
let health = 100;                 // slot: current HP
let bossLevel = 0;               // slot: starts at 0
let swordAcquired = false;
const BOSS_LEVEL  = 99;         // locked: Number of Boss remains same

// Reading from save slots
console.log(playerName);        // "Caraxes"
console.log(health);           // 100

// The game progresses update the slots
health = 70;                 // player took damage
bossLevel  = 3;              // progression on map
swordAcquired = true;         // sword found

console.log(health);          // 70
console.log(bossLevel);       // 3
console.log(swordAcquired)     // true

Declaring Variables: var, let and const

In games, not all save slots work the same way. Some hold your main campaign state, updated regularly. Some are locked achievement records you can only read, never modify.

JavaScript offers three keywords through which variables can be declared:

var: The original way to declare variables which is now deprecated. It can be redeclared and has no scope. It introduces a lot of bugs to the code by not following the modern rules and concepts introduced to JavaScript.

var playerName = "Caraxes";
console.log(playerName);            //Caraxes

//Redeclared
var playerName = "Neoz";
console.log(playerName);            //Neoz

💡
The problem with var is that it can be redeclared without any warning, which makes it easy to accidentally overwrite a value and create bugs which are difficult to spot.

let: This keyword is used when the variables are expected to see change overtime.

let health = 60;
let healthPotion = 20;
console.log(health);        // 60

// update value
health = health + healthPotion;
console.log(health);       // 80

let health = 100;         // SyntaxError:'health' has already been declared

💡
You can update it freely but you cannot redeclare the same variable in the same scope

const: This keyword is used when the variables are not supposed to change.

const maxHealth = 100;

maxHealth = 200;         //TypeError: Assignment to constant variable

💡
Default to const. Only switch to let if you know the value will change. Never use var in your code.

var vs let vs const

Feature	`var`	`let`	`const`
Redeclared	Yes	No	No
Reassigned	Yes	Yes	No
Scope	Function	Block	Block
Hoisted	Yes, as `undefined`	Yes but not initialized	Yes, but not initialized
Use	Avoid	Yes	Yes, preferred

Primitive Data Types: What Goes In The Slot?

A save file aka variable stores value, and every value has a type. Some slots hold text (a character name), some hold numbers (HP), some hold a simple yes/no flag (does the character have a sword?). In JavaScript, the type of the value determines what it is, how it would behave and what operations can be performed.

There are five primitive data types:

String

Any text placed between quotes, which can be single, double or backticks are treated as string type.

let firstName = "Caraxes";
let greeting = 'Hello';
let message = `Welcome to Neverland, ${firstName}!`; // Template literal

console.log(firstName); // Caraxes
console.log(greeting);  // Hello
console.log(message);   // Welcome to Neverland, Caraxes!

💡
Backtick strings or template literals lets you embed variables using ${}. Prefer them over string concatenation.

Number

Integers and decimals are number in JavaScript.

let health = 100;                 
let healthPotion = 1;              
let level = 0; 

console.log(health-10);    // 90
console.log(level + 1);    // 1

💡
Watch out for floating-point quirks: console.log(0.1 + 0.2); results in 0.30000000000000004 as JS uses IEEE 754 standard. use toFixed() to solve this problem or make use of library in case of sensitive data.

Boolean

They have two states: either yes/true or no/false. They are used in logic and consitions.

let isAlive = true;
let hasArmour = false;

console.log(isAlive);  // true
console.log(hasArmour);  // false

if (!hasArmour) {
  console.log("You are vulnerable in Boss fight"); // You are vulnerable in Boss fight
}

💡
Boolean variables often start with is, has, or can — like isLoggedIn, hasPermission, canUpdate. This makes the intent immediately clear.

Null

It is used to make an intentional empty slot.

let weaponEquipped = null;
console.log(weaponEquipped); // null

Undefined

When a variable or slot exist but a value is not stored in that slot. JavaScript does it automatically when you declare a variable without assigning a value.

let conquest;
console.log(conquest); // undefined

Highlights:

let playerName  = "Caraxes";   // String. Text in quotes
let health      = 100;        // Number. No quotes
let hasShield   = true;      // Boolean. true or false
let equippedGun = null;      // Null. Empty on purpose
let questReward;             // Undefined. Slot exists, nothing saved yet

// typeof reveals the type stored in each slot
console.log(typeof playerName);   // "string"
console.log(typeof health);        // "number"
console.log(typeof hasShield);     // "boolean"
console.log(typeof equippedGun);   // "object"  JS bug
console.log(typeof questReward);   // "undefined"

💡
typeof null returns "object" — this is a bug in JavaScript that was never fixed for backward compatibility reasons.

let weapon = null;
console.log(typeof weapon);      // "object" which is confusing
console.log(weapon === null);   // true. use this instead

Scope: Who can access which slot?

Some game data is global. Your player name shows in every menu, every screen. Other data only exists during a specific fight, a boss's HP bar lives only for that encounter. When you leave the arena, it's gone.

That's scope. It determines where in your code a variable is accessible. let and const are block-scoped, they live only inside the { } where they were created. var ignores blocks and leaks out, which is exactly the problem.

Global Scope

A variable declared outside any function or block is global. It can be accessed anywhere in your code.

Block Scope

Variables declared with let or const inside curly braces { } only exist within those braces.

const GAME_TITLE = "Dark Soul";    // Global scope but cant be changed
let playerName = "Caraxes";        // Global scope but can be changed

if (true) {                        // entering the boss arena
  let bossHealth = 7100;         // block-scoped: stays here
  const bossName   = "Nameless King"; // block-scoped: stays here
  var narrator     = "You can't trap me"; // leaks out!
} 

console.log(playerName);  // "Caraxes" 
console.log(narrator);    // "You can't trap me" | var leaked out
console.log(bossHealth);  // ReferenceError: bossHealth is not defined
console.log(bossName);    // ReferenceError: bossName is not defined

💡
var was designed before block scope existed. It ignores if, for, and while blocks. This means a var declared inside an if statement is accessible outside it. It is a real source of bugs. let and const were created specifically to fix this.

JavaScript Glitches

Every game ships with a few unintended bugs. JavaScript is no different, it had certain behaviour in its early days. As the language evolved, new features were introduced to help in fixing those issues, but the older issues cannot be patched because as too much of the web depends on them.

"5" + 3 equals "53", not 8 The + operator does two different things: math addition and string joining. If either side is a string, JS concatenates instead of adding. This surprises almost every beginner, especially when user input (from forms, URLs, etc.) arrives as a string that looks like a number.

// Bonus points come in from a form, they're a STRING
let bonus = "100";    // looks like a number, has quotes = string
let score  = 50;

console.log(score + bonus);           // "50100" | string concat
console.log(score + Number(bonus));   // 150 | explicit conversion
console.log(score + +bonus);         // 150 | unary + shorthand

const doesn't lock object contents const prevents reassigning the slot, but if the slot holds an object, the object's properties can still change. Think of it as locking the locker door, not what's stored inside it.

const player = { name: "Neoz", health: 100 };

player.health = 80;     // changing a property is allowed
console.log(player);    // { name: "Neoz", health: 80 }

player = {};             // TypeError | can't swap the whole object

Save File

A variable stores a named value in memory.
Use const by default. Switch to let only if the value needs to change. Avoid var.
The 5 primitive types are: string, number, boolean, null, and undefined.
Scope controls where a variable is accessible. let and const are block-scoped; var is not.
Use typeof to inspect what type a variable holds.

DEV Community: Saumya Agrawal

MongoDB is Great. Mongoose Makes it Better.

What is MongoDB

Why you cannot just use MongoDB directly in your Node app

Setting up the connection

Writing a schema

Adding constraints

Nested objects and references

Virtual fields

Hooks

Instance methods and static methods

Querying

Indexes

Error handling

Aggregation pipelines

Transactions

The complete schema

How it all fits together

References

The "Everything is a File" Tour of Linux

Two tools that will save you more than any tutorial

What even is /etc

DNS redirection or how I broke Google with one line

/etc/resolv.conf: the file that keeps rewriting itself

/etc/passwd and /etc/shadow: the user accounts are just a text file

/etc/ssh/sshd_config: watching bots try your front door

/etc/fstab: the file that can stop your machine from booting

/proc: the folder that is not actually on disk

Routing: where packets actually go

/dev: the devices that are not devices

/boot: where the kernel lives

/var/log: the system's diary

/etc/systemd/system/ writing a service that survives crashes

PATH why commands vanish when you break one variable

Permissions

Environment variables

Terminal shortcuts worth memorizing now

References

Beyond window: Understanding global and globalThis in JavaScript

What Is Node.js?

global: The Node.js Global Object

What lives on global

this in Node.js

The Problem That Needed Solving

globalThis

global vs globalThis

Do Not Add Things to global Yourself

References

Understanding JavaScript Variables and Data Types Through Game Design

Variables: The Save File

Declaring Variables: var, let and const

Primitive Data Types: What Goes In The Slot?

String

Number

Boolean

Null

Undefined

Scope: Who can access which slot?

Global Scope

Block Scope

JavaScript Glitches

Save File

Continue Your Quest

What even is `/etc`

`/etc/resolv.conf`: the file that keeps rewriting itself

`/etc/passwd` and `/etc/shadow`: the user accounts are just a text file

`/etc/ssh/sshd_config`: watching bots try your front door

`/etc/fstab`: the file that can stop your machine from booting

`/proc`: the folder that is not actually on disk

`/dev`: the devices that are not devices

`/boot`: where the kernel lives

`/var/log`: the system's diary

`/etc/systemd/system/` writing a service that survives crashes

`PATH` why commands vanish when you break one variable

`global`: The Node.js Global Object

What lives on `global`

`this` in Node.js

`globalThis`

`global` vs `globalThis`

Do Not Add Things to `global` Yourself