NestJS patterns -- modules, DI, exception filters, validation pipes, guards, interceptors, testing, config
98
89%
Does it follow best practices?
Impact
100%
1.36xAverage score across 12 eval scenarios
Passed
No known issues
A food delivery platform has an existing NestJS backend where a NotificationsController directly instantiates SMS and email clients using new SmsClient() and new EmailClient() inside the controller methods. The backend team has flagged this as a problem: it's impossible to test the controller in isolation, and any business logic changes require touching HTTP-level code. They also noticed that the controller is performing validation logic, price calculations, and message formatting — none of which belong there.
You have been asked to refactor the notifications feature into a proper NestJS architecture. There should be a NotificationsService that handles all business logic (composing messages, choosing SMS vs email based on user preference, etc.) and a lean controller that only deals with HTTP concerns. The service should depend on separate SmsService and EmailService providers that are themselves injectable. None of these services should reach into the HTTP request/response layer.
Write the refactored notifications module from scratch. You can use in-memory stubs for SmsService and EmailService — no real external clients are needed.
Produce TypeScript source files in notifications-api/src/:
notifications/notifications.module.tsnotifications/notifications.controller.tsnotifications/notifications.service.tsnotifications/sms.service.tsnotifications/email.service.tsnotifications/dto/send-notification.dto.tsInclude a brief README.md describing how the dependency injection is wired up.
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
nestjs-best-practices
verifiers