Full‑stack çerçeveler UI, veri ve sunucu mantığını tek bir yerde birleştiriyor. Nelerin değiştiğini, neden faydalı olduğunu ve ekiplerin nelere dikkat etmesi gerektiğini öğrenin.
Full‑stack çerçeveler ortaya çıkmadan önce “ön uç” ve “arka uç” arasındaki çizgi nispeten nettı: bir tarafta tarayıcı, diğer tarafta sunucu. Bu ayrım ekip rollerini, repo sınırlarını ve hatta insanların “uygulama”dan bahsetme şeklini şekillendirdi.
Ön uç, kullanıcının tarayıcısında çalışan kısımdı. Kullanıcıların gördüğü ve etkileşime geçtiği şeylere odaklanır: layout, stil, istemci tarafı davranış ve API çağrıları.
Pratikte, ön uç işi çoğunlukla HTML/CSS/JavaScript artı bir UI çerçevesi demekti; veri yüklemek ve kaydetmek için bir backend API'sine istek atılırdı.
Arka uç sunucularda yaşar ve veri ile kurallara odaklanırdı: veritabanı sorguları, iş mantığı, kimlik doğrulama, yetkilendirme ve entegrasyonlar (ödeme, e‑posta, CRM'ler). Ön uçun tüketeceği uç noktaları—genellikle REST veya GraphQL—sunardı.
Yararlı bir zihinsel model: ön uç sorar; arka uç karar verir.
Full‑stack çerçeve, bu çizgiyi kasıtlı olarak içinde geçen bir web çerçevesidir. Sayfaları render edebilir, route'lar tanımlayabilir, veri çekebilir ve sunucu kodu çalıştırabilir—aynı zamanda tarayıcıya yönelik bir UI üretebilir.
Yaygın örnekler: Next.js, Remix, Nuxt, SvelteKit. Amaç bunların hepsinin mutlaka “daha iyi” olması değil; UI kodu ile sunucu kodunun daha yakın yaşamasını normalleştirmeleridir.
Burada "artık backend'e ihtiyaç yok" demiyoruz. Veritabanları, arka plan işleri ve entegrasyonlar hâlâ var. Değişim, sorumlulukların paylaşılmasıyla ilgili: frontend geliştiriciler daha fazla sunucu meselesine dokunuyor, backend geliştiriciler daha fazla render ve kullanıcı deneyimiyle uğraşıyor—çünkü çerçeve sınırları beraber çalışmaya teşvik ediyor.
Full‑stack çerçeveler, ekiplerin ayrı frontend ve backend tutmanın koordinasyon maliyetinin getirisinden daha yüksek hissettiği durumlarda ortaya çıktı.
Modern ekipler daha hızlı üretim ve daha kolay iterasyon için optimize ediyor. UI, veri çekme ve “yapıştırma kodu” farklı repolarda ve farklı iş akışlarında olduğunda, her özellik bir bayrak yarışı olur: API tanımla, uygula, dökümante et, bağla, uyumsuz varsayımları düzelt, tekrar et.
Full‑stack çerçeveler bu el değiş-tokuşlarını azaltır; tek bir değişiklik sayfa, veri ve sunucu mantığını kapsayabilir.
Geliştirici deneyimi (DX) de önemlidir. Eğer bir çerçeve size routing, veri yükleme, önbellekleme primitifleri ve dağıtım varsayılanlarını bir arada veriyorsa, kütüphaneleri birleştirmekle değil, ürün inşa etmekle uğraşırsınız.
JavaScript ve TypeScript istemci ve sunucu tarafında ortak dil haline geldi; bundler'lar kodu her iki ortama da paketlemeyi pratik kıldı. Sunucunuz JS/TS'i güvenilir şekilde çalıştırınca, doğrulama, biçimlendirme ve tipleri sınırlar boyunca yeniden kullanmak kolaylaşıyor.
"İzomorfik" kod her zaman amaç olmayabilir—ama paylaşılan araçlar kaygıları aynı yerde toplamayı kolaylaştırıyor.
İki ayrı çıktıyı (bir sayfa ve bir API) düşünmek yerine, full‑stack çerçeveler tek bir özelliği göndermeyi teşvik eder: route, UI, sunucu tarafı veri erişimi ve mutasyonlar bir arada.
Bu, ürün işinin nasıl sınırlandığıyla daha iyi eşleşir: “Ödeme sayfasını yap” yerine “Ödeme UI'sını yap” ve “Ödeme uç noktalarını yap” demek zorunda kalmazsınız.
Bu sadelik, küçük ekipler için büyük bir kazançtır: daha az servis, daha az sözleşme, daha az hareketli parça.
Büyük ölçeklerde ise bu yakınlık bağlanmayı artırabilir, sahipliği belirsizleştirebilir ve performans ya da güvenlik tuzakları yaratabilir—yani kolaylığın yanında büyüdükçe korunması gereken kurallar gerekir.
Full‑stack çerçeveler render etmeyi, sunucuları, veritabanlarını ve maliyeti etkileyen bir ürün kararı haline getirir. Bir render modu seçtiğinizde, yalnızca sayfanın ne kadar hızlı hissettirilmesini seçmiyorsunuz—işin nerede ve ne sıklıkla yapıldığını belirliyorsunuz.
Server‑Side Rendering (SSR): sunucu her istek için HTML oluşturur. Taze içerik alırsınız, ama her ziyaret sunucu tarafında daha fazla iş anlamına gelir.
Static Site Generation (SSG): HTML önceden (derleme sırasında) oluşturulur. Sayfalar sunmak için çok ucuzdur, ancak güncellemeler yeniden derleme veya yeniden doğrulama gerektirir.
Hibrit rendering: yaklaşımları karıştırır; bazı sayfalar statik, bazıları sunucu tarafı render, bazıları kısmi güncelleme (ör. her N dakikada yeniden oluşturma) şeklinde olabilir.
SSR ile, kişisel bir widget eklemek gibi bir "ön uç" değişikliği, oturum sorguları, veritabanı okumaları ve yüksek trafikte daha yavaş yanıt süreleri gibi arka uç meselelerine dönüşebilir.
SSG ile, fiyat güncellemesi gibi bir "arka uç" değişikliği yeniden derleme veya kademeli yeniden oluşturma planlaması gerektirebilir.
Çerçeve gelenekleri bu karmaşıklığın çoğunu gizler: bir konfig bayrağı çevirirsiniz, bir fonksiyon export edersiniz veya özel bir klasöre dosya koyarsınız—ve aniden önbellekleme davranışı, sunucu yürütmesi ve derleme-vs-istek zamanında neyin çalıştığını tanımlamış olursunuz.
Önbellekleme sadece bir CDN ayarı değil. Render genellikle şunları içerir:
Bu yüzden render modları backend düşüncesini UI katmanına çeker: geliştiriciler bir sayfayı tasarlarken tazelik, performans ve maliyeti aynı anda belirler.
Full‑stack çerçeveler giderek “route”u sadece bir sayfa render eden URL'den daha fazlası olarak kabul ediyor. Tek bir route, veriyi yükleyen, form gönderimlerini işleyen ve API yanıtları döndüren sunucu tarafı kodu da içerebilir.
Pratikte, bu size ön uç deposunun içinde bir arka uç sağlar—ayrı bir servis yaratmadan.
Çerçeveye bağlı olarak, loader (sayfa için veri çeken), action (form postları gibi mutasyonları işleyen) veya açık API route (JSON döndüren) gibi terimlerle karşılaşırsınız.
UI dosyalarının yanında yaşadıkları için "ön uç" gibi hissettirseler de, klasik arka uç işleri yaparlar: istek parametrelerini okumak, veritabanı/servisleri çağırmak ve yanıt şekillendirmek.
Bu route‑temelli kolokasyon doğal gelir çünkü bir ekranı anlamak için gereken kod yakındır: sayfa bileşeni, veri ihtiyaçları ve yazma işlemleri genellikle aynı klasörde durur. Ayrı bir API projesinde arama derdinden kurtulursunuz; route'u takip edersiniz.
Route'lar hem render hem sunucu davranışını sahiplenince, arka uç kaygıları UI iş akışının bir parçası olur:
Bu sık döngü çoğaltmayı azaltabilir, ama risk de getirir: "bağlamak kolay" zamanla "yanlış yere mantık biriktirmek" olabilir.
Route handler'lar orkestrasyon için iyidir—girdiyi ayrıştırmak, bir domain fonksiyonunu çağırmak ve sonuçları HTTP yanıtına çevirmek için. Ancak karmaşık iş kurallarını orada büyütmek iyi bir fikir değildir.
Loader/action/API route'larda çok fazla mantık birikirse test etmek, yeniden kullanmak ve route'lar arasında paylaşmak zorlaşır.
Pratik bir sınır: route'ları ince tutun ve çekirdek kuralları ayrı modüllere (domain veya service katmanı) taşıyın.
Full‑stack çerçeveler veri getirmeyi onu kullanan UI ile kolokasyon yapmaya teşvik ediyor. Sorguları ayrı bir katmanda tanımlayıp props ile birkaç dosya boyunca geçirmek yerine, bir sayfa veya bileşen tam olarak ihtiyaç duyduğu veriyi kendi yanından çekebilir.
Ekipler için bu genellikle daha az bağlam değiştirme demektir: UI'ı okursunuz, sorguyu görürsünüz, veri yapısını anlarsınız—klasörler arasında zıplamak zorunda kalmazsınız.
Veri çekme bileşenlerin yanında durunca kilit soru şudur: bu kod nerede çalışıyor? Birçok çerçeve bir bileşenin sunucuda çalışmasına izin verir (veya sunucu yürütmesine geçiş yapmayı tercih ettirir), bu da doğrudan veritabanı veya iç servis erişimi için idealdir.
İstemci tarafı bileşenler ise yalnızca istemci‑güvenli verilere dokunmalıdır. Tarayıcıda alınan her şey DevTools'ta görülebilir, ağda yakalanabilir veya üçüncü taraf araçlar tarafından cache'lenebilir.
Pratik yaklaşım: sunucu kodunu "güvenilir", istemci kodunu "halka açık" olarak değerlendirin. İstemci veriye ihtiyaç duyuyorsa, bunu kasıtlı olarak bir sunucu fonksiyonu, API route'u veya çerçeve tarafından sağlanan bir loader aracılığıyla verin.
Sunucudan tarayıcıya akan veri serileştirilmelidir (çoğunlukla JSON). Bu sınır hassas alanların kazara sızmasına neden olabilir—örneğin passwordHash, dahili notlar, fiyat kuralları veya KKY.
Yardımcı korunmalar:
user include gizli özellikler taşıyabilir.Veri getirme bileşenlere taşındığında, bu sınır hakkındaki açıklık kolaylığın kadar önemlidir.
Full‑stack çerçeveler "karışık" hissettiren bir diğer sebep, UI ve API arasındaki sınırın paylaşılan tipler haline gelmesidir.
Paylaşılan tipler hem frontend hem backend'in import ettiği tip tanımlarıdır (çoğunlukla TypeScript arayüzleri veya çıkarılan tipler), böylece her iki taraf da User, Order veya CheckoutRequest gibi yapıların aynı olduğunu kabul eder.
TypeScript API sözleşmesini bir PDF veya wiki sayfasından editörünüzün uygulayabileceği bir şeye dönüştürür. Eğer backend bir alan adını değiştirirse veya bir özelliği isteğe bağlı yaparsa, frontend çalışma zamanı hatası yerine derleme zamanında başarısız olur.
Monorepo'larda küçük bir @shared/types paketi yayımlamak veya bir klasörü import etmek kolay olduğu için bu özellikle çekici hale gelir.
Sadece tipler elle yazıldığında gerçeklikten sapabilir. İşte şema ve DTO (Data Transfer Object)'lerin yardımı:
Şema‑öncelikli veya şemadan çıkarılmış yaklaşımlarla, girdileri sunucuda doğrulayabilir ve aynı tanımları istemci çağrılarını tiplemek için yeniden kullanabilirsiniz—"makinemde çalıştı" benzeri uyumsuzlukları azaltır.
Modelleri her yerde paylaşmak katmanları birbirine yapıştırabilir. UI bileşenleri doğrudan domain nesnelerine bağımlıysa (veya daha kötüsü, veritabanı biçimli tiplere) backend refaktörleri frontend refaktörlerine dönüşür ve küçük değişiklikler tüm uygulama boyunca dalgalar yaratır.
Pratik bir orta yol:
Böylece paylaşılan tiplerin hız avantajını kazanırken her iç değişikliği çapraz‑ekip koordinasyon olayına dönüştürmüş olmazsınız.
Server Actions (çerçeveden çerçeveye isim değişir) bir UI olayından sunucu tarafı kodunu yerel bir fonksiyon çağırıyormuş gibi çağırmanızı sağlar. Bir form gönderimi veya butona tıklama doğrudan createOrder() çağrısı yapabilir; çerçeve girdiyi serileştirir, isteği gönderir, sunucuda kodu çalıştırır ve sonucu döndürür.
REST veya GraphQL ile genellikle uç noktalar ve payload'lar düşünülür: bir route tanımlarsınız, bir istek şekillendirirsiniz, durum kodlarını ele alır, yanıtı parse edersiniz.
Server Actions bu zihinsel modeli "argümanlarla fonksiyon çağır" yönüne kaydırır.
Hiçbir yaklaşım mutlak üstün değildir. REST/GraphQL birden fazla istemci için açık, stabil sınırlar gerektiğinde daha net olabilir. Server Actions ise aynı uygulamanın hem tüketicisi hem üreticisi olduğu durumlarda daha akıcı gelir çünkü çağrı noktası tetikleyen bileşenin hemen yanında durabilir.
"Yerel fonksiyon" hissi yanıltıcı olabilir: Server Actions hâlâ sunucu giriş noktalarıdır.
Girdileri doğrulamak (tipler, aralıklar, zorunlu alanlar) ve yetkilendirmeyi aksiyonun içinde zorlamak gerekir; sadece UI'ya güvenmeyin.
Çağrı await createOrder(data) gibi görünse bile ağı geçer. Bu nedenle gecikme, aralıklı hatalar ve yeniden denemeler söz konusudur.
Yüklenme durumları, hata yönetimi, idempotency ve kısmi hataların dikkatli ele alınması gerekiyor—sadece birleştirmek daha rahat bir yol sağlar.
Full‑stack çerçeveler auth işini uygulama genelinde yayar çünkü istekler, render ve veri erişimi genellikle aynı projede—ve bazen aynı dosyada—gerçekleşir.
Temiz bir el teslimi yerine, kimlik doğrulama ve yetkilendirme middleware, route'lar ve UI kodunu etkileyen ortak kaygılar haline gelir.
Tipik bir akış birden fazla katmanı kapsar:
Bu katmanlar birbirini tamamlar. UI korumaları kullanıcı deneyimini iyileştirir, ama güvenlik değildir.
Çoğu uygulama şu yaklaşımlardan birini seçer:
Full‑stack çerçeveler sunucu render sırasında çerez okumayı kolaylaştırır ve kimliği sunucu tarafı veri çekmeye iliştirmeyi basitleştirir—kullanışlı ama hataların daha fazla yerde olabileceği anlamına gelir.
Yetkilendirme (ne yapmaya hakkinız olduğu) verinin okunduğu veya değiştirildiği yerde uygulanmalıdır: server actions, API handler'lar veya veritabanı erişim fonksiyonlarında.
Sadece UI'da yetkilendirme uygularsanız, bir kullanıcı arayüzü atlayıp uç noktaları doğrudan çağırabilir.
role: \"admin\" veya istek gövdesindeki userId).Full‑stack çerçeveler sadece nasıl kod yazdığınızı değiştirmez—"arka uç"unuzun aslında nerede çalıştığını da değiştirir.
Roller hakkındaki kafa karışıklığının büyük bir kısmı dağıtımdan gelir: aynı uygulama bir gün geleneksel bir sunucu gibi davranabilir, ertesi gün küçük fonksiyonlar yığını gibi.
Bir uzun süre çalışan sunucu klasik modeldir: sürekli açık kalan bir süreç çalıştırırsınız, bellek tutar ve isteklere hizmet eder.
Serverless kodunuzu istek geldiğinde çalıştırılan fonksiyonlar olarak çalıştırır. İstek yoksa kapanabilirler.
Edge kodu kullanıcılara daha yakın çalıştırır (çoğu zaman birçok bölgede). Düşük gecikme için iyidir ama runtime full‑sunucu kadar yetenekli olmayabilir.
Serverless ve edge ile cold start önemli hale gelir: bir durgunluktan sonra gelen ilk istek fonksiyonun açılmasını beklediği için daha yavaş olabilir. Çerçeve özellikleri (SSR, middleware, ağır bağımlılıklar) bu başlangıç maliyetini artırabilir.
Diğer yandan birçok çerçeve streaming destekler—sayfanın parçalarını hazır oldukça göndererek kullanıcıya hızlı bir şeyler gösterir.
Önbellekleme ortak bir sorumluluk haline gelir. Sayfa düzeyi önbellek, fetch önbelleği ve CDN önbelleği birbiriyle etkileşebilir. Bir "ön uç" kararı olan "sayfayı sunucuda render et" aniden cache invalidation, stale data ve bölgesel tutarlılık gibi backend‑temelli meselelere yol açabilir.
Ortam değişkenleri ve sırlar (API anahtarları, veritabanı URL'leri) artık sadece "arka uç"e ait değil. Tarayıcı için güvenli olanla server‑only arasında net kurallar, ayrıca ortamlarda sırların tutarlı yönetimi gerekir.
Gözlemlenebilirlik her iki katmanı da kapsamalı: merkezi loglar, dağıtık izler ve tutarlı hata raporlaması; böylece yavaş bir sayfa render'ı farklı yerde çalışan başarısız bir API çağrısıyla ilişkilendirilebilir.
Full‑stack çerçeveler sadece kod yapısını değiştirmez—"kimin neyi sahiplenmesi gerektiği" de değişir.
UI bileşenleri sunucuda çalışabiliyor, route tanımlayabiliyor ve veritabanına (dolaylı ya da doğrudan) çağrı yapabiliyorsa, eski frontend/backend teslim modeli karışabilir.
Birçok org özellik ekipleri modeline geçer: tek bir ekip bir kullanıcıya yönelik kesiti (ör. "Checkout" veya "Onboarding") uçtan uca sahiplenir. Bu, route'un sayfa, server action ve veri erişimini bir arada bulundurduğu çerçevelerle iyi uyar.
Ayrı frontend/backend ekipleri yine çalışabilir, ama daha net arayüzler ve inceleme pratikleri gerekir—aksi halde backend mantığı sessizce UI‑adjacent kodda birikebilir.
Orta yol genellikle BFF (Backend for Frontend) fikridir: web uygulaması UI'ya özel ince bir backend katmanı içerir (çoğunlukla aynı repoda).
Full‑stack çerçeveler route'ları, server action'ları ve auth kontrollerini sayfaların yanına koymayı kolaylaştırır. Bu güçlüdür—buna gerçek bir backend gibi davranın.
Kısa bir repo dokümanı oluşturun (ör. /docs/architecture/boundaries) ve bileşenlerde, route handler'larda ve paylaşılan kütüphanelerde neyin yer alması gerektiğini birkaç örnekle belirtin.
Amaç tutarlılık: herkes kodu nereye koyacağını ve nereye koymaması gerektiğini bilsin.
Full‑stack çerçeveler süper güç gibi gelebilir: UI, veri erişimi ve sunucu davranışını tek bir akıcı iş akışında inşa edersiniz. Bu gerçek bir avantaj olabilir—ama karmaşıklığın nerede yaşadığı da değişir.
En büyük kazanç hızdır. Sayfalar, API route'ları ve veri getirme desenleri bir arada olduğunda, ekipler genellikle daha hızlı gönderir çünkü koordinasyon yükü ve el değişimleri azalır.
Ayrıca entegrasyon hataları azalır. Paylaşılan araçlar (lint, format, tip kontrol, test koşucular) ve paylaşılan tipler frontend ile backend arasındaki uyumsuzlukları azaltır.
Monorepo tarzı bir kurulumla, refaktörler tek bir PR içinde tüm yığını etkileyerek daha güvenli olabilir.
Kullanışlılık karmaşıklığı gizleyebilir. Bir bileşenin sunucuda render edilmesi, istemcide rehydrate olması, sonra sunucu tarafı mutasyonları tetiklemesi—hata ayıklamak birden fazla runtime, önbellek ve ağ sınırını izlemeyi gerektirebilir.
Ayrıca bağlanma riski vardır: çerçevenin konvansiyonlarını derinlemesine kullanmak (routing, server actions, veri cache'leri) araç değiştirmeyi zorlaştırabilir. Taşınma planı olmasa bile, çerçeve yükseltmeleri yüksek bahisli hale gelebilir.
Karma yığınlar aşırı veri çekmeyi teşvik edebilir ("sunucu bileşeninde her şeyi çek"), veya bağımlı verilerin ardışık keşfedilmesiyle waterfall istekleri yaratabilir.
İstek zamanında render içinde ağır sunucu işleri gecikmeyi ve altyapı maliyetini artırabilir—özellikle trafik zirvelerinde.
UI kodu sunucuda çalışabildiğinde, sırlar, veritabanları ve iç API'lere erişim sunum katmanına daha yakın olabilir. Bu yanlış değil ama genellikle daha derin güvenlik incelemelerini tetikler.
İzin kontrolleri, denetim kayıtları, veri yerleşimi ve uyumluluk kontrolleri açık ve test edilebilir olmalı—kod "ön uç gibi görünüyor" diye varsayılmamalı.
Full‑stack çerçeveler her şeyi kolokasyona sokmayı kolaylaştırır, ama "kolay" dolaşıklaşmaya dönüşebilir.
Amaç eski silo'ları yeniden oluşturmak değil—sorumlulukları okunaklı tutmak ki özellikler güvenle değiştirilebilsin.
İş kurallarını rendering ve routing'ten bağımsız kendi modülü olarak ele alın.
İyi bir kural: neyin olması gerektiğine karar veren (fiyatlandırma kuralları, uygunluk, durum geçişleri) kod services/ içinde olmalı.
Bu UI'ınızı ince, server handler'larınızı sade tutar—ikisi de iyi sonuçlardır.
Çerçeveniz her yere import etmeyi sağlasa bile basit bir üç parçalı yapı kullanın:
Pratik bir koruma: UI sadece services/ ve ui/ import etsin; server handler'lar services/ import edebilir; sadece repository'ler DB istemcisini import etsin.
Katmanlara uygun testler:
Net sınırlar testleri daha ucuz yapar çünkü neyi doğruladığınızı izole edebilirsiniz: iş kuralları mı, altyapı mı, UI akışı mı.
Hafif konvansiyonlar ekleyin: klasör kuralları, lint kısıtlamaları ve "bileşende DB yok" gibi kontroller.
Çoğu ekip ağır süreçlere ihtiyaç duymaz—sadece kazara bağlanmayı önleyen tutarlı varsayılanlar yeterlidir.
Full‑stack çerçeveler UI ve sunucu kaygılarını tek bir kod tabanında topladıkça, dar boğaz genellikle "bunu birleştirebilir miyiz?" değil, "sınırları nasıl net tutup hızlı göndermeye devam ederiz?" sorusuna kayar.
Koder.ai bu gerçeklik için tasarlandı: sohbet arayüzüyle web, sunucu ve mobil uygulamalar yaratabileceğiniz bir vibe‑coding platformu—ama sonuçta gerçek, export edilebilir kaynak kodu elde edersiniz. Pratikte bu, uçtan uca özellikleri (route'lar, UI, server actions/API route'ları ve veri erişimi) tek bir iş akışında yineleyebileceğiniz, sonra üretilen projede yukarıda tartışılan sınır desenlerini uygulayabileceğiniz anlamına gelir.
Tipik bir full‑stack uygulama inşa ediyorsanız, Koder.ai'nin varsayılan yığı (web için React, backend için Go + PostgreSQL, mobil için Flutter) "UI / handler'lar / servisler / veri erişimi" ayrımına temizce uyar. Planlama modu, snapshot'lar ve rollback gibi özellikler, render modu, önbellekleme stratejisi veya auth yaklaşımı gibi çerçeve seviyesindeki değişiklikler tüm uygulamaya yayıldığında yardımcı olur.
Elle her şeyi yazsanız da ya da Koder.ai gibi bir platformla teslimat hızını artırsanız da temel ders aynı: full‑stack çerçeveler kaygıları kolokasyona sokmayı kolaylaştırır—bu yüzden sistemi anlaşılır, güvenli ve evrilmesi kolay tutmak için kasıtlı konvansiyonlara ihtiyacınız var.
Geleneksel olarak ön uç, tarayıcıda çalışan kodu (HTML/CSS/JS, UI davranışı, API çağrıları); arka uç ise sunucularda çalışan kodu (iş mantığı, veritabanları, kimlik doğrulama, entegrasyonlar) ifade eder.
Full-stack çerçeveler kasıtlı olarak her ikisini de kapsar: hem UI render eder hem de aynı projede sunucu tarafı kodu çalıştırır; böylece sınır artık ayrı bir kod tabanı değil, "ne nerede çalışsın" diye verilen bir tasarım kararı haline gelir.
Full-stack çerçeve, tek bir uygulama içinde hem UI render hem de sunucu tarafı davranış (routing, veri yükleme, mutasyonlar, kimlik doğrulama) desteği veren bir web çerçevesidir.
Örnekler: Next.js, Remix, Nuxt, SvelteKit. Ana değişim, route'ların ve sayfaların çoğunlukla ihtiyaç duydukları sunucu kodunun yanında yaşaması.
Koordinasyon maliyetini azaltırlar. Bir sayfayı bir repo, API'yi başka bir repo şeklinde geliştirmek yerine, son kullanıcıya dönük bir özelliği (route + UI + veri + mutasyon) tek bir değişiklikle gönderebilirsiniz.
Bu genellikle iterasyon hızını artırır ve ekipler/ projeler arasındaki uyumsuz varsayımlardan kaynaklanan entegrasyon hatalarını azaltır.
Render seçimi artık backend sonuçları doğuran bir ürün kararına dönüşür:
Seçim gecikme, sunucu yükü, önbellekleme stratejisi ve maliyet üzerinde doğrudan etkili olur—dolayısıyla “ön uç” işi artık backend tarzı takasları da içerir.
Önbellekleme, bir sayfanın nasıl oluşturulduğu ve tazeliğinin nasıl korunduğunun bir parçası haline gelir, sadece bir CDN ayarı değildir:
Bu kararlar genellikle route/sayfa kodunun yanında yer aldığından, UI geliştiricileri tazelik, performans ve altyapı maliyetine birlikte karar verirler.
Birçok çerçeve tek bir route içinde şunları bulundurabilir:
Bu kolokasyon kullanışlıdır, ancak route handler'ları gerçek backend giriş noktaları gibi ele alın: girdi doğrulaması yapın, yetkilendirme kontrolü uygulayın ve karmaşık iş kurallarını service/domain katmanına taşıyın.
Kod farklı yerlerde çalışabileceği için dikkat edilmesi gerekenler:
Pratik bir kural: UI'ya sadece ihtiyacı olan alanları içeren view model göndermek; ham DB kayıtlarını değil. Bu sayede , dahili notlar veya KKY gibi hassas bilgiler kazara açığa çıkmaz.
Paylaşılan TypeScript tipleri sözleşme kaymalarını azaltır: sunucu bir alanı değiştirirse, istemci derleme zamanında hata alır.
Ancak domain/DB biçimli modelleri her yerde paylaşmak katmanları birbirine yapıştırabilir. Güvenli bir orta yol:
Server Actions, bir UI olayından sunucu tarafı kodu yerel bir fonksiyon çağırıyormuş gibi kullanmanıza izin verir (ör. await createOrder(data)). Framework giriş/çıkışı serileştirir, isteği gönderir, sunucuda çalıştırır ve sonucu döndürür.
Yine de bunları birer genel sunucu giriş noktası olarak ele alın:
Full-stack çerçeveler kimlik doğrulama (auth) işini uygulama boyunca yayar; çünkü istekler, render ve veri erişimi genelde aynı projede—hatta bazen aynı dosyada—gerçekleşir.
Tipik akış katmanları:
passwordHashAncak güvenlik her zaman sunucu tarafında uygulanmalıdır: yetkilendirme veri erişimi sırasında (server actions, API handler'lar, veri erişim fonksiyonları) zorlanmalı; istemciden gelen role: "admin" veya userId gibi alanlara güvenilmemelidir.