I found myself staring at another GraphQL API. The schema was in a separate .graphql file, the resolvers were in another folder, and the database models were defined somewhere else. A simple change felt like archaeology, digging through layers to ensure everything still connected. I knew there had to be a better way—a method where my code itself was the single source of truth, from the database all the way to the client.

That’s when I started building APIs with NestJS, Prisma, and a code-first GraphQL approach. The difference was immediate. Let me show you how this combination creates a development experience where everything is connected and type-safe. You’ll write less boilerplate, catch errors before runtime, and build features faster.

We start with a simple idea: define your data structures as TypeScript classes. These classes become your GraphQL types, your validation rules, and with Prisma, your database schema. Think of it like building with LEGO blocks that only fit together the right way. If you try to connect incompatible pieces, your editor will tell you immediately.

Let’s set up our project. First, create a new NestJS application and install the essentials.

nest new blog-api
cd blog-api
npm install @nestjs/graphql @nestjs/apollo graphql apollo-server-express prisma @prisma/client

Now, configure the GraphQL module in your main app file. This is where the magic starts. We tell NestJS to generate the schema from our code.

// app.module.ts
import { Module } from '@nestjs/common';
import { GraphQLModule } from '@nestjs/graphql';
import { ApolloDriver, ApolloDriverConfig } from '@nestjs/apollo';
import { join } from 'path';
import { PrismaModule } from './prisma/prisma.module';
import { PostsModule } from './posts/posts.module';

@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: join(process.cwd(), 'src/schema.gql'),
      sortSchema: true,
    }),
    PrismaModule,
    PostsModule,
  ],
})
export class AppModule {}

Did you notice the autoSchemaFile path? That’s the file that will be auto-generated for you. You never have to write or manually update a .graphql file again.

Next, we define our data. With Prisma, your database schema is your foundation. Here’s a simple example for a blog post.

// prisma/schema.prisma
generator client {
  provider = "prisma-client-js"
}

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

model Post {
  id        String   @id @default(cuid())
  createdAt DateTime @default(now())
  title     String
  content   String
  published Boolean  @default(false)
}

Run npx prisma generate after this. Prisma will create a powerful, type-safe client for you. Now, the real question is, how do we expose this model through GraphQL without repeating ourselves? We use the code-first approach.

We create a corresponding class for our GraphQL object type using NestJS decorators. This class is both a TypeScript entity and a blueprint for our GraphQL schema.

// posts/models/post.model.ts
import { ObjectType, Field, ID } from '@nestjs/graphql';

@ObjectType()
export class Post {
  @Field(() => ID)
  id: string;

  @Field()
  createdAt: Date;

  @Field()
  title: string;

  @Field()
  content: string;

  @Field()
  published: boolean;
}

This is our GraphQL type. But how do we get data into it? That’s the job of the resolver. The resolver’s methods map directly to our GraphQL operations. See how the return type is our Post model? That’s the type-safety link.

// posts/posts.resolver.ts
import { Resolver, Query, Args } from '@nestjs/graphql';
import { Post } from './models/post.model';
import { PostsService } from './posts.service';

@Resolver(() => Post)
export class PostsResolver {
  constructor(private readonly postsService: PostsService) {}

  @Query(() => [Post])
  async posts(): Promise<Post[]> {
    return this.postsService.findAll();
  }

  @Query(() => Post, { nullable: true })
  async post(@Args('id', { type: () => ID }) id: string): Promise<Post | null> {
    return this.postsService.findOne(id);
  }
}

The service is where Prisma shines. We inject the Prisma client, and it gives us full autocomplete for our database queries. The Post type here comes from @prisma/client, ensuring the data shape matches exactly what the database returns.

// posts/posts.service.ts
import { Injectable } from '@nestjs/common';
import { PrismaService } from '../prisma/prisma.service';
import { Post } from '@prisma/client';

@Injectable()
export class PostsService {
  constructor(private prisma: PrismaService) {}

  async findAll(): Promise<Post[]> {
    return this.prisma.post.findMany();
  }

  async findOne(id: string): Promise<Post | null> {
    return this.prisma.post.findUnique({
      where: { id },
    });
  }
}

We’ve just created a fully functional, type-safe GraphQL endpoint. From the database query to the API response, every object property is known and checked by TypeScript. Making a change is now straightforward. Add a new field to the Prisma model, run prisma generate, add the @Field() decorator to your GraphQL model, and update your service—all with your IDE guiding you.

This approach extends beautifully to more complex scenarios. Need to create a post? Define an InputType. Want to validate data? Use class-validator decorators right on your input class. Implementing authorization becomes clearer because you can protect individual fields or resolvers based on user roles.

What happens when you need real-time updates? GraphQL subscriptions integrate seamlessly. You can publish events from your services and have resolvers listen to them, all while maintaining the same type-safe structure.

The performance benefit is significant. The generated Prisma client is optimized, and the Apollo Server behind NestJS offers caching, query planning, and tracing out of the box. You build on a robust foundation.

This method changed how I think about API development. It turns a fragmented process into a coherent, streamlined workflow. The confidence that comes from compile-time checks is something you quickly grow to depend on.

Give this approach a try in your next project. Start with a single model and experience the flow of type-safe development. I’m curious, what’s the first type of API you would build with this stack? Share your thoughts in the comments below. If you found this guide helpful, please like and share it with other developers who might be stuck in schema-file archaeology.