Forem: Voke

Building in Public: CV Analyzer - Closure

Voke — Mon, 09 Feb 2026 04:22:00 +0000

This series pauses here.

The CV Analyzer MERN app has been completed and converted into a portfolio project with a full demo.

As development progressed, implementation began to outpace the write-up cadence, so I shifted focus to shipping the product end-to-end.

Full demo video: https://youtu.be/ZZ2YzTXDOHs

Live app: https://cv-analyzer-nc73.onrender.com/

Thanks to everyone who followed along.

Building in Public: CV Analyzer - Act 6 · Scene 2: Making Sure Auth Is Solid Before Integration

Voke — Fri, 30 Jan 2026 03:45:19 +0000

Before connecting my React frontend to the Nodejs backend, I paused to make sure authentication was actually solid, so I wouldn’t be guessing later or fixing things under pressure.

Click here for Act 6 · Scene 1

Overview
Symmetry With Act 4 · Scene 2
What I’m Really Doing Here
Mental Model
Why this scene matters

Act 6 · Scene 2: Making Sure Auth Is Solid Before Integration

At this point, the backend works.
Users can register, log in, and log out. As demonstrated with Postman.

But working once isn’t enough. So I did a couple of tests off screen.

This scene is about slowing down on purpose to make sure the backend behaves clearly and predictably before anything depends on it.

Overview

In the previous scene, I finished setting up authentication on the backend. Even registered the first user in our database, logged in and logged out the user, all with the aid of Postman.

I could have jumped straight into the frontend in this Scene.

But NAAAAAA!!!I didn’t.

Instead, I stopped to ask a simple question:

If another part of the app starts using this tomorrow, will it behave the way we expect?

This scene is about answering that question.

Walk with me…

Symmetry With Act 4 · Scene 2

There’s an intentional mirror here:

Act 4 · Scene 2 = Frontend contract stabilization Click here for Act 4 · Scene 2
Act 6 · Scene 2 = Backend contract stabilization

Now I’m doing the same thing, just on the backend. [Done off screen, didn't document what happened. Just sharing my thoughts]

What I’m Really Doing Here

I’m not adding new features.

I’m making sure:

Successful actions behave the same every time
Errors are clear and predictable
User data is handled safely
Nothing depends on guesswork
By testing everything without a UI, I know the backend stands on its own.

And yes, everything works good and feels good. Now let's revisit the frontend and continue working there.

Mental Model

Right now:

User data is saved correctly
Passwords are protected
Login and logout behave reliably
The backend works even without a screen

Why This Scene Matters

This scene shows that I:

Don’t rush integration
Think about how systems will be used later
Validate behavior before things break
Build with real users in mind

Thanks for reading.
Let’s move on to the Next Act.

We in the Building…
Building in Progress…

Building in Public: AI CV Analyzer MERN App - Act 6 · Scene 1: Persisting the First User (Models, Database, Auth Flow)

Voke — Thu, 29 Jan 2026 04:59:48 +0000

This post documents how I implemented user registration, authentication, and database persistence using a TypeScript-based Nodejs Express backend with MongoDB, JWT, and bcrypt.

Click here for Act 5 · Scene 2

Overview
User Model
Database Choice and Setup
Registering the First User
Login and Logout
Validation with Postman
Mental Model
Why this scene matters

Act 6 · Scene 1: Persisting the First User (Models, Database, Auth Flow)

Overview

Until now, the backend has only proven that it could start, route requests, and respond correctly. In this scene, it moves into something real. I introduce a user model, connect the server to a database, and implement the full authentication flow. That is: register, login, and logout. I verify everything end to end before touching the frontend again.

At this point, the server was stable, middleware was in place, and routes were wired correctly. The next logical step was to introduce persistence and authentication logic.

This scene focuses on connecting the backend to a database, defining a user model, and implementing the first complete authentication flow: registration, login, and logout validated entirely through Postman before shifting back to the frontend.

Let’s jump right in…

User Model

I started by defining a User model using Mongoose. The model establishes the shape, constraints, and validation rules for user data at the database level.

const UserSchema = new mongoose.Schema(
  {
    name: {
      type: String,
      trim: true,
      required: [true, "please enter name"],
      minlength: [3, "name shouldn't be less than 3 letters"],
      maxlength: [20, "name shouldn't be maore than 20 letters"],
    },
    email: {
      type: String,
      trim: true,
      required: [true, "please enter email"],
      unique: true,
      match: [
        /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/,
        "Please provide a valid email",
      ],
    },
    password: {
      type: String,
      trim: true,
      required: [true, "please enter password"],
      minlength: [6, "password shouldn't be less than 6 letters"],
    },
    isRegistered: {
      type: Boolean,
      default: false,
    },
  },
  { timestamps: true }
);

export default mongoose.model("User", UserSchema);

Database Choice and Setup

I considered SQL. But I chose MongoDB.

To me, flexibility matters more than rigid schemas. Authentication data evolves. MongoDB makes that painless without sacrificing structure.

At this stage, the database runs locally using MongoDB Compass. The server connects during startup, ensuring persistence is available before accepting requests.

Please note that the connection string will later be moved to environment variables for production readiness.

Here is the code for the connection:

    await mongoose.connect("mongodb://localhost:27017/CV-ANALYZER");
    console.log("connected to DB")
    app.listen(PORT,"localhost",()=>{
        console.log(`server listening on port ${PORT}`)
    })

The index.ts file was where I placed it.

Registering the First User

The registration controller validates input:

if (!name || !email || !password) {
    console.log("input fields shouldn't be empty");
    return res.status(400).json({ msg: "input fields shouldn't be empty" });
  }

Checks for existing users:

const emailExists = await User.findOne({ email: email });
    if (emailExists) {
      console.log("kindly log in");
      return res.status(401).json({ msg: "kidly log in" });
    }

Hashes passwords using bcrypt

const salt = await bcrypt.genSalt(12);
  const hashedPassword = await bcrypt.hash(password, salt);

Only when everything checks out does the user get written to the database.

And right there, that’s the line between “toy backend” and “real system.”

And I must state that no tokens are issued here. Registration and authentication are treated separately.

Login and Logout

The login controller verifies credentials:

if (!email || !password) {
    console.log("input fields shouldn't be empty");
    return res.status(400).json({ msg: "input fields shouldn't be empty" });
  }

Validates password hashes:

const isPasswordValid = await bcrypt.compare(password, user.password);
    if (!isPasswordValid) {
      console.log("invalid credentials");
      return res.status(400).json({ msg: "invalid credentials" });
    }

Issues a signed JWT:

      const token = jwt.sign(
      { userId: user._id, userName: user.name },
      process.env.JWT_SECRET_V!,
      { expiresIn: "1d" }
    );

And stored as an HTTP-only cookie:

      res.cookie("token", token, {
        path: "/",
        httpOnly: true,
        expires: new Date(Date.now() + oneDay),
        // secure:true,
        // sameSite:"none"
      });

Logout is handled by clearing the authentication cookie, immediately invalidating the session.

  res.cookie("token", "", {
      path: "/",
      httpOnly: true,
      expires: new Date(0),
      // secure:true,
      // sameSite:"none"
    });

Validation with Postman

All authentication routes were tested using Postman:

I registered a user with this:

{
    "name":"voke",
    "email": "voke@gmail.com",
    "password": "xxxxxxx"
}

Postman output for Register:

I logged in as a User:

{
    //"name":"voke",
    "email": "voke@gmail.com",
    "password": "xxxxxxx"
}

Postman output for Login:

I then logged out the User:

Postman output for logout:

With all these done, I think it's safe for me to pay a visit to the frontend of this wonderful application.

Mental Model

Right now:

Authentication data persists correctly
Passwords are securely hashed
Tokens are issued and removed cleanly
The backend no longer depends on UI

Why This Scene Matters

This scene shows that I:

Implement authentication with security first practices
Validate backend behavior independently
Build systems ready for real users

Thanks for reading.
Let’s move on to the Next Scene.

We in the Building…
Building in Progress…

Click here for Act 6 · Scene 2

Building in Public: AI CV Analyzer MERN App - Act 5 · Scene 2 : From Setup to The First Backend Surface

Voke — Wed, 28 Jan 2026 04:11:02 +0000

This post documents how I put together a TypeScript based Nodejs Express backend, wiring middleware, startup scripts, routing structure, and validating the server end-to-end before introducing the coding logic.

Click here for Act 5 · Scene 1

Overview
The index.ts
Middleware Setup
Error Handler
Not Found Middleware
Startup: Failure
Fixing It
Routes and Controllers
Controllers
Routes
Testing with Postman
Mental Model
Why this scene matters

Act 5 · Scene 2: From Setup to The First Backend Surface

This scene focuses on establishing a stable backend foundation: a TypeScript Express server that boots cleanly, applies middleware in the right order, exposes its first routes, and can be validated end to end without a frontend.

Overview

With the required Node.js packages installed in the previous scene and version control already in place, the next step was to bring the backend to life.

This scene focuses on initializing the server entry point, configuring core middleware, resolving startup issues, and exposing the first backend surface through structured routes and controllers.

The index.ts

I created a src folder and dropped an index.ts file inside it.
That file is the server’s front door.

Initial imports went in immediately:

import express from "express";
import cors from "cors";
import "dotenv/config";
import { Request, Response } from "express";
import mongoose from "mongoose";
import cookieParser from "cookie-parser";

Just importing some basic packages, no biggie.

Middleware Setup

Before routes, before features, I stopped to wire some middlewares.

A middleware runs between the incoming request and the final response. In Express, it has access to req, res, and next.

Error Handler

Created a middleware folder in the src folder and added errHandlerMiddleware.ts in it.

Here is its content:

import { Request, Response, NextFunction } from "express";

export const errorHandlerMiddleware = (
  error: unknown,
  req: Request,
  res: Response,
  _next: NextFunction
) => {
  console.log("error message from errorHandlerMiddleware:", error);

  res
 .status(500)
 .json({ msg: error instanceof Error ? error.message : "something went wrong" });
};

Express only recognizes an error handler if it accepts four parameters, even if next is unused.

Not Found Middleware

This middleware handles unmatched routes:

import { Request, Response } from "express";

export const notFoundMiddleware = (req: Request, res: Response) => {
  res.status(404).send({ msg: "Route doesn't exist..." });
};

Both middlewares were imported and registered at the bottom of index.ts.

Startup: Failure

With those middlewares in place, I wired up a minimal server configuration:

const app = express();

app.use(cors({ origin: "http://localhost:3000", credentials: true }));
app.use(cookieParser());
app.use(express.json());

app.get("/", (_req: Request, res: Response) => {
  res.send("<h1>This is the index.ts route...</h1>");
});

app.use(notFoundMiddleware);
app.use(errorHandlerMiddleware);

const PORT = Number(process.env.PORT) || 5000;

Here's the Startup logic:

const start = async () => {
  try {
    app.listen(PORT, "localhost", () => {
      console.log(`server listening on port ${PORT}`);
 });
 } catch (error) {
    console.log("startupError:", error);
 }
};

start();

I then ran:

npm run dev

It resulted in:

npm error Missing script: "dev"

Fixing It

Fixed it by updating package.json:

"scripts": {
  "dev": "nodemon src/index.ts",
  "build": "tsc",
  "start": "npm run build && node dist/index.js"
}

Retried it:

npm run dev

Server started successfully.

Routes and Controllers

Once the server stayed up, I went on to create a controllers folder and a routes folder.

Controllers handle behavior.
Routes decide where requests go.

Controllers

controllers/authController.ts:

export const registerController = (_req: Request, res: Response) => {
  res.status(200).json({ msg: "This is the register route" });
};

export const loginController = (_req: Request, res: Response) => {
  res.status(200).json({ msg: "This is the login route" });
};

export const logoutController = (_req: Request, res: Response) => {
  res.status(200).json({ msg: "This is the logout route" });
};

Routes

routes/auth-route.ts:

const authRouter = Router();

authRouter.post("/register", registerController);
authRouter.post("/login", loginController);
authRouter.get("/logout", logoutController);

export default authRouter;

Testing with Postman

Before introducing the frontend to the backend, I verified backend behavior using Postman.

I then sent Requests:

Here is a picture of postman when first opened:

Made a request to the home route:

Meaning, this line ran:

app.get("/", (_req: Request, res: Response) => {
  res.send("<h1>This is the index.ts route...</h1>");
});

I then tested the register route:

Meaning, this line ran:

export const registerController = (_req: Request, res: Response) => {
  res.status(200).json({ msg: "This is the register route" });
};

Tested the login route:

Meaning, this line ran:

export const loginController = (_req: Request, res: Response) => {
  res.status(200).json({ msg: "This is the login route" });
};

And the logout route followed the same pattern.

Requests hit.
Responses returned successfully.
The server didn't crash

This means that we are ready to rock and roll.

Mental Model

Right now:

The backend boots reliably
Middleware has been introduced
Routes and controllers are separated
The system is ready for real logic

Why This Scene Matters

This scene shows that I:

Bring backend systems online incrementally
Build for maintainability
Don’t rush features before foundations

Thanks for reading.
Let’s move on to the Next Act.

We in the Building…
Building in Progress…

Click here for Act 6 · Scene 1

Building in Public: AI CV Analyzer MERN App - Act 5 · Scene 1 : Here Comes the Backend

Voke — Tue, 27 Jan 2026 04:05:47 +0000

This post documents the initial setup of a Node.js with TypeScript backend for a MERN application. Covering project separation, dependency selection, TypeScript configuration, and version control before any endpoints or code is written.

Click here for Act 4 · Scene 2

Overview
Creating the Backend Folder
Backend Initialization and Package Setup
Installing Backend Dependencies
TypeScript Configuration
Git Initialization
Mental Model
Why this scene matters

Act 5 Scene 1: Here comes the backend

In this scene, I don’t build APIs or wire authentication logic yet. I focus on something quiet but foundational. That is, preparing the backend to exist properly. That means separating it from the frontend, initializing the project, installing the right dependencies, configuring TypeScript, and putting version control in place so future backend work has a stable, secure starting point.

Overview

With the frontend now stable and the data payloads for authentication clearly defined, the next step was inevitable I had to introduce the backend.

So instead of forcing more UI features, I did the responsible thing and switched gears.

This scene is about setting up the server side foundation that will eventually power authentication and data persistence. No endpoints yet. No coding here.

This scene focuses on establishing the bare foundation.

Creating the Backend Folder

First move; let's call it separation.

At the root of the project, I created a backend folder right next to the frontend.

cv-analyzer/
>backend/
>frontend/

That single decision already changes how the project feels.
This is no longer a React app.
It’s a freaking system.

In fact, this separation enforces a clear boundary between client and server concerns from day one.

Backend Initialization and Package Setup

Inside the backend folder, I initialized a Node.js project:

npm init -y

This generated a base package.json, which serves as the entry point for all backend configuration.

Installing Backend Dependencies

Next came the essential packages:

npm install cors express jsonwebtoken bcryptjs dotenv mongoose cookie-parser typescript

This setup tells a clear story:

Express to run the server
JWT for authentication
bcrypt for password security
Mongoose for database communication
dotenv for secrets
CORS and cookies for browser interaction

Then I added developer tooling:

npm install nodemon
npm install -D ts-node ts-node-dev

These packages allow automatic server restarts and direct execution of TypeScript files during development.

TypeScript Configuration

I initialized a TypeScript configuration file:

npx tsc --init

To ensure proper Node.js type support, I added:

npm install @types/node

Without this, TypeScript would not recognize core Node features, like process.env, __dirname, or built-in APIs.

I also installed type definitions for the libraries used:

npm install --save-dev @types/express @types/cors @types/cookie-parser @types/jsonwebtoken

These don’t run the app.
They make the app safer to change.
They exist solely to improve correctness, tooling, and developer experience.

Git Initialization

Although Git had already been initialized earlier, this scene documents the setup properly.

From the project root, I added a .gitignore file and verified the repository status:

git init

git status

At this point, version control cleanly tracks both frontend and backend as a single system.

Mental Model

Right now:

Frontend and backend are clearly separated
The backend is TypeScript first.
Authentication infrastructure is in place before logic
The project is prepared for growth

Why This Scene Matters

This scene shows that I:

Introduce backend systems only when the frontend contract is ready
Set foundations before writing endpoints
Prioritize security, structure, and developer experience
Build like someone expecting the app to grow

Thanks for reading.
Let’s move on to the Next Scene.

We in the Building…
Building in Progress…

Click here for Act 5 · Scene 2

Building in Public: AI CV Analyzer MERN App - Act 4 · Scene 2 : Stabilizing the Frontend Contract

Voke — Mon, 26 Jan 2026 03:56:47 +0000

This post walks through how I locked down the AuthForm contract in a React and TypeScript app deciding what the frontend guarantees before the backend enters the room.

Click here for Act 4 · Scene 1

Overview
What This Scene Focuses On
One Form, Two Intentions
Light Validation
Shape of the Payload: What the Backend Will Receive
Mental Model
Why this scene matters

Act 4 · Scene 2 : Stabilizing the Frontend Contract

In this scene, I slow the momentum on purpose.
Instead of rushing into backend work, I stabilize the frontend contract that authentication will depend on.

Overview

Now that routing works, and pages actually show up when you click them, the temptation is obvious:
“Let’s spin up the backend.”

yaaaaaaaaaaaaaaay!!!

News flash
I didn’t.🤣🤣

Why?

Because before a backend exists, the frontend needs to answer a simple question honestly: What exactly am I sending you?

Authentication is the first true dependency between frontend and backend. If this boundary is unclear, everything else down the road becomes fragile. So, instead of jumping straight into API calls, I focused this scene on stabilizing the AuthForm contract.

This scene is not about authentication working.
It’s about authentication being well defined.

What This Scene Focuses On

Light but intentional input validation
Clear separation between login and registration modes
Explicit payload shapes the backend can rely on
Placeholder submit handlers to simulate real submission behavior
No networking yet. No backend assumptions.

One Form, Two Intentions

The AuthForm operates in two modes, controlled by a single piece of state:

const [haveAccount, setHaveAccount] = useState(false);

This boolean determines the intention of the form:

From a backend perspective, this distinction matters. Each mode produces a different but predictable payload.

Light Validation

The goal here is not to send meaningless requests.

Login validation

if (
  enteredEmail.trim().length === 0 ||
  enteredPassword.trim().length < 6
) {
  return console.log("Fill out the inputs");
}

This ensures that login requests meet a minimum bar of validity before leaving the browser.

Registration validation

if (enteredName.trim().length < 3) {
  return console.log("name should be at least 3 characters long");
}
if (enteredEmail.trim().length === 0) {
  return console.log("please enter valid email address");
}
if (enteredPassword.trim().length < 6) {
  return console.log("password must be at least 6 characters long");
}

These validations are similar to those of the login. They serves the same purpose.

Also, I am keeping validation deliberately light here.
This validation here:

Stops empty submissions
Stops obvious mistakes
Reduces useless backend calls

That’s what makes it lightweight

It doesn’t enforce security; that responsibility belongs to the server.

Shape of the Payload: What the Backend Will Receive

Once validation passes, the form produces a clear payload.

Registration payload

const userData: User = {
  name: enteredName,
  email: enteredEmail,
  password: enteredPassword,
};

Login payload

const userData:User = {
  email: enteredEmail,
  password: enteredPassword,
};

These payloads are what would be sent to the server.

The interface below serves as a form of map, or should I say guide, for the payloads:

export interface User {
  name?: string;
  email: string;
  password: string;
}

Mental Model

Right now:

The frontend knows what it’s sending
The backend can trust the shape of incoming data
Invalid intent is stopped early

Why This Scene Matters

This scene shows that I:

Understand authentication as infrastructure, not just UI
Build in a way that backend engineers can immediately work with
Don’t rush into APIs without contracts

Thanks for reading.
Let’s move on to the Next Act.

We in the Building…
Building in Progress…

Click here for Act 5 · Scene 1

Building in Public: AI CV Analyzer MERN App -Act 4 · Scene 1: The Analysis Component

Voke — Fri, 23 Jan 2026 04:05:37 +0000

This post shows how to fix broken navigation in a React app by wiring a real feature page into React Router v6.4+, turning a missing route into a working product flow.

Click here for Act 3 · Scene 2

Overview
What the AnalysisForm Is Really About
Why the AnalysisFormPage Exists: And Why I Didn’t Route the Component Directly
Mental Model
Why this scene matters

Act 4 · Scene 1: The Analysis Component

In this scene, I build and render the AnalysisFormPage, properly integrating it into the React Router route tree so the application’s main feature becomes accessible through navigation.

Overview

Auth was fixed in the last act. By the end of the previous act, authentication routes were fully wired into the application. Before that, clicking navigation links like Auth or Analyze Candidate resulted in an error boundary and the familiar message:

No routes matched this location.

Auth has now been resolved. But the same issue still exists for Analyze Candidate, and this scene focuses on fixing that properly.

This scene focuses on:

Introducing the AnalysisFormPage
Rendering it correctly through the router
Completing the navigation flow without errors

What the AnalysisForm Is Really About

This is where CVs and job descriptions enter the system.
Where raw text becomes something useful.
Where AI Talent Profile Analyzer stops being a name and starts becoming a tool.

For now, I am not after logic. I am just building the structure. Putting it together like a freaking LEGO block.

Here’s the initial JSX structure of the component:

return (
  <div className={classes["analysis-form-container"]}>
    <div className={classes.heading}>
      <h1>Analyze a Candidate</h1>
    </div>

    <div className={classes.body}>
      <form>
        <Card className={classes.cardClass}>
          <h2>Upload CV</h2>

          <div className={classes.actions}>
            <label className={classes.uploadButton}>
              Upload PDF or Text Files
              <input
                type="file"
                accept=".pdf,.txt"
                onChange={fileChangeHandler}
                hidden
              />
            </label>

            <button
              type="button"
              className={classes.secondaryButton}
              onClick={() => setShowPasteCv(true)}
            >
              Paste CV Text
            </button>

            <p>OR</p>

            <textarea
              placeholder="Paste CV text here..."
              value={cvText}
              onChange={cvTextChangeHandler}
            />
          </div>

          <div className={classes["lower-part"]}>
            <h2>Paste Job Description</h2>

            <textarea placeholder="Paste the job description here..." />

            <Button type="submit" className={classes.button3}>
              Run AI Analysis
            </Button>
          </div>
        </Card>
      </form>
    </div>
  </div>
);

The JavaScript behavior will be refined later. For now, this establishes the UI structure.

Why the AnalysisFormPage Exists: And Why I Didn’t Route the Component Directly

I don’t usually route components directly. I prefer that:

Pages should handle routing.
Components should handle UI.

So, I created AnalysisFormPage, imported the AnalysisForm component, and let it do its thing.

Code right here:

const AnalysisFormPage = () => {
  return <AnalysisForm />;
};

Then I wired it into the router.

children: [
  { path: "/", element: <HomePage /> },
  { path: "/auth", element: <AuthPage /> },
  { path: "/analysis-form", element: <AnalysisFormPage /> },
];

After saving and reloading, navigating to Analyze Candidate rendered the form successfully.

No error boundary. No warnings. Just a clean render.

See image below:

Mental Model

At this stage:

Routes map cleanly to pages. Yep! all pages
Pages handle routing
Components handle UI and interaction
Navigation reflects the actual application state

Why This Scene Matters

This scene shows that I:

Treat routing as application architecture, not an afterthought
Separate pages from components intentionally
Expect and resolve incomplete states during development

Thanks for reading.
Let’s move on to the Next Scene.

We in the Building…
Building in Progress…

Click here for Act 4 · Scene 2

Building in Public: AI CV Analyzer MERN App -Act 3 · Scene 2 : Fixing and Rendering the AuthPage

Voke — Thu, 22 Jan 2026 04:39:33 +0000

This post shows how to add an authentication page to a React app using React Router, correctly wiring routes and preparing the UI layer for user-based access and future scaling.

Click here for Act 3 · Scene 1

Overview
Why Authentication Shows Up Now
Architectural Foreshadowing (Thinking Ahead)
Creating the AuthForm and AuthPage
Making the Route Exist
While I Was At It With Auth… A Button Component Was Born
Mental Model
Why this scene matters

Act 3 · Scene 2 : Fixing and Rendering the AuthPage

In this scene, I introduce authentication into a React MERN application by wiring an AuthPage into the routing system and laying the groundwork for user based access control.

Overview

With navigation and routing in place, the next logical step was to introduce authentication.

At first, I debated skipping it entirely. But the more I stared at the app, the more obvious it became that authentication would eventually be required not just to identify users, but to control what they are allowed to do.
So instead of pretending auth doesn’t exist, I decided to face it early.

This scene focuses on:

Introducing an AuthPage
Rendering it properly through the router
Introducing a reusable Button component for shared UI behavior

The goal wasn’t to build auth fully yet, but to prepare the application for it.

Why Authentication Shows Up Now?

Authentication influences architecture decisions early on:

What users can see
What they can do
What eventually needs protecting

If I delay it too long, it will sneak up on me later without sneakers and will force some ugly refactors. So it's best to face it head on now

Architectural Foreshadowing (Thinking Ahead)

Introducing authentication automatically implies a few future decisions.

First: data persistence.

Once users can sign up or log in, I will need a database to store user records securely. And fetch them when needed. I am not introducing the database yet, but it’s already part of the mental model for where this product is headed. We will talk more about it when we cross that bridge.

Second: backend control and scaling

Authentication almost always means a backend, unless I hand over everything to a managed service like Firebase. But for this project, I want more control over how authentication is handled, especially with scaling in mind.

Vertical scaling, in particular, will require being intentional about how auth logic is structured. More on that later. This is already looking mouth watering. I am salivating already. MAAAAAN! I am in love with this whole process.

So, for now, let’s get started with authentication, and what better place to start than the AuthForm? And just to quickly add, I will not be implementing Google authentication in here yet, at least for now.

Creating the AuthForm and AuthPage

I started by creating an AuthForm component inside a dedicated auth folder under components alongside its SCSS module.

Folder structure:

components/
  auth/
    AuthForm.tsx
    AuthForm.module.scss

Then I created an AuthPage inside the pages directory to act as the route-level wrapper. The AuthPage inside the pages directory is to host the AuthForm.

Code below:

import AuthForm from "../components/auth/AuthForm";

const AuthPage = () => {
  return <AuthForm />;
};

export default AuthPage;

This keeps routing concerns separate from UI logic. As Pages handle routing, while Components handle UI.

Making the Route Exist

Of course, nothing renders until the router knows about it.

And I hope you remember this image from the previous scene:

So back to App.tsx.
I added the /auth route to the route tree:

children: [
  { path: "/", element: <HomePage /> },
  { path: "/auth", element: <AuthPage /> },
];

With this change, the /auth route now renders correctly.

While I Was At It With Auth… A Button Component Was Born

While building the AuthForm, I noticed that I would be making use of a styled Button more than once.

So instead of hardcoding styles, I introduced a reusable Button component inside the shared ui folder:

interface ButtonProps {
  children: React.ReactNode;
  className?: string;
  onClick?: () => void;
  type: "submit" | "button";
}

const Button = (props: ButtonProps) => {
  return (
    <button
      className={`${classes.button} ${props.className || ""}`}
      onClick={props.onClick}
    >
      {props.children}
    </button>
  );
};

Later, I will move the ButtonProps out of this Button.tsx file. I will store it in another file, which I will call interfaces.

Mental Model

Right now:

Routes unlock pages, well Auth page for now
Pages host components
UI building blocks reduce duplication
Authentication exists as infrastructure, not a feature sprint

Why This Scene Matters

This scene shows that I:

Think about users and permissions early
Build reusable UI intentionally
Prefer steady foundations over rushed features

Thanks for reading.
Let’s move on to the Next Act.

We in the Building…
Building in Progress…

Click here for Act 4 · Scene 1

Building in Public: AI CV Analyzer MERN App - Act 3 · Scene 1 : Before The AuthPage

Voke — Wed, 21 Jan 2026 04:09:43 +0000

This post walks through setting up reusable UI components and active navigation in a React app using React Router’s NavLink, preparing the codebase for authentication and future feature pages.

Click here for Act 2 · Scene 2

Overview
Creating a Reusable Card Component
Adding Active Navigation with NavLink
What Happens When Routes Don’t Exist (Yet)
Mental Model
Why This Scene Matters

Act 3 · Scene 1: Before The AuthPage

In this scene, I introduced reusable UI building blocks and active navigation using React Router’s NavLink, laying groundwork for authentication and analysis flows before building the actual pages.

Overview

With routing, layout, and the home page now stable, the application finally has a backbone. At this point, it made sense to pause feature work and ask myself a quiet question:

What UI decision am I going to regret not making early?

Two answers came back immediately:

Reusable layout wrappers
Navigation that knows where you are

So that’s what this scene is about.

Here in this scene, I am introducing two structural UI elements that will support everything that comes next:

A reusable Card component to standardize layout
Active navigation state using NavLink

Creating a Reusable Card Component

A Card is a reusable UI wrapper component that standardizes layout and styling. It centralizes layout and styling ensuring a consistent visual structure across the application.

Instead of repeating padding, borders, and spacing rules, I created a reusable wrapper.

Folder structure:

components/
ui/
card/
Card.tsx
Card.module.scss

The Card.tsx file:

import type React from "react";
import classes from "./Card.module.scss";

const Card: React.FC<{ children: React.ReactNode; className: string }> = (
  props
) => {
  return (
    <div className={`${classes.card} ${props.className}`}>
      {props.children}
    </div>
  );
};

export default Card;

Just a wrapper that does its job and stays out of the way. This is the kind of component you don’t think about later.

Adding Active Navigation with NavLink

Next problem:

The navigation had no awareness. It didn’t know where the user was. It didn’t react.

That felt kind of off.

I needed it to react when a user visits a specific page or route.

Instead of using the ever popular Link, I used NavLink in its place. And added a small helper to conditionally apply styles based on route activity:

const navDataHandler = (navData: any) => {
  return navData.isActive ? classes.active : "";
};

The MainNav looked like this:

<h1>
  <NavLink to="/" className={navDataHandler}>
    <span>AI Talent Profile</span> Analyzer
  </NavLink>
</h1>

<nav>
  <ul>
    <li>
      <NavLink to="/auth" className={navDataHandler}>
        Auth
      </NavLink>
    </li>
    <li>
      <NavLink to="/analysis-form" className={navDataHandler}>
        Analyze Candidate
      </NavLink>
    </li>
  </ul>
</nav>

This was added to the scss file:

.active {
  border-bottom: 1px solid red;
}

a {
  text-decoration: none;
}

At this point, active routes were visually clear.

What Happens When Routes Don’t Exist (Yet)

Alright, here comes an interesting part.

I saved the file. Hot reload kicked in. And for a moment, everything looked… fine.
The active state kicked in exactly where it should; there was a red underline under AI Talent Profile Analyzer, which told me the NavLink logic was doing its job.

But then I clicked Auth. And Boooooooom!!!

I saw this:

Got the Same thing for Analyze Candidate.

Meanwhile I saw this in the console for both auth and analyze candidate:

For auth:

For AnalyzeCandidate:

No routes matched location is what is being displayed in the browser console for both auth and analyze candidate.

But in all honesty, this was expected.

Do you know why?

This happened because these routes don’t exist yet in the router configuration.

Current router tree in App.tsx:

function App() {
  const router = createBrowserRouter([
    {
      path: "/",
      element: <RootLayout />,
      errorElement: <ErrorPage />,
      children: [{ path: "/", element: <HomePage /> }],
    },
  ]);

  return <RouterProvider router={router} />;
}

As you can see from the code above, there are no entries for: /auth or /analysis-form.

So React Router correctly falls back to the error boundary.

This is not a bug. I repeat, this is not a bug.
That’s the system working as designed.

So, how do I go about fixing it? Well, stay tuned. We will break it down in the next scene.

Mental Model

At this stage:

Navigation reflects application state
UI building blocks are reusable and consistent
Routes are intentionally incomplete
The app is telling me what to build next

Why This Scene Matters

This scene shows that I:

Build foundations before features
Expect systems to be incomplete mid-build
Think in reusable UI layers
Let architecture guide the next step

Thanks for reading.
Let’s move on to the Next Scene.

We in the Building…
Building in Progress…

Building in Public: AI CV Analyzer MERN App - Act 2 · Scene 2 : Revisiting the App.ts

Voke — Tue, 20 Jan 2026 04:58:11 +0000

This post shows how to set up routing in a modern React app using React Router v6.4+, connecting layouts, pages, and error handling so your application renders correctly and behaves like a real product.

Click here for Act 2 · Scene 1

Overview
First Things First: A Proper Home
Error Handling with an Error Page
Structuring App.tsx
UI Consistency: Global CSS Reset
Refining the Home Component
Mental Model
Why This Scene Matters

In this scene, I wire up a real React application using React Router v6.4+, turning App.tsx into a routing hub that connects layouts, pages, and error handling so the UI finally renders like a real product.

Overview:

In the previous scene, I introduced a proper layout system using RootLayout and a persistent MainNav. Structurally, everything was in place, but visually, nothing showed up.

In fact, to be very specific, I built the frame. And it comprised of; The navigation and The Layout. But for some reason, the app said: “nice try fella, but I aint gonna render anything”.

Frustrating right?

This scene focuses on connecting the pieces:

Defining routes
Introducing a home page
Handling invalid routes
Making the layout actually render

First things first: a proper Home

Rather than leaving placeholder content inside the App.tsx, I introduced a dedicated HomePage component. Simply because that Voke is going in… text sitting inside App.tsx had overstayed its welcome. So I pulled it out into its own HomePage component.

This would ensure App.tsx handles routing and configuration, and Pages define structure. While Components handle UI. Each would have a responsibility of its own.

So the Home page looked like this:

const HomePage = () => {
  return <h2>Voke is going in...</h2>;
};

export default HomePage;

Not to worry, I come back to this in a minute.

Error Handling with an Error Page

Next, I introduced an ErrorPage component to handle undefined routes and routing errors. This is an answer to a question that kept hitting me like a punching bag receiving jabs from Balrog in Street Fighter.

And that is: what happens when someone types a random URL?
Instead of letting the app break silently, I introduced an ErrorPage.

Not flashy. Just responsible.

import { Link } from "react-router-dom";
import MainNav from "../components/main-nav/MainNav";

const ErrorPage = () => {
  return (
    <>
      <MainNav />
      <main style={{ width: "100%", maxWidth: "70rem", margin: "5rem auto" }}>
        <h2>Page not found</h2>
        <p>
          <Link to="/">Go back home</Link>
        </p>
      </main>
    </>
  );
};

export default ErrorPage;

This ensures:

Invalid URLs don’t crash the app
Users always have a recovery path
Navigation remains consistent even on error states.

So in plain English, if a route doesn’t exist, the user sees the navigation, gets a clear message, and has a way back home.

That’s basic UX hygiene. And it’s easier to do now than later.

Structuring App.tsx

Now comes the heart of the app.

With pages in place, App.tsx became the central routing configuration using React Router v6.4+. I intentionally chose React Router v6.4+ because it introduces the data router APIs (createBrowserRouter). This gives me a more scalable routing setup with first-class support for layouts and error boundaries. So I stuck with v6.4+.

And it’s best I spell this out here. App.tsx isn’t a UI file anymore, it’s now the traffic controller.

This is how the App.tsx file looks like now:

import { createBrowserRouter, RouterProvider } from "react-router-dom";
import RootLayout from "./pages/RootLayout";
import HomePage from "./pages/HomePage";
import ErrorPage from "./pages/ErrorPage";

function App() {
  const router = createBrowserRouter([
    {
      path: "/",
      element: <RootLayout />,
      errorElement: <ErrorPage />,
      children: [{ path: "/", element: <HomePage /> }],
    },
  ]);

  return <RouterProvider router={router} />;
}

![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/89v2pxmr9suj8n54hnf0.png)


export default App;

At this point:

Layouts were nested correctly
Routes were declarative
Errors were handled centrally

This simply meant that the application was beginning to have a pulse. Did I hear some say breathe [in the voice of the uncredited singer of the fabolous song breathe].

So if I save and reload the page, I will get this:

UI Consistency: Global CSS Reset

As you can see from the image above, once everything was rendered, spacing issues became obvious. The layout felt… off. This happened because default browser margins and padding were creeping in

A quick global reset fixed it:

* {
  box-sizing: border-box;
  margin: 0;
  padding: 0;
}

With that code block added in, saw this:

This brought the layout back under control and gave the UI a predictable baseline to build on.

Refining the Home Component

At this point, it felt wrong to keep UI markup inside HomePage.
Pages shouldn’t worry about how things look, they should worry about where things live.

So I pushed the UI one level down and introduced a dedicated Home component which also had its own style file.

HomePage now handles routing, while Home focuses purely on presentation.

The Home component:

import classes from "./Home.module.scss";

const Home = () => {
  return (
    <div className={classes["home-container"]}>
      <h1>Analyze candidate-job fit using AI</h1>
      <p>Get instant insights on CVs and job descriptions with AI</p>
    </div>
  );
};

export default Home;

This component is then rendered inside HomePage, keeping concerns separated.

That separation already feels like it will pay off later.

Saved it, and checked my browser and saw this:

That's more like it...

Mental Model

At this stage:

App.tsx is the heart
RootLayout can be compared to a skeleton
While pages are meant for destinations
And Components render the presentations

Well, they all seem to play a role. They all know their role, like the video game tagline SmackDown 2: Know your role. 😊

And with all these, the foundation seems stable.

Why This Scene Matters

This scene demonstrates that I:

Understand modern React Router architecture (v6.4+)
Separate configuration, layout, pages, and UI cleanly
Build structure before features
can refactor when needed

Thanks for reading.
Let’s move on to the Next Scene.

We in the Building…
Building in Progress…

Click here for Act 3 · Scene 1

Building in Public: AI CV Analyzer MERN App - Act 2 · Scene 1 - Laying Down the App’s Spine (Main Navigation)

Voke — Mon, 19 Jan 2026 03:51:45 +0000

This post walks through setting up the core navigation for a React application, building a permanent layout spine that supports pages, routing, and future feature development.

Click here for Act 1 · Scene 2

Overview
Building the MainNav (basic setup)
Where Does the Navigation Live?
Introducing the Root Layout (where things actually come together)
What Is Outlet and What Does It Actually Do?
Mental model
Why this scene matters

Overview

Let’s keep the train moving, shall we?

After cleaning up the template in Act 1 and letting you all know that
Voke is going in…, I hit that familiar moment every builder knows:
The app technically exists… but it doesn’t feel like anything yet.

There’s

No structure.
No sense of direction.
Just a bland page staring right back at you.

So instead of rushing into “AI” or “analysis logic”, I stopped and asked a boring but important question:

If this were a real product, what would always be on the screen?

The answer was obvious: navigation.

So, before going in on all the features that this application would have, it would first need a spine. An app needs a spine.

So in this scene, I focused on building the main navigation not as decoration, but as a permanent part of the product’s layout.

Are you with me? If so, let’s go…

Building the MainNav (basic setup)

So I went into the src folder and created a components folder, then a main-nav folder inside it. In the main-nav folder, I created a file called MainNav.tsx. It also had a brother called MainNav.module.scss.

Here’s what the first version of MainNav.tsx looks like:

import classes from "./MainNav.module.scss";

const MainNav = () => {
  return (
    <header className={classes.header}>
      <h1>
        <span>AI Talent Profile</span> Analyzer
      </h1>

      <nav>
        <ul>
          <li>Auth</li>
          <li>AnalyzeCandidate</li>
        </ul>
      </nav>
    </header>
  );
};

export default MainNav;

At this point:

There’s no routing
There’s no auth logic
And no conditions

With what we have up there in the code block, that already answers the question of what this application is about.

I kept the styles local using an SCSS module:

.header {
  width: 100%;
  height: 5rem;
  display: flex;
  align-items: center;
  justify-content: space-between;

  background-color: rgb(242, 237, 237);
  padding: 0 10%;

  nav {
    ul {
      display: flex;
      gap: 1rem;
      list-style: none;
      margin: 0;
      padding: 0;
    }
  }
}

Nothing groundbreaking here in both files. They would get beefier as we continue.

Where Does the Navigation Live?

O.k! I hope it’s not what you guys are thinking. Did I hear someone say:

“Easy answer, the navigation lives in the computer”? lol.

And that’s not a jab at your ribs when I say all jokes aside.

But seriously, I saved everything… hot reload kicked in…
And nothing showed up.

Which made sense.

A navigation component by itself doesn’t magically appear in an app. It’s no Harry Potter.
It needs a home, a place that exists above individual pages.

And that brings us to this bad guy, the Root Layout.

Introducing the Root Layout (where things actually come together)

Meet the RootLayout component. A layout wrapper for the app when using React Router v6+.

With the introduction out of the way, a navigation component is useless if it isn’t anchored into the app correctly.

So instead of spraying the navigation across pages, I introduced a RootLayout using React Router’s layout pattern.

This layout defines:

What stays on screen permanently
What changes when routes change

Here’s the layout:

import { Outlet } from "react-router-dom";
import MainNav from "../components/main-nav/MainNav";

const RootLayout = () => {
  return (
    <>
      <MainNav />
      <main style={{ width: "100%", maxWidth: "70rem", margin: "2rem auto" }}>
        <Outlet />
      </main>
    </>
  );
};

export default RootLayout;

So with all that in place, our darling navigation finally got a place it could call home. Isn’t that cute…😊😊😊.

What Is Outlet and What Does It Actually Do?

<Outlet /> is a React Router component that acts as a placeholder for nested routes.
It tells React Router: Render the matched child route here. And as you can see from the code up there, it’s from the react-router-dom library, so it is meant to handle and deal with page routings.

Mental model

Now we see that:

MainNav lives at the top. It’s always present.
And
Outlet becomes the surface where everything else will evolve.

At this stage, the UI still isn’t doing much. But the mental model is already cleaner.

But still, even with all these, all that we have done isn’t yet visible.

Stay tuned, we will have that sorted out in the next scene.

Why this scene matters

This scene isn’t just about headers or CSS.

It shows that I:

Am not rushing to bolt on AI features yet.
Am building the frame first, because products collapse when the foundation is rushed.
Think in layouts and systems, not just components.
Intentionally build things boring first, so they don’t fight me later.

Thanks for reading.
Let’s move on to the Next Scene.

We in the Building…
Building in Progress…

Click here for Act 2 · Scene 2

Building in Public: AI CV Analyzer MERN App - ACT 1 · Scene 2: Clearing the Noise

Voke — Fri, 16 Jan 2026 17:52:26 +0000

This article is part of my AI CV Analyzer MERN App series. A step-by-step buildinpublic walkthrough of creating a full-stack AI résumé analysis platform using MongoDB, Express, React, Node.js, and AI.

Click here for Act 1 · Scene 1

Overview
Cleaning up the default template
Putting something back: Voke is going in…
Why the text looked centered (and why I fixed it)
Why this scene matters

Overview

Before adding features, routes, or AI logic, I needed one thing:

A quiet starting point.

The default Vite template is great for demos, but for an actual product, it’s just noise. Logos, counters, and styles, all of which are not needed in this app.

So this scene is about wiping the slate clean. Got it? wiping the slate clean. Somebody hand me a board wiper.

Cleaning up the default template

By default, App.tsx comes with logos and example JSX meant to show Vite + React working.

Yeah! yeah! It works, but we won't be needing it.

I opened src/App.tsx and removed:

the demo state
the Vite + React logos
the example markup
the default styles tied to that demo

The goal wasn’t to refactor anything, but to get it blank so I could put anything I want there.

After stripping the template down, App.tsx was reduced to the bare minimum:

function App() {
  return <></>;
}

export default App;

Reloading the app gave me a blank page.

Image below:

Putting something back: voke is going in…

A completely blank screen is expected, but I wanted a visible confirmation that:

The app is alive
Hot reload is working
And I am now in control of what shows up.

So I added a simple line:

function App() {
  return (
    <>
      <h2>Voke is going in...</h2>
    </>
  );
}

export default App;

Image below:

Nothing special.
Just a marker that says: “Yeah, this is mine now.”

Why the text looked centered (and why I fixed it)

When that text showed up, it was centered on the page. As you can see in the image above.

That wasn’t coming from React; it was coming from the default CSS Vite ships with.

Those styles are great for demos, but they silently influence layout in ways you don’t want once you start designing real UI.

So I went into index.css and App.css and commented out the default styles.

I want layout decisions to be:

explicit
intentional
owned by the app, not the template

Once the styles were cleared, the text appeared at the top.

Image below:

Much better, if you asked me.

Why this scene matters

This isn’t just about deleting boilerplate.

It’s about:

eliminating hidden behavior
starting from a neutral baseline

When this app later deals with:

loading states
AI responses
error screens
multi-step flows

…I don’t want to be fighting leftover demo styles or layout issues that I forgot to deal with earlier.

Let’s move on to the Next Act.

We are in the Building…
Building in Progress…

Click here for Act 2 · Scene 1

Forem: Voke

Building in Public: CV Analyzer - Closure

Building in Public: CV Analyzer - Act 6 · Scene 2: Making Sure Auth Is Solid Before Integration

Table of Contents

Act 6 · Scene 2: Making Sure Auth Is Solid Before Integration

Overview

Symmetry With Act 4 · Scene 2

What I’m Really Doing Here

Mental Model

Why This Scene Matters

Building in Public: AI CV Analyzer MERN App - Act 6 · Scene 1: Persisting the First User (Models, Database, Auth Flow)

Table of Contents

Act 6 · Scene 1: Persisting the First User (Models, Database, Auth Flow)

Overview

User Model

Database Choice and Setup

Registering the First User

Login and Logout

Validation with Postman

Mental Model

Why This Scene Matters

Building in Public: AI CV Analyzer MERN App - Act 5 · Scene 2 : From Setup to The First Backend Surface

Table of Contents

Act 5 · Scene 2: From Setup to The First Backend Surface

Overview

The index.ts

Middleware Setup

Error Handler

Not Found Middleware

Startup: Failure

Fixing It

Routes and Controllers

Controllers

Routes

Testing with Postman

Mental Model

Why This Scene Matters

Building in Public: AI CV Analyzer MERN App - Act 5 · Scene 1 : Here Comes the Backend

Table of Contents

Act 5 Scene 1: Here comes the backend

Overview

Creating the Backend Folder

Backend Initialization and Package Setup

Installing Backend Dependencies

TypeScript Configuration

Git Initialization

Mental Model

Why This Scene Matters

Building in Public: AI CV Analyzer MERN App - Act 4 · Scene 2 : Stabilizing the Frontend Contract

Table of Contents

Act 4 · Scene 2 : Stabilizing the Frontend Contract

Overview

What This Scene Focuses On

One Form, Two Intentions

Light Validation

Shape of the Payload: What the Backend Will Receive

Mental Model

Why This Scene Matters

Building in Public: AI CV Analyzer MERN App -Act 4 · Scene 1: The Analysis Component

Table of Contents

Act 4 · Scene 1: The Analysis Component

Overview

This scene focuses on:

What the AnalysisForm Is Really About

Why the AnalysisFormPage Exists: And Why I Didn’t Route the Component Directly

Mental Model

Why This Scene Matters

Building in Public: AI CV Analyzer MERN App -Act 3 · Scene 2 : Fixing and Rendering the AuthPage

Table of Contents

Act 3 · Scene 2 : Fixing and Rendering the AuthPage

Overview

Why Authentication Shows Up Now?

Architectural Foreshadowing (Thinking Ahead)

First: data persistence.

Second: backend control and scaling

Creating the AuthForm and AuthPage

Making the Route Exist

While I Was At It With Auth… A Button Component Was Born

Mental Model

Why This Scene Matters