Initial commit

skills/implementing-query-pagination/references/api-implementation-examples.md

@@ -0,0 +1,164 @@
+# Complete API Implementation Examples
+
+## Example 1: API Endpoint with Cursor Pagination
+
+```typescript
+import { prisma } from './prisma-client';
+
+type GetPostsParams = {
+  cursor?: string;
+  limit?: number;
+};
+
+export async function GET(request: Request) {
+  const { searchParams } = new URL(request.url);
+  const cursor = searchParams.get('cursor') || undefined;
+  const limit = Number(searchParams.get('limit')) || 20;
+
+  if (limit > 100) {
+    return Response.json(
+      { error: 'Limit cannot exceed 100' },
+      { status: 400 }
+    );
+  }
+
+  const posts = await prisma.post.findMany({
+    take: limit,
+    skip: cursor ? 1 : 0,
+    cursor: cursor ? { id: cursor } : undefined,
+    orderBy: { createdAt: 'desc' },
+    include: {
+      author: {
+        select: { id: true, name: true, email: true },
+      },
+    },
+  });
+
+  const nextCursor = posts.length === limit
+    ? posts[posts.length - 1].id
+    : null;
+
+  return Response.json({
+    data: posts,
+    nextCursor,
+    hasMore: nextCursor !== null,
+  });
+}
+```
+
+**Client usage:**
+
+```typescript
+async function loadMorePosts() {
+  const response = await fetch(`/api/posts?cursor=${nextCursor}&limit=20`);
+  const { data, nextCursor: newCursor, hasMore } = await response.json();
+
+  setPosts(prev => [...prev, ...data]);
+  setNextCursor(newCursor);
+  setHasMore(hasMore);
+}
+```
+
+## Example 2: Filtered Cursor Pagination
+
+```typescript
+type GetFilteredPostsParams = {
+  cursor?: string;
+  authorId?: string;
+  tag?: string;
+  limit?: number;
+};
+
+async function getFilteredPosts({
+  cursor,
+  authorId,
+  tag,
+  limit = 20,
+}: GetFilteredPostsParams) {
+  const where = {
+    ...(authorId && { authorId }),
+    ...(tag && { tags: { some: { name: tag } } }),
+  };
+
+  const posts = await prisma.post.findMany({
+    where,
+    take: limit,
+    skip: cursor ? 1 : 0,
+    cursor: cursor ? { id: cursor } : undefined,
+    orderBy: { createdAt: 'desc' },
+  });
+
+  return {
+    data: posts,
+    nextCursor: posts.length === limit ? posts[posts.length - 1].id : null,
+  };
+}
+```
+
+**Index requirement:**
+
+```prisma
+model Post {
+  id        String   @id @default(cuid())
+  authorId  String
+  createdAt DateTime @default(now())
+
+  @@index([authorId, createdAt, id])
+}
+```
+
+## Example 3: Small Admin Table with Offset
+
+```typescript
+type GetAdminUsersParams = {
+  page?: number;
+  pageSize?: number;
+  search?: string;
+};
+
+async function getAdminUsers({
+  page = 1,
+  pageSize = 50,
+  search,
+}: GetAdminUsersParams) {
+  const skip = (page - 1) * pageSize;
+
+  const where = search
+    ? {
+        OR: [
+          { email: { contains: search, mode: 'insensitive' as const } },
+          { name: { contains: search, mode: 'insensitive' as const } },
+        ],
+      }
+    : {};
+
+  const [users, total] = await Promise.all([
+    prisma.user.findMany({
+      where,
+      skip,
+      take: pageSize,
+      orderBy: { createdAt: 'desc' },
+      select: {
+        id: true,
+        email: true,
+        name: true,
+        role: true,
+        createdAt: true,
+      },
+    }),
+    prisma.user.count({ where }),
+  ]);
+
+  return {
+    data: users,
+    pagination: {
+      page,
+      pageSize,
+      totalPages: Math.ceil(total / pageSize),
+      totalRecords: total,
+      hasNext: page < Math.ceil(total / pageSize),
+      hasPrev: page > 1,
+    },
+  };
+}
+```

skills/implementing-query-pagination/references/bidirectional-pagination.md

@@ -0,0 +1,35 @@
+# Bidirectional Pagination
+
+Support both forward and backward navigation in cursor-based pagination.
+
+## Pattern
+
+```typescript
+async function getBidirectionalPosts(
+  cursor?: string,
+  direction: 'forward' | 'backward' = 'forward',
+  pageSize: number = 20
+) {
+  const posts = await prisma.post.findMany({
+    take: direction === 'forward' ? pageSize : -pageSize,
+    skip: cursor ? 1 : 0,
+    cursor: cursor ? { id: cursor } : undefined,
+    orderBy: { id: 'asc' },
+  });
+
+  const data = direction === 'backward' ? posts.reverse() : posts;
+
+  return {
+    data,
+    nextCursor: data.length === pageSize ? data[data.length - 1].id : null,
+    prevCursor: data.length > 0 ? data[0].id : null,
+  };
+}
+```
+
+## Key Points
+
+- Use negative `take` value for backward pagination
+- Reverse results when paginating backward
+- Return both `nextCursor` and `prevCursor` for navigation
+- Maintain consistent ordering across directions

skills/implementing-query-pagination/references/common-mistakes.md

@@ -0,0 +1,84 @@
+# Common Pagination Mistakes
+
+## Mistake 1: Using non-unique cursor
+
+**Problem:**
+```typescript
+cursor: cursor ? { createdAt: cursor } : undefined,
+```
+
+Multiple records can have the same `createdAt` value, causing skipped or duplicate records.
+
+**Fix:** Use composite cursor with unique field:
+
+```typescript
+cursor: cursor ? { createdAt_id: cursor } : undefined,
+orderBy: [{ createdAt: 'desc' }, { id: 'asc' }],
+```
+
+## Mistake 2: Missing skip: 1 with cursor
+
+**Problem:**
+```typescript
+findMany({
+  cursor: { id: cursor },
+  take: 20,
+})
+```
+
+The cursor record itself is included in results, causing duplicate on next page.
+
+**Fix:** Skip cursor record itself:
+
+```typescript
+findMany({
+  cursor: { id: cursor },
+  skip: 1,
+  take: 20,
+})
+```
+
+## Mistake 3: Offset pagination on large datasets
+
+**Problem:**
+```typescript
+findMany({
+  skip: page * 1000,
+  take: 1000,
+})
+```
+
+Performance degrades linearly with page number on large datasets.
+
+**Fix:** Use cursor pagination:
+
+```typescript
+findMany({
+  cursor: cursor ? { id: cursor } : undefined,
+  skip: cursor ? 1 : 0,
+  take: 1000,
+})
+```
+
+## Mistake 4: Missing index on cursor field
+
+**Problem:**
+Schema without index causes full table scans:
+
+```prisma
+model Post {
+  id        String   @id
+  createdAt DateTime @default(now())
+}
+```
+
+**Fix:** Add appropriate index:
+
+```prisma
+model Post {
+  id        String   @id
+  createdAt DateTime @default(now())
+
+  @@index([createdAt, id])
+}
+```

skills/implementing-query-pagination/references/data-change-handling.md

@@ -0,0 +1,75 @@
+# Handling Data Changes During Pagination
+
+## The Problem
+
+**Offset Pagination Issue:** Duplicates or missing records when data changes between page loads.
+
+### Example Scenario
+
+1. User loads page 1 (posts 1-20)
+2. New post is inserted at position 1
+3. User loads page 2 (posts 21-40)
+4. **Post 21 appears on both pages** (was post 20, now post 21)
+
+### Why It Happens
+
+Offset pagination uses absolute positions:
+- Page 1: Records at positions 0-19
+- Page 2: Records at positions 20-39
+
+When a record is inserted:
+- Page 1 positions: 0-19 (includes new record at position 0)
+- Page 2 positions: 20-39 (old position 20 is now position 21)
+- **Position 20 was seen on page 1, appears again on page 2**
+
+## Cursor Pagination Solution
+
+Cursor pagination is immune to this problem:
+
+```typescript
+const posts = await prisma.post.findMany({
+  take: 20,
+  skip: cursor ? 1 : 0,
+  cursor: cursor ? { id: cursor } : undefined,
+  orderBy: { createdAt: 'desc' },
+});
+```
+
+**Why it works:**
+- Uses record identity (cursor), not position
+- Always starts from the last seen record
+- New records appear in correct position
+- No duplicates or gaps
+
+## Mitigation for Offset Pagination
+
+If you must use offset pagination:
+
+### Strategy 1: Accept the Limitation
+Document behavior for admin tools where occasional duplicates are acceptable.
+
+### Strategy 2: Timestamp Filtering
+Create stable snapshots using timestamp filtering:
+
+```typescript
+const snapshotTime = new Date();
+
+async function getPage(page: number) {
+  return await prisma.post.findMany({
+    where: {
+      createdAt: { lte: snapshotTime },
+    },
+    skip: page * pageSize,
+    take: pageSize,
+    orderBy: { createdAt: 'desc' },
+  });
+}
+```
+
+**Limitations:**
+- Doesn't show new records during pagination session
+- User must refresh to see new data
+
+### Strategy 3: Switch to Cursor
+
+The best solution is to redesign using cursor pagination.

skills/implementing-query-pagination/references/performance-comparison.md

@@ -0,0 +1,43 @@
+# Performance Comparison
+
+## Benchmark: 500k Posts
+
+**Cursor Pagination (id index):**
+- Page 1: 8ms
+- Page 100: 9ms
+- Page 1000: 10ms
+- Page 10000: 11ms
+- **Stable performance**
+
+**Offset Pagination (createdAt index):**
+- Page 1: 7ms
+- Page 100: 95ms
+- Page 1000: 890ms
+- Page 10000: 8,900ms
+- **Linear degradation**
+
+## Memory Usage
+
+Both approaches:
+- Load only pageSize records into memory
+- Similar memory footprint for same page size
+- Database performs filtering/sorting
+
+## Database Load
+
+**Cursor:**
+- Index scan from cursor position
+- Reads pageSize + 1 rows (for hasMore check)
+
+**Offset:**
+- Index scan from beginning
+- Skips offset rows (database work, not returned)
+- Reads pageSize rows
+
+## Optimization Guidelines
+
+1. **Always add indexes** on ordering fields
+2. **Test with realistic data volumes** before production
+3. **Monitor query performance** in production
+4. **Cache total counts** for offset pagination when possible
+5. **Use cursor by default** unless specific requirements demand offset