I’ve been thinking a lot about type safety lately. Why? Because last month, I spent three days debugging an API issue that traced back to a simple type mismatch. That frustration led me to explore how we can build GraphQL APIs with end-to-end type safety using NestJS, Prisma, and a code-first approach. The results were game-changing, and I want to share them with you.
Let’s start by setting up our project. First, install the core dependencies:
npm install @nestjs/graphql graphql @nestjs/prisma prismaThis gives us the foundation for both GraphQL and database operations. Now, configure the GraphQL module in app.module.ts:
GraphQLModule.forRoot({
autoSchemaFile: 'schema.gql',
buildSchemaOptions: { dateScalarMode: 'timestamp' }
})Notice how we’re generating the schema automatically? That’s the code-first magic at work. Have you ever struggled with keeping your schema and resolvers in sync?
For our database, Prisma brings strong typing to the table. Here’s a sample user model:
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
posts Post[]
}Run npx prisma generate and watch as TypeScript interfaces appear automatically. Now when we create a resolver, we get full type checking:
@Resolver(() => User)
export class UsersResolver {
constructor(private prisma: PrismaService) {}
@Query(() => [User])
async users(): Promise<User[]> {
return this.prisma.user.findMany();
}
}See how the return type matches our GraphQL type? That’s the safety net I wish I’d had earlier. But what about relationships? Let’s add posts:
@ObjectType()
export class Post {
@Field(() => ID)
id: number;
@Field()
title: string;
}
@Resolver(() => User)
export class UsersResolver {
@FieldResolver(() => [Post])
async posts(@Parent() user: User) {
return this.prisma.user.findUnique({
where: { id: user.id }
}).posts();
}
}The @FieldResolver decorator handles nested data with complete type safety. How much time would this save in your current project?
Authentication is where many APIs stumble. Let’s implement a secure approach:
@UseGuards(GqlAuthGuard)
@Mutation(() => AuthPayload)
async login(@Args('input') input: LoginInput) {
const user = await this.authService.validateUser(input);
return {
token: this.jwtService.sign({ userId: user.id }),
user
};
}The GqlAuthGuard extends Passport.js to protect our endpoints. For real-time features, subscriptions are surprisingly straightforward:
@Subscription(() => Post, {
filter: (payload, variables) =>
payload.postAdded.userId === variables.userId
})
postAdded(@Args('userId') userId: number) {
return pubSub.asyncIterator('postAdded');
}Performance matters too. We solve N+1 queries with Prisma’s dataloader integration:
const userLoader = new Dataloader(ids =>
prisma.user.findMany({
where: { id: { in: ids } }
})
);Testing might seem challenging but is quite manageable:
it('creates user', async () => {
const result = await testApp.execute({
query: `mutation {
createUser(data: { email: "[email protected]" }) { id }
}`
});
expect(result.data.createUser.id).toBeDefined();
});For security, we add rate limiting and query complexity analysis. In main.ts:
const server = new ApolloServer({
plugins: [
ApolloServerPluginLandingPageLocalDefault(),
queryComplexityPlugin({
maxComplexity: 1000
})
]
});Deployment to platforms like Vercel takes minutes with proper Docker configuration. Monitoring? I prefer OpenTelemetry with Prometheus.
This stack has transformed how I build APIs. The type safety catches errors early, Prisma simplifies database work, and NestJS provides structure. Give it a try - I think you’ll find the developer experience as rewarding as I do. What pain points would this solve in your workflow?
If this approach resonates with you, share it with your team. Questions or insights? Let’s discuss in the comments below - your experiences might help others too. Like this article if you found it useful!
