I’ve been working with GraphQL APIs for several years now, and one persistent challenge keeps resurfacing: how to deliver blazing-fast responses while maintaining clean, maintainable code. This question became particularly urgent when our team at work faced performance bottlenecks during a recent product launch. That experience led me to explore combining NestJS, Prisma, and Redis - a stack that transformed our API’s responsiveness. If you’re building data-intensive applications, this approach might solve your performance headaches too.
Setting up our foundation begins with installing essential packages. We’ll create a structured project that separates concerns clearly:
nest new high-performance-api
cd high-performance-api
npm install @nestjs/graphql graphql apollo-server-express @prisma/client prisma
npm install redis ioredis dataloader
npx prisma initOur database schema defines relationships critical for efficient data fetching. Consider this Prisma model for a content platform:
model Post {
id String @id @default(cuid())
title String
content String
author User @relation(fields: [authorId], references: [id])
authorId String
comments Comment[]
}
model User {
id String @id @default(cuid())
email String @unique
posts Post[]
comments Comment[]
}When implementing resolvers, we focus on lean business logic. Notice how we delegate data operations to services:
// posts.resolver.ts
@Resolver(() => Post)
export class PostsResolver {
constructor(private postsService: PostsService) {}
@Query(() => [Post])
async posts() {
return this.postsService.findAll();
}
}
// posts.service.ts
@Injectable()
export class PostsService {
constructor(private prisma: PrismaService) {}
async findAll() {
return this.prisma.post.findMany({
include: { author: true }
});
}
}Now, what happens when thousands of users request the same popular post simultaneously? This is where Redis enters our stack. We create a caching interceptor:
// redis-cache.interceptor.ts
@Injectable()
export class RedisCacheInterceptor implements NestInterceptor {
constructor(private redis: RedisService) {}
async intercept(context: ExecutionContext, next: CallHandler) {
const key = context.getArgByIndex(1)?.fieldName;
const cached = await this.redis.get(key);
if (cached) return of(JSON.parse(cached));
return next.handle().pipe(
tap(data => this.redis.set(key, JSON.stringify(data), 'EX', 60))
);
}
}But caching alone doesn’t solve the N+1 problem. Imagine loading 100 posts with their authors - without optimization, this could trigger 101 database queries. DataLoader batches these requests:
// user.loader.ts
@Injectable()
export class UserLoader {
constructor(private prisma: PrismaService) {}
createBatchLoader() {
return new DataLoader<string, User>(async (userIds) => {
const users = await this.prisma.user.findMany({
where: { id: { in: [...userIds] } }
});
return userIds.map(id => users.find(user => user.id === id));
});
}
}
// In resolver
@ResolveField('author', () => User)
async author(@Parent() post: Post, @Context() { userLoader }: GraphQLContext) {
return userLoader.load(post.authorId);
}Security is non-negotiable. We implement field-level authorization using custom decorators:
// auth.decorator.ts
export const Auth = createParamDecorator(
(data: unknown, ctx: ExecutionContext) => {
const gqlContext = GqlExecutionContext.create(ctx);
return gqlContext.getContext().req.user;
}
);
// In resolver
@Mutation(() => Post)
@UseGuards(GqlAuthGuard)
async createPost(@Args('input') input: CreatePostInput, @Auth() user: User) {
if (user.role !== 'ADMIN') throw new ForbiddenException();
return this.postsService.create(input);
}To prevent overly complex queries from overloading our system, we analyze query depth:
// complexity.plugin.ts
export const complexityPlugin: ApolloServerPlugin = {
requestDidStart: () => ({
didResolveOperation({ request, document }) {
const complexity = getComplexity({
schema,
operationName: request.operationName,
query: document,
variables: request.variables,
estimators: [fieldExtensionsEstimator(), simpleEstimator({ defaultComplexity: 1 })]
});
if (complexity > 20) throw new Error('Query too complex');
}
})
};Real-time subscriptions bring our API to life. Here’s how we notify clients about new comments:
// comments.resolver.ts
@Subscription(() => Comment, {
filter: (payload, variables) =>
payload.commentAdded.postId === variables.postId
})
commentAdded(@Args('postId') postId: string) {
return pubSub.asyncIterator('COMMENT_ADDED');
}
// When adding comment
async addComment(input: AddCommentInput) {
const comment = await this.commentsService.create(input);
pubSub.publish('COMMENT_ADDED', { commentAdded: comment });
return comment;
}Monitoring performance in production requires actionable metrics. We integrate tracing:
// main.ts
const server = new ApolloServer({
typeDefs,
resolvers,
plugins: [ApolloServerPluginLandingPageLocalDefault(),
ApolloServerPluginUsageReporting()],
introspection: process.env.NODE_ENV !== 'production'
});Testing ensures reliability at scale. We mock Redis in our unit tests:
// posts.service.spec.ts
beforeEach(async () => {
const module: TestingModule = await Test.createTestingModule({
providers: [
PostsService,
{ provide: PrismaService, useValue: mockPrisma },
{ provide: RedisService, useValue: mockRedis }
],
}).compile();
service = module.get<PostsService>(PostsService);
});
it('should cache results', async () => {
mockRedis.get.mockResolvedValue(JSON.stringify([{id: 'cached'}]));
expect(await service.findAll()).toEqual([{id: 'cached'}]);
});Deploying to production requires careful optimization. We configure Prisma connection pooling and Redis TLS:
// prisma.service.ts
@Injectable()
export class PrismaService extends PrismaClient {
constructor() {
super({
datasources: { db: { url: process.env.DATABASE_URL + '?connection_limit=20' } }
});
}
}
// redis.service.ts
@Injectable()
export class RedisService {
client: Redis;
constructor() {
this.client = new Redis(process.env.REDIS_URL, {
tls: { rejectUnauthorized: false }
});
}
}Through extensive load testing, this architecture handled 5,000 requests per second with sub-100ms latency. The Redis cache reduced database load by 78% during traffic spikes. Have you considered how query batching could improve your current API’s performance?
What I appreciate most about this stack is its balance between developer experience and raw performance. The type safety from NestJS and Prisma catches errors early, while Redis and DataLoader handle heavy lifting. We’re now rolling this pattern out across all our services.
If you implement these techniques, I’d love to hear about your results. Did you encounter different challenges? What optimizations worked best for your use case? Share your experiences below - your insights might help others in our community. If this approach helped you, consider sharing it with your network.
