DEV Community: Kshyatisekhar Panda

Stop Writing Types Twice: A Fullstack TypeScript Playbook

Kshyatisekhar Panda — Wed, 08 Apr 2026 19:45:55 +0000

If you're building fullstack with JavaScript (React on the front, Node.js on the back, TypeScript across both) you've hit this wall before. You define an interface on the backend. You define the same interface on the frontend. They drift apart. Bugs happen. Nobody notices until production.

This post walks through a pipeline where you define your data shape once as a Zod schema on the backend, and every other layer (API docs, frontend types, React Query hooks) is generated from it automatically using Orval. Change the schema, regenerate, and TypeScript tells you exactly what broke. Across the entire stack.

No shared packages to publish. No Swagger YAML to maintain by hand. No "hey can you update the frontend types" Slack messages.

A quick note: we're still in the process of learning and fully adopting this flow ourselves. We haven't battle-tested every edge case, and our team is still building muscle memory around the workflow. But the early results have been promising enough that I wanted to share what we've seen so far. Think of this less as "here's the perfect setup" and more as "here's a path worth exploring if you're dealing with the same pain."

The Flow

Here's how a single type definition moves through each layer. Every arrow is automated.

Backend owns the data shape:
SQL Query → Service Layer → Zod Schema → OpenAPI Spec (JSON)

Frontend consumes the contract:
OpenAPI Spec → Orval codegen → TypeScript interfaces + React Query hooks + typed fetch calls → React Components

The OpenAPI spec is the handshake between the two sides. Generated, not handwritten.

Backend: Define Once

The backend team owns three things: talking to the database, defining the data shape, and producing the API contract.

The Database Query

You write SQL. You get rows with database-native column names.

// comments.query.ts
export const GET_COMMENTS_QUERY = `
  SELECT ID, TASK_ID, AUTHOR_ID, BODY_TEXT, CREATED_AT
  FROM TASK_COMMENTS
  WHERE TASK_ID = :p_task_id
`;

The Service Layer

Maps database naming to JavaScript naming. This is the only manual mapping in the entire pipeline.

// comments.service.ts
private static mapRow(row: Record<string, unknown>) {
  return {
    commentId: row.ID,
    taskId:    row.TASK_ID,
    authorId:  row.AUTHOR_ID,
    body:      row.BODY_TEXT,
    createdAt: row.CREATED_AT,
  };
}

BODY_TEXT becomes body. This happens in one place. If the database column changes, this is the only line you update.

The Zod Schema

This is where one definition does three jobs at once.

// comments.schema.ts
export const ZCommentSchema = z.object({
  commentId: z.number().int().positive()
    .meta({ description: 'Unique comment identifier' }),
  taskId:    z.number().int().positive(),
  authorId:  z.number().int().positive(),
  body:      z.string().max(4000)
    .meta({ description: 'Comment text content' }),
  createdAt: z.string().datetime(),
});

// TypeScript type derived, not duplicated
export type Comment = z.infer<typeof ZCommentSchema>;

// Response wrapper
export const ZGetCommentsResponseSchema = z.object({
  status: z.literal('success'),
  data: z.array(ZCommentSchema),
});

What you get from this single definition:

Runtime validation. Bad data is rejected before it leaves your controller.

TypeScript type. z.infer<> gives you the type. No separate interface needed.

API documentation. Those .meta() descriptions flow into the OpenAPI spec and eventually into the frontend dev's IDE tooltip.

The Route Definition

Your Express route wires the Zod schema into the API spec:

// swagger-specification.ts
'/tasks/{taskId}/comments': {
  get: {
    operationId: 'getComments',
    responses: {
      '200': {
        content: {
          'application/json': {
            schema: ZGetCommentsResponseSchema,
          },
        },
      },
    },
  },
},

OpenAPI Spec Generation

A build script serializes everything into an OpenAPI JSON file. You never edit that JSON. It's an artifact.

yarn generate:openapi

This JSON file is the contract. It's the only thing the frontend needs from the backend. No meetings, no Slack threads, no "what does this endpoint return?"

Frontend: Generate Everything

The frontend team owns two things: generating typed hooks from the contract, and building the UI with them.

Orval Configuration

Orval reads the backend's OpenAPI JSON and generates everything the frontend needs. It supports React Query, SWR, Angular, and plain axios/fetch out of the box.

// orval.config.ts
export default defineConfig({
  api: {
    input: { target: '../../services/api/openapi-specs/api.json' },
    output: {
      target: 'src/api/gen',
      client: 'react-query',
      httpClient: 'fetch',
      override: {
        mutator: {
          path: './src/api/fetchInstance.ts',
          name: 'fetchInstance',
        },
      },
    },
  },
});

The Fetch Instance

Your custom fetch wrapper. This is the only hand-written API code on the frontend.

// fetchInstance.ts
export const fetchInstance = async <T>(
  url: string,
  init?: RequestInit,
): Promise<T> => {
  const response = await fetch(`${BASE_URL}${url}`, {
    ...init,
    credentials: 'include',
  });

  const data = await response.json();

  if (!response.ok) {
    throw new ApiError(response.status, response.statusText, data);
  }

  return data as T;
};

Code Generation

Run yarn generate:specs. Orval produces a file you never touch:

// gen/api.ts — AUTO-GENERATED, DO NOT EDIT

export interface GetComments200DataItem {
  /** Unique comment identifier */
  commentId: number;
  taskId: number;
  authorId: number;
  /** Comment text content */
  body: string;
  createdAt: string;
}

export function useGetComments(
  taskId: number,
  options?: ...
): UseQueryResult<GetComments200, ApiError> {
  // fully wired TanStack Query hook
}

You didn't write that interface. You didn't write that hook. They exist because the backend's Zod schema exists. The descriptions from .meta() are now JSDoc comments. Hover in VS Code, there they are.

Your React Component

Just use the hook. Everything is typed.

export const CommentsSection = ({ taskId }: { taskId: number }) => {
  const { data, isFetching } = useGetComments(taskId);

  return (
    <List>
      {data?.data.map((comment) => (
        <ListItem key={comment.commentId}>
          <ListItemText
            primary={comment.body}
            secondary={`User ${comment.authorId} · ${comment.createdAt}`}
          />
        </ListItem>
      ))}
    </List>
  );
};

Try typing comment. and your IDE shows exactly what's available. Try comment.bodyText and you get a red squiggly. Not a runtime bug. A compile-time error.

What Changes Feel Like

Backend adds a field: Add editedAt to the Zod schema. The OpenAPI spec updates automatically. Tell the frontend team to regenerate.

Frontend regenerates: Run yarn generate:specs. The type now has editedAt. IDE autocompletes it. No guessing.

Backend renames a field: Change body to content in the Zod schema. Frontend regenerates. TypeScript lights up every component that still says .body. Fix them. Ship.

Backend removes a field: Delete it from the schema. Frontend regenerates. TypeScript shows every line that references something that no longer exists.

The compiler becomes the sync mechanism between teams. Not discipline. Not Slack. The compiler.

Where It Breaks Down

We're still early in adopting this, and we've already found the rough edges.

DB to service mapping is still manual. If someone renames a column in the database and doesn't update the service layer, you get undefined at runtime. Zod doesn't know about your SQL. Integration tests against a real database are the only real safety net here. This is the weakest link in the chain.

The fetch layer trusts the backend. The return data as T cast assumes the backend sent what the spec promises. If it didn't, TypeScript won't catch it. You can add Zod parsing on the response path too, but most teams skip it for performance. We're still debating whether to add it for development builds only.

Stale generated code. If the backend updates a schema and the frontend doesn't regenerate, types are out of sync. We added this to CI:

yarn generate:specs
git diff --exit-code src/api/gen/

Build fails if generated code is out of date. This one we've already implemented, and it's caught things.

Team habits take time. The tooling is the easy part. Getting everyone to trust the generated code, stop writing manual interfaces, and remember to regenerate. That's the real adoption curve. Some team members still instinctively create frontend types by hand. We have to remind ourselves to delete them and use the generated ones.

What You Need

Tool	Purpose
Zod + zod-openapi	Define schemas, convert to OpenAPI
Orval	Read OpenAPI, generate React Query hooks
TanStack Query	Data fetching and caching
TypeScript strict mode	Makes the whole chain enforceable

If you're already using Zod and TanStack Query, you're halfway there. The gap is just adding zod-openapi and Orval. Maybe half a day of setup.

The Point

After enough years of fullstack JavaScript, the pattern is always the same: the bugs that hurt don't come from complex logic. They come from two sides of the stack disagreeing about the shape of data.

This pipeline draws a clean line. Backend owns the shape. Frontend consumes the shape. An OpenAPI spec is the handshake between them. Generated, not handwritten, never out of date.

We're not going to pretend we've got it all figured out. We're still learning the workflow, still smoothing out the edges, still catching ourselves falling back to old habits. But the direction feels right. The few times the compiler has caught a type mismatch that would've been a runtime bug, those moments make the investment feel worth it.

If you're dealing with the same frontend-backend sync headaches, this is worth a spike. Set it up on one endpoint. See how it feels. That's what we did, and we haven't looked back.

Building My Portfolio with AI as a Pair Programmer

Kshyatisekhar Panda — Tue, 07 Apr 2026 21:41:45 +0000

I've been a full stack developer for over 7 years. I've built dashboards, APIs, real-time apps, and enterprise software. But I'd never built a proper portfolio site for myself. It was always on the list, never at the top.

What changed was Claude Code. I wanted to try AI-assisted development on a real project, not a toy example. And I wanted to learn Astro at the same time. So I opened a terminal and started a conversation.

This post is about what that experience was actually like.

The Setup

I started with an empty directory and a vague idea. I knew I wanted a dark-themed portfolio that showed my work, my career history, my cricket stats, and some travel photography. I didn't have a design in mind. I didn't have a Figma file. I just had a list of things I wanted on the page.

I told Claude what I was looking for and it scaffolded an Astro project with TypeScript in strict mode. Within minutes I had a full project structure with components for each section: Hero, About, Skills, Projects, Beyond Code, Contact, and a Footer.

That first version was fast. Maybe too fast.

The First Version Was Too Much

The initial design had a lot going on. The hero section had a video background with a blur filter, a grain texture overlay, an accent gradient, and a dark overlay on top of all that. Every section had hover animations. There were four cards in a row that felt cramped on most screens.

I looked at it and told Claude it felt like too much. That one comment changed the direction of the whole project. Claude agreed and suggested stripping the hero down to just video plus a dark overlay, changing the Beyond Code section to a 2x2 grid, and hiding the empty travel gallery until I had actual photos.

This was the moment I realized what AI pair programming is really about. It's not about generating code. It's about having a conversation where you steer the direction and the AI handles the execution.

Debugging Emoji Rendering

One of the more unexpected bugs was emoji rendering. I wanted emojis for the Beyond Code section. Cricket bat, football, airplane, video camera. Claude used unicode escape sequences like \uD83C\uDFCF in the Astro template.

They rendered as literal text. Instead of a cricket bat emoji, the page showed the string \uD83C\uDFCF.

The issue was that Astro's HTML template doesn't evaluate unicode escapes the way JavaScript string literals do. The fix was simple: use actual emoji characters instead of escape sequences. But diagnosing it required understanding how Astro processes templates differently from JavaScript.

Extracting My LinkedIn Data

I wanted my real career history on the site, not placeholder text. But LinkedIn blocks automated access. Every fetch attempt returned HTTP 999.

So I saved the page source from my browser and gave it to Claude. The file was 1.3MB, two lines of heavily escaped React SSR data. Not exactly readable.

Claude searched through the data using pattern matching. It found my job titles, company names, and education buried inside nested React component trees. Things like "children":["Senior Analyst Programmer at ..."] hidden among thousands of lines of tracking data and UI component definitions.

From that mess it extracted my complete career timeline: six roles across India and Sweden, from trainee to senior developer, plus early internships and my university education. All real, all accurate.

That was genuinely impressive. I wouldn't have had the patience to parse that file manually.

Adding Travel Photography

I dropped some photos into the project directory. A shot of Trollstigen in Norway, two Northern Lights photos from Kiruna and Abisko, a Stockholm sunset, kayaks by the Norwegian fjords, and a winter campfire scene.

One of the photos was a .dng file (a RAW camera format). Claude converted it to JPEG using sharp-cli, then resized and optimized all six images from 21MB down to about 650KB total. It set up a gallery grid with hover overlays showing the location of each photo.

When I told Claude the Northern Lights photos were from Kiruna and Abisko (not just "Scandinavia"), it updated the captions immediately. Small detail, but it matters. These are my photos and my memories. Getting the locations right matters.

Theme Toggle

I mentioned wanting both dark and light themes. Claude added CSS custom properties for a light theme, a moon/sun toggle button in the navbar, localStorage persistence, and a script that runs before the page renders to prevent a flash of the wrong theme.

It also respects the system preference on first visit. If your OS is set to light mode, the site starts in light mode. That kind of detail is easy to forget but makes a real difference.

What Worked

Speed. The entire site went from empty directory to deployed on Vercel in one session. Components, styles, responsive design, animations, image optimization, blog setup with Astro content collections. All of it.

Iteration. The back and forth felt natural. I'd describe what I wanted, Claude would build it, I'd review and push back, and we'd converge on something good. It wasn't me accepting whatever was generated. It was a real collaboration.

Learning Astro. I came in knowing React and left understanding a fundamentally different approach to frontend development. Astro's component model, its zero-JS-by-default philosophy, content collections, and island architecture. I learned all of it by building, not by reading docs.

What Didn't Work

First drafts are generic. Claude's initial text for my experience descriptions was made up. Generic lines like "Developed enterprise-grade software solutions" that could apply to anyone. I had to call that out and provide my real career data. AI can't know what you actually did at your job.

Unicode in Astro templates. This one caught us both off guard. It's the kind of framework-specific gotcha that AI doesn't always know about until it fails.

You still need taste. Claude will build whatever you ask for. If you ask for grain textures, blur filters, and gradient overlays all at once, you'll get exactly that. It takes a human to look at the result and say "this is too much."

What I'd Tell Other Developers

Try it. Not as a replacement for knowing how to code, but as a way to move faster on things you already understand conceptually. I knew what I wanted in a portfolio. I knew what good frontend code looks like. Claude helped me get there without spending a week on CSS.

Stay in the driver's seat. Review every line. Push back when something feels off. The best results came from me being specific about what I wanted and honest about what wasn't working.

Use it to learn. I specifically chose Astro because I didn't know it. Having an AI that could scaffold, explain, and iterate on Astro code while I was learning it was genuinely useful. It's like having a coworker who already knows the framework you're picking up.

The Result

The site is live at kshyatisekhar-panda.vercel.app. The code is on GitHub. It has a video hero, career timeline, skills grid, project showcase, cricket stats, travel photography, a resume viewer, a blog (you're reading it), and light/dark theme support.

Every line of code was written through conversation. Not generated and forgotten, but discussed, reviewed, and refined.

That's what AI pair programming looks like in practice.