{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicljvsgaffnfh22akwisywf2khwvenngkfcaqyzdrifuc6oheyqcy",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mp7psmgh3422"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreig2eppny2xkwqxmkg6ufmwagj5x3x5kbn4dibslmlabs3iea6cqmq"
    },
    "mimeType": "image/webp",
    "size": 395632
  },
  "path": "/chijioke_uzodinma_d6ae6ef/how-we-migrated-bloom-after-from-vanilla-js-to-nextjs-typescript-ggl",
  "publishedAt": "2026-06-26T19:35:46.000Z",
  "site": "https://dev.to",
  "tags": [
    "frontend",
    "javascript",
    "nextjs",
    "typescript",
    "route groups",
    "Grace"
  ],
  "textContent": "As part of Rise Academy's frontend program, students are grouped and assigned real projects to work on. My group was assigned **Bloom After** — and our task was to migrate its existing Vanilla JS frontend to **Next.js with TypeScript**. Not because the old one was broken, but because that's exactly the kind of thing you need to do once on a real codebase before you can say you actually know how. I was the one who set up the new project and made most of the architectural decisions, so this is a first-hand account of how we approached it.\n\n##  Why We Migrated\n\nHonestly? The legacy frontend still worked. This wasn't a \"the codebase is on fire\" situation — it was a deliberate learning exercise set by Rise Academy. Bloom After was one of three projects assigned across student groups, and the task was to migrate it to a modern stack. Part of the value of Rise Academy's program is that you work on real projects, not toy examples — so the problems you encounter are real too.\n\nThat said, the migration did surface real problems worth solving:\n\n  * **Inconsistent data shapes.** Some backend responses used `_id`, others `id`. Some used `desc`, others `description`. Messy in any codebase, good to clean up.\n  * **Auth in localStorage.** Fine for a learning project, but not a habit worth keeping — so we fixed it properly.\n  * **No enforced structure.** As the team grew, having no patterns made it easy to do things differently every time.\n\n\n\nThe goal wasn't to rescue a broken app. It was to learn migration — and learn it on something real enough to matter.\n\n##  The Setup Decisions I Made Before Anyone Wrote a Single Component\n\nBefore I let anyone start building, I made a few calls that I think saved us a lot of pain.\n\n###  1. Keep CSS Class Names the Same\n\nThe legacy app had a full stylesheet. Rather than rewriting CSS, I told the team: **keep every class name identical to what it was in the Vanilla JS version.** We only import the CSS a page actually needs, not a global dump of everything.\n\nThis meant:\n\n  * No duplicate styling work\n  * No visual regressions from class name mismatches\n  * Designers and devs could reference the same class names they already knew\n\n\n\n###  2. Route Groups for Shared Layouts\n\nNext.js App Router supports route groups — folders wrapped in parentheses that don't affect the URL but let you share layouts. I used this heavily:\n\n\n\n    app/\n    ├── (public)/          # Marketing pages — shared public header\n    ├── (admin)/           # Admin pages — shared admin header\n    └── (dashboard)/       # User dashboard — shared sidebar\n\n\nEach group gets its own `layout.tsx`, so the right header/sidebar renders automatically without any conditional logic inside components.\n\n###  3. Normalise the Data at the Type Layer\n\nBefore writing a single component, I created TypeScript interfaces that reflected what the data _should_ look like — not what the backend was actually sending. Then I wrote normalisation utilities to map the messy API responses into clean, predictable shapes.\n\n\n\n    // types/course.ts\n    export interface Course {\n      id: string;           // normalised from _id or id\n      title: string;\n      description: string;  // normalised from dead or description\n      createdAt: string;\n    }\n\n    // utils/normalise.ts\n    export function normaliseCourse(raw: Record<string, unknown>): Course {\n      return {\n        id: (raw._id ?? raw.id) as string,\n        title: raw.title as string,\n        description: (raw.description ?? raw.dead) as string,\n        createdAt: raw.createdAt as string,\n      };\n    }\n\n\nThis is one of the biggest wins TypeScript gave us. Once the normalisation layer existed, every component downstream could trust the shape of its data.\n\n##  Week 1: Foundation\n\n###  The Index Page + First Components\n\nI started with the index page to validate the setup end-to-end — routing, CSS imports, layout — before anyone else touched the codebase. Once that was solid, I built the first two shared components:\n\n  * **TeamMembers** — displays the team section on the public-facing pages\n  * **SuggestionDrawer** — a slide-in drawer for user suggestions\n\n\n\nThese were deliberately simple. I wanted them as reference points for how components should be structured in this project before other team members started contributing.\n\n###  `api.ts` — The Single HTTP Client\n\nInstead of letting every file do its own `fetch`, I created a centralised HTTP client:\n\n\n\n    // lib/api.ts\n    const BASE_URL = process.env.NEXT_PUBLIC_API_URL;\n\n    async function request<T>(\n      method: string,\n      endpoint: string,\n      body?: unknown\n    ): Promise<T> {\n      const res = await fetch(`${BASE_URL}${endpoint}`, {\n        method,\n        headers: { \"Content-Type\": \"application/json\" },\n        body: body ? JSON.stringify(body) : undefined,\n        credentials: \"include\",\n      });\n\n      if (!res.ok) throw new Error(`${method} ${endpoint} → ${res.status}`);\n      return res.json();\n    }\n\n    export const api = {\n      get: <T>(endpoint: string) => request<T>(\"GET\", endpoint),\n      post: <T>(endpoint: string, body: unknown) => request<T>(\"POST\", endpoint, body),\n      patch: <T>(endpoint: string, body: unknown) => request<T>(\"PATCH\", endpoint, body),\n      del: <T>(endpoint: string) => request<T>(\"DELETE\", endpoint),\n    };\n\n\nThen I created `lifestyle-api.ts` — a thin wrapper around `api.ts` that scoped all requests to the `/lifestyle` backend route. This gave other team members a focused, simple API surface for that part of the product without them needing to know the full backend structure.\n\n##  Week 2: Admin, Auth, and Access Control\n\n###  Reworking Authentication — localStorage → Cookies\n\nThe legacy frontend stored the auth token in `localStorage`. That's fine for simple apps, but it's vulnerable to XSS and it makes server-side auth checks impossible. I migrated to **NextAuth** with **httpOnly cookies**.\n\nThe key pieces:\n\n**Custom API routes for login/logout:**\n\n\n\n    // app/api/auth/login/route.ts\n    import { cookies } from \"next/headers\";\n\n    export async function POST(req: Request) {\n      const { email, password } = await req.json();\n\n      const res = await fetch(`${process.env.API_URL}/auth/login`, {\n        method: \"POST\",\n        headers: { \"Content-Type\": \"application/json\" },\n        body: JSON.stringify({ email, password }),\n      });\n\n      if (!res.ok) return Response.json({ error: \"Invalid credentials\" }, { status: 401 });\n\n      const { token } = await res.json();\n\n      cookies().set(\"token\", token, {\n        httpOnly: true,\n        secure: process.env.NODE_ENV === \"production\",\n        sameSite: \"lax\",\n        path: \"/\",\n      });\n\n      return Response.json({ ok: true });\n    }\n\n\n\n    // app/api/auth/logout/route.ts\n    import { cookies } from \"next/headers\";\n\n    export async function POST() {\n      cookies().delete(\"token\");\n      return Response.json({ ok: true });\n    }\n\n\nThe token never touches the client — it lives in an httpOnly cookie the browser manages automatically.\n\n###  Middleware for Protected Routes\n\nNext.js middleware runs before a request hits any page. I used it to protect all admin routes:\n\n\n\n    // middleware.ts\n    import { NextResponse } from \"next/server\";\n    import type { NextRequest } from \"next/server\";\n\n    export function middleware(request: NextRequest) {\n      const token = request.cookies.get(\"token\");\n\n      if (!token) {\n        return NextResponse.redirect(new URL(\"/login\", request.url));\n      }\n\n      return NextResponse.next();\n    }\n\n    export const config = {\n      matcher: [\"/admin/:path*\"],\n    };\n\n\nClean, centralised, impossible to bypass by navigating directly to a URL.\n\n###  Admin Pages\n\nWith auth solid, I built out:\n\n  * **Admin Dashboard** — overview metrics, quick actions\n  * **Admin Navbar + Sidebar** — shared layout components inside `(admin)/layout.tsx`\n  * **Admin Renderers** — reusable display components used across dashboard views\n  * **`/admin/content-manager`** — lists all content pieces\n  * **`/admin/content-manager/editor`** — full rich-text editor for creating and updating content\n\n\n\n##  On the Deployment Strategy\n\nI own all deployments — both the new Next.js frontend and the backend. The legacy Vanilla JS frontend is still live and running in parallel.\n\nMy personal take on how this should be handled: **don't rush killing the legacy version.** If I had the call, I'd keep both live for at least a month after the new one is stable, watch for unexpected errors, and only decommission the old one once we're confident. For a product with active users, the right approach is a gradual traffic migration — send a small percentage to the new frontend, validate it handles the load, then shift everyone over. Rushing that step is how you cause an outage.\n\n##  What I'd Do Differently\n\n  * **Set up the normalisation layer before anything else,** not alongside the first components. A week in, I was backfilling types for things I'd already built.\n  * **Document the route group structure on day one.** A few teammates added pages in the wrong group early on because the convention wasn't written down yet.\n  * **Add a shared error boundary early.** We added it later and had to retrofit it — easier to start with one.\n\n\n\n##  Maintenance\n\nThe new frontend is now in active development. I maintain it going forward. The backend and legacy frontend are maintained by Grace.\n\n##  Final Thoughts\n\nMigrations are less about the code and more about the decisions you make before you write any. The CSS class naming convention, the route groups, the normalisation layer, the single HTTP client — none of those are complicated individually. Together, they made it possible for a small team to move fast without creating a new mess to replace the old one.\n\nIf you're planning a similar migration, the main thing I'd say is: **design the constraints first, then build inside them.**\n\n_Found this useful? Drop a reaction or share it — and feel free to ask questions in the comments._",
  "title": "How We Migrated Bloom After from Vanilla JS to Next.js + TypeScript"
}