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.