Forem: Matsu

How Relational Databases Find Database: Understanding Table and Index Scans

Matsu — Thu, 12 Mar 2026 10:08:04 +0000

When creating indexes it's important to understand how they work. In my previous post, I've explained the basics of indexes and the EXPLAIN command. Now we can go a step further and look at the different types of reads a database can perform.

Understanding these access patterns is crucial because it helps us evaluate the trade-offs of creating (or not creating) an indexes. It also gives us insight into what happens under the hood when a query is executed.

At a high level, databases retrieve data in two main ways:

Scanning the table directly (reading rows sequentially);
Using an index to locate rows more efficiently;

The query planner decides which strategy to use based on statistics, table size, and how selective the query conditions are.

Since different databases use slightly different terminology, I've included the names used by each database engine for reference.

1. Full table scan (FTS)

Oracle DB: Full table scan
SQL Server: Table Scan
MySQL: Table Scan
PostgreSQL: Sequential scan (Seq Scan)

This is generally the least efficient scan, with O(n) complexity. The database reads the entire table sequentially, checking each row to see if it matches the query conditions.

When is it used?

For small tables, the query optimizer may decide that a full table scan is actually more efficient than using an index;
For queries that need most of the rows in the table;

Sequential scans are not always bad. Modern databases can read tables very efficiently using sequential disk access, which can sometimes outperform index lookups when a large percentage of rows must be returned.

Full table scans can lead to high I/O, increased CPU usage, and slower response times, especially on large datasets. Monitoring queries and minimizing unnecessary full table scans is a key part of database performance tuning.

2. Index Scan

Oracle DB: Index Range Scan
SQL Server: Index Seek
MySQL: Index Lookup / Range Scan
PostgreSQL: Index Scan

An Index Scan uses an index to locate relevant rows and then fetches the full row from the table (often called the heap in PostgreSQL).

This means the database performs two steps:

Find matching entries in the index
Follow pointers to retrieve the actual rows in the table

When is it used:

Queries filtering on columns with an index;
When only a small subset of rows matches the criteria;

Because the database must jump between the index and the table, index scans can involve random I/O. For queries that return many rows, this can become slower than a sequential scan.

3. Covering Index Scan

Oracle DB: Index Fast Full Scan
SQL Server: Index Seek (covering)
MySQL: Covering Index
PostgreSQL: Index Only Scan

A covering index scan can satisfy the query using only the index, without reading the main table. This avoids additional I/O and can be extremely fast.

In PostgreSQL, this appears as an Index Only Scan, although the database may still access the table if it needs to check row visibility.

When is it used:

Queries that only request columns included in the index;
Read-heavy queries where performance is critical;

Indexes require additional storage. They are most effective when queries are frequent and selective, and less useful if the query needs columns that are not part of the index.

4. Bitmap Index Scan

Oracle DB: Bitmap Index Scan
SQL Server: Bitmap Filter
MySQL: Not implemented the same way
PostgreSQL: Bitmap Index Scan & Bitmap Heap Scan

The database first scans one or more indexes and builds a bitmap representing the locations of matching rows. It then reads the table pages in a more optimized order.

When is it used:

Queries with multiple indexed conditions (e.g., WHERE status='active' AND type='premium');
Medium to large tables where reading rows individually would be slow;

More memory usage to build the bitmap. Very efficient for combining multiple indexes, but not ideal for very small or highly selective queries.

Choosing the right scan

The query planner decides which scan to use based on several factors:

Table size
Index availability
Selectivity of the query
Table statistics

Because of this, adding an index does not guarantee it will be used. If the planner estimates that most rows will be returned, it may choose a sequential scan instead.

Understanding these access methods helps interpret EXPLAIN output and design indexes that actually improve performance.

Console You Later!

"The API Is Slow, Fix It!" – What I Learned About `EXPLAIN` and Indexing

Matsu — Thu, 29 May 2025 13:52:40 +0000

During a technical interview, the situation was something like this:

“Your manager tells you: the API is too slow. Fix it!”

So I started walking through what I’d do — checking logs, measuring response time, analyzing the stack. Eventually, we narrowed it down to the database, suspecting a slow query.

I mentioned I’d try to optimize it based on “feeling” and maybe throw in some indexes. Then the interviewer dropped a simple but powerful tip:

“Have you tried running it with EXPLAIN?”

That’s when I learned something new and honestly, it changed the way I look at query performance.

What Does `EXPLAIN` Actually Show?

When you write a query, the database doesn’t just run it blindly, it builds an execution plan. And EXPLAIN reveals exactly how it plans to execute that query.

Think of it like saying: “Show me how you're going to fetch these results before you actually do it.”

With it, you can discover:

If it’s doing a full table scan;
If your indexes are being used or totally ignored;
What kind of join is being applied (Nested Loop, Hash Join, etc.);
How many rows it thinks it will read;
And how “expensive” the query is, cost-wise.

It’s simple to run:

EXPLAIN SELECT * FROM users WHERE email = 'hi@devmatsu.com';

Why Not Add Indexes Everywhere?

Another key part of the interview was when we discussed indexing. I first said, "maybe because of storage cost?" — but the better answer was:

"Indexes speed up reads, but make writes more expensive."

Every time you run an INSERT, UPDATE, or DELETE, the database also has to update every related index. So the trade-off is:

Too many indexes → fast reads, but slow writes.
Too few indexes → fast writes, but slow reads.

That’s why indexing is a design choice, not a default solution. And again, EXPLAIN helps you check if your index is actually being used or if it’s just sitting there eating up space.

What I Took from That Interview

EXPLAIN isn’t optional, it’s your ally for understanding performance;
Indexing is powerful, but it comes at a cost. Use it with intention;
And most of all: interviews aren’t just tests. Sometimes, they’re great learning moments.

Console You Later!

Setting a Default Node Version for Your Project with .nvmrc

Matsu — Thu, 24 Apr 2025 20:12:08 +0000

I used to switch between projects and wonder why some things just... broke.

Then I realized the issue: each project was using a different Node.js version.

Sometimes one needed Node 18 for a modern API, while another was still running on 16.

That’s when I found out about .nvmrc.

What is `.nvmrc`?

It’s a simple file that you add to the root of your project to define the Node.js version that should be used.

No JSON. No config object. Just the version number.

18.16.1

How does it work?

When using NVM (Node Version Manager), you can run:

nvm use

And NVM will automatically switch your Node.js version to the one specified in .nvmrc.

This is super helpful when you clone a repo and want to make sure you're using the right environment.

Why it matters

Keeps your local version consistent with the project
Prevents bugs caused by incompatible Node versions
Makes onboarding easier for teams

If you're working with multiple Node projects, this tiny file can save you hours of debugging.

Console You Later!

How JavaScript Gets Updated: ECMAScript, V8 and Your Runtime Explained

Matsu — Sun, 13 Apr 2025 19:37:10 +0000

I remember when I started coding in JavaScript, I used to think:

"Okay... so JavaScript gets updated like any language... just update and that's it."

But that's not exactly how things work here. JavaScript runs in different environments like browser, Node.js, Deno — and what actually decides if you can use that new fancy feature you saw on X (the old Twitter) is your runtime.

In this post, I’ll explain how new JavaScript features are released, how ECMAScript fits into this process and why your runtime decides what features you can use (or not).

What is ECMAScript?

ECMAScript is the official specification of the language and JavaScript is just an implementation of that spec.

Every year, a group called TC39 (the committee that defines the language) releases a new ECMAScript version — adding new features, syntax, and behavior.

Examples of features introduced by ECMAScript versions:

Version	Year	Features example
ES6	2015	`let`, `const`, arrow functions, classes
ES2020	2020	Optional chaining `?.`, Nullish coalescing `??`
ES2022	2022	`#privateFields` in classes, top-level `await`

But How Do We Get Those Features?

That's the point. It's not about updating JavaScript. It depends on the JavaScript Engine you’re running.

What is a JavaScript Engine?

A JavaScript Engine is what reads, parses, and executes your JavaScript code. Each environment (browser, Node.js) uses an engine.

Popular engines:

V8 → used by Chrome and Node.js
SpiderMonkey → used by Firefox
JavaScriptCore (Nitro) → used by Safari

When Do You Get New JavaScript Features?

Environment	How do you get new features?
Browser	By updating the browser
Node.js	By updating your Node.js version

It's simple as that. If you want to use new features just need to update the browser or the Node.js version

Why Is This Important?

Because when you’re writing code locally — in your machine — you can probably use everything that your Node.js or browser supports. But when you're writing code for production (especially frontend), you need to care about your users' environment.

Example:

If your users still use old browsers like IE11 (hope not) or very old Android versions — you can’t use optional chaining ?. directly.

The browser wouldn’t even understand that syntax.

That’s why tools like: Babel, TypeScript, Webpack, Vite and others exist — to transpile your code and convert modern JavaScript to old compatible syntax.

Final Thoughts

JavaScript is updated every year through ECMAScript but you only get those new features when your environment supports them — either by updating the engine (browser, Node.js) or transpiling your code for compatibility.

Now every time you see a new JavaScript feature, remember:

It’s not about "updating JavaScript" — it’s about your engine.

Console You Later!

Closures vs Classes in JavaScript: What I Learned Solving LeetCode #2622

Matsu — Tue, 08 Apr 2025 13:56:07 +0000

I was solving LeetCode #2622 – Cache With Time Limit and the goal was to create a function that returns a caching system with TTL (time-to-live).

My first instinct? Use a closure. It's a common pattern — just define a variable outside the function and the inner function can reference it.

🔁 Closure-style cache:

function createCache() {
  const store = new Map();

  return {
    set(key, value, ttl) {
      store.set(key, { value, expiry: Date.now() + ttl });
    },
    get(key) {
      const cached = store.get(key);
      if (!cached || cached.expiry < Date.now()) return -1;
      return cached.value;
    }
  };
}

Easy. It works, it's scoped and no one can touch store from the outside — classic closure encapsulation. But the LeetCode problem expected us to extend a function via its prototype — and that threw me off. I was like: "How the heck do I create a private variable across prototype methods?"
That’s when the light bulb went on.

Using `this` + Classes = Encapsulation

I realized I needed to treat it like a class and that’s when I remembered: when using prototypes (or classes), you can store shared data inside this.
So I did:

var TimeLimitedCache = function () {
  this.cache = new Map();
};

TimeLimitedCache.prototype.set = function (key, value, duration) {
  const expiredAt = Date.now() + duration;
  const existed = this.cache.has(key);
  this.cache.set(key, { value, expiredAt });
  return existed;
};

TimeLimitedCache.prototype.get = function (key) {
  const entry = this.cache.get(key);
  if (!entry || entry.expiredAt < Date.now()) return -1;
  return entry.value;
};

Now everything lives inside this.cache. No need for an external closure and it works great across all methods.

Private Fields in Classes

At that point I thought: "Wait, so this whole thing is basically behaving like a class!". And if it’s a class, can we go one step further? What about private fields?
In the past, we'd use a naming convention like _cache, but that was just a signal, not actual protection.
But now with modern JavaScript (since ES2022), we can use native private fields with the # symbol:

class TimeLimitedCache {
  #cache = new Map();

  set(key, value, duration) {
    const expiredAt = Date.now() + duration;
    const existed = this.#cache.has(key);
    this.#cache.set(key, { value, expiredAt });
    return existed;
  }

  get(key) {
    const entry = this.#cache.get(key);
    if (!entry || entry.expiredAt < Date.now()) return -1;
    return entry.value;
  }
}

That’s real encapsulation!

What I Learned

Closures are a great way to encapsulate state, especially for factory functions;
Classes with this are a powerful alternative when you want to work with prototypes or build something that feels more like an object;
Modern JavaScript gives us native private fields (#);

No matter what pattern you choose, closures or classes, the key is to understand the trade-offs and when each tool fits better.

Solving this problem gave me a new perspective on how classes and closures can often solve the same thing in different ways.

Console You Later!

What happens when both try and finally return in JavaScript?

Matsu — Mon, 07 Apr 2025 03:05:26 +0000

What do you think will happen if we run this code?

function test() {
  try {
    throw new Error("oops");
  } catch (e) {
    return 'catch';
  } finally {
    return 'finally';
  }
}

console.log(test());

At first you might think:

"Okay, it throws an error, so it goes into the catch block and returns 'catch'... right?”

But not quite! Actually this code will return finally! But why? Let me explain.

How `try`, `catch` and `return` Work

We usually think of return as an immediate exit, but in JavaScript, that’s not exactly how it works under the hood. When the JS engine hits a return, it creates something called a Completion Record.

Think of it as a sticky note that says:

"Hey, we're done here. The reason is return and here's the value to give back"

This record is kept internally by the JavaScript engine until the function truly finishes.

The flow with `finally`

Here's a real-world metaphor:

You go to the market (that's your function)

You try to buy apples (try), but if they’re out of stock, you get bananas instead (catch).

As you're about to check out, your mom calls and says:
“Forget that — just buy milk!” (finally).

So no matter what you were planning to bring home (apples or bananas), you end up bringing milk.

Here's the code version:

function goToMarket() {
  try {
    throw new Error('No apples today!');
    return 'Apples';
  } catch (e) {
    return 'Bananas';
  } finally {
    return 'Milk';
  }
}

console.log(goToMarket()); // 'Milk'

Why Does This Happen?

The try block tries to return 'Apples', but an error is thrown.
The catch block handles it and returns 'Bananas'.
Before the function can return 'Bananas', the finally block runs and its return 'Milk' overrides everything.

So 'Milk' is the final return value.

ECMAScript Spec (in simple terms)

According to the ECMAScript spec:

A return in try or catch doesn't immediately return — it creates a Completion Record;
The finally block is always executed, regardless of what happened in try or catch;
If the finally block has its own return, it overwrites any previous return;

That’s why finally becomes the actual return value.

Reference

This behavior follows the ECMAScript specification, which details how CompletionRecords are handled during function execution.

Final Thoughts

The finally block isn't just a "cleanup" section — it can take control of your function's return value if you’re not careful. Even if try or catch has a return, a return inside finally will override it.

So next time you're writing error handling, think twice before returning inside a finally block, it might silently change your function’s behavior.

Understanding this little quirk helps you avoid unexpected bugs and gives you more control over your code flow.

Console You Later!

What is Immutability in JavaScript?

Matsu — Sun, 06 Apr 2025 03:43:58 +0000

Immutability is a powerful concept in programming and especially important in JavaScript, even if we don't always think about it. It affects how we manage data, state and side effects in our applications.

In this post, we'll break down what immutability means, why it matters and how you can work with it in practice.

What is Immutability?

Basically Immutability means something cannot be changed after it's created. For example in JavaScript, primitive values like numbers, strings and booleans are immutable. This doesn't mean the variable can't be reassigned, it means the value itself can't be changed in place.

Example with a string:

let name = 'Matsu';

// Trying to change just one character (this won't work)
name[0] = 'B';

console.log(name); // 'Matsu' → Still the same

// But we can reassign the variable
name = 'John';
console.log(name); // 'John'

So the string itself is immutable but the variable name can be reassigned to a new string. In contrast, objects and arrays are mutable by default, which means you can change their contents directly.

Example with an object:

const user = { name: 'Matsu' };

// Modifying the object
user.name = 'John';

console.log(user); // { name: 'John' }

This can lead to unintended side effects, especially when multiple parts of your code are referencing and modifying the same object or array, such as shared data or state.

What Can Immutability Do?

Avoid side effects (accidentally changing shared data);
Make debugging easier (state doesn't change in hidden ways);
Improve performance in some cases (e.g. with reference checks);
Work better with frameworks like React, which rely on state changes via new objects;

Working with Immutability in JavaScript

To keep data immutable, we usually create new copies instead of modifying the original.

Copying Arrays

const numbers = [1, 2, 3];

// Instead of: numbers.push(4)
const newNumbers = [...numbers, 4];

console.log(numbers);     // [1, 2, 3]
console.log(newNumbers);  // [1, 2, 3, 4]

Copying Objects

const user = { name: 'Matsu', age: 28 };

// Instead of: user.age = 29
const updatedUser = { ...user, age: 29 };

console.log(user);        // { name: 'Matsu', age: 28 }
console.log(updatedUser); // { name: 'Matsu', age: 29 }

Attention with Deep Copy vs Shallow Copy

Most techniques (like spread (...) and Object.assign) create shallow copies. This means only top-level properties are copied. If the object contains nested objects, those nested references remain shared between the original and the copy.

const person = {
  name: 'Matsu',
  address: { city: 'Tokyo' }
};

const clone = { ...person };
clone.address.city = 'Osaka';

console.log(person.address.city); // 😱 'Osaka'

Even though we used the spread operator, person.address and clone.address still point to the same object in memory, so changing one affects the other.

To truly copy all levels of an object, you need a deep clone. One common approach is using cloneDeep from Lodash:

import _ from 'lodash';
const deepClone = _.cloneDeep(person);

This creates a new object where even the nested structures are fully cloned, breaking the reference between the original and the copy.

You can check my post about Exploring Object Cloning Techniques in JavaScript to dive deeper.

Enforcing Immutability in JavaScript

You might think using const would make an object or array immutable, but that's not the case. const only prevents reassignment, not mutation.
By default, JavaScript objects and arrays are mutable. But there are ways to partially enforce immutability at runtime using built-in methods like:

`Object.freeze()`

Prevents adding, removing or modifying properties of an object making the object shallowly immutable.

const config = Object.freeze({
  apiUrl: 'https://api.example.com',
  retries: 3,
});

config.retries = 5;
console.log(config.retries); // 3 — change is ignored or throws in strict mode

⚠️ Note: This only works on the first level. If the object has nested properties, they’re still mutable unless you recursively freeze them.

Example: Freezing an Array

You can also use Object.freeze() to prevent changes to an array, for example, if you want to enforce a fixed set of values (e.g. length, content):

const roles = Object.freeze(['admin', 'editor', 'viewer']);

roles.push('guest');         // ❌ won't work
roles[0] = 'superadmin';     // ❌ won't work
roles.length = 0;            // ❌ won't work

console.log(roles); // [ 'admin', 'editor', 'viewer' ]

This is useful when you want to protect reference lists, roles, or static options in your app.

`Object.seal()`

Prevents adding or removing properties, but you can still modify existing ones.

const settings = { theme: 'dark' };
Object.seal(settings);

settings.theme = 'light';      // ✅ allowed
settings.language = 'en';      // ❌ can't add new property
delete settings.theme;         // ❌ can't delete property

console.log(settings); // { theme: 'light' }

These methods are great for protecting config objects, shared constants or preventing accidental mutations especially in larger codebases.

When to Use Immutability?

When managing application state (especially in React or Redux);
When writing pure functions;
When you want predictable and reliable behavior in your code;

Final Thoughts

Immutability is not about never changing anything, it's about changing things safely by creating new versions instead of modifying existing ones. You can also "lock" objects and arrays using Object.freeze() or Object.seal() to help prevent accidental changes.

It leads to better, cleaner and more bug-resistant code, especially as your project grows. So embrace immutability and you'll avoid a lot of hidden side effects and unexpected behavior.

Console You Later!

Programming Paradigms Explained with Code Examples

Matsu — Fri, 04 Apr 2025 14:12:18 +0000

When you're learning to code or expanding your knowledge, you'll often hear the term "programming paradigms" but what does that actually mean?

A programming paradigm is a way to approach problem-solving using code. It's about how you structure your logic and instructions. Different paradigms shape the way you think and organize your solutions.

Let's explore some of the main ones with simple examples.

1. Imperative Programming

This is one of the most common and intuitive paradigms. You tell the computer how to do something, step by step.

Example (in JavaScript):

let sum = 0;
for (let i = 0; i <= 5; i++) {
  sum += i;
}
console.log(sum); // 15

2. Declarative Programming

You focus on what you want instead of how to do it. SQL and even parts of React are declarative.

Example (SQL):

SELECT * FROM users WHERE age > 18;

Example (React - .jsx file):

function Greeting() {
  return <h1>Hello, world!</h1>;
}

It may not look declarative at first, but the point is: React uses JavaScript under the hood, the way you define UI with JSX is declarative because you're describing what should be rendered based on the current state or props, not how to manually build or update the DOM.

3. Object-Oriented Programming (OOP)

This paradigm organizes code that encapsulate both data and behavior. It's great for modeling real-world entities.

Example (TypeScript):

class Animal {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  speak(): void {
    console.log(`${this.name} makes a sound.`);
  }
}

class Dog extends Animal {
  speak(): void {
    console.log(`${this.name} barks.`);
  }
}

const dog = new Dog('Rex');
dog.speak(); // Rex barks.

4. Functional Programming

In functional programming, you use pure functions and avoid mutating data. It's about composition, immutability and statelessness.

Example (JavaScript):

const double = (x) => x * 2;
const result = [1, 2, 3].map(double);
console.log(result); // [2, 4, 6]

Final Thoughts

Modern languages like JavaScript, Python and TypeScript are multi-paradigm so you can combine functional, object-oriented and imperative styles depending on what fits best.

Here are some languages commonly associated with each paradigm:

Paradigm	Languages
Imperative	JavaScript, TypeScript, Go, Python, Java, Rust
Declarative	SQL, JavaScript (JSX), Elixir
Object-Oriented	TypeScript, Python, C#, Java, Kotlin
Functional	JavaScript, TypeScript, Python, Kotlin, Elixir

If you're aiming to grow as a developer, understanding paradigms is a powerful step. Knowing the fundamentals helps you understand what you're doing and why you're doing it that way.

Console You Later!

Memoization and Caching: Are they the same in JavaScript?

Matsu — Tue, 01 Apr 2025 01:55:47 +0000

At first glance, Memoization and Caching might seen like the same thing. After all, both techniques involve saving results to avoid doing the same work again. But while they are related, they're not exactly the same and understanding the difference between them will make you have a strong fundamentals.

In this post, we'll break down what memoization and caching really are, compare them side by side and walk through practical examples so you'll never confuse them again.

What is Memoization?

Memoization is a specific form of caching that's focused on functions. It stores the result of a function based on its inputs arguments.

If the function is called again with the same arguments, the stores result is returned instead of running the function again.
It's typically used for:

Pure Functions (functions that always return the same output for the same input);
Expensive calculations that are repeated often;
Variables in outer functions that are preserved through closures (e.g., for storing cached values);

It usually stores values in memory, like in a plain object or closure.

What is Caching?

Caching is a broader concept. It referes to storing any kind of data so it can be accessed faster in the future, not just functions results.

It's used everywhere

API responses;
Database query results;
Images, files, computed reports;
Session data, user info, etc;

And it can be stored anywhere:

In memory;
In a Redis store;
In the browser (localStorage, indexedDB);
On disk

Key differences

Feature	Memoization	Caching
Scope	Function-level	Global / application-level
Purpose	Store function results	Store any reusable data
Based On	Function arguments	Keys like URL, ID, custom cache key
Typical Storage	In-memory (object or closure)	Memory, Redis, disk, browser
Use Cases	Recursive calculations, pure logic	API calls, DB queries, static files
Invalidation	Rare (input-based)	TTL, manual purge, cache strategy needed
Example	`factorial(n)`, `fibonacci(n)`	Cached API response by user ID

Memoization in code

Let's look at a simple example using the factorial function, which is a great case for memoization because each result depends on the previous one.

Without Memoization:

function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1);
}

console.log(factorial(5)); // 120
console.log(factorial(5)); // Recalculates everything again

With Memoization:

function memoizedFactorial() {
  const cache = {};

  return function factorial(n) {
    if (n in cache) {
      console.log('From cache:', n);
      return cache[n];
    }

    if (n <= 1) return 1;

    const result = n * factorial(n - 1);
    cache[n] = result;
    return result;
  };
}

const factorial = memoizedFactorial();

console.log(factorial(5)); // Calculated
console.log(factorial(5)); // Cached!
console.log(factorial(6)); // Uses cached factorial(5)

This shows how we avoid redundant work by reusing previous results.

Caching in code (Example with Redis)

Now let's say we have a function that fetches user data, possibly expensive if it hits a DB or API.
Instead of recalculating or re-fetching it every time we cache it using Redis.

async function getUser(userId) {
  const key = `user:${userId}`;
  const cached = await redis.get(key);

  if (cached) {
    console.log('Returned from Redis cache');
    return JSON.parse(cached);
  }

  const user = await fetchUserFromDB(userId);
  await redis.set(key, JSON.stringify(user), 'EX', 60); // Cache for 60s
  return user;
}

This is not memoization, but it is caching. It's not tied directly to a function's input/output relationship in memory. It's stored in an external cache layer and used across multiple calls.

When to Use Each

Use memoization when:

You're working with pure functions;
You want to optimize repeated calculations;
You don't want to introduce external storage (just use in-memory);

Use caching when:

You want to store data fetched or computed from external sources;
You need to share results between processes or requests;
You need expiration, invalidation or disk/network-level persistence;

Final thoughts

Memoization and caching are related but they solve different problems.

Memoization is about functions calls: if I call this again with the same input, don't recompute it.

Caching is about data reuse: if I already fetched this, let's avoid doing it again.

Quick recap:

Memoization is a type of caching;
All memoization is caching, but not all caching is memoization;
Both can drastically improve performance if used in the right context;

Console You Later!

What is an IIFE in JavaScript and Why Would You Use It?

Matsu — Fri, 28 Mar 2025 21:32:28 +0000

In JavaScript, you might have seen a function that seems to call itself right after it's defined. That’s called an IIFE, short for Immediately Invoked Function Expression. It might look weird at first, but it has some interesting use cases. Let’s explore what it is, how it works, and when to use it.

What is an IIFE?

An IIFE is a function that runs immediately after it’s defined. The main idea is to create a new scope without polluting the global one.

Here’s how it looks:
(function () { console.log('This runs immediately!'); })();
Or, with arrow function syntax:
(() => { console.log('Arrow IIFE runs immediately!'); })();

Why Does This Work?

In JavaScript, when you define a function like:
function sayHi() {}
…it’s just a declaration, and it won’t run until you call it.

But to make the function run immediately, you need to turn it into an expression. That’s why we wrap it in parentheses:

The first () turns the function into a function expression.
The second () calls it.

Common Use Cases

Avoiding Global Scope Pollution IIFEs help keep variables inside their own scope so they don’t interfere with other parts of your code.

(function () { const secret = 'I stay local'; console.log(secret); // Works here })();

console.log(secret); // Error: secret is not defined

Running Setup Code Once If you want to run some initialization logic right away (like setting up configs), IIFE can be a clean solution.

const app = (() => { const config = { env: 'production' }; console.log('App is starting...'); return { getConfig: () => config }; })();

Using await in Non-Async Environments (Async IIFE) In environments where you can't use top-level await (like older Node.js or CommonJS modules), an async IIFE allows you to run asynchronous code with await.

(async () => { const response = await fetch('https://api.example.com/data'); const data = await response.json(); console.log(data); })();

This is super useful for running async logic without needing to define and then manually call a separate async function.

IIFEs are a handy JavaScript pattern that allow you to execute functions immediately while keeping variables scoped locally. While not as common in ES6+ codebases thanks to modules and let/const, they're still worth knowing — especially when you stumble across them in older code or want a quick isolated block.

Console You Later!

Comparing Promise Chaining vs. Async/Await in JavaScript

Matsu — Wed, 22 Jan 2025 14:21:57 +0000

In modern JavaScript (Node.js included), asynchronous operations can be managed using either Promise chaining or the Async/Await syntax. Both approaches help avoid deeply nested callbacks (the infamous “callback hell”) and ensure cleaner, more readable code. However, there are some nuanced differences in style and usage between the two.

Promise Chaining

Promise chaining involves returning a new Promise from each .then() in a sequence. It can look like this:

fetchUserData()
  .then((userData) => processData(userData))
  .then((processedData) => displayResults(processedData))
  .catch((error) => handleError(error));

Pros

Clear Step-by-Step Flow: Each .then() block details a subsequent step, making the logic flow relatively clear.
Global Error Handling: A single .catch() at the end can handle errors thrown at any step in the chain.
Widely Supported: Promises have been part of JS for quite some time, so this style is compatible with most JavaScript environments.

Cons

Nested Chaining: When multiple asynchronous tasks need branching logic, chaining can become more complex or deeply nested.
Readability: While much better than callbacks, a series of .then() calls can still feel a bit verbose or less synchronous-like compared to Async/Await.

Tip: Using `resolve` and `reject` directly in Promise chaining

When creating custom Promises, you might come across this pattern:

new Promise((resolve, reject) => {
  Promise.all(tasks).then(resolve).catch(reject);
});

This works because resolve and reject are functions and then()/catch() pass their result as arguments. So writing .then(resolve) is equivalent to .then((result) => resolve(result)).

Avoid calling them like resolve() immediately or you'll trigger them at the wrong time.

I came across this pattern while solving LeetCode 2721, where we implement a custom version of Promise.all. Passing resolve directly into .then() made the solution cleaner and avoided unnecessary async/await usage.”

Async/Await

Async/Await is syntactic sugar on top of Promises that provides a more synchronous feel to asynchronous code:

async function run() {
  try {
    const userData = await fetchUserData();
    const processedData = await processData(userData);
    displayResults(processedData);
  } catch (error) {
    handleError(error);
  }
}

run();

Pros

Synchronous-Like Syntax: The code reads in a top-down manner, making asynchronous flows easier to follow.
Inline Error Handling: Using try...catch blocks within an async function allows more granular handling of errors where they occur.
Cleaner Logic: Multiple await can be used without creating a “chain”, potentially making the code easier to refactor or maintain.

Cons

Error Handling Complexity: While try...catch is powerful, ensuring you handle all errors properly across multiple awaits can require careful structuring.
Requires Modern JS: Async/Await is supported in modern JavaScript environments (Node.js >= 8, modern browsers), so very old environments would need transpiling.

Which One Should You Use?

Personal / Team Preference: Some teams prefer the explicit .then() chaining, especially if they’re used to it. Others love the synchronous style of async/await.
Complexity: For more complex, branching async flows, async/await can make the logic significantly easier to read and maintain.
Error Handling: If you need fine-grained error handling at specific points, try...catch in async/await can be more intuitive. If a single .catch() is enough, Promise chaining might be sufficient.

Key Takeaways

Both Are Promises: Async/Await is syntactic sugar over Promises, so under the hood, they function the same way.
Readability: async/await often results in code that looks and behaves more like synchronous code, improving readability.
Error Handling: Promise chaining uses .catch(), whereas async/await can use multiple try...catch blocks, providing more control.
Environment: Make sure your environment (or your build setup) supports async/await if you choose it.

Ultimately, choosing between Promise chaining and async/await often comes down to preference and code style. Both approaches handle asynchronous operations effectively, so pick the method that best suits your workflow.

Console You Later!

Why [4, 11, 2, 23].sort() in JavaScript Isn’t What You Expect

Matsu — Sun, 05 Jan 2025 00:25:24 +0000

When sorting arrays in JavaScript, you might expect [4, 11, 2, 23].sort() to return [2, 4, 11, 23]. Surprisingly, the result is [11, 2, 23, 4]. Let’s explore why this happens, and how Unicode code points factor into the comparison.

Default Sort Behavior
By default, JavaScript’s Array.prototype.sort() method sorts elements as strings in ascending Unicode order. This means each array element is converted to a string, and the comparison is made based on these string values, character by character.

Let’s see the array as strings:

"4"
"11"
"2"
"23"

When comparing these strings, JavaScript looks at the first character of each string and compares their Unicode code points:

String	First Character	Unicode Code Point
"4"	'4'	52
"11"	'1'	49
"2"	'2'	50
"23"	'2'	50

"11" vs. "2":
- '1' (code 49) vs. '2' (code 50) ⇒ 49 < 50 ⇒ "11" comes before "2".
"2" vs. "23":
- Both start with '2' (code 50). Then "2" ends, while "23" continues with another '3'.
- By string comparison rules, a shorter string that is a prefix of a longer one is considered smaller ⇒ "2" comes before "23".
"23" vs. "4":
- '2' (code 50) vs. '4' (code 52) ⇒ 50 < 52 ⇒ "23" comes before "4".

Ultimately, as strings, the sorted order is "11" < "2" < "23" < "4", which corresponds to [11, 2, 23, 4] when converted back to numbers in the array.

How to Fix It (Sort Numerically)

If you want to sort numbers in numeric order, you need to provide a compare function to the sort() method. This compare function tells JavaScript how to compare two elements numerically instead of as strings:

[4, 11, 2, 23].sort((a, b) => a - b);
// [2, 4, 11, 23]

If a - b is negative, a comes before b.
If a - b is zero, the order of a and b stays as is.
If a - b is positive, a comes after b.

Key Takeaways

Default String Comparison: JavaScript’s default sort() converts elements to strings and sorts them in ascending Unicode order.
Numeric Sorting: To sort numbers, provide a compare function—(a, b) => a - b.

Armed with this knowledge, you can confidently sort arrays in JavaScript, whether you need to sort them as strings or numbers.

Console You Later!

Forem: Matsu

How Relational Databases Find Database: Understanding Table and Index Scans

Choosing the right scan

"The API Is Slow, Fix It!" – What I Learned About `EXPLAIN` and Indexing

What Does EXPLAIN Actually Show?

Why Not Add Indexes Everywhere?

What I Took from That Interview

Setting a Default Node Version for Your Project with .nvmrc

What is .nvmrc?

How does it work?

Why it matters

How JavaScript Gets Updated: ECMAScript, V8 and Your Runtime Explained

What is ECMAScript?

Examples of features introduced by ECMAScript versions:

But How Do We Get Those Features?

What is a JavaScript Engine?

When Do You Get New JavaScript Features?

Why Is This Important?

Example:

Final Thoughts

Closures vs Classes in JavaScript: What I Learned Solving LeetCode #2622

🔁 Closure-style cache:

Using this + Classes = Encapsulation

Private Fields in Classes

What I Learned

What happens when both try and finally return in JavaScript?

How try, catch and return Work

The flow with finally

Why Does This Happen?

ECMAScript Spec (in simple terms)

Reference

Final Thoughts

What is Immutability in JavaScript?

What is Immutability?

Example with a string:

Example with an object:

What Can Immutability Do?

Working with Immutability in JavaScript

Copying Arrays

Copying Objects

Attention with Deep Copy vs Shallow Copy

Enforcing Immutability in JavaScript

Object.freeze()

Example: Freezing an Array

Object.seal()

When to Use Immutability?

Final Thoughts

Programming Paradigms Explained with Code Examples

1. Imperative Programming

Example (in JavaScript):

2. Declarative Programming

Example (SQL):

Example (React - .jsx file):

3. Object-Oriented Programming (OOP)

Example (TypeScript):

4. Functional Programming

Example (JavaScript):

Final Thoughts

Memoization and Caching: Are they the same in JavaScript?

What is Memoization?

What is Caching?

Key differences

Memoization in code

Caching in code (Example with Redis)

When to Use Each

Use memoization when:

Use caching when:

Final thoughts

Quick recap:

What is an IIFE in JavaScript and Why Would You Use It?

What is an IIFE?

Why Does This Work?

Common Use Cases

Comparing Promise Chaining vs. Async/Await in JavaScript

Promise Chaining

Pros

Cons

Tip: Using resolve and reject directly in Promise chaining

Async/Await

Pros

What Does `EXPLAIN` Actually Show?

What is `.nvmrc`?

Using `this` + Classes = Encapsulation

How `try`, `catch` and `return` Work

The flow with `finally`

`Object.freeze()`

`Object.seal()`

Tip: Using `resolve` and `reject` directly in Promise chaining