01RSC hangi problemleri hedefliyorThe problems RSC actually targets
Klasik bir SPA'de basit bir kural işler: ekranda görünen her şeyin kodu kullanıcının cihazına iner. Markdown parser, tarih kütüphanesi, grafik motoru — sadece bir kez, sadece render için gerekseler bile bundle'a girerler. Ürün büyüdükçe bundle büyür ve ilk yükleme, en yavaş kullanıcının telefonunda ödenir.
A classic SPA runs on a simple rule: the code for everything on screen ships to the user's device. The markdown parser, the date library, the charting engine — even if they're needed once, only for rendering, they enter the bundle. As the product grows, the bundle grows, and the first load is paid for on the slowest user's phone.
İkinci problem waterfall: bileşen render olur, veri ister, çocuğu render olur, o da veri ister — her adım bir network turu. Üçüncüsü daha sessiz: veri zaten sunucuda durur, ama client'a taşımak için bir API katmanı yazılır. Endpoint, tip, fetch, hata yönetimi — aynı verinin ikinci bir tanımı, sadece taşıma için.
The second problem is the waterfall: a component renders, requests data, its child renders and requests more — every step a network round trip. The third is quieter: the data already lives on the server, yet an API layer gets written just to ferry it to the client. Endpoints, types, fetches, error handling — a second definition of the same data, built purely for transport.
Üç problemin kökü aynı: render client'ta yaşadığı için, render'a lazım olan her şey de client'a taşınmak zorunda. Yıllardır code splitting, lazy loading ve BFF katmanlarıyla bu taşımanın acısını hafifletiyoruz. RSC ise taşımayı hafifletmiyor; sorunun kökünü değiştiriyor — render'ın bir kısmını verinin zaten olduğu yere geri götürüyor.
The three problems share one root: because rendering lives on the client, everything rendering needs has to be shipped to the client. For years we've been softening the pain of that shipment with code splitting, lazy loading and BFF layers. RSC doesn't soften the shipment; it changes the root — moving part of rendering back to where the data already is.
RSC bir performans hilesi değil; render'ın nerede yaşadığına dair bir karar.
RSC is not a performance trick; it's a decision about where rendering lives.
02Yeni zihinsel model: sınırThe new mental model: the boundary
Bir server component, yalnızca sunucuda çalışan bir bileşendir. Çıktısı — üretilen UI ağacı — serialize edilip client'a gönderilir; kodu ve bağımlılıkları hiçbir zaman bundle'a girmez. Klasik SSR'dan farkı burada: SSR aynı bileşeni önce sunucuda, sonra hydration için client'ta çalıştırır. Server component client'ta hiç var olmaz.
A server component is a component that only ever runs on the server. Its output — the rendered UI tree — is serialized and sent to the client; its code and dependencies never enter the bundle. That's the difference from classic SSR: SSR runs the same component on the server first, then again on the client for hydration. A server component never exists on the client at all.
Öğrenilmesi gereken asıl şey sınırdır. "use client" bir kapıdır: kapının sunucu tarafında veri erişimi, gizli anahtarlar ve ağır kütüphaneler yaşar; client tarafında state, event ve etkileşim. Server action'lar aynı kapının dönüş yönü — client'taki bir form, sunucudaki bir fonksiyonu API endpoint yazılmadan çağırır.
The real thing to learn is the boundary. "use client" is a door: on the server side of it live data access, secrets and heavy libraries; on the client side, state, events and interaction. Server actions are the same door in the return direction — a form on the client calls a function on the server without an API endpoint being written.
Kapıdan geçen her şey serialize edilebilir olmalı: props olarak fonksiyon değil veri gider, kapının öbür yanında import edilen her paket bundle'a dahil olur. Sınırı nereye çizdiğiniz, mimarinin asıl tasarım kararı hâline gelir.
Everything passing through the door must be serializable: data crosses as props, functions don't, and every package imported on the far side joins the bundle. Where you draw the boundary becomes the real design decision of the architecture.
// page.jsx — server component / sunucu bileşeni import { db } from "./db" // client'a asla inmez / never ships export default async function Page() { const posts = await db.posts.latest() return <Feed posts={posts} /> } // feed.jsx — kapının öbür yanı / the other side of the door "use client" export function Feed({ posts }) { /* state & event burada yaşar / lives here */ }
03Gerçekten ne iyileşiyorWhat genuinely improves
Modelin bedava olmadığını birazdan söyleyeceğiz; önce dürüstçe kazanç hanesi:
We'll get to the fact that the model isn't free; first, honestly, the gains column:
- Sıfır bundle ağırlıklı bağımlılıklar. Markdown, syntax highlighting, tarih işleme sunucuda kalır. Kullanıcı kütüphaneyi değil, sonucunu indirir.
- Zero-bundle-weight dependencies. Markdown, syntax highlighting, date handling stay on the server. The user downloads the result, not the library.
- Aracısız veri erişimi. Bileşen veritabanına ya da iç servise doğrudan uzanır. Sadece taşıma için var olan API katmanı — ve onun bakımı — ortadan kalkar.
- Direct data access. The component reaches into the database or internal service directly. The API layer that existed purely for transport — and its maintenance — disappears.
- Streaming. Sayfanın hazır kısımları hemen gönderilir; yavaş veri bekleyen bölgeler Suspense sınırlarıyla sonradan akar. Waterfall, sunucunun hızlı iç ağında çözülür.
- Streaming. The ready parts of the page ship immediately; regions waiting on slow data stream in later behind Suspense boundaries. The waterfall gets resolved on the server's fast internal network.
04Dürüst maliyetler — ve gerekli mi?The honest costs — and do you need it?
Birinci maliyet zihinsel: ekip artık her dosyada "bu kod nerede çalışıyor?" sorusunu sormak zorunda. İki model bir arada yaşar ve bu, öğretilmesi gereken gerçek bir yüktür. İkincisi cache semantiği: neyin hangi katmanda, ne kadar süre cache'lendiği RSC dünyasında hataların yeni adresi. Üçüncüsü bağımlılık: RSC'yi bugün üretimde kullanmak pratikte Next.js şeklinde bir framework kullanmak demek — React'in kendisi değil, bir framework'ün yorumu. Ekosistem de hâlâ sınırın iki yanına bölünmüş durumda; kütüphaneler uyum sağlıyor, ama churn bitmedi.
The first cost is mental: the team now has to ask "where does this code run?" in every file. Two models coexist, and that is a real teaching burden. The second is caching semantics: what gets cached at which layer, for how long, is the new home of bugs in the RSC world. The third is coupling: using RSC in production today effectively means using a framework shaped like Next.js — a framework's interpretation, not React itself. And the ecosystem is still split across the boundary; libraries are adapting, but the churn isn't over.
Peki gerekli mi? İçerik ağırlıklı, SEO'nun ve ilk yüklemenin kritik olduğu, veri-yoğun ürünlerde takas net biçimde lehinize. Ama login arkasında yaşayan bir dashboard, bir iç araç, bir editör için iyi kurulmuş bir SPA hâlâ doğru cevap; düz SSR da öyle. RSC bir zorunluluk değil, bir araç. Sınırı çizmeye değecek kadar bundle'ınız ve trafiğiniz yoksa, çizmeyin.
So — do you need it? For content-heavy, data-dense products where SEO and first load are critical, the trade clearly favors you. But for a dashboard living behind a login, an internal tool, an editor, a well-built SPA is still the right answer; so is plain SSR. RSC is a tool, not an obligation. If you don't have enough bundle and traffic to make the boundary worth drawing, don't draw it.