DEV Community: Emmanuel Sunday

ABAC and CASL with NestJS

Emmanuel Sunday — Wed, 27 May 2026 10:11:50 +0000

A few days ago, I published an article that introduced an optimal way to handle permissions in Node.js in its entirety.

It's an approach that dismisses you from hard-locking permissions from arbitrary statements like "Pharmacy can perform this," "if (!Pharmacy) throw error," etc.

It's a common concept known as Attribute-Based Access Control (ABAC), which you'll find in advanced systems.

This article will address why and how to get this done in NestJS.

NB: We'll be speaking in NestJS language for the sake of this article.

When RBAC Fails

Maintainability

Imagine you have an app with multiple roles — pharmacy, customer, doctor — and you've handled all the necessary role handling.

Enough…

@Roles(Roles.Pharmacy)

And more than enough…

@UseGuard(RolesGuard)

…across your controllers.

The moment there's a need to create an Admin role, you'll find yourself scavenging to add Roles.ADMIN everywhere possible across controllers.

You'll also then need to sit down and spend hours, if not days, making sure all your if (!Roles.Pharmacy) throw error statements across services now include !Roles.Admin.

Sad to say, but this is decoupled code.

Scalability

Role-Based Access Control (RBAC) is only manageable with 2 roles.

A system that, by any means, has more than 2 roles will struggle to be maintained.

Imagine building a Google Cloud clone while using if (!Roles.Pharmacy) throw error — you quickly realize the bottlenecks.

Lack of Reusability

It's always necessary to handle permissions at the service level as well as at the controller level.

It's a lot cleaner at the controller level with a Roles decorator.

We can't say the same for the service level. You'll always end up with a myriad of if (!pharmacy) throw error statements across methods.

Imagine doing this over and over again for an application with multiple resources.

ABAC and CASL

ABAC introduces permission handling from a discrete standpoint.

I could equate role-based permission to knowing the smallest particle of "elements" as atoms, and one day realizing there exist "protons," "electrons," and "neutrons."

That's exactly what we do with ABAC.

Instead of focusing on "this is a hydrogen atom" and its characteristics, we are rather concerned with the constituents of the hydrogen atom.

We could even use our knowledge of these constituents to simulate other elements.

Enough chemistry. Let's get to the nitty-gritty.

TL;DR: ABAC moves away from "Who are you?" (role) to "Are you allowed to perform this specific action on this specific object?". CASL is a framework around ABAC.

NestJS Implementation

The first thing you do is create policies.

Policies allow you to control who can do what per resource.

This is properly known as "ability" in CASL.

Here's what it looks like for an inventory resource:

// inventory/inventory.ability.ts
import { AbilityBuilder } from '@casl/ability';

export function InventoryAbility(user, builder: AbilityBuilder<any>) {
  const { can, cannot } = builder;

  if (user.role === 'pharmacy') {
    can('create', 'Inventory');
    can('update', 'Inventory', {
      pharmacyId: user.pharmacyId,
    });
    can('read', 'Inventory');
  }

  if (user.role === 'customer') {
    can('read', 'Inventory');
  }

  if (user.role === 'admin') {
    can('manage', 'all');
  }

  cannot('delete', 'Inventory');
}

For a NestJS execution, we'll create these for every resource we have.

This allows us to control who can do what per resource.

Next, we'll register this "ability" in our ability factory.

// ability.factory.ts
import { Injectable } from '@nestjs/common';
import { AbilityBuilder, Ability } from '@casl/ability';
import { InventoryPolicy } from './policies/inventory.policy';
import { MedicalPolicy } from './policies/medical.policy';
import { OrderPolicy } from './policies/order.policy';

@Injectable()
export class AbilityFactory {
  createForUser(user) {
    const builder = new AbilityBuilder(Ability);

    InventoryPolicy(user, builder);
    MedicalPolicy(user, builder);
    OrderPolicy(user, builder);

    return builder.build();
  }
}

This is syntax that allows us to register our "abilities" to a central system provided by CASL, so we can access them anywhere in our codebase.

Next, we create an authorization guard.

We'll call this ability.guard.ts.

Your guard then becomes a clean, reusable piece of infrastructure.

// auth/casl/abilities.guard.ts
import {
  CanActivate,
  ExecutionContext,
  Injectable,
} from '@nestjs/common';
import { Reflector } from '@nestjs/core';
import { AbilityFactory } from './ability.factory';

@Injectable()
export class AbilitiesGuard implements CanActivate {
  constructor(
    private reflector: Reflector,
    private abilityFactory: AbilityFactory,
  ) {}

  canActivate(context: ExecutionContext): boolean {
    const request = context
      .switchToHttp()
      .getRequest();
    const user = request.user;
    const ability =
      this.abilityFactory.createForUser(user);
    const abilityHandler = this.reflector.get(
      'ability',
      context.getHandler(),
    );

    return abilityHandler
      ? abilityHandler(ability)
      : true;
  }
}

This ensures we authorize based on ability definitions in our controller.

We'll also create an Ability decorator.

// auth/casl/check-abilities.decorator.ts
import { SetMetadata } from '@nestjs/common';

export const CheckAbilities = (handler) =>
  SetMetadata('ability', handler);

Using CASL

Authorization at the controller level becomes very declarative.

We can now comfortably have this:

@Get(':id')
@UseGuards(AbilitiesGuard)
@CheckAbilities((ability) =>
  ability.can('read', 'Inventory'),
)
async getInventory(
  @Param('id') id: string,
) {
  return this.inventoryService.findOne(id);
}

Instead of passing a "Roles.PHARMACY" like we normally do with a Roles Guard, we check "who can actually read inventory."

Because in the future, we could want a doctor to. We may want a customer too. We could change the roles from pharmacy to something else.

This is easily feasible with our implementation.

Reusable. Maintainable. Scalable.

Now, a service protection example would look like this:

async updateInventory(
  user,
  inventoryId: string,
  updateData,
) {
  const inventory =
    await this.inventoryRepo.findOne(inventoryId);
  const ability =
    this.abilityFactory.createForUser(user);

  if (ability.cannot('update', inventory)) {
    throw new ForbiddenException(
      'You do not own this inventory record.',
    );
  }

  return this.inventoryRepo.update(
    inventoryId,
    updateData,
  );
}

I'm a solo developer who's currently a free agent — openly looking for software engineering roles. My portfolio is at www.me.soapnotes.doctor.

Thank you so much!

Senior Developer Approach to Permissions in Node.js

Emmanuel Sunday — Thu, 14 May 2026 15:37:44 +0000

So you scaffolded a blog post and handled permissions in a clean way…

Perhaps…

const isAllowedToUpdate = user.id === author.id || user.role;

const BlogPost = () => {
  return (
    <BlogPost>
      {isAllowedToUpdate && <EditBlogPost />}
    </BlogPost>
  );
};

Shocker: That was a vulnerable piece of code right there.

It shows how fragile randomly handling permissions with if/else can be.

One little oversight and you're breaking a costly business logic.

So let's fix that.

Let's be more maintainable, reusable, and scalable.

That's the purpose of this article.

Let's get right in.

The Very Basics

I was recently the backend developer for a project that involved 4 roles:

Pharmacy
Customer
Consultant
Driver

For the sake of clarity, I'll reduce the resources involved to just 3:

Inventory
Medical records
Deliveries

So here's the basics of the relationship.

Customers can:

Read all inventories
Read only Medical records assigned to them
Create orders
Read only orders they create.

Pharmacies can:

Create inventories
Read inventories, but only ones they own
Update inventories, but only ones they own
Delete inventories, but only ones they own

Consultants can:

Create medical records
Read only medical records they own
Update only medical records they own
Delete only medical records they own

Drivers can:

Read deliveries assigned to them

You may also notice something in addition to all this: consultants have no business with inventory, pharmacies have no business with deliveries, and drivers have no business with medical records — and so on.

The Fast Way

In an Express project, you could quickly put something like this together:

if (user.role === "customer") {
  // ...
}

if (user.role === "consultant" && medicalRecord.consultantId === user.id) {
  // ...
}

And even better, with middleware.

and have something as clean as this:

authorize(["consultant", "pharmacy"]);

This restricts a particular route from being accessed by any role other than those passed in.

This solves a lot of problems — it protects routes from being accessed by other roles, and quickly narrows down the scope of concern.

The Rise of Spaghetti Code

Think about a situation where the resource in question is an "order" which a customer can only create (not update or delete), a pharmacy can only read if assigned to them, a driver can only read if assigned to them, and a consultant can only read if assigned to them.

My dear brothers and sisters…

You're ending up with:

authorize(["customer", "consultant", "driver", "pharmacy"]);

Whereas you only needed each of these roles to just read "orders" assigned to them.

In a NestJS project, at this point, there's no point calling a roles guard (the Express equivalent).

Just protect the endpoint (controller) generally and move the role logic to the service.

And my dear brothers and sisters, this is how you end up with this...

if (user.role === "consultant") {
  if (record.consultantId === user.id) {
    // allow

  }
} else if (user.role === "pharmacy") {
  // ...
} else if (user.role === "driver"

Repeated 20 different places.

This is how you have permission logic bleeding directly into the route handlers.

A spaghetti code.

The Fall of Spaghetti Code

Spaghetti code is basically duplicated business logic that eventually becomes inconsistent business logic.

It's complex code with a touch of inconsistencies, tight coupling, and a lack of modularity.

If we had to implement our scenario with the previous approach, we'd have very complicated, lengthy conditions multiplied across all the necessary routes.

What's the fix?

RBAC vs ABAC

RBAC and ABAC are the primary access control models common in business apps.

RBAC (Role-Based Access Control) gives access to resources based on roles. ABAC (Attribute-Based Access Control) uses attributes to grant access to resources.

RBAC is what we're familiar with. It's what we used earlier.

Both have their edge cases, their good and bad, their upsides, and their downsides.

You get the point.

RBAC is much simpler but struggles with multiple roles and nuanced multi-tenancy applications like the one illustrated above.

ABAC is much more discreet and rigid, but can be overkill at times.

So what do we do?

We go with ABAC. It's the best for our case scenario.

Implementing ABAC

With ABAC, we move away from "Who are you?" (role) to "Are you allowed to perform this specific action on this specific object?"

There are many ways to approach ABAC, but for simplicity and the context of our scenario, I'll lay the foundation and outline the most common approach in Node.js.

The Strategy: Decouple Logic from Controllers

The core idea: instead of checking user.role everywhere, you define policies per resource that evaluate attributes — who the user is, what the resource is, and what action is being taken.

A policy can look like this:

customer: ["create:orders", "view:ownOrders"],
pharmacy: ["view:ordersAssigned"]

Roles, but with a set of defined actions they can perform, all in an array of strings.

This (string-based ABAC) works, but could even be better with Logic Map ABAC:

const policies = {
  customer: [
    { action: 'create', subject: 'Order' },
    { 
      action: 'read', 
      subject: 'Order', 
      condition: (user, order) => order.customerId === user.id 
    }
  ],
  pharmacy: [
    { 
      action: 'read', 
      subject: 'Order', 
      condition: (user, order) => order.pharmacyId === user.id 
    },
    { 
      action: 'update', 
      subject: 'Inventory', 
      condition: (user, inv) => inv.ownerId === user.id 
    }
  ]
};

The point is, there are myriad ways you can achieve this.

Just pay attention to the goal

Instead of checking user.role everywhere, you define policies per resource that evaluate attributes — who the user is, what the resource is, and what action is being taken.

For a long time, the industry standard has been CASL.

So let's talk about it.

CASL

CASL (pronounced "castle") is an isomorphic authorization JavaScript library that manages user permissions by defining what actions (read, update, delete) a user can perform on specific subjects (e.g., Article, User).

It's based on ABAC.

A CASL inventory policy setup could look like this:

export const InventoryPolicy = (user, { can }) => {
  if (user.role === 'pharmacy') {
    can('manage', 'Inventory', { pharmacyId: user.id });
  }
  if (user.role === 'customer') {
    can('read', 'Inventory');
  }
};

Based on this policy, pharmacies can only manage inventory they own, while customers can only read.

Now we need an ability.factory file.

Stay with me.

import { AbilityBuilder, Ability } from '@casl/ability';
import { InventoryPolicy } from './policies/inventory.policy';
import { MedicalPolicy } from './policies/medical.policy';
// ... import other policies

export function createAbilitiesForUser(user) {
  const builder = new AbilityBuilder(Ability);

  // We pass the user and the builder's methods to each policy
  InventoryPolicy(user, builder);
  MedicalPolicy(user, builder);
  // Add as many as you need...

  return builder.build();
}

An ability factory is used in CASL to centralize and dynamically generate a user's permissions based on their identity or role.

It centralizes all authorization rules to live in one single file.

In our case, we had to put our policies inside.

And it eventually finds a way to build a central policy with which our app (across files) works with.

For your Express project, your middleware could then look like this:

const checkPermission = (action, subject) => {
  return (req, res, next) => {
    const ability = defineAbilitiesFor(req.user);

    if (ability.can(action, subject)) {
      return next();
    }

    return res.status(403).json({ message: "Forbidden" });
  };
};

You see.

Apt.

And our route becomes as simple as:

router.post('/inventory', checkPermission('create', 'Inventory'), (req, res) => { ... });

Beautiful.

Independent of whatever goes on with our policy, what we change, and what we do.

All it knows to check is "who has the ability" to create inventory based on the created policy.

This allows for flexibility and reusability.

For instance, if we introduce an admin role tomorrow, all we have to do is add it to our policy — and everything still works perfectly.

Now, route protection alone isn't enough.

Let's also reuse this in our service:

// In your Service
async function updateInventory(user, inventoryId, updateData) {
  const inventory = await db.inventory.find(inventoryId);
  const ability = defineAbilitiesFor(user);

  // ABAC logic happens here, away from the if/else mess
  if (ability.cannot('update', inventory)) {
    throw new ForbiddenException("You do not own this inventory record.");
  }

  return db.inventory.update(inventoryId, updateData);
}

And voila.

This solves every edge case.

For instance, you may notice in our inventory policy, we had something like this...

if (user.role === 'pharmacy') {
    can('manage', 'Inventory', { pharmacyId: user.id });
  }

This means pharmacies can manage inventory as long as they own it.

So when we do this...

router.post('/inventory', checkPermission('create', 'Inventory'), (req, res) => { ... });

...we're filtering the forbidden users at the route level.

Immediately.

They never get to the service.

The Upsides

Policies live in one place. Add a role, update the policy file. Done.
Controllers stay dumb. They declare what permission is needed, not how to evaluate it.
Services stay clean. They check ability against the actual object, not the user's role string.
Business logic stays consistent. Because it only exists once.

This is also similarly beautiful for NestJS projects.

If there are requests, I could make a NestJS implementation for this.

I'm a solo developer who's currently a free agent — openly looking for software engineering roles. My portfolio is at www.me.soapnotes.doctor.

Thank you so much!

Why Do Big Websites Use Cloudflare?

Emmanuel Sunday — Wed, 15 Apr 2026 19:54:30 +0000

Okoro, this is the 25th website you're building, and you don't care to know what, why, and how Cloudflare actually works?

Wooo. Dishonor on you.

Well, on a serious note, this is the topic of the day.

Two. Three. Four.

Let's Qwiikly get started.

The Internet's Backbone

Sometime around November 2025, ChatGPT, X, Spotify, Canva, Zoom, League of Legends (literally half of the internet) went down.

But how so unanimously?

Cloudflare is your answer.

Cloudflare powers 20% of websites (really big ones).

The likes of Netflix, Discord, Shopify, Visa, etc. In numbers, this is around 200–250 million websites.

For this reason, it's very crucial and… delicate.

Every request, response, and change cascades down to these ~200 million websites.

If that means going down, so be it.

Their Love Is Unconditional

On November 18th, 2025, Cloudflare went down.

There was another outage 17 days later, in the midst of the festive season.

By February 2026, it had partially gone down again for some users.

And if we go by history lessons, I'd also mention June 21, 2022; June 24, 2019; July 17, 2020; April 14–15, 2020; etc.

History repeats itself, they say.

But here's the question you've all been tapping your feet to ask…

Why the strong affinity to this company? Aren't there competitors? Is it so vital? Is it worth it?

The Game-Changing Technology

Imagine you have a popular African delicacy (say, "Egusi Soup") that you loved during a visit to Nigeria.

You loved this soup so much that when you returned to your country, you still wanted to eat it and considered importing it.

Assuming the soup doesn't spoil, it would cost an arm, a leg, and most importantlym time to get it to your country.

But there could be one way to solve this problem.

Request that the Nigerian restaurant open a branch in your country.

Let's assume they honor this.

They get to your country, but their food tastes so good that they start receiving a ton of orders from different corners, precincts, and states.

Eventually, just like before, it may cost an arm, a leg, and most importantly, time to fulfill orders.

Well, not if they use Cloudflare.

What Cloudflare Does

Cloudflare is primarily a middleman in the web services industry.

Cloudflare's mission is to help build a better internet by providing the infrastructure that makes businesses online fast, reliable, and secure.

Here's what that means.

In our previous analogy, the first difference that employing Cloudflare would make **is this:

Cloudflare sets up a distribution system across countries. **

Across pivotal locations, it builds storefronts that equally disperse demand pressure.

The closer each location is to you, the faster you get your tasty Egusi Soup.

Cloudflare CDN

The feature that does this is the Cloudflare CDN.

Instead of a website keeping its files in one single location, Cloudflare stores copies of those files (videos, music, images) on thousands of servers worldwide.

Speed: When you click a link, Cloudflare pulls the data from the closest and most convenient server to you, making load times significantly faster.
Redundancy: If one server goes down, there are thousands of others ready to take its place.

DDoS Protection & Encryption

Cloudflare mitigated 20.5 million DDoS attacks in Q1 2025 alone (358% YoY increase)

In Q3 2025, Cloudflare blocked 8.3 million attacks (3,780/hour or ~1/second), up 15% QoQ and 40% YoY.

Cloudflare loves to set out patrols across locations to prevent abuse of services, neutralize fabricated excessive demands, and filter out bad customers.

DNS

In keeping with its commitments to speed, reliability, and security, Cloudflare also offers a DNS service.

Before you can visit a site like google.com, your computer needs to know its "address."

This is called DNS (Domain Name System), and it functions like a phone book.

So just like matching names to phone numbers, DNS matches web names to numerical IP addresses.

Cloudflare provides one of the fastest and most reliable DNS services in the world — often known by the address 1.1.1.1.

Now, the question I'll leave with you all is: why aren't there more competitors?

And that is a wrap.

Btw, I'm a solo developer who's a free agent currently — openly looking for software engineering roles. My portfolio is at www.me.soapnotes.doctor.

Thank you so much!

Data Fetching in React: The Senior Dev Approach

Emmanuel Sunday — Thu, 09 Apr 2026 22:17:25 +0000

The beauty of React is... flexibility.

In 2013, React was released as a client manipulation framework.

I know it's a library, Charlie ;)

Two years later, a young man named Michael Jackson built React Router, so React could manage full-stack applications.

But that was not enough.

Tanner Linsley built React Query to support the notion that useEffect was a bad idea for managing APIs.

The effrontery.

But this has been the beauty of React.

The flexibility to do stuff your way.

The effrontery to create a personal approach in your cabinet and call it a better approach.

This has been the beauty.

And just maybe, a downside…

Reusability in UI

React perfectly solved the problem of UI reusability.

They introduced "composition," where a component is a cocktail of JavaScript, CSS, and HTML.

Stay with me.

You create a component, and that is all you need.

Changes in your UI are a function of a state change.

Hence, UI = f(state).

This means all you have to worry about is how the "state" in your application changes, and the UI will respond appropriately.

This was pure brilliance —

and it destroyed the likes of AngularJS, BackboneJS, and EmberJS, which relied on an MVC architecture and complex jargon to manage HTML, CSS, and JS.

However, there's a problem.

The problem is that in the real world, there's more to building an app than just the UI layer.

Yes, React solved the complexity of UI, but maybe not yet for non-static sites.

Reusability in Logic

Where and how does data fetching fit into this brilliance React came with?

The earlier versions of React never had a thing like hooks.

So it was worse.

We would use UI components and class components.

...where class components handled non-UI logic (e.g., data fetching, etc.).

And UI components, like the name implies, handled UI logic.

Author's Note: These class components and their methods became the building blocks for hooks.

Let's be a little practical.

This is what fetching user data looked like in React a few years back.

Stay with me.

import React from "react";

export function withUsers(WrappedComponent) {

  return class extends React.Component {

    state = { users: [] };

    componentDidMount() {

      fetch("/api/users")
        .then(res => res.json())
        .then(data => this.setState({ users: data }));

    }

    render() {

      return <WrappedComponent users={this.state.users} {...this.props} />;

    }

  };

}

Author's Note: componentDidMount() is a "lifecycle" method available in React classes, which tracks and renders only the first instance of a component mounting. This, alongside other "lifecycle" methods, was later implemented in the useEffect hook.

import React from "react";

export default function UserList({ users }) {

  return (
    <ul>
      {users.map(u => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );

}

The first snippet is a class component, and the second is a UI component.

We put them together here…

import { withUsers } from "./withUsers";
import UserList from "./UserList";

export default withUsers(UserList);

The issue with this is that it's cumbersome.

And very error-prone.

The more you think about the above logic, the more you see bugs.

React knew better and created hooks.

They solved UI reusability, so why not solve logic reusability too?

The Advent of Hooks

In 2018, at one of the year's most prominent tech conferences, React Today and Tomorrow, Dan Abramov introduced the concept of hooks.

By February 2019, hooks were officially released with React 16.8.

This was bliss.

This was a game-changer.

We had probably solved logic reusability.

Or so we thought.

Rather than extending the React class component and calling componentDidMount, componentDidUpdate, or any other lifecycle method, we could use a single useEffect hook.

Notabene:

The useEffect hook encapsulates three class lifecycle methods:

componentDidMount – runs once when the component first appears.
componentDidUpdate – runs when props or state change.
componentWillUnmount – runs cleanup when the component is removed.

A good refactor of our data-fetching illustration using the useEffect hook could look like this…

import React, { useState, useEffect } from "react";

export default function UserList() {

  const [users, setUsers] = useState([]);

  useEffect(() => {

    fetch("/api/users")
      .then(res => res.json())
      .then(data => setUsers(data));

  }, []);

  return (
    <ul>
      {users.map(u => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );

}

Much easier on the eyes.

The Issue With useEffect

useEffect can actually get the job done for data fetching.

Yes.

And for our little illustration above, it may be sufficient if we add a few lines of code to handle loading state, error state, error reset state, race conditions during unmount, caching, cache invalidation, fallback for network failures, stale request management, and more.

Yikes!

You see, using useEffect to fetch data in React is "tutorial" code.

It works

...but there are a ton of things that could go wrong.

There are a ton of edge cases.

A supposedly better version of our illustration could look like this.

... with loading and error states, plus a filter parameter to filter users.

import React, { useState, useEffect } from "react";

export default function UserList({ filter }) {

  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {

    setLoading(true);

    fetch(`/api/users?filter=${filter}`)
      .then(res => {
        if (!res.ok) throw new Error("Network response was not ok");
        return res.json();
      })
      .then(data => setUsers(data))
      .catch(err => setError(err))
      .finally(() => setLoading(false));

  }, [filter]);

  if (loading) return <p>Loading users...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <ul>
      {users.map(u => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );

}

There are already two hidden bugs in this code.

Suppose the request throws an error the first time, and the error state beautifully handles it.

Our app will keep showing the error state even after the next successful request.

But this is an easy fix.

We initialize every request with setError(null).

Yes.

But suppose, again, a user clicks the first time and it takes so long to load that they click a second time.

Perhaps Cloudflare went down during the first request but queued it, and the second one went through.

Our requests will run into a race condition.

The second response arrives, and whenever the first one finishes loading, it interrupts.

If this is a time- or resource-sensitive request, it could be consequential.

You could get an old bank statement, an old market price, inconsistent information, rate-limited responses, and the list goes on.

Now, you could try to solve all of these problems and end up with code like this…

import React, { useState, useEffect } from "react";

export default function UserList({ filter }) {

  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {

    const controller = new AbortController(); // Create an abort controller
    const signal = controller.signal;

    setLoading(true);
    setError(null);

    fetch(`/api/users?filter=${filter}`, { signal })
      .then(res => {
        if (!res.ok) throw new Error("Network response was not ok");
        return res.json();
      })
      .then(data => setUsers(data))
      .catch(err => {
        if (err.name !== "AbortError") { // Ignore abort errors
          setError(err);
        }
      })
      .finally(() => {
        if (!signal.aborted) setLoading(false); // Only update loading if not aborted
      });

    // Cleanup function cancels fetch if component unmounts or filter changes
    return () => {
      controller.abort();
    };

  }, [filter]);

  if (loading) return <p>Loading users...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <ul>
      {users.map(u => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );

}

Even with this, if our server data changes after the component mounts, our component never updates automatically unless the filter changes again.

If the request fails due to a temporary network glitch, the fetch just errors out, and users must manually reload their tab.

There's zero caching.

No deduplication.

And even if you present this to your manager at work, they'll simply say "Abstract" — because there's a lot going on.

I could keep bringing a lot of sad paths around this for the next 5mins.

React Query In The Chat

Here's what our app would look like with React Query.

import React from "react";
import { useQuery } from "@tanstack/react-query";

export default function UserList({ filter }) {

  const { data: users = [], isLoading, error } = useQuery(
    ["users", filter],                     // Query key: unique per filter
    () => fetch(`/api/users?filter=${filter}`).then(res => {
      if (!res.ok) throw new Error("Network response was not ok");
      return res.json();
    })
  );

  if (isLoading) return <p>Loading users...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <ul>
      {users.map(u => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  );

}

Every edge cases addressed.

As Fireship, in one of its popular article puts it, React Query solves the 5 O'Clock Rule.

It reduces boilerplate to the bearest minimum.

Intelligent cache management
Automatic cache invalidation
Auto-refetching when data goes stale
Scroll position recovery
Offline support
Refetching on window focus
Dependent queries
Paginated queries
Request cancellation
Prefetching for faster experiences
Polling for real-time updates
Mutations to safely update data
Infinite scrolling support
Data selectors for efficient consumption
…and much more

React Query makes one thing fundamentally clear.

Server state and client state are fundamentally different things.

Client state — like whether a modal is open or what a user has typed into a form — lives in your app and is always up to date.
Server state, on the other hand, lives remotely, can change without your app knowing, and needs to be fetched, kept fresh, and synchronised.

Managing that with useEffect was, is, and will always be a mismatch.

React Query is the senior developer approach to data fetching in REACT.

And that is a wrap.

Uhm, btw, I'm a solo developer who's a free agent currently. Openly looking for software engineering roles. My portfolio is at www.me.soapnotes.doctor .

Thank you so much!

Composition in React: Building like a Senior React Dev

Emmanuel Sunday — Sat, 20 Dec 2025 07:26:58 +0000

Raise your hand if you've ever worked with an external UI library.

✋.

I'm a big fan of Shadcn myself.

These are the heroes front-end devs didn't ask for but need dearly.

Beautiful UIs. Quick Implementations.

Beautiful stuff.

But that's actually not the point of discussion.

Walk with me, let's do some analysis with these libraries.

React Composition

Assuming I wanted to work with a library like Shadcn, and chose to use the card components for whatever reason.

It's straightforward.

pnpm add shadcn@latest card

Now, how do I use this card component?

export function Card() {
  return (
    <Card className="w-full max-w-sm">
      <CardHeader>
        <CardTitle>Login to your account</CardTitle>
        <CardDescription>
          Enter your email below to log in to your account
        </CardDescription>
        <CardAction>
          <Button variant="link">Sign Up</Button>
        </CardAction>
      </CardHeader>
      <CardContent>
        <form>
          <div className="flex flex-col gap-6">
            <div className="grid gap-2">
              <Label htmlFor="email">Email</Label>
              <Input
                id="email"
                type="email"
                placeholder="m@example.com"
                required
              />
            </div>
            <div className="grid gap-2">
              <div className="flex items-center">
                <Label htmlFor="password">Password</Label>
                <a
                  href="#"
                  className="ml-auto inline-block text-sm underline-offset-4 hover:underline"
                >
                  Forgot your password?
                </a>
              </div>
              <Input id="password" type="password" required />
            </div>
          </div>
        </form>
      </CardContent>
      <CardFooter className="flex-col gap-2">
        <Button type="submit" className="w-full">
          Login
        </Button>
        <Button variant="outline" className="w-full">
          Login with Google
        </Button>
      </CardFooter>
    </Card>
  )
}

This is just a sign-up page.

You know what?

I checked Chakra UI and loved their card implementation even more.

Watch this…

import { Avatar, Button, Card } from "@chakra-ui/react"

const Demo = () => {
  return (
    <Card.Root width="320px">
      <Card.Body gap="2">
        <Avatar.Root size="lg" shape="rounded">
          <Avatar.Image src="https://picsum.photos/200/300" />
          <Avatar.Fallback name="Nue Camp" />
        </Avatar.Root>
        <Card.Title mt="2">Nue Camp</Card.Title>
        <Card.Description>
          This is the card body. Lorem ipsum dolor sit amet, consectetur
          adipiscing elit. Curabitur nec odio vel dui euismod fermentum.
          Curabitur nec odio vel dui euismod fermentum.
        </Card.Description>
      </Card.Body>
      <Card.Footer justifyContent="flex-end">
        <Button variant="outline">View</Button>
        <Button>Join</Button>
      </Card.Footer>
    </Card.Root>
  )
}

What did you notice common in these demos?

They have a parent component and child components that somehow come together to make things work.

….and voila…you have a card component.

Chakra UI even goes a step further to do something weird.

<Card.Root>
  <Card.Description>
  </Card.Description>
</Card.Root>

Can JSX now do dot notations?!!

How do all these work?

This whole thing is known as composition.

In React terms, it's called compound components.

This is how you build UIs for scalability, reusability, and separation of concerns.

And that's why these big UI libraries employ that.

Now, why do you use them? How do you use them? When should you use them? I'm answering all these questions in a moment.

The big question: why?

I applied to a frontend role earlier this week and was taken to the next stage of assessment.

We were told to build a checkout page and were presented with the UI on Figma.

Long story short, this is what it looks like…

Very simple.

It's also live. You can check it out: https://crypto-checkout-omega.vercel.app

Now, how do you build a checkout like this, thinking in systems?

Focus on this word…

Utility.

Inversion of Control

I'll digress a bit to talk about building a simple onboarding page.

Very simple.

if (step === 1) { ... }
else if (step === 2 && isBusiness) { ... }
else if (step === 2 && !isBusiness) { ... }
else if (step === 3 && country === 'NG') { ... }

Right?

To be fair, this is a good implementation.

...but very far from an enterprise-grade solution.

It struggles with maintainability, scalability, and reusability.

It actually looks a lot better in my illustration.

I've seen situations where this gets to 700 lines of code with so many conditions, and it becomes difficult to wrap your head around it.

Do you want to know what a Composition (Compound Components) implementation for this looks like?

<Onboarding>
  <Onboarding.Step id="account">
    <AccountSetup />
  </Onboarding.Step>

  <Onboarding.Step id="kyc">
    <KYCForm />
  </Onboarding.Step>

  <Onboarding.Step
    id="business"
    when={userType === 'business'}
  >
    <BusinessDetails />
  </Onboarding.Step>

  <Onboarding.Step
    id="bank"
    when={country === 'NG'}
  >
    <BankAccount />
  </Onboarding.Step>

  <Onboarding.Complete />
</Onboarding>

And that's basically every code.

Composition is a design pattern in which multiple components are designed to work together by sharing implicit state and behavior.

It works with something called "Inversion of control."

Inversion of Control is a design principle where the flow of control is delegated to a higher-level component, rather than being explicitly managed by the consumer.

In simpler terms:

Traditional control: You call the code
Inverted control: The code calls you

Here's what I mean…

Traditional Control…

<Checkout
  amount={5000}
  paymentMethod="card"
  onPaymentMethodChange={setMethod}
/>

Inverted Control…

<Checkout>
  <Checkout.Amount />
  <Checkout.PaymentMethods />
  <Checkout.Submit />
</Checkout>

The component "Checkout" basically handles state and logic, while you control the layout by how many "child components" you choose to put out.

If, for instance, I now want to have a forward feature, I only throw in a <Checkout.Forward /> component to handle that.

<Checkout>
  <Checkout.Amount />
  <Checkout.PaymentMethods />
  <Checkout.Submit />
  <Checkout.Forward />
</Checkout>

Say you're building a checkout page that has limited features for certain countries due to restrictions. This becomes a beauty to handle.

Utility driven

Composition becomes very useful when you're building single components that aim to be "utilitarian".

E.g., Imagine building a Card UI like Chakra UI does.

So you write

export function Card({
  title,
  subtitle,
  description,
  imageUrl,
  imageAlt,
  showHeader = true,
  showFooter = true,
  primaryActionLabel,
  onPrimaryActionClick,
  secondaryActionLabel,
  onSecondaryActionClick,
  footerText,
  isLoading,
  disabled,
  theme = 'light',
}: CardProps) {
  return (
    <div className={`card card--${theme}`}>

Hectic!

You'll have so many moving parts (that would never be enough) sent as props. So many things to remember. And yet not with much control.

At this point, Composition saves the day.

<Card theme="dark">
  <Card.Header>
    <h3>Premium Plan</h3>
    <p>Best for teams</p>
  </Card.Header>

  <Card.Image src="/plan.png" alt="Plan image" />

  <Card.Body>
    <p>Unlimited projects and advanced analytics</p>
  </Card.Body>

  <Card.Actions>
    <button>Subscribe</button>
    <button>Learn more</button>
    <small>Cancel anytime</small>
  </Card.Actions>
</Card>

Voila, that's all you need!

Implementing Compound Components

Now, let's go back to our onboarding illustration.

<Onboarding>
  <Onboarding.Step id="account">
    <AccountSetup />
  </Onboarding.Step>

  <Onboarding.Step id="kyc">
    <KYCForm />
  </Onboarding.Step>

  <Onboarding.Step
    id="business"
    when={userType === 'business'}
  >
    <BusinessDetails />
  </Onboarding.Step>

  <Onboarding.Step
    id="bank"
    when={country === 'NG'}
  >
    <BankAccount />
  </Onboarding.Step>

  <Onboarding.Complete />
</Onboarding>

Here's how we can implement this…

Onboarding.tsx

const OnboardingContext = React.createContext<any>(null);

export const Onboarding = ({ children }: { children: React.ReactNode }) => {
  const [currentStep, setCurrentStep] = React.useState(0);
// Filter steps based on "when" prop
  const steps = React.Children.toArray(children).filter(
    (child: any) => child.props.when !== false
  );

  const value = {
    currentStep,
    totalSteps: steps.length,
    next: () => setCurrentStep((s) => s + 1),
    prev: () => setCurrentStep((s) => s - 1),
  };

  return (
    <OnboardingContext.Provider value={value}>
      {steps[currentStep]}
    </OnboardingContext.Provider>
  );
};

We build a filter method that filters children with a truthy "when" prop value.

We track currentStep ID and setCurrentStep, and made sure to put it in React Context.

This allows the relevant components down the line to change the "currentStep" for themselves globally.

Step Component

Onboarding.Step = ({ children }: { children: React.ReactNode }) => {
  return <>{children}</>;
};

Complete Component

Onboarding.Complete = () => {
  return <div>🎉 Onboarding complete!</div>;
};

The most important part of this implementation is the display logic.

 {steps[currentStep]}

"steps" is an array of React children.

The index "[currentstep]" lets React know what children to display at any point.

E.g steps[0], steps[1].

Remember, every component inside the Onboarding Context Provider has access to currentSteps and setCurrentSteps, so can easily move the step of the whole onboarding.

Final usage…

<Onboarding>
  <Onboarding.Step id="account">
    <AccountSetup />
  </Onboarding.Step>

  <Onboarding.Step id="kyc">
    <KYCForm />
  </Onboarding.Step>

  <Onboarding.Step
    id="business"
    when={userType === 'business'}
  >
    <BusinessDetails />
  </Onboarding.Step>

  <Onboarding.Step
    id="bank"
    when={country === 'NG'}
  >
    <BankAccount />
  </Onboarding.Step>

  <Onboarding.Complete />
</Onboarding>

PS: If you're smart, you may notice...

<Onboarding.Complete />

...was left out.

With our current logic, it'll be left out since the "steps" array filters out React children without a truthy "when" prop value.

How do we fix this?

Let's adjust the logic a lil bit...

  const steps = React.Children.toArray(children).filter((child) => {
    if (React.isValidElement(child)) {
      // Only include Step components with when !== false
      if (child.type === Onboarding.Step) {
        return child.props.when !== false;
      }
    }
    return false;
  });

This works because every React child has a type object, which is actually the name of the component.

Hence, we can use that to explicitly sort out only the steps component, Onboarding.Step.

Back to my Interview

This is what my final parent "Checkout" component looked like

<Checkout>
      <Checkout.TransferTabs />
      <Checkout.Body>
        <Checkout.CryptoToCash when="crypto-to-cash" />
        <Checkout.CashToCrypto when="cash-to-crypto" />
        <Checkout.CryptoToFiat when="crypto-to-fiat-loan" />
      </Checkout.Body>

    </Checkout>

So how did I implement this?

Think deeply (maybe ask ChatGPT 😂).

Actually, the github repo is available @ https://github.com/ebubesunday16/crypto-checkout.

Side quest: I'm still jobhunting! Would take any job at this point. Portfolio is at https://me.soapnotes.doctor

Don't Overengineer

If it's a utilitarian component. Engineer. Not a utilitarian component? Do not engineer.

E.g., I still comfortably had this somewhere in my code…

<AmountInput 
  label='You pay'
  value={payingAmount}
  onChange={handlePayingAmountChange}
  placeholder="0.00"
  selectedCrypto={selectedPayingCrypto}
  onCryptoChange={setSelectedPayingCrypto}
/>

Unless I'm also going to build a calculator and so badly want to cling to the logic I had with it (which is beautiful, btw), there's no need to make "AmountInput" a compound component.

It has only one purpose to serve me, and not many moving parts.

Love and light. Peace ✌️

Beautiful Error Handling with Tanstack Query and Axios (The best combo??)

Emmanuel Sunday — Thu, 11 Dec 2025 20:44:19 +0000

If you've ever worked on a big project, from the ground up to a live project, one puzzle you'll undoubtedly solve is error handling.

Proper error handling becomes your eye when things go wrong.

Errors from the backend are beautifully sent to the frontend.

You easily decode each error, understand, and can tell what is wrong at every point in time.

I was recently working on a project, Ideliver.

An Uber App but for drugs with an added interface - consultations.

So we'll be handling customer management (buying of drugs, booking consultation with medical personnel, etc), pharmacy inventory (drugs management, etc), consultations (chatting, video calls, etc), and driver (maps, notifications, etc).

The stack is simple. React Native for the frontend. Express and Supabase for backend services. Tanstack Query and Axios for data fetching.

Obviously, this can easily get overwhelming.

So proper structure needs to be in place to have anything work and work properly.

Before you get lost in the wind, let's get back to our topic.

The Backend Services

We have a very simple architecture for this.

Supabase as BAAS handles auth in its entirety. Think authentication, session management, etc.

Express handles Authorization, Database querying, and every other backend service as needed.

For Express, we employ a simplified MVC architecture.

Models for handling all database operations with Supabase.

Views as service classes in the front-end.

…and controllers for business logic.

Forget about the names you don't understand.

We just use them to ensure structure and separation of concerns (beautiful CS concept) in our backend.

but stay with me…

There's the good part!

For this post, we will handle backend errors in the controllers (we'll take this up a notch with global error handling in a future article).

Basically, this sends the error object to the frontend.

Here's what a controller could look like for us.

export const completeProfile = async (req, res) => {
  try {
    const { role, userData } = req.body;

    const existingProfile = await UserProfileModel.getCustomerProfile(req.user.id);

    if (existingProfile) {
      return res.status(400).json({ 
    error: "ProfileError"
    message: "Profile already exists", 

});
    }

    const result = await UserProfileModel.createProfileWithEntity(
      req.user.id,
      role,
      userData
    );

    res.json({
      message: "Profile completed successfully",
      role,
      userId: req.user.id
    });
  } catch (error) {
        res.status(500).json({ 
    error: "ProfileError"
message: error.message 
});
  }
};

Hectic!

Let's reduce our focus to this…

  const existingProfile = await UserProfileModel.getCustomerProfile(req.user.id);

    if (existingProfile) {
      return res.status(400).json({ 
    error: "ProfileError"
    message: "Profile already exists", 

});

Assuming a user somehow managed to attempt to create a profile while they already have a profile, it should trigger an error.

An error with a 400 status code.

Simply put, our response would look like this…

{ 
    error: "ProfileError"
    message: "Profile already exists", 

}

So how do we handle this beautifully on the frontend?

Here's where all the good stuff happens with axios and Tanstack Query.

The good part: Axios

If you've never used Axios before, it's a promise-based HTTP client that makes API requests cleaner and more manageable than the native fetch API.

If you don't understand what all that means, follow me.

npm, pnpm, or yarn install axios.

Previously, you'll need to use "fetch" to make API requests.

…and it could look like this for our setup…

const completeProfile = async (payload) => {
  const res = await fetch('/profile/complete', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(payload),
  });

  if (!res.ok) {

    const errorData = await res.json().catch(() => ({}));
    throw new Error(errorData.message || 'Failed to complete profile');
  }

  return res.json();
};

With Axios, this is all you need…

const completeProfile = async (payload) => {
  const { data } = await axios.post('/profile/complete', payload);
  return data;
};

Am I clear? 😂

So what about error handling with Axios?

Axios throws an Axios Error object (we talked about throw previously!!!) internally when the status code of a response moves beyond 2xx.

Yes, a 400 status code will trigger an error.

In our case, the error looks like this…

{
  "response": {
    "status": 400,
    "data": {
      "error": "ProfileError",
      "message": "Profile already exists"
    }
  }
}

If we use fetch, we definitely need to do this…

if (!res.ok) {

    const errorData = await res.json().catch(() => ({}));
    throw new Error(errorData.message || 'Failed to complete profile');
  }

…to trigger an error, when the response is beyond 2××.

Well, Axios has simplified that already.

Tanstack Query (formerly React Query)

The error object Axios throws would usually be caught by a try and catch block if you were to follow the normal, average junior dev React routine.

This is what I mean…


const useCompleteProfile = (payload) => {
    try {

const response = await completeProfile(payload)

} catch(error){
 setErrorState(error)

}

}

But we're not junior devs, and we know better.

So we use Tanstack Query.

What is Tanstack Query?

TanStack Query is a powerful data-fetching and state-management library designed to simplify working with asynchronous data in React applications.

With TanStack Query, you no longer manage loading states, errors, retries, caching, or background refresh logic manually.

The library handles all of this automatically, allowing you to focus on building features instead of wiring data-handling boilerplate.

Yikes!

For our use case, here's what that means.

const useCompleteProfile = (payload) => {
    return useMutation({
        mutationFn: completeProfile(payload),
});
}

And in the error component we choose to use, we do something like this…

{mutation.isError && (
  <View className="bg-red-100 p-3 rounded-lg">
    <Text className="text-red-600">
      {mutation.error?.response?.data?.message}
    </Text>
  </View>
)}

Voila.

Beautiful isn't it?

We just beautifully handled the error.

This isn't in any way a thorough article that should guide you on everything you need to know about these libraries, architecture, or structure.

There is so much to them!

This is however a beautiful way to manage errors from the backend to the frontend of any project.

Explore! Thanks for reading.

throw error vs throw new error? Error handling the right way

Emmanuel Sunday — Sun, 26 Oct 2025 19:03:34 +0000

Error handling is part and parcel of good software development.

You could probably live without them if you’re building a landing page, an invitation card, and maybe (hopefully) an MVP?!.

However, if you ever want to delve deep into building world-class products, projects that stand the test of time, you need some good error-handling skills in your arsenal.

Last week, I published a helpful guide on try and catch block error.

Today, I’m in the mood (actually, a bug put me in the mood :)) to talk about “throwing errors”

Let’s get right in.

Throwing errors

I sincerely got to learn about throwing errors, playing with Supabase.

E.g, A typical fetch query to Supabase could look like this…


const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)

The error object provides information about errors encountered from your interactions with Supabase.

For example, think of fetching a column that doesn’t exist, or inputting the wrong column name in an insert request.

That obviously won’t work.

Supabase tries to let you know where the problem comes from, and they do it best with the error object.

So how do you handle this error object?

That’s where the concept of “throwing” comes in.

PS: If you don’t know what Supabase is, it’s basically a BAAS. It’s primarily known for its database services, similar to Firebase but built on PostgreSQL (the icing on the cake).

Exception

You genuinely can do whatever you want with an error object.

A younger me would probably console.log, but that’s bad practice.

Arguably, every error should raise an exception.

In other words, every error should gracefully stop a code from running.

E.g., instead of your app crashing for poor internet connectivity, your app should gracefully realize “Network connection failed” and do whatever you tell it to do.

This is exactly what the catch block in JavaScript’s “try and catch” does.

When the code in the try block fails, the catch block is gracefully executed.

This is broadly the definition of “exception.”

It stops a code and creates a backup plan.

So how does throw come into play?

Throw

Throw is a JavaScript keyword that raises an exception.

Remember, an exception stops the code from running and creates a backup plan.

Throw?

Throw raises an exception.

It tells an exception, “alright, this is the time you stop the code and do your backup thingy.”

Here’s a good example…


try {

const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)

throw error

} catch (err) {

}

At the point of “throw” there, the code stops.

Try and catch block

Throw raises an exception. It doesn’t handle the exception. A try and catch block does.

Let me illustrate again.

Look at this code,


try {

const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)

throw error

} catch (err) {

console.error(err)

}

Usually, the “throw” always looks for the nearest catch block to handle its value.

If the value is “error” (like in our case), it sends it to the catch block to handle it.

The catch block receives value via the prop.


catch (err) {

console.error(err)

}

At this point, you can console.log(), console.error, etc.

The industry standard, however, is to console.error so your browser recognizes it as an error

PS: Without a throw, catch would wait for the try block to fail before resorting to the catch block. With a throw, it immediately resorts to the catch block that moment, passing the value of the throw to the catch block prop.

I believe you better understand what this code does…


try {

const { data, error } = supabase.from(‘user_profiles’).select(‘*’).eq(user_id, ‘userId’)

throw error

} catch (err) {

console.error(err)

}

throw error vs throw New Error

So what’s the difference between throw New Error() and throw error?

The “new Error()” is the only difference.

throw new Error is basically a throw with a safety helmet.

throw could actually throw anything in reality.

Could be a string, number, or even an error object.

Here’s what I mean…


throw 'Something went wrong'; // throws a string

throw 404;                   // throws a number

throw { message: 'Bad request' }; // throws an object

Any time you throw “new Error”, it becomes the “throw new Error()” we’ve been talking about.

“new Error” is an instance of an error.

Take a deep breath.

An instance of an error, is just a fancy label that informs javascript that whatever you’re throwing is actually an “error”, so they can employ their complete arsenal of tools to combat the error.

When should use one over the other

Simply put, if a service has an error object, use…


throw error

If it doesn’t and you’re manually creating the errors labels for yourself, use…




throw new Error()

The reason is simple…

The error object from a service is most likely rich with every information you need. You most likely don't need to hamper it. Always, send the error straight to your logs. 

On the other hand, when you run a service yourself or want to handle error and their type manually, use error new Error().

______

Lastly, keep in mind, throw takes any value. String. Numbers. Objects. 

throw new Error() only takes strings.

The real reason you need a try and catch block (probing 101)

Emmanuel Sunday — Sun, 19 Oct 2025 21:56:13 +0000

A lot of junior developers always get told to “put it in the try block.”

“Use a try and catch block”

“You catch the error if the requests fail”

“It helps you avoid having a request crash out”

But without a catch block, if you look closely, we can still handle errors 🙂. Yes.

We could console.error.

Throw new Error().

We could console.log (errors).

Most “external sources” also have error objects.

So, we can technically live without them?

Or so you may think?!!!

Well, sit with me for a sec let's charter.

Exceptions (AKA Try…catch)

Introduced in the programming language CLU (a now-obscure but influential MIT language), exceptions were introduced to make code cleaner.

In 1980, Ada adopted them, then C++.

In 1995, Java made it mainstream with try, catch, and finally.

In 2025, you NEED them.

Let's get their practicality right…

Here's an “exception” implementation in JavaScript().

Python devs, inhale, exhale. Now change the catch block for “exception.” We're good now, right? (JS devs, skip)

Now, what's the significance of “exceptions" here?


try {
  const res = await fetch('/api');
  if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
  const data = await res.json();
  console.log('Data:', data);
} catch (err) {
  console.error('Request failed:', err.message);
}

A good observer could point out we are already handling errors with the “res.ok” condition. So maybe.. It's…redundant?

NB: if (!res.ok) throw new Error(HTTP error: ${res.status}); simply means… if the response is not in the 200-299 range of status code, throw an error.

Now here's the catch.

Any response whether in the 200 status code range (success) or in the 400 (server errors), are still responses.

In other words your fetch request technically went through. Whether it received and returned a failed HTTP request, is a story for another day.

But there's a thousand (I mean, more than two) reasons your fetch request will not even be made, talk more of getting a response like 500.

Network failure

Imagine a user on your app makes a request, and the next second their network trips off.

A try…catch block will gracefully resort your request to the catch block and do whatever the catch block says.

And If you had a catch block like this…

try {
  const res = await fetch('/api');
  if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
  const data = await res.json();
  console.log('Data:', data);
} catch (err) {
  console.error('Request failed:', err.message);
}

… your user gracefully knows they lost connection.

Sooo much better than a blank screen or crashed app.

…at least I think.

Ps: Here's one beauty you should know…

In our example, we said if !res.ok, throw an error.

try {
  const res = await fetch('/api');
  if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
  const data = await res.json();
  console.log('Data:', data);
} catch (err) {
  console.error('Request failed:', err.message);
}

Fun fact: “throw new Error” is a statement that raises an exception (try…catch block), and creates a new instance of error .

If that's confusing, here's what I mean…

In our case, the moment !res.ok, our code stops at the point of “throw new…” and calls the catch block.

Now when the catch block processes…

catch (err) {
  console.error('Request failed:', err.message);

…err.message has the value “HTTP error: ${res.status}” like we passed with throw new Error().

Beautiful isn't it?

Read that twice to understand better.

To simply put, throw new Error() makes your code resort to the nearest catch block in its composition, while passing a value to it.

Server errors

A fetch request may not be received for hundreds of reasons, extra common with external APIs.

The end point may be deprecated, may not be accepting your parameters, or be temporarily down.

Things happen and that's why applications need maintenance.

Try…catch could be one of those maintenance.

One thousand reasons you need a try and catch block…

I remember telling you one thousand reasons earlier on, while arrogantly giving you only two.

Here are other 998 reasons

Error Handling

Allows you to catch runtime errors instead of letting the program crash.
Ensures your application can gracefully handle unexpected situations.

Control Flow

Lets you separate normal logic from error logic.
You can decide how to respond to different errors (retry, log, notify, etc.).

Debugging

Provides access to the error object (err) so you can inspect the problem.
Makes it easier to trace, log, and fix bugs.

Consistency Across Layers

Ensures backend servers don’t crash on errors.
Helps frontend apps display user-friendly messages instead of breaking the UI.

Support for Asynchronous Code

Works with async/await to handle promises that might reject.
Consolidates multiple potential failures into one catch block.

Clean, Readable Code

Avoids messy error checking everywhere (if statements for every operation).
Makes code more structured and maintainable.

I have only 6 here. Now go and find the 992 yourself.

And if you have some here, support us in the comment section.

Have a nice day debugging!