Forem: Emmanuel Sunday

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!