- Home
- Skills
- Yanko Belov
- Code Craft
- N Plus One Prevention
n-plus-one-prevention_skill
- TypeScript
6
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill yanko-belov/code-craft --skill n-plus-one-prevention- SKILL.md4.7 KB
Overview
This skill prevents N+1 database queries by enforcing eager loading and single-query patterns when fetching related data. I focus on spotting queries inside loops and transforming them into JOINs, includes, or aggregate queries. The goal is predictable, constant query counts and fast list endpoints as data grows.
How this skill works
The skill inspects code for database queries executed inside loops or array iterations and flags patterns that produce 1 + N queries. It suggests concrete replacements using ORM eager loading (include/relations/select), raw SQL joins, or grouped aggregates so related data is fetched in a single query. It also provides runtime detection guidance by counting queries per request and emitting alerts when counts exceed a threshold.
When to use it
- You see await or DB calls inside map(), forEach(), or any loop.
- List or index endpoints are slower than single-item endpoints.
- One API response triggers many database queries for related records.
- You notice query count growing linearly with result size.
- Preparing a code review or performance audit for database-heavy routes.
Best practices
- Never put a database query inside a loop — always refactor to eager loading or a single aggregate query.
- Learn and use your ORM's include/relations/select syntax for joins and nested relations.
- Prefer a single optimized query over many tiny ones; measure query count per request.
- Use GROUP BY or subqueries for counts/aggregates instead of per-item queries.
- Treat caching as optional; fix the query first, then add cache if needed.
Example use cases
- Replace per-item Customer.findByPk calls with Order.findAll({ include: [Customer] }).
- Compute order counts per user with a single GROUP BY instead of calling count() per user.
- Load products and their suppliers with a single join instead of querying supplier per product.
- Add middleware to log query count per HTTP request and warn when it exceeds 10.
- Refactor endpoints that currently make N+1 queries before traffic increases.
FAQ
No — treat any query inside a loop as a bug. Even small datasets grow and add latency; always refactor to eager loading.
What if my ORM doesn't support eager loading?
Use raw SQL joins or write a subquery that returns related data in one round trip, or switch to an ORM/extension that supports includes.
Can caching solve N+1 issues?
Caching masks symptoms but doesn't fix the underlying pattern. Cache misses still hit the database and complexity increases; fix queries first.