DEV Community: Chinwuba

Starting the Frontend for a Full-Stack E-commerce Store (Auth Store, Axios, and Public vs. Protected Routing)

Chinwuba — Fri, 10 Jul 2026 11:49:22 +0000

With the backend for Task 1 (CodeAlpha's Full Stack Internship) done — Prisma schema, seed data, JWT auth with role-based access control, product routes, cart routes, and transactional order processing — it's time to build the frontend. This post covers the first few pieces: the Zustand auth store, the Axios instance, and the routing decisions that determine which pages are public and which require login.

Why Start With the Auth Store

Before touching a single page component, you need a place to hold the logged-in user's state that survives page refreshes and is accessible from anywhere in the component tree. That's what the Zustand store is for.

Here's the store, after going through a couple of iterations:

import { create } from "zustand";

export const useAuthStore = create((set, get) => ({
  user: JSON.parse(localStorage.getItem("user")) || null,
  token: localStorage.getItem("token") || null,

  login: (user, token) => {
    localStorage.setItem("user", JSON.stringify(user));
    localStorage.setItem("token", token);
    set({ user, token });
  },

  logout: () => {
    localStorage.removeItem("user");
    localStorage.removeItem("token");
    set({ user: null, token: null });
  },
}));

A couple of things worth calling out, because they're easy to get subtly wrong:

1. set() takes one object, not positional arguments.

An earlier draft of this store called set(user, token, role) — three separate arguments. Zustand's set function only accepts a single object (or a function returning one) that gets shallow-merged into state. Passing multiple arguments means everything after the first one is silently ignored. If you're new to Zustand coming from useState, this is a natural mistake to make, since useState's setter takes a single value directly, not an object — so the instinct to just "pass the values" carries over incorrectly.

2. Don't duplicate data that's already nested.

The Task 1 schema adds a role field to User (USER or ADMIN) that Task 3 didn't have. The first instinct might be to store it as its own top-level field in the store, separate from user:

// Don't do this
role: JSON.parse(localStorage.getItem("role")) || null,

But role already lives inside user.role. Storing it twice means you now have two sources of truth for the same value. If you ever update the user object elsewhere (say, a future profile edit) and forget to sync the standalone role field, they drift apart, and now some part of your UI is reading stale data. The fix is just not creating the duplicate in the first place — read user.role wherever you need it, and keep the store lean.

The corrected version above stores user and token only. user.role is accessed via useAuthStore((state) => state.user.role) anywhere it's needed.

The Axios Instance

Same pattern from Task 3, carried over with just a port change:

import axios from "axios";

const API = axios.create({
  baseURL: "http://localhost:3000/api",
});

API.interceptors.request.use((req) => {
  const token = localStorage.getItem("token");

  if (token) {
    req.headers.Authorization = `Bearer ${token}`;
  }

  return req;
});

export default API;

The interceptor runs before every outgoing request, checks localStorage for a token, and attaches it as a Bearer header if present. The conditional check matters — if you skip it and just do req.headers.Authorization = \Bearer ${token}`unconditionally, you'll send the literal string"Bearer null"or"Bearer undefined"` on every request from a logged-out user, which is harmless in this case since there's no route guard on the backend for those requests, but it's sloppy and will bite you the moment you add a route where a malformed header causes a different error path than a missing one.

One gotcha here worth flagging explicitly: the backend port has to match. If your Task 1 server's .env still has PORT=5000 (the default from the setup doc) but your Axios baseURL points at 3000, every request fails with a connection error that has nothing to do with your code — it just looks like your fetch calls are broken. Always confirm the .env and the Axios baseURL agree before debugging anything else.

The Routing Decision: What's Public vs. Protected

This is the part that's genuinely different from Task 3, and worth thinking through rather than copy-pasting.

In Task 3 (the project management tool), everything behind /dashboard required a login — that's expected for a private collaboration tool. But an e-commerce store is different. Real stores let you browse without an account and only ask you to log in when you're actually trying to buy something. Gating the whole app behind auth here would just be bad UX and doesn't match how e-commerce actually works.

So the routing split is:

Public, no guard: /login, /register, /products, /products/:id
Protected: /cart, /orders

The ProtectedRoute wrapper itself is unchanged from Task 3's pattern:

`javascript
const ProtectedRoute = ({ children }) => {
const token = useAuthStore((state) => state.token);

if (!token) {
return ;
}
return children;
};
`

One subtle bug that came up while wiring this: the wrapper initially pulled token from useCartStore instead of useAuthStore. Since cartStore doesn't have a token field at all, state.token silently evaluated to undefined every time — which meant !token was always true, and /cart and /orders redirected to /login even for a logged-in user. No error was thrown; it just quietly did the wrong thing. This is a good reminder that when a protected route "isn't working," check which store you're actually reading from before assuming the logic itself is wrong — a wrong import can produce exactly the same symptom as a logic bug, but the fix is completely different.

`jsx <Routes> <Route path="/login" element={<Login />} /> <Route path="/register" element={<Register />} /> <Route path="/" element={<Products />} /> <Route path="/products" element={<Products />} /> <Route path="/products/:id" element={<ProductDetail />} /> <Route path="/cart" element={ <ProtectedRoute> <Cart /> </ProtectedRoute> } /> <Route path="/orders" element={ <ProtectedRoute> <Orders /> </ProtectedRoute> } /> </Routes> `

The Reverse Guard: Redirecting Away From `/login`

ProtectedRoute solves "you need a token to see this page." But there's a mirror-image problem: a logged-in user shouldn't be able to navigate to /login or /register and see the form again. That doesn't belong in a route wrapper, though — it's page-specific logic, so it lives inside Login.jsx and Register.jsx themselves. On mount, each page checks useAuthStore((state) => state.token), and if a token exists, redirects to /products immediately instead of rendering the form.

The "Add to Cart" Consequence of Public Browsing

Making /products public has a knock-on effect worth planning for before writing ProductCard.jsx: a logged-out visitor can now reach a product page and click "Add to Cart" with no token in the store at all. There are two ways to handle that:

Let the click fire the API call anyway. It fails with a 401 from the backend's protect middleware, and you catch that in a .catch() block and redirect to /login.
Check useAuthStore((state) => state.token) inside the component before firing the request, and redirect to /login immediately if there's no token.

Option 2 is the better call. There's no wasted network round-trip, and you don't have to inspect an error response just to figure out why the request failed — you already know, because you checked first. It also means the "why can't I add this to my cart" experience for a logged-out user is instant instead of waiting on a failed request.

What's Next

With the auth store, Axios instance, and routing structure in place, the next steps are Login.jsx and Register.jsx — controlled forms that call the auth endpoints, store the result via authStore.login(), and handle the already-logged-in redirect. After that: the product listing page with debounced search, product detail with quantity selection, the cart interface, and order history.

Building an E-commerce Backend: Auth, Cart, and Transactional Orders with Prisma

Chinwuba — Wed, 08 Jul 2026 21:14:02 +0000

This is the second stage of my CodeAlpha Full Stack internship — two projects, built in a deliberate order so the patterns from the first carry forward. First was a project management tool (auth + real-time updates with Socket.io). This one is a store: products, cart, orders. Same stack — Express, Prisma, PostgreSQL, JWT — but the interesting part isn't the CRUD, it's the order-placement flow, which is the first genuinely transactional piece of logic in the whole internship.

I'll walk through the schema decisions, the auth changes from project one, and then spend most of the time on the part that actually matters: making sure an order can never be created without correctly and atomically updating stock and clearing the cart.

The schema

model User {
  id        String   @id @default(cuid())
  name      String
  email     String   @unique
  password  String
  role      String   @default("USER")
  createdAt DateTime @default(now())

  orders    Order[]
  cartItems CartItem[]
}

model Product {
  id          String   @id @default(cuid())
  name        String
  description String
  price       Float
  image       String?
  stock       Int      @default(0)
  category    String
  createdAt   DateTime @default(now())

  cartItems  CartItem[]
  orderItems OrderItem[]
}

model CartItem {
  id       String @id @default(cuid())
  quantity Int    @default(1)

  user      User    @relation(fields: [userId], references: [id])
  userId    String

  product   Product @relation(fields: [productId], references: [id])
  productId String

  @@unique([userId, productId])
}

model Order {
  id        String   @id @default(cuid())
  status    String   @default("PENDING")
  total     Float
  createdAt DateTime @default(now())

  user   User        @relation(fields: [userId], references: [id])
  userId String

  items OrderItem[]
}

model OrderItem {
  id       String @id @default(cuid())
  quantity Int
  price    Float

  order   Order   @relation(fields: [orderId], references: [id])
  orderId String

  product   Product @relation(fields: [productId], references: [id])
  productId String
}

Two decisions worth explaining, because they're easy to get wrong if you're building this for the first time.

OrderItem.price is a snapshot, not a reference. It would be tempting to skip this field and just read product.price whenever you display an order. Don't. Product prices change over time — if you don't freeze the price at the moment of purchase, every historical order silently reflects today's price instead of what the customer actually paid. OrderItem.price is a receipt. Product.price is a price tag. They're allowed to diverge, and that divergence is the whole point.

CartItem has a compound unique constraint on [userId, productId]. Without it, adding the same product to your cart twice creates two separate rows, and now your entire cart-rendering and total-calculation logic has to merge duplicates. With the constraint in place, Prisma gives you upsert — one call that either creates the row or increments the existing one, and the database itself guarantees you can never end up with two rows for the same user/product pair.

Auth: adding roles to the JWT

The auth pattern here is the same one from the project management tool — register, hash with bcrypt, sign a JWT, verify on protected routes. The one addition is role, which defaults to "USER" and is upgraded to "ADMIN" manually via Prisma Studio (there's no signup flow for creating admins — that's intentional; a store with self-service admin registration is a security bug waiting to happen).

The detail that matters: the JWT payload needs the role baked in, not just the user id.

const accessToken = jwt.sign(
  { id: user.id, role: user.role },
  process.env.ACCESS_SECRET,
  { expiresIn: "7d" }
);

Why put role in the token instead of looking it up from the database on every request? Because the entire value of a JWT is that it's self-contained — the server can verify a request is legitimate without touching the database at all. If you only put id in the payload, every admin-check becomes an extra database round-trip. Put role in at sign-time, and your admin middleware becomes a single equality check:

router.post("/", protect, (req, res, next) => {
  if (req.user.role !== "ADMIN") {
    return res.status(403).json({ message: "Admin access required" });
  }
  next();
}, createProduct);

One failure mode worth flagging because it's silent: if you forget to include role in the sign call, req.user.role is undefined everywhere downstream. undefined !== "ADMIN" still evaluates to true, so the check works in the sense that it still returns 403 — it just returns 403 to everyone, including actual admins. No error, no crash, just a completely broken feature that looks like it's functioning correctly in every log you'd check.

Cart: upsert and the stock check ordering

router.post("/cart", protect, async (req, res) => {
  const { productId, quantity } = req.body;

  try {
    const product = await prisma.product.findUnique({
      where: { id: productId },
    });

    if (!product) {
      return res.status(404).json({ message: "Product not found" });
    }

    if (product.stock < quantity) {
      return res.status(400).json({ message: "Low on stock" });
    }

    const cartItem = await prisma.cartItem.upsert({
      where: {
        userId_productId: {
          userId: req.user.id,
          productId,
        },
      },
      update: {
        quantity: { increment: quantity },
      },
      create: {
        userId: req.user.id,
        productId,
        quantity,
      },
    });

    res.status(201).json({ cartItem });
  } catch (error) {
    res.status(500).json({ message: "Something went wrong" });
  }
});

Two things about this that aren't obvious the first time you write it.

The compound key in where is named userId_productId — Prisma builds this name automatically from the field order exactly as declared in @@unique([userId, productId]). Get the order backwards (productId_userId) and Prisma throws a schema validation error immediately, which is at least a loud failure rather than a silent one.

The stock check has to happen before the upsert, as a completely separate query. It's tempting to think the upsert alone is enough — but upsert doesn't know or care about business rules like stock levels, it only knows how to match-or-create a row. If you skip the manual check, a user's cart can silently hold more units of a product than actually exist. You won't find out until the order transaction rejects it later, at which point the error is far less useful to the person who just spent five minutes filling out a cart that was never going to check out.

Deleting a cart item needs the same ownership discipline as everything else that touches user-scoped data:

router.delete("/cart/:itemId", protect, async (req, res) => {
  try {
    const del = await prisma.cartItem.deleteMany({
      where: { id: req.params.itemId, userId: req.user.id },
    });
    if (del.count === 0) {
      return res.status(404).json({ message: "Cart item not found" });
    }
    res.status(200).json({ message: "Deleted successfully" });
  } catch (error) {
    res.status(500).json({ message: "Something went wrong" });
  }
});

Note this uses deleteMany, not delete. Prisma's delete only accepts a unique identifier in its where clause — id alone, or a declared compound unique — it does not accept an arbitrary combination like { id, userId } unless that pair is itself declared as a compound unique constraint in the schema. deleteMany accepts any filter, and if the filter matches nothing (because the item belongs to someone else), it just deletes zero rows instead of throwing or, worse, deleting the wrong thing. That distinction — validation error vs. silently-correct no-op — is worth internalizing early, because it comes up constantly once you're writing ownership checks on every mutation.

Orders: the transaction

This is the part of the project that's actually hard, and it's hard for a good reason: placing an order isn't one write, it's four, and they all have to succeed together or not at all.

Fetch the user's cart with product data
Validate stock for every item
Create the order with nested order items
Decrement stock on every product
Clear the cart

If step 3 succeeds but step 4 fails, you've got an order in your database for stock that was never actually reserved — a real order for a product you can't fulfill. prisma.$transaction exists specifically to prevent this: it wraps a set of writes in a single all-or-nothing unit, so a thrown error anywhere inside rolls back everything that already happened in that block.

router.post("/orders", protect, async (req, res) => {
  try {
    const newOrder = await prisma.$transaction(async (tx) => {
      const cartItems = await tx.cartItem.findMany({
        where: { userId: req.user.id },
        include: { product: true },
      });

      if (cartItems.length === 0) {
        throw new Error("Cart is empty");
      }

      for (const item of cartItems) {
        if (item.quantity > item.product.stock) {
          throw new Error(`Not enough stock for ${item.product.name}`);
        }
      }

      const totalPrice = cartItems.reduce((sum, item) => {
        return sum + item.product.price * item.quantity;
      }, 0);

      for (const item of cartItems) {
        await tx.product.update({
          where: { id: item.productId },
          data: { stock: { decrement: item.quantity } },
        });
      }

      await tx.cartItem.deleteMany({
        where: { userId: req.user.id },
      });

      const order = await tx.order.create({
        data: {
          userId: req.user.id,
          total: totalPrice,
          items: {
            create: cartItems.map((item) => ({
              productId: item.productId,
              quantity: item.quantity,
              price: item.product.price,
            })),
          },
        },
      });

      return order;
    });

    return res.status(201).json({ order: newOrder });
  } catch (error) {
    return res.status(400).json({ message: error.message });
  }
});

A few details worth calling out explicitly, because they're the kind of thing that's easy to get subtly wrong.

Every call inside the callback uses tx, not prisma. This is the one rule that makes the whole transaction actually work as a unit — if you accidentally call prisma.product.update(...) instead of tx.product.update(...) inside the block, that write happens outside the transaction and won't roll back if a later step fails, defeating the entire purpose.

The price in OrderItem.create comes from item.product.price, fetched server-side — never from the request body. If a client could send its own price for an order item, they could send 0.01 and buy anything for a cent. The price the customer pays has to originate from data the server looked up itself.

Errors thrown inside the transaction should just throw — don't try to send an HTTP response from inside the callback. The outer catch block is the only place that should touch res. If you try to respond from inside the transaction and then let execution continue to an outer response as well, you get ERR_HTTP_HEADERS_SENT, because Node won't let you send two responses to one request.

The nested items.create takes an array, one entry per cart item — not a single object. An order with three different products needs three OrderItem rows. Trying to collapse a multi-product order into a single hardcoded create: {...} object will either throw (if you're missing required fields) or silently create an order that only remembers one of the products the customer actually bought.

Reading orders back out

router.get("/orders", protect, async (req, res) => {
  const orders = await prisma.order.findMany({
    where: { userId: req.user.id },
    include: { items: { include: { product: true } } },
    orderBy: { createdAt: "desc" },
  });
  return res.status(200).json({ orders });
});

router.get("/orders/:id", protect, async (req, res) => {
  const order = await prisma.order.findUnique({
    where: { id: req.params.id },
    include: { items: { include: { product: true } } },
  });

  if (!order) return res.status(404).json({ message: "Order not found" });
  if (order.userId !== req.user.id) {
    return res.status(403).json({ message: "Unauthorized" });
  }

  return res.status(200).json({ order });
});

The single-order route is the one place I'd flag for anyone building this: it's tempting to reach for findMany out of habit since it's what you've been using everywhere else, but you're fetching exactly one order by its own primary key, and findMany returns an array — meaning order.userId would be undefined no matter who's asking, since arrays don't have that property, only the objects inside them do. findUnique gives you the object directly, which is what the ownership check actually needs to work against.

That ownership check itself matters more than it might look — without it, any authenticated user who can guess or intercept an order id can view someone else's order details, including what they bought and how much they paid. It's a two-line check, but it's the difference between a private order history and a data leak.

What's next

Backend for the store is done — schema, auth with roles, cart, and the transactional order flow. Frontend is next: product listing with debounced search, cart UI, and order history, following the same auth patterns already wired up from the first project. Full internship repo (once complete) will be linked from my profile.

Debugging this stuff

Chinwuba — Fri, 26 Jun 2026 16:30:32 +0000

One of the biggest misconceptions beginners have is that experienced developers don't make mistakes.

The reality is the exact opposite.

Experienced developers simply know how to investigate mistakes faster.

While building a full-stack project management application with React, Zustand, Express, Prisma, PostgreSQL, Axios, and JWT authentication, I encountered dozens of small bugs.

None of them were particularly difficult.

But every single one taught an important lesson about how modern frontend applications actually work.

This article walks through those lessons.

1. React Doesn't Execute Async Effects

One of the first mistakes I made was writing:

useEffect(async () => {
  const res = await API.get("/projects");
}, []);

It looks innocent.

It even feels natural.

But React doesn't allow an async function to be passed directly into useEffect.

Why?

Because React expects the callback to either return nothing or return a cleanup function.

An async function always returns a Promise.

Instead, the correct pattern is:

useEffect(() => {
  const fetchProjects = async () => {
    const res = await API.get("/projects");
    setProjects(res.data);
  };

  fetchProjects();
}, []);

This pattern appears everywhere in React applications.

Learning it early saves a lot of frustration.

2. Defining a Function Isn't the Same as Calling It

Another bug was surprisingly simple.

I wrote:

useEffect(() => {
  const fetch = async () => {
    ...
  };
}, []);

Everything looked correct.

Except...

I never called fetch().

React happily mounted the component.

Nothing crashed.

Nothing loaded.

Sometimes bugs aren't complicated.

They're just forgotten function calls.

3. Understanding Axios Responses

Axios returns an object.

Not your data directly.

For example:

const response = await API.get("/projects");

The project array isn't inside response.

It's inside:

response.data

This mistake caused me to store the entire Axios response inside React state.

Instead of:

setProjects(response);

it should be:

setProjects(response.data);

Understanding the structure of third-party libraries is just as important as understanding JavaScript itself.

4. Why API Base URLs Matter

My Axios instance already had:

baseURL: "http://localhost:5000/api"

Yet I was making requests like:

API.get("/api/projects");

Which produced:

/api/api/projects

That tiny duplication resulted in requests hitting endpoints that didn't exist.

A simple reminder:

Know what your abstractions are already doing.

5. React Router Navigation

Initially I attempted:

const enterProject = () => {
    return <Navigate to="/projects/1" />
}

Nothing happened.

That's because <Navigate /> is a React component.

It only works during rendering.

Inside event handlers, navigation should use:

const navigate = useNavigate();

navigate("/projects/1");

React Router provides different APIs for different situations.

Choosing the wrong one silently breaks navigation.

6. Protected Routes Aren't Magic

A protected route is simply conditional rendering.

Mine looked like:

const token = useAuthStore(state => state.token);

if (!token) {
    return <Navigate to="/login" />;
}

return children;

The important realization was this:

Protected routes don't "know" whether someone is logged in.

They simply check whether authentication state exists.

If your store isn't updated correctly, the protected route behaves exactly as instructed.

7. One Incorrect Property Name Broke Authentication

This was probably my favorite debugging moment.

The backend returned:

{
    user,
    accessToken
}

My frontend expected:

const { user, token } = res.data;

Because token didn't exist, Zustand stored:

undefined

Then every protected route saw:

token === undefined

and redirected me back to login.

Nothing was wrong with React.

Nothing was wrong with Zustand.

Nothing was wrong with React Router.

The frontend and backend simply disagreed on a property name.

This reinforces an important lesson:

Frontend and backend contracts must always match.

8. Zustand Made Authentication Surprisingly Clean

One thing I really appreciated was Zustand's simplicity.

Instead of passing props through multiple components, authentication lived inside a global store.

A simplified version looked like:

{
    user,
    token,
    notifications
}

with actions like:

login()

logout()

setNotifications()

The login action simultaneously:

updated React state
stored credentials
persisted authentication

Components simply subscribed to the state they needed.

No reducers.

No boilerplate.

No unnecessary complexity.

9. Empty Data Isn't the Same as Unauthorized

While building the notification system, I initially assumed this:

"No notifications probably caused the request to fail."

Not quite.

If there are no notifications, the backend should return:

[]

with:

200 OK

Instead I received:

401 Unauthorized

Why?

Because the Navbar mounted before login.

The notification request fired immediately.

There was no JWT token.

The request failed.

The solution wasn't checking whether notifications existed.

The solution was checking whether the user was authenticated before making the request.

10. Debugging Is a Skill

Perhaps the biggest lesson from this project had nothing to do with React.

It was learning a debugging workflow.

Instead of guessing:

Check browser console.
Check Network tab.
Inspect API response.
Verify backend contract.
Inspect state.
Confirm component lifecycle.
Follow the data from database to UI.

Every bug became much easier once I stopped guessing and started tracing data.

Final Thoughts

Building software isn't about typing code as quickly as possible.

It's about understanding how data moves through a system.

In this single project I strengthened my understanding of:

React Hooks
Zustand
Axios
JWT Authentication
Protected Routes
Express APIs
Prisma
Component lifecycles
API design
Navigation
Debugging techniques

Every small bug revealed another piece of how modern web applications work.

That's what makes building projects so valuable.

Tutorials show you the happy path.

Projects teach you everything else.

If you're learning React, my biggest advice is simple:

Build something real.

The bugs will become your best teachers.

And always build and code as art

Understanding Zustand

Chinwuba — Tue, 23 Jun 2026 12:49:30 +0000

For a long time, state management felt more complicated than it needed to be.

I understood React's useState.

I understood passing props.

I understood lifting state up.

But the moment applications became larger, everything started getting messy.

Then I started learning Zustand.

At first, I was confused.

Not because Zustand was complicated.

So I decided to stop memorizing syntax and instead understand the problem Zustand was trying to solve.

This article is the explanation I wish I had when I first started learning it.

The Problem: React State Doesn't Scale Forever

Let's start with plain React.

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

Simple.

Beautiful.

No problems.

But now imagine you're building a real application.

You have:

A Navbar
A Dashboard
A Profile page
Protected routes
Notifications

All of them need access to the logged-in user.

Where do you store the user?

You might start with:

const [user, setUser] = useState(null);

Then pass it down as props.

Then:

Suddenly you're passing the same piece of data through multiple components.

Some components don't even use it.

They're just forwarding it.

This is called prop drilling.

As applications grow, prop drilling becomes frustrating.

What Zustand Actually Solves

Zustand gives your application a shared state outside React components.

Think of it like this:

Without Zustand:

Component A
↓
Component B
↓
Component C
↓
Component D

Every level passes props.

With Zustand:

   Store
  /  |  \
 /   |   \

Navbar Dashboard Profile

Every component talks directly to the store.

No middleman.

No prop drilling.

The Mental Model That Made Zustand Click

Forget the library for a moment.

A Zustand store is just:

{
state,
actions
}

State = Data

Actions = Functions that modify the data

That's it.

Example:

{
count: 0,

increment() {
count++;
}
}

Zustand simply gives React a way to access and update that object.

Creating Your First Store

Install Zustand:

npm install zustand

Create a store:

import { create } from "zustand";

const useCounterStore = create((set) => ({
  count: 0,

  increment: () =>
    set((state) => ({
      count: state.count + 1,
    })),
}));

plaintext
Notice two things:

State
count: 0
Action
increment: () => ...

plaintext
That's the entire pattern.

What Is set()?

This was one of my biggest questions.

Think of set() as Zustand's version of React's state updater.

React:

setCount(count + 1);

Zustand:

set({
  count: 1,
});

Or:

set((state) => ({
  count: state.count + 1,
}));

javascript
Whenever you want to update state, use set().

Using a Store Inside Components

function Counter() {
  const count = useCounterStore(
    (state) => state.count
  );

  const increment = useCounterStore(
    (state) => state.increment
  );

  return (
    <button onClick={increment}>
      {count}
    </button>
  );
}

javascript
Here we're selecting specific pieces of state.

This is important because Zustand only re-renders components that depend on changed values.

That's one reason it's so fast.

Building a Real Authentication Store

Let's create something closer to production.

We need:

User
Token
Notifications
Login
Logout
Initial State
user: null,
token: null,
notifications: [],

But we have a problem.

Refreshing the page resets state.

If the user refreshes:

user = null
token = null

They're logged out.

Not ideal.

Introducing localStorage

The browser provides:

localStorage

Data stored there survives page refreshes.

Save:

localStorage.setItem("token", token);

Read:

localStorage.getItem("token");

Remove:

localStorage.removeItem("token");

Why We Use JSON.stringify()

localStorage only stores strings.

This works:

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

javascript

This doesn't:

localStorage.setItem(
  "user",
  { name: "Jeffrey" }
);

javascript
Objects must become strings.

JSON.stringify(user);

When reading:

JSON.parse(
  localStorage.getItem("user")
);

plaintext

Complete Auth Store

import { create } from "zustand";

export const useAuthStore = create(
  (set) => ({
    user:
      JSON.parse(
        localStorage.getItem("user")
      ) || null,

    token:
      localStorage.getItem("token") ||
      null,

    notifications: [],

    login: (user, token) => {
      localStorage.setItem(
        "user",
        JSON.stringify(user)
      );

      localStorage.setItem(
        "token",
        token
      );

      set({ user, token });
    },

    logout: () => {
      localStorage.removeItem("user");

      localStorage.removeItem("token");

      set({
        user: null,
        token: null,
      });
    },

    setNotifications: (
      notifications
    ) => {
      set({ notifications });
    },
  })
);

javascript

Why Notifications Might Belong in Global State

This was another question I had.

Why not just keep notifications in component state?

Because notifications are usually displayed globally.

Example:

Navbar bell icon
Dashboard
Activity page
Real-time updates

Multiple unrelated components need the same data.

That's a strong sign the data belongs in a global store.

Why Not Use Cookies Instead?

Many wise developers(like me ofc) ask this.

Cookies and localStorage solve different problems.

Cookies:

Sent automatically with every request
Can expire automatically
Good for authentication when using HTTP-only cookies

localStorage:

Easy JavaScript access
Simpler API
Great for client-side persistence

Many production systems actually use:

Access Token → Memory
Refresh Token → HTTP-only Cookie

But for learning projects and many React applications, localStorage is easier to understand.

Zustand vs Redux

A quick comparison.

Redux:

dispatch({
type: "LOGIN",
payload: user,
});

Reducer:

switch(action.type) {
case "LOGIN":
}

Zustand:

That's it.

Less boilerplate.

Less configuration.

Less mental overhead.

For many projects, that's enough.

Common Beginner Mistakes

Forgetting to Return an Object

Wrong:

create((set) => {
  count: 0;
});

javascript
Correct:

create((set) => ({
  count: 0,
}));

javascript

Using Semicolons Instead of Commas

Wrong:

{
  count: 0;
  user: null;
}

javascript
Correct:

{
  count: 0,
  user: null,
}

javascript

Parsing Non-JSON Data

Wrong:

JSON.parse(
  localStorage.getItem("token")
);

If the token is already a string:

localStorage.getItem("token");

is enough.

Final Thoughts

The biggest lesson I learned wasn't a Zustand API.

It was this:

State management libraries aren't really about managing state. They're about managing complexity.

When your application grows beyond a handful of components, sharing data becomes harder than creating it.

Zustand solves that problem with an incredibly small API:

State
Actions
set()

That's essentially the whole library.

Once I stopped focusing on the syntax and started focusing on the problem, Zustand finally clicked.

And honestly, that's true for most technologies we learn as developers.

We don't learn tools by memorizing APIs.

We learn them by understanding why they exist.
Once again, write code as art.

Setting up socket.io

Chinwuba — Sun, 21 Jun 2026 18:23:53 +0000

This article covers what I learned or maybe didn't really learn.

The Problem With Traditional HTTP

Most web applications use HTTP.

The flow looks like this:

Client → Request → Server
Client ← Response ← Server

Once the server sends the response, the connection is closed.

This works perfectly for:

Authentication
CRUD operations
Fetching data
Form submissions

But what happens when the server needs to send information without being asked?

For example:

A new task is assigned
Someone comments on a task
A project status changes
A teammate updates a board

With traditional HTTP, the browser would need to keep asking:

"Anything new?"

This technique is called polling, and it's inefficient.

That's where Socket.io comes in.

What Socket.io Actually Does

Socket.io creates a persistent connection between the client and server.

Instead of repeatedly opening and closing connections, the connection stays alive.

Now communication becomes two-way:

Client ↔ Server

The client can send data whenever it wants.

The server can also send data whenever it wants.

This is what makes real-time applications possible.

Why Express Alone Isn't Enough

One thing that confused me initially was why Socket.io couldn't simply be attached directly to my Express app.

The answer lies in how Express works.

When you write:

app.listen(5000);

Express creates the HTTP server internally.

You don't have direct access to it.

Socket.io, however, needs access to the raw HTTP server.

So instead of:

app.listen(PORT);

The flow becomes:

const httpServer = createServer(app);

Then Socket.io attaches to that server:

const io = new Server(httpServer);

Finally:

httpServer.listen(PORT);

This architecture allows Socket.io and Express to share the same server.

Understanding Events

Socket.io is event-driven.

Everything revolves around two methods:

socket.emit()

and

socket.on()

Think of them as:

emit = send
on = listen

For example:

Client:

socket.emit("join-project", projectId);

Server:

socket.on("join-project", (projectId) => {
  // handle join
});

The client sends.

The server listens.

Simple.

The Concept That Made Everything Click: Rooms

The feature that finally made Socket.io make sense to me was rooms.

Imagine a walkie-talkie.

People on Channel 1 hear messages sent to Channel 1.

People on Channel 2 hear messages sent to Channel 2.

Socket.io rooms work similarly.

In my project management application:

Project A = Room A
Project B = Room B
Project C = Room C

When a user opens a project:

socket.join(projectId);

Now they're listening to updates from that project.

When someone creates a task:

io.to(projectId).emit("task-updated");

Only users in that project receive the event.

Everyone else remains unaffected.

This prevents unnecessary updates and scales much better.

Where Real-Time Events Should Be Triggered

One thing I initially misunderstood was where to emit events.

My first instinct was to put everything inside the Socket.io connection handler.

But that's not where the business logic happens.

The actual changes occur inside route handlers.

For example:

POST /tasks

creates a task.

After successfully creating the task:

Save task to database
Get Socket.io instance
Find project room
Emit update

Conceptually:

Create Task
↓
Database Success
↓
Emit Event
↓
Clients Update UI

This sequence is important.

You never want to emit an event before the database operation succeeds.

Making Socket.io Available Everywhere

Another clever pattern I learned was storing the Socket.io instance on the Express app.

app.set("io", io);

Then inside any route:

const io = req.app.get("io");

This prevents:

Circular imports
Global variables
Messy architecture

Every route can access Socket.io cleanly.

Real-World Example: Task Creation

Imagine a user creates a task.

Without Socket.io:

User A creates task
↓
Database updated
↓
User B sees nothing
↓
Must refresh page

With Socket.io:

User A creates task
↓
Database updated
↓
Server emits event
↓
User B instantly sees update

No refresh required.

That's the power of real-time communication.

Thanks for reading.

Building the Backend for a Project Management Tool — Express, Prisma, and the Mistakes I Made Along the Way

Chinwuba — Sat, 20 Jun 2026 17:22:21 +0000

I'm currently completing a Full Stack Development internship with CodeAlpha, and the first project is a collaborative project management tool. Think stripped-down Trello/Asana users create projects, invite members, organize tasks across boards, assign them, comment on them, and get real-time updates via Socket.io.
Before touching the frontend, I spent considerable time getting the backend right. This post documents exactly what I built, the patterns I now understand at a deeper level, and the specific mistakes I caught while writing every line myself.

The Stack

Express.js — HTTP server and routing
Prisma — ORM for database queries
PostgreSQL via Supabase — relational database
JWT + bcryptjs — authentication
Socket.io — real-time updates (coming in the next post)

The Schema First

Everything downstream depends on the schema being right, so this is where the thinking happened. A few decisions worth explaining:

ProjectMember as a junction table

Users and Projects have a many-to-many relationship a user can be in many projects, a project can have many users. ProjectMember is the junction table that sits between them, and it carries extra data: the user's role (OWNER or MEMBER).

prisma
model ProjectMember {
  id        String  @id @default(cuid())
  role      String  @default("MEMBER")

  user      User    @relation(fields: [userId], references: [id])
  userId    String

  project   Project @relation(fields: [projectId], references: [id])
  projectId String

  @@unique([userId, projectId])
}

The @@unique([userId, projectId]) at the bottom is a model-level constraint — it means a user can only appear once per project. It also creates a named composite key userId_projectId that Prisma exposes for lookups, which comes in useful when checking membership:

js
const checkMember = await prisma.projectMember.findUnique({
  where: {
    userId_projectId: {
      userId: req.user.id,
      projectId: id,
    },
  },
})

Tasks belong to Boards, not Projects

This is the key architectural decision for Kanban. Each board represents a column — To Do, In Progress, Done. Moving a task between columns is just updating its boardId. No status enum on the task, no column type field — the board it belongs to is its status. Clean and simple.
Board ordering

prisma
model Board {
  id    String @id @default(cuid())
  name  String
  order Int
  ...
}
The order field controls column ordering. When you query boards, you sort by order: 'asc' and columns always render in the right sequence.

The Shared Prisma Client

Ai's first instinct was to instantiate PrismaClient in every route file. That's wrong. Each instantiation opens a new connection pool — in development with hot reloading, this causes connection exhaustion fast.

The correct pattern(i don dey correct Ai sef) is one shared instance across the entire app:

js
// server/src/lib/prisma.js
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()
export default prisma

Every route file imports from here. One instance, one connection pool. This is a pattern worth internalizing early because it applies beyond Prisma — any stateful singleton (database connections, logger instances, cache clients) should be initialized once and shared.

Auth Middleware

The protect middleware guards every protected route. It reads the Authorization header, extracts the Bearer token, verifies it against the JWT secret, and attaches the decoded payload to req.user so downstream handlers can access the user's id.

js
export function protect(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1]

  if (!token) return res.status(401).json({ message: 'Not authorized' })

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET)
    req.user = payload
    next()
  } catch {
    return res.status(401).json({ message: 'Invalid token' })
  }
}

The optional chaining on req.headers.authorization?.split(' ')[1] matters. If the header doesn't exist at all, calling .split() on undefined throws a TypeError. Optional chaining short-circuits and returns undefined, which the null check then handles cleanly.

To apply it across an entire router instead of adding it to each individual route:

js
const router = Router()
router.use(protect) // applies to every route below this line

Why No Refresh Tokens

The standard auth pattern for production apps uses short-lived access tokens (15 minutes) paired with long-lived refresh tokens. When the access token expires, the client silently exchanges the refresh token for a new one without prompting the user to log in again.
Implementing this properly requires:

Storing refresh tokens in the database
A /refresh endpoint
Token rotation on every use
Storing the refresh token in an httpOnly cookie
Revocation logic for logout

For an internship project, that's meaningful infrastructure overhead with no real benefit. Instead, I set expiresIn: '7d' on the access token. The user stays logged in for a week, the token expires, they log in again. Simple, works fine at this scope.
The tradeoff is a stolen access token has a longer damage window — but for a portfolio project management app, that's not a real concern. In production systems, refresh tokens are absolutely worth implementing correctly. Here, they're over-engineering.

Project Creation with `$transaction`

Creating a project is not a single write. It's three:

Create the Project record
Create a ProjectMember record making the creator an OWNER
Create three default Board records — To Do, In Progress, Done

If the project creates successfully but the membership write fails, you have a project with no owner. If boards fail, you have a project with no columns. Either scenario is corrupted data.
prisma.$transaction wraps all three writes atomically — either all succeed together, or if any one fails, everything rolls back like nothing happened:

js
const newProject = await prisma.$transaction(async (tx) => {
  const project = await tx.project.create({
    data: { name, description }
  })

  await tx.projectMember.create({
    data: {
      userId: req.user.id,
      projectId: project.id,
      role: 'OWNER'
    }
  })

  await tx.board.createMany({
    data: [
      { projectId: project.id, name: 'To Do', order: 0 },
      { projectId: project.id, name: 'In Progress', order: 1 },
      { projectId: project.id, name: 'Done', order: 2 },
    ]
  })

  return project
})

Inside the transaction callback, you use tx instead of prisma. The tx is a transactional client — every operation through it participates in the same atomic unit. Note that createMany takes { data: [...] } as an object with a data key, not a plain array.

Prisma Relations Always Return Arrays

This one caught me during the task delete route, and it's worth highlighting because it will catch you too.
When you include a relation that's defined as RelationModel[] in your schema, Prisma always returns an array — even when you filter it down to a single record with a where clause inside the include.
I needed to check if the requesting user was a project owner. I included memberships filtered to the current user:

js
include: {
  project: {
    include: {
      memberships: {
        where: { userId: req.user.id }
      }
    }
  }
}

Then tried to access the role like this:
jsfindTask.board.project.memberships.role // undefined

That returns undefined because memberships is an array. The [] in ProjectMember[] in your schema is the tell. You always need to index into it first:

js
const membership = findTask.board.project.memberships[0]
if (!membership || membership.role !== 'OWNER') {
  return res.status(403).json({ message: 'Not authorized' })
}

The alternative is using findFirst with a where clause instead of filtering inside include — that returns a single object directly. Either approach works, just be consistent.

Authorization Logic — Getting the Conditions Right

The task delete route was the most logic-heavy. Two types of users can delete a task — the creator or a project OWNER. Everyone else gets blocked.
The condition that tripped me up was the operator choice between && and ||. The correct condition in plain English: "block if the user is NOT the creator AND they are also NOT an owner." Both conditions must be true to block.

js
if (
  findTask.createdById !== req.user.id &&
  (!membership || membership.role !== 'OWNER')
) {
  return res.status(403).json({ message: 'Not authorized' })
}

Using || instead of && would block creators who aren't owners, which is wrong. Think it through before writing authorization conditions — they're the easiest place to introduce subtle bugs that only surface in edge cases.

Route Ordering Matters

In the notifications router, I have two PATCH routes:

PATCH /read-all
PATCH /:id/read

Express matches routes top to bottom. If /:id is declared first, Express will match the string "read-all" as the id parameter and hit the wrong handler entirely. The fix is straightforward — always declare specific routes before parameterized ones.

This applies across your entire Express app too. GET /api/posts/feed must come before GET /api/posts/:id or "feed" gets treated as an id.

The Full Route Map

POST   /api/auth/register
POST   /api/auth/login

GET    /api/projects
POST   /api/projects
GET    /api/projects/:id
POST   /api/projects/:id/members
DELETE /api/projects/:id

POST   /api/boards/:boardId/tasks
PATCH  /api/tasks/:id
DELETE /api/tasks/:id

GET    /api/tasks/:taskId/comments
POST   /api/tasks/:taskId/comments

GET    /api/notifications
PATCH  /api/notifications/read-all
PATCH  /api/notifications/:id/read

All routes tested in Postman — register, login, create project, fetch projects, all working.

What's Next

Socket.io integration for real-time task and comment updates. After that, the full frontend — five pages, drag-and-drop with @dnd-kit, and the ProjectBoard component which carries most of the complexity.
The backend patterns here — the shared Prisma client, transactions, relation arrays, authorization logic — carry directly into the next two projects in this internship. Get them right once and they become instinct.

Understanding Prisma and Sql — Relationships, Schema, and Querying

Chinwuba — Fri, 19 Jun 2026 14:34:21 +0000

Part 1 — Understanding Relationships in the Schema

Before you can query, you need to understand what the schema is actually saying. Prisma uses a specific syntax to define how models relate to each other.

One-to-Many

One user has many posts. One post belongs to one user.

model User {
  id    String @id @default(cuid())
  name  String
  posts Post[]           // <-- User has many posts (array = many)
}

model Post {
  id       String @id @default(cuid())
  content  String
  author   User   @relation(fields: [authorId], references: [id])  // <-- Post belongs to one User

  authorId String // <-- This is the foreign key stored in the DB
}

What to understand here:

Post stores the foreign key (authorId) — that's always where @relation lives, on the model that "owns" the foreign key. User just has posts Post[] as a reference back, it stores nothing extra in the database for that.

When you write @relation(fields: [authorId], references: [id]) you're saying: the authorId column in this table points to the id column in the User table.

Many-to-Many (via a junction table)

One user can be a member of many projects. One project can have many members. You need a table in between.

model User {
  id          String          @id @default(cuid())
  memberships ProjectMember[]  // User has many memberships
}

model Project {
  id      String          @id @default(cuid())
  members ProjectMember[]  // Project has many memberships
}

model ProjectMember {
  id        String  @id @default(cuid())
  role      String  @default("MEMBER")

  user      User    @relation(fields: [userId], references: [id])
  userId    String

  project   Project @relation(fields: [projectId], references: [id])
  projectId String

  @@unique([userId, projectId])  // A user can only appear once per project
}

ProjectMember is the junction table. It holds foreign keys to both sides and can carry its own data (like role). @@unique([userId, projectId]) is a composite unique constraint — it means the combination of both columns must be unique. A user can appear multiple times in the table, but never twice for the same project.

Self-Referential (a model relating to itself)

This is what Follow does in a social media platform — a User follows another User.

model User {
   id String  @id @default(cuid())
  followers Follow[] @relation("Following")  // People who follow this user
  following Follow[] @relation("Follower")   // People this user follows
}

model Follow {
  id          String @id @default(cuid())

  follower    User   @relation("Follower", fields: [followerId], references: [id])
  followerId  String

  following   User   @relation("Following", fields: [followingId], references: [id])
  followingId String

  @@unique([followerId, followingId])
}

Because both sides point to User, Prisma can't figure out which is which without named relations. "Follower" and "Following" are just labels that let Prisma match up which field on User maps to which side of Follow. The names themselves don't matter, they just have to match between the model and the junction table.

Named Relations (Two Relations to the Same Model)

Same problem occurs in a Task model — a task has an assignedTo user and a createdBy user. Both point to User, so both need names:

model Task {
  assignedTo   User?   @relation("AssignedTo", fields: [assignedToId], references: [id])
  assignedToId String?

  createdBy    User    @relation("CreatedBy", fields: [createdById], references: [id])
  createdById  String
}

model User {
  assignedTasks Task[] @relation("AssignedTo")
  createdTasks  Task[] @relation("CreatedBy")
}

The question mark in the assignedTo user is to show that it's optional.
Rule: any time two fields in the same model point to the same other model, both need a name. Prisma will throw an error at migration time if you forget.

Part 2 — Reading Data (Queries)

Every read in Prisma starts with one of these:

Method	When to use it
`findMany`	Get a list of records
`findUnique`	Get exactly one record by a unique field
`findFirst`	Get the first record matching a filter

`findUnique`

Used when you're looking up by a field marked @id or @unique in the schema.

// Get user by id
const user = await prisma.user.findUnique({
  where: { id: 'some-id' }
})

// Get user by email (also @unique)
const user = await prisma.user.findUnique({
  where: { email: 'jeffrey@velto.com' }
})

// Composite unique — ProjectMember has @@unique([userId, projectId])
const membership = await prisma.projectMember.findUnique({
  where: {
    userId_projectId: {   // <-- Prisma generates this name from the field names
      userId: 'abc',
      projectId: 'xyz'
    }
  }
})

The composite unique key name is generated by joining the field names with underscores. @@unique([userId, projectId]) becomes userId_projectId. @@unique([postId, userId]) on Like becomes postId_userId.

findUnique returns null if nothing is found, it doesn't throw.

`findMany`

Gets a list. By default it returns everything. You narrow it with filters.

// All projects
const projects = await prisma.project.findMany()

// All projects ordered by name
const projects = await prisma.project.findMany({
  orderBy: { name: 'asc' }  // 'asc' or 'desc'
})

// Latest 20 posts
const posts = await prisma.post.findMany({
  orderBy: { createdAt: 'desc' },
  take: 20
})

// Posts 21-40 (pagination)
const posts = await prisma.post.findMany({
  orderBy: { createdAt: 'desc' },
  take: 20,
  skip: 20
})

`findFirst`

Like findMany but returns only the first match. Useful when you need one record but can't use findUnique because you're not filtering by a unique field.

const task = await prisma.task.findFirst({
  where: { title: 'Fix the login bug' }
})

Part 3 — `where`

where is how you filter. It maps 1:1 to SQL's WHERE clause.

Basic equality

const users = await prisma.user.findMany({
  where: { role: 'ADMIN' }
})

this returns all records with role ADMIN

Operators

Prisma wraps operators in objects:

where: {
  price: { gt: 50 }        // greater than
  price: { gte: 50 }       // greater than or equal
  price: { lt: 100 }       // less than
  price: { lte: 100 }      // less than or equal
  price: { not: 50 }       // not equal
  name: { contains: 'shoe' }             // SQL LIKE '%shoe%'
  name: { contains: 'shoe', mode: 'insensitive' }  // case-insensitive
  name: { startsWith: 'Nike' }
  name: { endsWith: 'Pro' }
  id: { in: ['id1', 'id2', 'id3'] }     // SQL IN
  id: { notIn: ['id1', 'id2'] }
}

AND, OR, NOT

// Both conditions must be true (AND is the default when you pass multiple fields)
where: {
  category: 'Electronics',
  price: { lte: 100 }
}

// Explicit OR — either condition matches
where: {
  OR: [
    { name: { contains: 'shoe', mode: 'insensitive' } },
    { description: { contains: 'shoe', mode: 'insensitive' } }
  ]
}

// NOT
where: {
  NOT: { role: 'ADMIN' }
}

// Combining them
where: {
  AND: [
    { category: 'Electronics' },
    {
      OR: [
        { name: { contains: 'phone' } },
        { name: { contains: 'laptop' } }
      ]
    }
  ]
}

Relation Filters — `some`, `every`, `none`

These are used inside where when you want to filter by properties of a related model.

// Get all projects where the current user is a member
const projects = await prisma.project.findMany({
  where: {
    members: {
      some: { userId: req.user.id }
    }
  }
})

some means "at least one related record matches this condition." This is the most common one.

// some — at least one member has role OWNER
where: { members: { some: { role: 'OWNER' } } }

// every — ALL members have role OWNER (rarely needed)
where: { members: { every: { role: 'OWNER' } } }

// none — NO members have role OWNER
where: { members: { none: { role: 'OWNER' } } }

The feed query in a social media platform uses a nested some:

// Posts from users the logged-in user follows
where: {
  author: {
    followers: {
      some: { followerId: req.user.id }
    }
  }
}

Breaking this down: you're filtering Post where the author (a User) has followers (a list of Follow records) where at least one has followerId matching the current user. That's a three-level deep filter in one where.

Conditional where (dynamic filters)

This pattern shows up in the products search route:

const { category, search } = req.query

const products = await prisma.product.findMany({
  where: {
    ...(category && { category }),           // Only add if category is provided
    ...(search && {
      OR: [
        { name: { contains: search, mode: 'insensitive' } },
        { description: { contains: search, mode: 'insensitive' } }
      ]
    })
  }
})

The spread ...(condition && { key: value }) is a JavaScript pattern — if category is undefined or empty, the spread adds nothing. If it has a value, it spreads { category: 'Electronics' } into the where object.

Part 4 — `select`

select lets you choose exactly which fields to return. Everything not listed is excluded.

// Only get id, name, email — not password, not createdAt
const user = await prisma.user.findUnique({
  where: { id: userId },
  select: {
    id: true,
    name: true,
    email: true
  }
})

You cannot use select and include at the same level at the same time. You pick one.

But you CAN use select inside an include:

const tasks = await prisma.task.findMany({
  include: {
    assignedTo: {
      select: { id: true, name: true }  // Only get id and name of the user, not their password etc.
    }
  }
})

This is the correct pattern for pulling in related data without exposing sensitive fields.

Part 5 — `include`

include tells Prisma to JOIN related data and return it nested in the result. Without it, relations just don't come back.

// Without include — you just get the task fields
const task = await prisma.task.findUnique({ where: { id } })
// Result: { id, title, description, boardId, assignedToId, createdById, ... }
// No user data, no board data, no comments

// With include
const task = await prisma.task.findUnique({
  where: { id },
  include: {
    assignedTo: true,   // Include the full User object
    board: true,        // Include the full Board object
    comments: true      // Include all Comment objects in an array
  }
})
// Result: { id, title, ..., assignedTo: { id, name, email, ... }, board: { ... }, comments: [...] }

Nested include

You can include inside an include:

const project = await prisma.project.findUnique({
  where: { id },
  include: {
    boards: {
      orderBy: { order: 'asc' },
      include: {
        tasks: {
          include: {
            assignedTo: {
              select: { id: true, name: true }
            }
          }
        }
      }
    }
  }
})

This gives you: project → boards (sorted) → tasks → assignedTo (just id and name). Three levels deep in one query.

Filtering inside include

You can put a where inside an include to filter the related records:

// Only include memberships where the user is an OWNER
include: {
  members: {
    where: { role: 'OWNER' }
  }
}

// The isFollowing trick from a social media platform — only include the Follow record if it belongs to the current user
include: {
  likes: {
    where: { userId: req.user.id }
  }
}
// If the current user liked this post, likes array has 1 item. If not, it's empty [].
// So isLiked = likes.length > 0

Part 6 — `_count`

_count gives you the count of related records without fetching them all. It's like doing a COUNT(*) in SQL without loading the actual rows.

const projects = await prisma.project.findMany({
  include: {
    _count: {
      select: {
        members: true,  // Count how many members
        boards: true    // Count how many boards
      }
    }
  }
})

// Result: { id, name, ..., _count: { members: 4, boards: 3 } }

You can combine _count with other includes:

include: {
  _count: { select: { likes: true, comments: true } },
  assignedTo: { select: { id: true, name: true } },
  comments: true
}

Part 7 — Writing Data

`create`

const user = await prisma.user.create({
  data: {
    name: 'Jeffrey',
    email: 'jeffrey@velto.com',
    password: hashedPassword
  }
})

You can create related records inline (nested writes):

// Create a project and immediately create its boards in one call
const project = await prisma.project.create({
  data: {
    name: 'Velto Website Redesign',
    boards: {
      create: [
        { name: 'To Do', order: 0 },
        { name: 'In Progress', order: 1 },
        { name: 'Done', order: 2 }
      ]
    }
  }
})

`createMany`

Creates multiple records in one database call:

await prisma.board.createMany({
  data: [
    { name: 'To Do', order: 0, projectId: project.id },
    { name: 'In Progress', order: 1, projectId: project.id },
    { name: 'Done', order: 2, projectId: project.id }
  ]
})

createMany doesn't support nested creates or return the created records by default. Use create with nested writes if you need that.

`update`

// Update a single record by unique field
await prisma.task.update({
  where: { id: taskId },
  data: { title: 'New title' }
})

Partial updates — only update what you send:

// Only update fields the client sent, ignore undefined ones
const { title, description, priority, boardId } = req.body

await prisma.task.update({
  where: { id },
  data: {
    ...(title !== undefined && { title }),
    ...(description !== undefined && { description }),
    ...(priority !== undefined && { priority }),
    ...(boardId !== undefined && { boardId })
  }
})

Atomic operations (increment/decrement without a read-then-write):

await prisma.product.update({
  where: { id: productId },
  data: { stock: { decrement: quantity } }
})

// Also available: increment, multiply, divide, set

`updateMany`

Updates all records matching a filter:

// Mark all notifications as read for this user
await prisma.notification.updateMany({
  where: { userId: req.user.id, read: false },
  data: { read: true }
})

updateMany returns { count: N } — the number of records updated.

`upsert`

Either creates or updates depending on whether the record exists. Takes three fields: where, update, create.

// Add to cart — if the user already has this product, increment quantity
const cartItem = await prisma.cartItem.upsert({
  where: {
    userId_productId: {        // Composite unique key
      userId: req.user.id,
      productId
    }
  },
  update: {
    quantity: { increment: quantity }   // Record exists — just increment
  },
  create: {
    userId: req.user.id,
    productId,
    quantity                            // Record doesn't exist — create it
  }
})

`delete`

await prisma.task.delete({ where: { id: taskId } })

`deleteMany`

// Clear the entire cart after placing an order
await prisma.cartItem.deleteMany({ where: { userId: req.user.id } })

Part 8 — Transactions (`$transaction`)

A transaction groups multiple operations so they either all succeed or all fail together. This is critical any time you're doing multiple writes that depend on each other.

const result = await prisma.$transaction(async (tx) => {
  // Use 'tx' instead of 'prisma' inside here
  const order = await tx.order.create({ data: { ... } })

  await tx.cartItem.deleteMany({ where: { userId } })

  for (const item of cartItems) {
    await tx.product.update({
      where: { id: item.productId },
      data: { stock: { decrement: item.quantity } }
    })
  }

  return order
})

If any operation inside throws an error, Prisma rolls back everything — none of it hits the database. This is how you protect against partial failures (order created but cart not cleared, or stock decremented but order creation failed).

To trigger a rollback manually, just throw inside the transaction:

const result = await prisma.$transaction(async (tx) => {
  if (cartItems.length === 0) throw new Error('Cart is empty')
  // ... rest of the logic
})

Part 9 — `orderBy`, `take`, `skip`

These work together for sorting and pagination.

// Sort by one field
orderBy: { createdAt: 'desc' }

// Sort by multiple fields
orderBy: [
  { priority: 'asc' },
  { createdAt: 'desc' }
]

// Limit results
take: 20

// Skip N records (for pagination)
// Page 1: skip 0, take 20
// Page 2: skip 20, take 20
// Page 3: skip 40, take 20
skip: (page - 1) * limit

// Sort related records inside include
include: {
  boards: {
    orderBy: { order: 'asc' }
  }
}

Part 10 — Putting It All Together

Here's a realistic "get project with everything" query that combines most of what's above:

const project = await prisma.project.findUnique({
  where: { id: projectId },
  include: {
    // All members with just the fields we need from User
    members: {
      include: {
        user: {
          select: { id: true, name: true, email: true }
        }
      }
    },
    // All boards sorted by order
    boards: {
      orderBy: { order: 'asc' },
      include: {
        tasks: {
          include: {
            // Assignee — only need id and name
            assignedTo: {
              select: { id: true, name: true }
            },
            // Comment count without loading the actual comments
            _count: {
              select: { comments: true }
            }
          }
        }
      }
    }
  }
})

// Check the user is actually a member before returning
const isMember = project.members.some(m => m.userId === req.user.id)
if (!isMember) return res.status(403).json({ message: 'Not a member' })

Quick Reference

What you want	How to do it
Filter records	`where: { field: value }`
Filter with comparison	`where: { price: { gt: 50 } }`
Text search	`where: { name: { contains: q, mode: 'insensitive' } }`
Either/or filter	`where: { OR: [...] }`
Filter by related record	`where: { relation: { some: { field: value } } }`
Include related data	`include: { relation: true }`
Include and filter related	`include: { relation: { where: { ... } } }`
Pick specific fields	`select: { id: true, name: true }`
Pick fields on included relation	`include: { relation: { select: { ... } } }`
Count related records	`include: { _count: { select: { relation: true } } }`
Sort results	`orderBy: { field: 'asc' }`
Limit results	`take: N`
Paginate	`take: N, skip: N`
Create with related records	`create: { data: { relation: { create: [...] } } }`
Add or increment (upsert)	`upsert: { where, update, create }`
Increment a number atomically	`update: { data: { stock: { decrement: 5 } } }`
Update many at once	`updateMany: { where, data }`
Delete many at once	`deleteMany: { where }`
Group multiple writes safely	`$transaction(async (tx) => { ... })`

Building Authentication and Project Creation with Express, Prisma, JWT, and Database Transactions

Chinwuba — Thu, 18 Jun 2026 19:30:28 +0000

Authentication is one of those topics that seems simple on the surface.

A user enters an email and password.

You check the credentials.

You log them in.

Done.

But once you start building a real application, you quickly discover that authentication involves security, authorization, database design, token management, middleware, and data consistency.

In this article, I'll walk through the authentication system and project creation workflow I built for a project management application using:

Node.js
Express
Prisma ORM
PostgreSQL
JWT
bcrypt

We'll cover:

Password hashing
JWT authentication
Route protection middleware
Login and registration endpoints
Prisma relationships
Authorization
Database transactions

Let's dive in.

Understanding Password Hashing

One of the most common beginner questions is:

If bcrypt hashes a password, how does it know whether the password is correct during login?

The answer is:

bcrypt never decrypts anything.

Hashing is a one-way operation.

For example:

text
password123

might become:

text
$2a$10$Y7s8J...

The hash cannot be reversed back into the original password.

During login:

User enters password
Server retrieves stored hash
bcrypt hashes the incoming password
bcrypt compares both values securely

js
const match = await bcrypt.compare(
  password,
  user.password
)

If the comparison succeeds:

js
true

The user is authenticated.

This approach ensures passwords are never stored in plaintext.

Building the Registration Endpoint

The registration flow looks like this:

Client
  ↓
POST /register
  ↓
Validate Input
  ↓
Check Existing User
  ↓
Hash Password
  ↓
Create User
  ↓
Generate JWT
  ↓
Return Response

The first step is checking whether the email already exists.
Of course the frontend will ensure that an empty form is not submitted.

const existingUser =
  await prisma.user.findUnique({
    where: { email }
  })

If a user already exists:

return res.status(400).json({
  message: "Email already exists"
})

Next, hash the password.

const hashedPassword =
  await bcrypt.hash(password, 10)

The number 10 represents the salt rounds.

Higher values increase security but require more computation.

The user can now be stored safely.

const user = await prisma.user.create({
  data: {
    name,
    email,
    password: hashedPassword
  }
})

Generating JWT Tokens

After registration, we don't want the user to immediately log in again.

Instead, we generate a token.

const token = jwt.sign(
  { id: user.id },
  process.env.JWT_SECRET,
  {
    expiresIn: "7d"
  }
)

The payload contains:

{
  id: user.id
}

The token is then returned to the client.

res.status(201).json({
  user,
  token
})

Building the Login Endpoint

Email
Password
   ↓
Find User
   ↓
Compare Password
   ↓
Generate JWT
   ↓
Return User + Token

First locate the user.

const user =
  await prisma.user.findUnique({
    where: { email }
  })

Never reveal whether the email exists.

Bad:

Email not found

Good:

Invalid credentials

This prevents attackers from enumerating valid accounts.

Next compare passwords.

const match =
  await bcrypt.compare(
    password,
    user.password
  )

If comparison fails:

return res.status(401).json({
  message: "Invalid credentials"
})

Generate the token and return the user.

Before returning, remove the password.

const {
  password: _,
  ...safeUser
} = user

This is object destructuring.

The password field is extracted and discarded.

Everything else becomes:

safeUser

Now return:

{
  user: safeUser,
  token
}

Protecting Routes with Middleware

Authentication alone isn't enough.

We also need authorization.

For example:

GET /projects

should only work for logged-in users.

This is where middleware comes in.

export function protect(
  req,
  res,
  next
) {
  const token =
    req.headers.authorization
      ?.split(" ")[1]

  if (!token) {
    return res.status(401).json({
      message: "Not authorized"
    })
  }

  try {
    const decoded =
      jwt.verify(
        token,
        process.env.JWT_SECRET
      )

    req.user = decoded

    next()
  } catch {
    return res.status(401).json({
      message: "Invalid token"
    })
  }
}

A request header looks like:

Authorization:
Bearer eyJhbG...

The middleware extracts the token.

If valid:

req.user = decoded

This allows every protected route to access:

req.user.id

Why We Query Projects Through Memberships

A user can belong to many projects.

A project can contain many users.

This is a many-to-many relationship.

Example schema:

User
 ↕
ProjectMembership
 ↕
Project

To fetch projects belonging to a user:

await prisma.project.findMany({
  where: {
    memberships: {
      some: {
        userId: req.user.id
      }
    }
  }
})

The keyword:

some

means:

At least one related record matches.

Prisma also supports:

every

and

none

for more advanced filtering.

Creating Projects Safely

Creating a project involves multiple database writes.

We need to:

Create project
Create owner membership
Create default boards

Without protection, something could fail midway.

Imagine:

Project Created
Membership Failed
Boards Not Created

Now the database contains a broken project.

To solve this, Prisma provides transactions.

await prisma.$transaction(
  async (tx) => {
    ...
  }
)

Inside the transaction:

const project =
  await tx.project.create(...)

Create owner membership.

await tx.projectMember.create(...)

Create default boards.

await tx.board.createMany(...)

Finally:

return project

If any operation fails:

ROLLBACK

Everything is undone automatically.

This is called an atomic operation.

Either all steps succeed.

Or none of them do.

Why Transactions Matter

Many beginners think transactions are only useful for banking systems.

In reality, they matter whenever multiple writes must stay consistent.

Examples:

Creating projects
Creating orders
Processing payments
Assigning team members
Booking tickets
Inventory management

If your business logic requires multiple dependent writes, transactions should be one of the first tools you consider.

Key Lessons Learned

Building authentication taught me several important lessons:

Hash passwords, never store plaintext.
JWTs authenticate users without storing session state.
Middleware keeps protected routes clean and reusable.
Authorization is different from authentication.
Prisma relation filters make querying powerful.
Transactions protect database consistency.
Security decisions often matter more than the code itself.

Authentication is often the first serious backend system developers build, and it introduces many concepts that appear throughout software engineering.

Understanding these fundamentals makes it much easier to build larger applications confidently and securely.

Thanks for reading.

Building a Project Management Tool from Scratch — Starting with the Prisma Schema

Chinwuba — Wed, 17 Jun 2026 21:17:53 +0000

I'm currently a day into Task 3 of my CodeAlpha Full Stack internship. The task: build a collaborative project management tool — think Trello — using React, Express.js, PostgreSQL, and Socket.io for real-time updates.

Before touching Express routes or React components, the first thing I had to nail was the database schema. This post is a full breakdown of the schema I designed, the reasoning behind every model, and the specific Prisma patterns that tripped me up while writing it.

If you're learning Prisma or building anything with relational data, stick around, some of this took me longer to get right than I expected.

The Stack

Backend: Express.js (Node.js with ES modules)
ORM: Prisma
Database: PostgreSQL (hosted on Neon)
Frontend: React + Vite (coming later in the series)
Real-time: Socket.io (Task 3 specific)

What the App Needs to Do

Before writing any schema, I mapped out the features:
Users can create projects and invite other users by email. Projects have boards (columns like To Do, In Progress, Done). Boards contain tasks. Tasks can be assigned to project members, have priorities and due dates, and can be commented on. The app also sends notifications when someone is assigned a task or invited to a project.
That gave me six models: User, Project, ProjectMember, Board, Task, Comment, and Notification.

The User Model

prisma
model User {
  id        String   @id @default(cuid())
  name      String
  email     String   @unique
  password  String
  createdAt DateTime @default(now())

  memberships   ProjectMember[]
  assignedTasks Task[]          @relation("AssignedTo")
  createdTasks  Task[]          @relation("CreatedBy")
  comments      Comment[]
  notifications Notification[]
}

A few things worth noting here.

@default(cuid()) generates a collision-resistant unique ID as a string — something like clx3k2j0f0000.... This is preferable to auto-incrementing integers for publicly exposed IDs because it doesn't leak information about your record count and is safe to put in URLs.

The two Task relations — assignedTasks and createdTasks — both point to the Task model. Prisma needs you to name them explicitly with @relation("AssignedTo") and @relation("CreatedBy") because it can't automatically figure out which relation is which when two fields point at the same model. If you leave the names off, Prisma throws an error during migration. You'll use these same names on the Task model to connect both sides.

The Project Model

prisma
model Project {
  id          String   @id @default(cuid())
  name        String
  description String?
  createdAt   DateTime @default(now())

  members ProjectMember[]
  boards  Board[]
}

Simple. The ? after String makes description optional — Prisma will accept null for that field. Project doesn't have a direct relation to Task, tasks live inside boards, and boards live inside projects. The hierarchy is intentional and covered in the Board section below.

The ProjectMember Model (Junction Table)

prisma
model ProjectMember {
  id   String @id @default(cuid())
  role String @default("MEMBER")

  user      User    @relation(fields: [userId], references: [id])
  userId    String

  project   Project @relation(fields: [projectId], references: [id])
  projectId String

  @@unique([userId, projectId])
}

This is a junction table — it sits between User and Project to represent a many-to-many relationship. One user can be a member of many projects. One project can have many members. You can't store that on either table alone, so you need this middle model.
What makes it more than a basic junction table is the role field. It stores whether the user is an "OWNER" or "MEMBER". This is what you'll query later when checking permissions — only owners can delete a project or remove other members.

The @@unique([userId, projectId]) at the bottom is a model-level constraint that ensures a user can only be added to a project once. Without it, you could accidentally insert duplicate membership records. If you try to create a duplicate, Prisma throws a unique constraint error which you can catch and return a 409.

On the relation syntax, every relation in Prisma requires two things: the relation field itself and the foreign key field. For userId, that looks like:

prisma
user   User   @relation(fields: [userId], references: [id])
userId String

The fields array contains the foreign key on this model. The references array contains the field it points to on the related model. Both arrays are required, leave one out and Prisma won't generate the migration.

The Board Model

prisma
model Board {
  id    String @id @default(cuid())
  name  String
  order Int

  project   Project @relation(fields: [projectId], references: [id])
  projectId String

  tasks Task[]
}

This is one of the more important design decisions in the schema. Tasks don't belong directly to a project — they belong to a board, which belongs to a project. The reason: moving a task between columns (To Do → In Progress) is just updating the task's boardId to point at a different board. That's the entire drag-and-drop mechanic on the backend. One field update. No complex logic.

The order field is an integer that controls column rendering order. When you create a project, you auto-create three boards: To Do (order 0), In Progress (order 1), Done (order 2). The frontend sorts them by order: 'asc' and renders them left to right.

The Task Model

prisma
model Task {
  id          String    @id @default(cuid())
  title       String
  description String?
  dueDate     DateTime?
  priority    String    @default("MEDIUM")
  createdAt   DateTime  @default(now())

  board   Board  @relation(fields: [boardId], references: [id])
  boardId String

  assignedTo   User?   @relation("AssignedTo", fields: [assignedToId], references: [id])
  assignedToId String?

  createdBy   User   @relation("CreatedBy", fields: [createdById], references: [id])
  createdById String

  comments Comment[]
}

The two user relations here are the most interesting part. A task has a creator (required — every task must have been created by someone) and an assignee (optional — tasks don't always need to be assigned).
For the optional relation:

prisma
assignedTo   User?   @relation("AssignedTo", fields: [assignedToId], references: [id])
assignedToId String?

The ? on User? and String? both matter. User? tells Prisma the relation itself is nullable. String? tells Prisma the foreign key column in the database can be null. You need both — one without the other causes a validation error.
For the required relation:

prisma
createdBy   User   @relation("CreatedBy", fields: [createdById], references: [id])
createdById String

No ?. Every task must have a creator.
The named relations "AssignedTo" and "CreatedBy" here must exactly match the names used on the User model. Prisma uses these names to link both sides of the relation together.

The Comment Model

prisma
model Comment {
  id        String   @id @default(cuid())
  content   String
  createdAt DateTime @default(now())

  task   Task   @relation(fields: [taskId], references: [id])
  taskId String

  author   User   @relation(fields: [authorId], references: [id])
  authorId String
}

Nothing complex here. Comments belong to a task and have an author. The relation field is named author (not user) to make intent clear and avoid ambiguity — there's already a user relation on other models. Consistent, readable naming matters especially when you're querying nested includes.

The Notification Model

prisma
model Notification {
  id        String   @id @default(cuid())
  message   String
  read      Boolean  @default(false)
  createdAt DateTime @default(now())

  user   User   @relation(fields: [userId], references: [id])
  userId String
}

Intentionally simple. A notification is just a message for a user, with a read boolean to track whether they've seen it. Notifications get created in two places: when a user is assigned a task, and when a user is invited to a project. The API has endpoints to mark individual notifications as read and to bulk-mark all as read with updateMany.

The Full Schema Together

Once all six models are written, running the migration is:

bash
npx prisma migrate dev --name init

Prisma reads the schema, diffs it against the current database state, generates SQL, and runs it. It also regenerates the Prisma Client so your type-safe queries stay in sync with the schema.
If you want to inspect the data visually:

bash
npx prisma studio

This opens a browser GUI at localhost:5555 where you can browse and edit records directly — useful when you're testing routes and want to verify data is being written correctly.

Mistakes I Made While Writing This

A few errors I ran into that are worth documenting:
Using @default(now()) on an id field. That's a DateTime default, id fields need @default(cuid()) or @default(uuid()). Easy to confuse if you're writing fast.
Forgetting the colon in references: [id]. I wrote references[id] twice before catching it. The full syntax is @relation(fields: [fieldName], references: [id]) — both keys require the colon.

Using single quotes for string defaults. Prisma requires double quotes. @default('MEMBER') throws. @default("MEMBER") works.
Forgetting relation names when two fields on a model point to the same model. If User has both assignedTasks and createdTasks, and both are Task[], Prisma can't figure out the mapping without the @relation("name") on both sides.

What's Next

Schema is done and migrated. Next up is the Express backend — auth routes, project routes, task routes, comment routes, and the Socket.io setup for real-time task updates and comments.
I'll be posting each stage as I go. If you're building something similar or just learning Prisma, the relation naming and junction table patterns in this post will come up in pretty much every relational project you build.

I Built a JWT Authentication API from Scratch with Express, Prisma & Supabase — Here's Everything I Learned

Chinwuba — Tue, 16 Jun 2026 14:44:24 +0000

I'm currently 9 weeks into a 16-week Express.js roadmap I set for myself. The goal at the end is to build a full client portal for my agency, Velto — with client login, project tracking, invoices, and Paystack payments.

This week I hit the JWT auth checkpoint. Register, login, protected routes, refresh tokens, logout. All of it from scratch, no Auth0, no Supabase magic auth, no shortcuts.

This post is everything — the concepts, the code, the mistakes, and the things most tutorials gloss over.

What is a JWT, actually?

A JWT (JSON Web Token) is a string with three base64-encoded parts separated by dots:

header.payload.signature

The header tells you the algorithm used. The payload is your actual data — userId, email, whatever you put in. The signature is the header and payload hashed together with your secret key.
Here's the critical thing most tutorials don't hammer home enough: the header and payload are not encrypted. Anyone can decode them. What they cannot do is forge the signature without your secret key. That's the entire security model. The server doesn't need to store the token or look it up in a database on every request — it just checks if the signature is valid.
Think of it like a government-issued ID. Anyone can read what's on the card. Nobody can fake the hologram.

Access Tokens vs Refresh Tokens — Why You Need Both

This is where most beginner JWT tutorials fall apart. They give you one token, store it in localStorage, call it done. That's a problem.

If you make your access token last 30 days, a stolen token is a 30-day problem. If you make it last 15 minutes, users have to log in every 15 minutes. Neither is acceptable.

The solution is two tokens:

Access token — short-lived (15 minutes). Sent with every request in the Authorization header. Small blast radius if stolen.

Refresh token — long-lived (7 days). Stored in an httpOnly cookie. Used only to get a new access token when the current one expires. Never touches localStorage.

httpOnly cookies cannot be accessed by JavaScript at all — not by your code, not by malicious scripts. This is why we use them for the refresh token. XSS attacks can't steal what they can't read.

Project Structure

jwt-auth-api/
  src/
    controllers/
      authController.js
    middleware/
      authMiddleware.js
    routes/
      authRoute.js
    app.js
    prismaClient.js
  index.js
  prisma/
    schema.prisma
  .env

]
Clean separation from the start. Controllers handle logic. Routes handle mapping. Middleware handles gatekeeping.

The Prisma Setup

One thing that burned me early: Prisma 6 changed the generator syntax. If you're on Prisma 6 and you see provider = "prisma-client" auto-generated in your schema, that generates TypeScript output files into a local folder — which Node.js can't run directly in a CommonJS project.

The fix is to use the classic generator:

js
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

This puts the compiled client in node_modules/@prisma/client where Node can find it normally. Import it like:

js
const { PrismaClient } = require('@prisma/client')

Also — if you're on Supabase free tier, use npx prisma db push instead of npx prisma migrate dev. The migrate command requires a shadow database that Supabase free tier doesn't provide. db push syncs your schema directly and is fine for development.

The User model for this project:

prisma
model User {
  id        Int      @id @default(autoincrement())
  email     String   @unique
  password  String
  createdAt DateTime @default(now())
}

One shared Prisma instance across the entire app:

js
// src/prismaClient.js
const { PrismaClient } = require('@prisma/client')
const prisma = new PrismaClient()

module.exports = prisma

Never instantiate PrismaClient in multiple files — each instance opens a connection pool. One file, one instance, export it everywhere.

The Register Route

js
async function register(req, res, next) {
  const { email, password } = req.body
  try {
    const existingUser = await prisma.user.findUnique({
      where: { email }
    })

    if (existingUser) {
      return res.status(409).json('That email is already taken')
    }

    const hash = await bcrypt.hash(password, 10)

    const newUser = await prisma.user.create({
      data: { email, password: hash }
    })

    res.status(201).json({
      userId: newUser.id,
      email: newUser.email
    })
  } catch (err) {
    next(err)
  }
}

A few things worth noting:

bcrypt.hash() is asynchronous — it returns a Promise. Forgetting await here means you store the string [object Promise] in your database. Your users will never be able to log in again because their password is now literally a Promise object.
Salt rounds of 10 is the standard. It controls how computationally expensive the hash is. Higher = more secure, slower. 10 is the industry default balance.
Never return the hashed password in your response. Return only what the client actually needs — id and email.

The Login Route

js
async function login(req, res, next) {
  const { email, password } = req.body
  try {
    const user = await prisma.user.findUnique({ where: { email } })

    if (!user) {
      return res.status(404).json('No account found with that email')
    }

    const passwordMatch = await bcrypt.compare(password, user.password)

    if (!passwordMatch) {
      return res.status(401).json('Invalid credentials')
    }

    const accessToken = jwt.sign(
      { id: user.id, email: user.email },
      process.env.JWT_SECRET,
      { expiresIn: '15m' }
    )

    const refreshToken = jwt.sign(
      { id: user.id, email: user.email },
      process.env.JWT_REFRESH_SECRET,
      { expiresIn: '7d' }
    )

    res.cookie('refreshToken', refreshToken, {
      httpOnly: true,
      sameSite: 'strict',
      maxAge: 7 * 24 * 60 * 60 * 1000
    })

    return res.status(200).json({
      id: user.id,
      email: user.email,
      accessToken
    })
  } catch (err) {
    next(err)
  }
}

bcrypt.compare() is what does the verification. You never decrypt a bcrypt hash — it's a one-way function. Instead, compare() hashes the submitted password the same way and checks if the outputs match.

Notice the two different secrets. Access token uses JWT_SECRET. Refresh token uses JWT_REFRESH_SECRET. This is intentional — if your access token secret leaks, an attacker cannot forge refresh tokens. They're completely independent.

The cookie options matter:
httpOnly: true — JavaScript cannot read this cookie. Period.
sameSite: 'strict' — the cookie is never sent on cross-site requests, which prevents CSRF attacks
maxAge — set to match the refresh token expiry so they expire together

Auth Middleware

This is the gatekeeper. Every protected route runs through this function first.

js
const jwt = require('jsonwebtoken')

function authMiddleware(req, res, next) {
  const authHeader = req.headers.authorization

  if (!authHeader) {
    return res.status(401).json('No authorization header')
  }

  const token = authHeader.split(' ')[1]

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET)
    req.user = decoded
    next()
  } catch (err) {
    return res.status(401).json('Invalid or expired token')
  }
}

module.exports = authMiddleware

The Authorization header arrives as a string: Bearer eyJhbGci.... Split on the space, grab index 1.

jwt.verify() is synchronous by default. It does two things: validates the signature and checks if the token has expired. If either fails, it throws. That's why the try/catch is essential — you can't use if (!decoded) because verify doesn't return null on failure, it throws an error.

Once verified, the decoded payload — which contains the id and email you signed in during login — gets attached to req.user. Every protected route then has access to the current user without a database lookup.

The Refresh Route

js
function refresh(req, res, next) {
  const refreshToken = req.cookies.refreshToken

  try {
    if (!refreshToken) {
      return res.status(401).json('No refresh token')
    }

    const decoded = jwt.verify(refreshToken, process.env.JWT_REFRESH_SECRET)

    const newAccessToken = jwt.sign(
      { id: decoded.id, email: decoded.email },
      process.env.JWT_SECRET,
      { expiresIn: '15m' }
    )

    return res.status(200).json(newAccessToken)
  } catch (err) {
    next(err)
  }
}

The secret rule: verify with the same secret you signed with. The refresh token was signed with JWT_REFRESH_SECRET during login, so you verify it with JWT_REFRESH_SECRET here. The new access token is signed with JWT_SECRET because that's what the auth middleware expects.

req.cookies.refreshToken — this is why cookie-parser is registered in app.js. Without it, req.cookies doesn't exist.

Logout

js
function logout(req, res) {
  res.clearCookie('refreshToken')
  res.status(200).json({ message: 'Logged out' })
}

Simple. Clear the cookie. The access token will naturally expire in 15 minutes — there's no server-side revocation needed at this stage.

The Routes

js
const express = require('express')
const router = express.Router()
const { register, login, logout, refresh } = require('../controllers/authController')
const authMiddleware = require('../middleware/authMiddleware')

router.post('/register', register)
router.post('/login', login)
router.post('/logout', logout)
router.post('/refresh', refresh)
router.get('/me', authMiddleware, (req, res) => res.json(req.user))

module.exports = router

/me is the protected route. authMiddleware sits between the route and the handler — Express runs them in order. If the middleware calls next(), the handler runs. If it returns a response, the handler never runs.

What the `.env` needs

DATABASE_URL=your_supabase_connection_string
JWT_SECRET=make_this_long_and_random
JWT_REFRESH_SECRET=make_this_different_and_also_long
PORT=3000

Generate your secrets with something like:

node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"

If you're building something similar, the thing most tutorials skip is the two-token architecture. Get that right and everything else falls into place.

Remember write code as art

JWT Authentication in Node.js: Building a Production-Ready Login System from Scratch

Chinwuba — Mon, 15 Jun 2026 21:56:51 +0000

Authentication is one of the first major milestones every backend developer encounters.

At first, it looks deceptively simple:

User enters email
User enters password
Server checks credentials
User gets logged in

But underneath that simple flow is an entire security architecture involving password hashing, token signing, cookie security, database validation, and route protection.

In this article, we'll walk through how JWT authentication actually works and how to build a complete authentication system using:

Node.js
Express
Prisma ORM
PostgreSQL
bcryptjs
jsonwebtoken
cookie-parser

By the end, you'll understand not just the code, but the reasoning behind every step.

What is JWT?

JWT stands for JSON Web Token.

It is a compact string that allows a server to verify a user's identity without storing session data on the server.

A JWT looks something like this:

xxxxx.yyyyy.zzzzz

The token consists of three sections separated by dots.

Part 1: Header

The header contains metadata.

json

{
  "alg": "HS256",
  "typ": "JWT"
}

This tells us:

Which algorithm was used
That the token is a JWT

Part 2: Payload

The payload contains claims.

json
{
  "userId": 1,
  "email": "test@example.com",
  "iat": 123456789,
  "exp": 123457789
}

Typical claims include:

User ID
Email
Roles
Permissions
Expiration dates

Important:

The payload is NOT encrypted.

Anyone can decode it.

Never store passwords or sensitive information inside a JWT payload.

Part 3: Signature

This is where security comes from.

The server combines:

text
Header + Payload + Secret Key

Then generates a cryptographic signature.

If someone modifies the payload:

json
{
  "userId": 999999,
  "role": "admin"
}

the signature becomes invalid.

The server immediately detects the tampering.

This is what makes JWT trustworthy.

The Authentication Flow

Let's walk through a complete login lifecycle.

Registration

User submits:

json
{
  "email": "user@example.com",
  "password": "password123"
}

Server:

Checks if email already exists
Hashes password
Saves user

Database stores:

Email: user@example.com
Password: $2a$10$L6...

Never:

Password: password123

Why Password Hashing Matters

Passwords should never be stored directly.

Imagine your database leaks.

If passwords are plain text:

text
password123
qwerty
admin123

Attackers instantly gain access.

Instead we hash passwords.

Using bcrypt:

const hash = await bcrypt.hash(password, 10);

Output:

$2b$10$A2K3...

The original password cannot be recovered.

Logging In

When a user logs in:

json
{
  "email": "user@example.com",
  "password": "password123"
}

The server:

Step 1

Finds the user.

js
const user = await prisma.user.findUnique({
  where: {
    email,
  },
});

Step 2

Compares passwords.

const validPassword = await bcrypt.compare(
  password,
  user.password
);

bcrypt hashes the submitted password and compares it to the stored hash.

No decryption happens.

Generating an Access Token

After successful login:

js
const accessToken = jwt.sign(
  {
    id: user.id,
    email: user.email,
  },
  process.env.JWT_SECRET,
  {
    expiresIn: "15m",
  }
);

The token now becomes proof of authentication.

Why Access Tokens Expire

Many beginners ask:

"Why not make the token last forever?"

Because stolen tokens happen.

A leaked token with:

text
expiresIn: "365d"

gives attackers a year of access.

A token with:

text
expiresIn: "15m"

limits damage significantly.

This introduces a problem:

Users would constantly need to log in again.

That's where refresh tokens come in.

Refresh Tokens

A refresh token is a long-lived token.

Example:

js
const refreshToken = jwt.sign(
  payload,
  process.env.JWT_REFRESH_SECRET,
  {
    expiresIn: "7d",
  }
);

Purpose:

Access token expires quickly
Refresh token issues new access tokens

Users stay logged in.

Security remains strong.

Why Store Refresh Tokens in Cookies?

Instead of sending refresh tokens in JSON responses:

js
res.cookie("refreshToken", refreshToken, {
  httpOnly: true,
  sameSite: "strict",
  maxAge: 7 * 24 * 60 * 60 * 1000,
});

Benefits:

httpOnly

JavaScript cannot access the cookie.

Protection against XSS attacks.

sameSite: strict

Prevents many CSRF attacks.

maxAge

Automatically expires.

Prisma Integration

A simple User model:

prisma
model User {
  id         Int      @id @default(autoincrement())
  email      String   @unique
  password   String
  createdAt  DateTime @default(now())
}

Generate client:

npx prisma generate

Push schema:

npx prisma db push

Or create migrations:

npx prisma migrate dev

The Login Controller

A typical flow:

js
1. Find user
2. Verify password
3. Generate access token
4. Generate refresh token
5. Set cookie
6. Return response

The controller becomes the central authentication orchestrator.

Protecting Routes

Authentication isn't useful until routes are protected.

Example:

http
GET /profile

Only authenticated users should access it.

This is where middleware shines.

Building Auth Middleware

Every request arrives with:

http
Authorization: Bearer eyJhbGc...

Middleware:

js
const authMiddleware = (
  req,
  res,
  next
) => {
  const authHeader =
    req.headers.authorization;

  if (!authHeader) {
    return res.status(401).json({
      message: "Unauthorized",
    });
  }

  const token =
    authHeader.split(" ")[1];

  const decoded = jwt.verify(
    token,
    process.env.JWT_SECRET
  );

  req.user = decoded;

  next();
};

What Happens During Verification?

The server checks:

Signature validity
Secret key match
Expiration date

If any check fails:

js
jwt.verify()

throws an error.

Request gets rejected.

Accessing User Data

Because middleware attached the payload:

js
req.user

controllers can access:

req.user.id
req.user.email

without querying the database again.

This is one of JWT's biggest advantages.

JWT is Stateless

Traditional sessions:

Client → Session ID
Server → Session Store

Server must remember every session.

JWT:

Client → Token
Server → Verify Token

No session storage required.

Everything needed exists inside the token.

This is called stateless authentication.

Common Mistakes Beginners Make

Storing Passwords in JWTs

Never.

JWT payloads are readable.

Forgetting Expiration

Always use:

expiresIn

Using decode() for Authentication

Wrong:

jwt.decode(token)

Decode does NOT verify.

Use:

jwt.verify(token)

for authentication.

Returning Passwords

Never send:

user.password

back to clients.

Even hashed passwords should remain private.

Real-World Authentication Architecture

A production-ready setup usually looks like:

POST /auth/register
POST /auth/login
POST /auth/logout
POST /auth/refresh
GET  /auth/me

Refresh:
Issue new access token.

Logout:
Remove refresh token.

Me:
Return current user.

This architecture powers countless SaaS applications today.

Final Thoughts

JWT authentication seems complicated at first because multiple concepts are happening simultaneously:

Password hashing
Database validation
Token generation
Cookie security
Middleware protection
Route authorization

But once you understand the flow, everything starts to click.

The key realization is this:

Authentication is not about logging users in.

Authentication is about proving identity securely on every request.

JWT, bcrypt, Prisma, and Express work together to make that possible.

Master these fundamentals and you'll have the foundation needed to build secure APIs, SaaS products, client portals, and production-grade backend systems.

As usual be write code as art

From Raw SQL Strings to Type-Safe Queries: How I Learned Prisma ORM

Chinwuba — Sun, 07 Jun 2026 17:20:06 +0000

I'm a web design agency CEO teaching myself full-stack development in public.
This is week 7 of a 16-week roadmap I built to go from React-only to full React + Express + PostgreSQL. Last week I finished Express core — routing, middleware, CORS, error handling, full CRUD with in-memory arrays. This week the arrays are gone. I'm talking to a real database now.

This post covers everything I learned about Prisma ORM — what it is, why it exists, how migrations work, how the client works, and how I wired it all into Express. I'll show you the actual code I wrote, the mistakes I made, and what clicked for me along the way.

The problem Prisma solves

Before I touch any Prisma code, I need to explain why it exists. Because if you don't understand the problem, the solution feels like unnecessary abstraction.

When you talk to PostgreSQL from Node.js without any tools, you write raw SQL as strings:

js
const result = await db.query(`SELECT * FROM projects WHERE client_id = ${clientId}`)

This works. But it has real problems that become painful at scale.
No type safety. You typed client_id — but what if the column is actually called clientId? You won't find out until runtime. Your editor has no idea what your database looks like, so it can't warn you. Every query is a guess.

No autocomplete. The result you get back is a plain JavaScript object. You're guessing the shape. Is it result.rows? result.data? Depends on the library. And the object itself carries no type information — autocomplete is completely dead.
No database history. You add a column in development, forget to add it in production, things break at the worst possible time. You need a way to track database structure changes the same way you track code changes — with version control.

Prisma solves all three. Type safety, autocomplete, and a migration system that versions your database schema like git versions your code.

What Prisma actually is

Prisma is an ORM — Object Relational Mapper. It sits between your Express app and your PostgreSQL database. Instead of writing SQL strings, you write JavaScript. Prisma translates that JavaScript into the correct SQL and executes it.
But it's not just a query translator. It has three distinct parts that work together:

Prisma Schema — a single file where you describe your entire database structure. Tables, columns, data types, relationships. Your entire database in one place.
Prisma Migrate — a CLI tool that reads your schema, compares it to the current state of your database, and generates the SQL needed to bring them in sync. Every change is saved as a migration file — a permanent record of how your database evolved.
Prisma Client — an auto-generated, fully typed JavaScript client. Once your schema is defined, Prisma generates a client that knows exactly what your database looks like. Your editor knows your tables, your columns, their types. Full autocomplete, full type safety.

Project setup

I'm using Node.js with CommonJS (require/module.exports), Express, and Supabase for my PostgreSQL database.

bash
mkdir prisma-project && cd prisma-project
npm init -y
npm install express dotenv cors
npm install prisma @prisma/client
npx prisma init

npx prisma init creates two things: a prisma/ folder with a schema.prisma file, and a .env file at the root with a DATABASE_URL placeholder.

I replaced that placeholder with my Supabase connection string from Settings → Database → Connection string → URI.

One issue I hit: I had a prisma.config.ts file auto-generated by Prisma 6 that was intercepting my .env loading. The error was: "Prisma config detected, skipping environment variable loading." Deleting prisma.config.ts fixed it immediately.

The Schema

Everything in Prisma starts with prisma/schema.prisma. This file is your single source of truth for the database.

prisma
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Client {
  id        Int       @id @default(autoincrement())
  name      String
  email     String    @unique
  createdAt DateTime  @default(now())
  projects  Project[]
}

model Project {
  id        Int      @id @default(autoincrement())
  title     String
  status    String   @default("active")
  createdAt DateTime @default(now())
  clientId  Int
  client    Client   @relation(fields: [clientId], references: [id])
}

Let me break this down piece by piece.
model maps to a database table. Each field inside is a column. The type after the field name (String, Int, DateTime) is Prisma's type system — it maps to the correct PostgreSQL type automatically.

The @ decorators are modifiers:

@id — marks this field as the primary key
@default(autoincrement()) — the database auto-generates an incrementing integer
@unique — no two rows can share this value
@default(now()) — auto-fills with the current timestamp on insert
@default("active") — sets a literal string default

The last two lines of the Project model are the foreign key relationship:

prisma
clientId  Int
client    Client   @relation(fields: [clientId], references: [id])

clientId is the actual column in the database — an integer that stores the id of the related client. The client field below it is not a column — it's a virtual relation field that tells Prisma how to do the join. fields: [clientId] is the foreign key on this model. references: [id] is the primary key it points to on Client.

The projects Project[] field on the Client model is the other side of the same relation — it tells Prisma that one client can have many projects. Again, not a column. Just a relation definition.

Migrations

Once the schema is written, I ran:

bash
npx prisma migrate dev --name init

Prisma reads the schema, generates the SQL to create both tables with the correct columns, constraints, and foreign keys, executes it against my Supabase database, and saves the generated SQL as a migration file in prisma/migrations/.

That migration file is committed to git alongside your code. Every subsequent schema change — adding a column, renaming a field, adding a new model — gets its own migration. You always have a full history of how your database structure evolved.
After the migration ran, both tables appeared in my Supabase dashboard with the correct structure.

The Prisma Client singleton

After migration, I ran npx prisma generate (migrate dev does this automatically). This generates the typed client based on my schema.

The critical thing about Prisma Client: it should be a singleton. Creating a new PrismaClient() in every file that needs database access will open a new connection pool each time, which exhausts your database connections quickly.

The solution is one file that creates the instance and exports it:

js
// lib/prisma.js
const { PrismaClient } = require("@prisma/client")
const prisma = new PrismaClient()

module.exports = prisma

Every route file imports from here. One instance, shared across the whole app.

The routes

My project structure:

prisma-project/
├── lib/
│   └── prisma.js
├── routes/
│   ├── clients.js
│   └── projects.js
└── index.js

clients.js

js
const prisma = require("../lib/prisma")
const express = require("express")
const router = express.Router()

router.post("/", async (req, res, next) => {
  try {
    const { name, email } = req.body
    const newClient = await prisma.client.create({
      data: { name, email }
    })
    res.status(201).json(newClient)
  } catch (err) {
    next(err)
  }
})

router.get("/", async (req, res, next) => {
  try {
    const clients = await prisma.client.findMany()
    res.json(clients)
  } catch (err) {
    next(err)
  }
})

module.exports = router

projects.js

js
const express = require("express")
const prisma = require("../lib/prisma")
const router = express.Router()

router.post("/", async (req, res, next) => {
  try {
    const { title, clientId } = req.body
    const newProject = await prisma.project.create({
      data: { title, clientId }
    })
    res.status(201).json(newProject)
  } catch (err) {
    next(err)
  }
})

router.get("/", async (req, res, next) => {
  try {
    const projects = await prisma.project.findMany({
      include: { client: true }
    })
    res.json(projects)
  } catch (err) {
    next(err)
  }
})

router.put("/:id", async (req, res, next) => {
  const { status } = req.body
  const projectId = Number(req.params.id)
  try {
    const updated = await prisma.project.update({
      where: { id: projectId },
      data: { status }
    })
    res.json(updated)
  } catch (err) {
    next(err)
  }
})

router.delete("/:id", async (req, res, next) => {
  const projectId = Number(req.params.id)
  try {
    await prisma.project.delete({
      where: { id: projectId }
    })
    res.json({ message: `Project ${projectId} deleted successfully` })
  } catch (err) {
    next(err)
  }
})

module.exports = router

A few things worth noting:
prisma.project.create takes a data object — the fields you want to write. Fields with defaults (status, createdAt) don't need to be included.

prisma.project.findMany with include: { client: true } performs a JOIN under the hood and returns the client object nested inside each project. One line of JavaScript, no SQL join syntax.

prisma.project.update and prisma.project.delete both take a where clause to identify which record to target. where: { id: projectId } maps to WHERE id = $1 in SQL.

req.params.id is always a string — I wrapped it with Number() before passing it to Prisma since the schema expects an Int.

index.js

js
require("dotenv").config()
const cors = require("cors")
const express = require("express")
const clientRouter = require("./routes/clients")
const projectRouter = require("./routes/projects")

const app = express()
const PORT = process.env.PORT || 5000

app.use(express.json())
app.use(cors({ origin: "*" }))
app.use("/clients", clientRouter)
app.use("/projects", projectRouter)

function errMiddleware(err, req, res, next) {
  res.status(err.status || 500).json({
    statusCode: err.status || 500,
    message: err.message || "Something went wrong"
  })
}

app.use(errMiddleware)

app.listen(PORT, () => {
  console.log(`App running on port ${PORT}`)
})

One routing mistake I made: I defined routes as router.post("/clients", ...) inside the router file while also mounting at app.use("/clients", router) in index.js. That made the actual endpoint /clients/clients. The fix is to use "/" inside the router file since the prefix already lives in

index.js.

The error middleware has the 4-argument signature (err, req, res, next) — Express identifies error middleware by that fourth argument. It must be registered after all routes. err.status || 500 ensures you always send a valid status code even if the error object doesn't carry one.

Testing in Postman

All 6 routes tested and working:

POST /clients → returns created client with auto-generated id and timestamp
GET /clients → returns array of all clients
POST /projects → returns created project with status: "active" auto-filled
GET /projects → returns all projects with nested client object from the JOIN
PUT /projects/1 → returns updated project with new status
DELETE /projects/1 → returns success message

Building in public. Sharing everything.

DEV Community: Chinwuba

Starting the Frontend for a Full-Stack E-commerce Store (Auth Store, Axios, and Public vs. Protected Routing)

Why Start With the Auth Store

The Axios Instance

The Routing Decision: What's Public vs. Protected

The Reverse Guard: Redirecting Away From /login

The "Add to Cart" Consequence of Public Browsing

What's Next

Building an E-commerce Backend: Auth, Cart, and Transactional Orders with Prisma

The schema

Auth: adding roles to the JWT

Cart: upsert and the stock check ordering

Orders: the transaction

Reading orders back out

What's next

Debugging this stuff

1. React Doesn't Execute Async Effects

2. Defining a Function Isn't the Same as Calling It

3. Understanding Axios Responses

4. Why API Base URLs Matter

5. React Router Navigation

6. Protected Routes Aren't Magic

7. One Incorrect Property Name Broke Authentication

8. Zustand Made Authentication Surprisingly Clean

9. Empty Data Isn't the Same as Unauthorized

10. Debugging Is a Skill

Final Thoughts

Understanding Zustand

The Problem: React State Doesn't Scale Forever

What Zustand Actually Solves

What Is set()?

Using a Store Inside Components

Building a Real Authentication Store

Introducing localStorage

Why We Use JSON.stringify()

Complete Auth Store

Why Notifications Might Belong in Global State

Why Not Use Cookies Instead?

Common Beginner Mistakes

Setting up socket.io

The Problem With Traditional HTTP

What Socket.io Actually Does

Why Express Alone Isn't Enough

Understanding Events

The Concept That Made Everything Click: Rooms

Where Real-Time Events Should Be Triggered

Making Socket.io Available Everywhere

Real-World Example: Task Creation

Building the Backend for a Project Management Tool — Express, Prisma, and the Mistakes I Made Along the Way

The Stack

The Schema First

ProjectMember as a junction table

Tasks belong to Boards, not Projects

The Shared Prisma Client

Auth Middleware

Why No Refresh Tokens

Project Creation with $transaction

Prisma Relations Always Return Arrays

Authorization Logic — Getting the Conditions Right

Route Ordering Matters

What's Next

Understanding Prisma and Sql — Relationships, Schema, and Querying

Part 1 — Understanding Relationships in the Schema

One-to-Many

Many-to-Many (via a junction table)

Self-Referential (a model relating to itself)

Named Relations (Two Relations to the Same Model)

Part 2 — Reading Data (Queries)

findUnique

findMany

findFirst

Part 3 — where

Basic equality

Operators

AND, OR, NOT

Relation Filters — some, every, none

Conditional where (dynamic filters)

Part 4 — select

Part 5 — include

Nested include

The Reverse Guard: Redirecting Away From `/login`

Project Creation with `$transaction`

`findUnique`

`findMany`

`findFirst`

Part 3 — `where`

Relation Filters — `some`, `every`, `none`

Part 4 — `select`

Part 5 — `include`

Part 6 — `_count`

`create`

`createMany`

`update`

`updateMany`

`upsert`

`delete`

`deleteMany`

Part 8 — Transactions (`$transaction`)

Part 9 — `orderBy`, `take`, `skip`

What the `.env` needs