Yazılara Sayfalama Eklerken: Hangi Katman Neyi Biliyor
Yazı sayısı arttıkça ana sayfa usePosts() ile tüm yayınlanmış yazıları tek seferde çekiyordu — 20+ yazı ile bu hem gereksiz veri transferi hem de kullanıcıya anlamsız derecede uzun bir sayfa demek. Çözüm, projelerde zaten var olan sayfalama desenini posts'a taşımaktı — ama kategori olmadığı için deseni biraz sadeleştirerek.
API tarafı: groupBy yok, çünkü kategori yok
// apps/api/src/posts/posts.service.ts
async listPublished({ page, pageSize }: ListPostsQuery) {
const where = { published: true };
const [items, total] = await Promise.all([
this.prisma.post.findMany({ where, orderBy: { createdAt: 'desc' }, skip: (page - 1) * pageSize, take: pageSize }),
this.prisma.post.count({ where }),
]);
return { items, total, page, pageSize, totalPages: Math.max(1, Math.ceil(total / pageSize)) };
}
Projelerin categoryCounts alanı (her kategori sekmesi için tüm katalog üzerinden hesaplanan sayaç) burada yok — posts'ta filtrelenebilir bir kategori yok, sadece published: true sabit filtresi var. Aynı Promise.all([findMany, count]) deseni korunuyor, ama şema daha küçük: paginatedPostsSchema'da categoryCounts alanı hiç yok.
Web tarafı: ana sayfa "teaser", /posts "tam liste"
Ana sayfa artık usePosts({ pageSize: 3 }) ile sadece son 3 yazıyı çekiyor ve altına "Tüm yazıları gör" linkiyle yeni bir /posts sayfasına yönlendiriyor — tıpkı /projects'in kendi sayfası olduğu gibi. Bu ayrım bilinçli: ana sayfa bir "vitrin", /posts ise gerçek arşiv. İki farklı UX ihtiyacı (hızlı önizleme vs. tam gezinme) iki farklı sayfaya karşılık geliyor, tek sayfaya sıkıştırılmaya çalışılmıyor.
Admin tarafı neden hiç değişmedi
/posts/admin endpoint'i (ve apps/admin'in usePosts()'u) bu değişiklikten tamamen bağımsız kaldı — zaten listAll() ile tüm yazıları dönüyordu, projelerdeki "admin tüm kataloğu yönetir, sayfalanmış görünüm değil" ilkesiyle tutarlı. Yayınlanmış/taslak ayrımı olmadan, admin panelinde 20-30 yazıyı tek tabloda görmek hâlâ makul; sayfalama ihtiyacı önce halka açık siteye, admin'e değil.