Backend Queries

Automate Prisma backend data access with repositories, transactions, and soft deletes.

1|Updated Dec 4, 2024
One-click install
npx skills add https://github.com/imkdw/imkdw-dev --skill backend-queries-imkdw
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: Backend Queries
Source: https://github.com/imkdw/imkdw-dev/tree/main/.claude/skills/backend-queries
Command: npx skills add https://github.com/imkdw/imkdw-dev --skill backend-queries-imkdw

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Inefficient or improperly managed database queries can lead to slow application performance, resource exhaustion, and data inconsistencies, impacting user experience and system stability. This Skill ensures optimal and reliable database interactions.

Core Features & Use Cases

  • Repository Pattern: Abstract database access with dedicated repository classes, promoting clean architecture and testability.
  • Prisma ORM: Leverage Prisma for type-safe, efficient, and readable database queries, reducing common ORM pitfalls.
  • Transaction Management: Ensure data consistency and atomicity by wrapping multiple operations in prisma.$transaction(), preventing partial updates.
  • Soft Delete Pattern: Implement and consistently apply soft delete logic (filtering deletedAt: null) across all queries, preserving historical data without permanent deletion.
  • Use Case: When implementing a CreateArticleUseCase, ensure that the article creation and any related tag associations are wrapped in a single Prisma transaction to guarantee atomicity, and that all read operations automatically filter soft-deleted articles.

Quick Start

Guide me in creating a new repository method findBySlug for the ArticleRepository that retrieves an article by its slug, ensuring soft-deleted records are excluded and it accepts an optional Prisma transaction client.

Frequently Asked Questions about Backend Queries

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize database queries in a Prisma application?

Optimize Prisma queries by using eager loading with `include` and `select`, wrapping multiple operations in `prisma.$transaction()` for atomicity, filtering soft-deleted records with `deletedAt: null`, and implementing the repository pattern to centralize and cache efficient data access logic across your application.

What's the best way to handle transactions in Prisma to ensure data consistency?

Use `prisma.$transaction()` to wrap multiple database operations into a single atomic unit, preventing partial updates and ensuring all changes succeed or fail together. Pass the transaction client to repository methods that participate in the transaction for coordinated execution.

How do I implement soft deletes with Prisma across all queries?

Add a `deletedAt` timestamp field to your schema, then filter `deletedAt: null` consistently in all read queries and repository methods. Soft delete by updating `deletedAt` instead of removing records, preserving historical data while keeping queries automatically exclude deleted rows.

Can I use the repository pattern with Prisma in a layered architecture?

Yes. Place repository classes in `shared/repository/`, use-case classes in `features/{feature}/use-case/`, and read-only query classes alongside them. Each layer maps Prisma results to domain objects, maintaining clean separation and testability across your application's data access tiers.

Why should I abstract database access with repositories instead of querying Prisma directly?

Repositories centralize query logic, reduce duplication, improve testability through dependency injection, enforce consistent patterns like soft delete filtering and transaction handling, and make switching database implementations easier without rewriting business logic.

What happens if I don't wrap related database operations in a transaction?

Without transactions, partial failures leave your database in an inconsistent state—for example, creating an article succeeds but associating tags fails, orphaning data. Transactions guarantee atomicity: all operations complete or all roll back together.