Sunucu taraflı render mı, SPA mı

Bir uygulamanın arayüzünü nerede oluşturduğu — sunucuda mı, tarayıcıda mı — seçimi kadar gelişigüzel verilip bu kadar uzun etkisini sürdüren mimari karar azdır. Çoğu zaman bir karar olarak değil, kendiliğinden anlaşılır bir şey olarak yaşanır: O sırada ne yaygınsa o alınır, genellikle bir single-page application, çünkü modern frontend'ler böyle yapılır. Risk de tam bu gelişigüzellikte yatar, çünkü bu seçim bir ekibin tüm ömür boyunca taşıdığı karmaşıklığı biçimlendirir.

Bu doküman seçimi olduğu gibi ele alıyor: uzun vadeli sonuçları olan bir mimari karar olarak. İki yolun gerçekte nerede ayrıştığını, daha parlak seçeneğin hangi maliyetleri gizlediğini ve kararın dürüstçe hangi ölçüte dayandığını ortaya koyuyor. Hiçbir framework modasını izlemiyor ve kazanan ilan etmiyor; her yolun neye uygun olduğunu anlatıyor. Sürüm ya da rakam verilmiyor.

1. Yanlış soru

“SPA mı yapıyoruz?” nadiren gerçek bir sorudur; çoğu zaman önceden yapılmış bir varsayımdır. Single-page application standart hâline geldi ve standart olmak güçlü ama kötü bir gerekçedir: Neyin yaygın olduğunu söyler, neyin uygun olduğunu değil. Asıl soru, alışılmış yolun izlenip izlenmeyeceği değil, uygulamanın gerçekte ne kadar etkileşimli olduğu ve ne kadar yaşaması gerektiğidir — çünkü doğru yol modaya değil, buna göre belirlenir.

Sorunun neden önemli olduğu, etki alanında yatar. Arayüzün sunucuda mı tarayıcıda mı oluştuğu yalnızca yükleme davranışını değil, tüm yapım biçimini belirler: sistemin kaç hareketli parçası olduğunu, ne kadar durumun (state) iki kez tutulduğunu, ne kadar araç zincirinin bakımının yapıldığını ve bunların ne kadarının on yıl sonra hâlâ anlaşılır olduğunu. Gelişigüzel yapılan bir seçim, ekibi hiçbir zaman bilinçli olarak seçmediği bir karmaşıklığa bağlar.

Ödünleşim. Soruyu bilinçli olarak sormak, rahat standardı sorgulamak ve kendi sisteminiz için yargıda bulunmak demektir — alışılmış yolu izlemekten daha fazla emek.

Maliyet. Bu yargı, uygulamanın gerçekte ne kadar etkileşimli olduğuna dair dürüst bir değerlendirme gerektirir — ve ekipler etkileşim ihtiyaçlarını düzenli olarak abartır.

Ne zaman farklı karar veririz. Bir uygulamanın açıkça yüksek etkileşimli olduğu yerde — bir editör, tarayıcıda sürekli ve ince taneli durum barındıran bir araç — SPA akla yatkın seçimdir ve uzun bir incelemeye gerek kalmaz.

2. İkisini gerçekte ne ayırır

Fark özünde basittir: Sunucu taraflı render'da sunucu hazır arayüzü oluşturur ve onu gösteren tarayıcıya gönderir; single-page application'da ise sunucu esasen boş bir iskelet ve bir program gönderir, arayüzü tarayıcının kendisi oluşturur ve çalışma sırasında güncel tutar. İlk durumda iş ve durum ağırlıklı olarak sunucudadır; ikincisinde ikisi de tarayıcıya kayar.

Neredeyse geri kalan her şey bu tek kaymadan doğar. Bir SPA, kendi durumu, kendi mantığı, kendi araç zinciri olan, tarayıcıda bağımsız bir uygulamaya dönüşür — ve genellikle verilerini çektiği, sunucuya açılan bir API'ye ihtiyaç duyar. Sunucu taraflı render edilen bir sistem ise tek bir yerde yaşayan ve tarayıcı tarafı küçük kalan bir uygulama olarak kalır. Böylece seçim, teknolojiden çok kaç bağımsız sistem inşa edip işleteceğinizle ilgilidir: bir mi, iki mi.

Şema: Sunucu taraflı yaklaşımda arayüzü sunucu oluşturur, tarayıcı gösterir. SPA'da ise tarayıcı arayüzü kendisi oluşturur ve verilerini bir API üzerinden çeker — bir yerine iki sistem.

Ödünleşim. Tarayıcıya kayma, zenginlik ve ayrışmayı (decoupling), inşa edip işlettiğiniz ikinci bir bağımsız sistem pahasına satın alır.

Maliyet. İki sistem; iki araç zinciri, durum ve mantık için iki yer, arada bir API demektir — sunucu taraflı yolda olmayan bir karmaşıklık.

Ne zaman farklı karar veririz. Tarayıcıdaki zenginliğin uygulamanın amacını oluşturduğu yerde ikinci sistem bir külfet değil, işin ta kendisidir — o zaman kayma doğrudur.

3. Single-page application'ın güçlü yanları

SPA'nın küçümsenmemesi gereken gerçek güçlü yanları vardır. Zengin, anlık etkileşime izin verir: Durum sunucuya uğramadan tarayıcıda değişir, arayüz hemen tepki verir ve karmaşık, uygulama benzeri akışlar — sürükleme, düzenleme, anında geri bildirim — akıcı hissettirir. Bir sayfalar dizisi gibi değil, bir uygulama gibi hissettirmesi gereken yazılım için bu doğal yoldur.

Buna sık dile getirilen ikinci bir avantaj eklenir: İlk yüklemeden sonra uygulama içindeki gezinme anlık hissettirir, çünkü artık tam sayfa değişimine gerek yoktur — tarayıcı yalnızca değişeni günceller. Bir kullanıcının uzun süre kaldığı ve görünümler arasında çok geçiş yaptığı uygulamalar için bu, akıcılıkta hissedilir bir kazançtır. Bunun bedeli daha uzun ilk yüklemedir: SPA, sonrasında daha hızlı olmak için başta daha fazlasını yükler — araç benzeri uygulamalar için iyi, kullanıcının yalnızca kısa süre ziyaret ettiği uygulamalar için kötü bir takas.

Bir de ayrışma vardır. SPA verilerini bir API üzerinden aldığı için frontend kısmı sunucudan bağımsızdır ve ayrı geliştirilebilir — kimi zaman kendi ritmiyle çalışan ayrı bir ekip tarafından. Aynı API'nin birden fazla arayüze, örneğin bir web ve bir mobil uygulamaya hizmet ettiği yerde bu ayrışma karşılığını verir, çünkü mantık tek bir yerde, sunucuda durur ve arayüzler onu paylaşır.

Ödünleşim. SPA'nın güçlü yanları — zenginlik ve ayrışma — ikinci bir sistemin karmaşıklığı ve bir sözleşmeye dönüşen bir API pahasına satın alınır.

Maliyet. Zengin etkileşim ve ayrışmış bir frontend, sunucu taraflı bir arayüzden daha fazla kod, daha fazla araç ve durum ile API konusunda daha fazla özen gerektirir.

Ne zaman farklı karar veririz. Uygulamanın ne zengin etkileşime ne de birden fazla arayüze ihtiyaç duyduğu yerde SPA'nın güçlü yanları kullanılmadan kalır ve yalnızca bedeli taşınır — o zaman sunucu taraflı yol daha iyidir.

4. Sunucu taraflı render'ın güçlü yanları

Sunucu taraflı render'ın trend içinde kolayca gözden kaçan bir gücü vardır: sadelik. Tek bir yerde tek bir sistem olarak kalır. Tarayıcıda güncel tutulması gereken ikinci bir uygulama durumu, iki kez tutulan durum, ek bir sınır olarak API yoktur. Arayüz hazır gelir; bu da ilk yüklemeyi hızlı kılar ve arama motorları ile insanlar için ilk görünürlüğü ek bir çaba gerektirmeden sağlar. Tarayıcı tarafı küçük kalır ve böylece yıllar içinde anlaşılması ve bakımı daha kolay olur.

Bir diğer, sessiz avantaj sağlamlıktır. Arayüz sunucudan hazır geldiği için, tarayıcıda bir şey yüklenmediğinde ya da bir cihaz zayıf olduğunda bile temel hatlarıyla çalışır — kapsamlı bir programın hatasız çalışmasına daha az bağımlıdır. Bir SPA tarayıcı programıyla ayakta durur ya da düşer; sunucu taraflı render edilen bir sistem ise her şey yolunda gitmediğinde bile temel bir fayda sunar. Geniş ve tanınmayan bir kitleye hitap eden uygulamalar için bu sağlamlık gerçek bir değerdir.

Bu sadelik, özellikle uzun ömürlülük açısından güçlü bir argümandır. Tek parçalı bir sistem iki parçalı bir sistemden daha yavaş yaşlanır, çünkü birbirinden uzaklaşabilecek daha az hareketli parçası vardır ve küçük tarayıcı tarafı SPA dünyasının hızla değişen araç zincirine maruz kalmaz. On yıl için bir sistem inşa eden ve zengin etkileşime ihtiyaç duymayan kişi, sunucu taraflı yolla huzur kazanır — daha az değişen, daha az yetiştirilmesi gereken şey.

Ödünleşim. Sunucu taraflı render'ın sadeliği, huzur ve uzun ömrü, bir SPA'nın sunduğu zengin ve anlık etkileşimden vazgeçme pahasına satın alır.

Maliyet. Yine de uygulama benzeri etkileşime ihtiyaç duyulan yerde, bunu bir SPA'nın doğası gereği sunduğundan daha fazla emekle taklit etmek gerekir.

Ne zaman farklı karar veririz. Uygulama özünde zengin, ince taneli etkileşim gerektirdiği anda sunucu taraflı sadelik yetmez — o zaman SPA'nın zenginliği bedeline değer.

5. SPA'nın gizli maliyetleri

SPA standart olduğu için maliyetleri çoğu zaman artık fark edilmez — inşa etmenin olağan bedeli sayılırlar. Oysa gerçektirler ve ömür boyunca ağır basarlar. Birincisi durumun iki kez tutulmasıdır: Sunucunun bildiğini SPA'nın da bilmesi gerekir ve ikisini güncel ve tutarlı tutmak, tek parçalı sistemde var olmayan sürekli bir hata kaynağıdır. İkincisi araç zinciridir: SPA dünyası hızlı hareket eder ve bugün modern biçimde inşa edilmiş bir frontend, on yıl boyunca tekrar tekrar yeni araçlara, sürümlere ve kalıplara uyarlanmayı gerektirir.

Üçüncü ve çoğu zaman hafife alınan maliyet, iki sistem sorununun kendisidir. Bir değil, sözleşmeye dönüşen ve uzun ömürlü API'lerin gerektirdiği tüm özeni talep eden bir API ile birbirine bağlı iki uygulama inşa edip işletirsiniz. Her hata iki sistemden birinde ya da sınırlarında olabilir; bu da teşhisi zorlaştırır. Bu maliyetler, SPA'nın sanıldığı gibi koşulsuz standart olmaması gerektiğinin nedenidir: Zenginliğine ihtiyaç duyulduğunda doğru seçimdir, duyulmadığında pahalı bir dolambaç.

Bu maliyetlere, tasarımda görünmeyen ve işletimde daha da ağır basan bir maliyet de dâhildir: iki sistemin gerektirdiği yetkinlik. Sunucu taraflı render edilen bir sistem tek bir alana hâkim bir ekip ister; bir SPA ise sunucuyu, bağımsız frontend'i ve aradaki API'yi anlayan — ve frontend araçlarının hızlı değişimini yıllar boyunca taşıyabilen — insanlar ister. İnsanların değiştiği on yıllık bir süreçte, bir SPA'nın gerektirdiği ek ve daha geniş yetkinlik gerçek ve tekrarlayan bir maliyet kalemidir. İşletilmesi daha az yetkinlik gerektiren bir sistem, onu inşa edenlerin değişmesinden daha kolay sağ çıkar.

Ödünleşim. Gizli maliyetleri kabul etmek, standardı bedava saymamak ve bedelini faydasıyla tartmak demektir.

Maliyet. Dürüst hesap, kendi etkileşim ihtiyacınızı — alışıldığı gibi abartmak yerine — soğukkanlılıkla değerlendirmenizi gerektirir.

Ne zaman farklı karar veririz. SPA'nın zenginliğinin uygulamanın özünü oluşturduğu yerde maliyetleri iyi bir yatırımdır; temkin, bunların karşılığı alınmadan alışkanlıktan taşındığı yerler içindir.

6. Ölçüt: etkileşim düzeyi ve ömür

Karar iki soruya dayanır. Birincisi: Uygulama gerçekte ne kadar etkileşimli — özünde tarayıcıda sürekli, ince taneli durum barındıran bir araç gibi mi hissettiriyor, yoksa veri gösteren ve ara sıra değiştiren bir görünümler dizisi gibi mi? İkincisi: Ne kadar yaşaması gerekiyor — bakım kolaylığının on yıl boyunca önem taşıdığı uzun ömürlü bir sistem mi, yoksa sonraki bakımının pek önemi olmayan kısa ömürlü bir şey mi?

Şema: Ya biri ya öteki değil, bir yelpaze. Sayfa benzeri uygulamalar solda, araç benzeri olanlar sağda yer alır — ve geniş orta alan sunucu taraflı render edilir, yer yer etkileşimli hâle getirilir.

Birlikte bu iki soru dürüst cevabı verir. Sayfa benzeri, uzun ömürlü bir uygulama sunucu taraflı render edilmelidir — orada sadelik yıllar içinde kazanır. Değeri etkileşimde yatan araç benzeri bir uygulama SPA olarak inşa edilmelidir — orada zenginliği bedeline değer. En yaygın hata, sayfa benzeri, uzun ömürlü bir uygulamayı standart olduğu için SPA olarak inşa etmek ve faydasını hiç görmeden maliyetlerini on yıl boyunca taşımaktır.

Ödünleşim. Bu iki soruya göre karar vermek, standardı izlemek yerine kendi etkileşim ihtiyacınızı ve ömrü dürüstçe adlandırmayı gerektirir.

Maliyet. İki değerlendirme de hataya açıktır — ekipler gereken etkileşimi düzenli olarak abartır, ömrü ise düzenli olarak hafife alır.

Ne zaman farklı karar veririz. Bir ekibin iki yapım biçiminden birine derinlemesine hâkim olduğu ve uygulamanın sınır bölgede yer aldığı yerde aşinalık belirleyici olabilir — iyi hâkim olunan bir yapım biçimi, teoride biraz daha uygun olanı yener.

7. Orta yol

Seçim bir ya o ya bu meselesi değildir. Belki de en çok hafife alınan yol ortadaki yoldur: zengin etkileşimin gerçekten gerektiği yerlerde noktasal etkileşim adaları barındıran, sunucu taraflı render edilen bir uygulama. Sistemin zemini sade ve uzun ömürlü kalır; yalnızca uygulama benzeri etkileşim gerektiren az sayıdaki yer daha zengin inşa edilir. Böylece sunucu taraflı yolun huzurunu ve SPA'nın zenginliğini tam da önemli olduğu yerde elde edersiniz — sistemin tamamını bir SPA'ya dönüştürmeden.

Bu orta yol, iyi mühendislikte baştan sona görülen tutuma karşılık gelir: emek isteyen ve hareketli olanı küçük tutmak ve gerçekten ihtiyaç duyan yerlerle sınırlamak. Tek bir yerin zenginliği uğruna bütün bir uygulamayı SPA olarak inşa etmek yerine zenginliği ihtiyaç duyulan yere taşır, gerisini sade bırakırsınız. Birçok sistem için — yönetim uygulamaları, portallar, tek tük etkileşimli bölümleri olan uygulamalar — bu en uygun cevaptır ve aynı zamanda en az bilinçli olarak seçilenidir.

Ödünleşim. Orta yol, büyükte sadeliği ve küçükte zenginliği, ikisi arasındaki sınırı temiz çizme özeni pahasına satın alır.

Maliyet. İki yapım biçimini tek sistemde karıştırmak, adaların sınırlı kalması ve sistemin tamamını fark ettirmeden bir SPA'ya dönüştürmemesi için disiplin gerektirir.

Ne zaman farklı karar veririz. Neredeyse her yerin zengin etkileşime ihtiyaç duyduğu durumda orta yol yapaydır ve baştan sona SPA daha dürüsttür; neredeyse hiçbir yerin ihtiyaç duymadığı durumda adasız, saf sunucu taraflı render yeterlidir.

8. Tipik hatalar

Frontend seçiminin başarısız olduğu tekrarlayan örüntüler — neredeyse hepsi ihtiyaç yerine standardı izlemenin türevleridir:

• Zenginliğe ihtiyaç olup olmadığını incelemeden, standart olduğu için SPA inşa etmek.
• Kendi etkileşim ihtiyacını abartmak ve gerçekte sayfa benzeri olanı araç benzeri sanmak.
• SPA'nın gizli maliyetlerini — iki kez tutulan durum, hızla değişen araç zinciri, iki sistem — bedava bir olağan durum gibi ele almak.
• Ömrü hafife almak ve SPA araç zincirinin ileride gerektireceği bakımı hesaba katmamak.
• Sayfa benzeri, uzun ömürlü bir sistemi SPA olarak inşa etmek ve faydasını görmeden maliyetlerini on yıl boyunca taşımak.
• Orta yolu gözden kaçırmak ve birkaç etkileşimli yer yüzünden sistemin tamamını bir SPA'ya dönüştürmek.
• İki sistem arasında uzun ömürlü bir sözleşmeye dönüşecek olmasına rağmen SPA'nın API'sini gelişigüzel tasarlamak.

9. Karar kontrol listesi

Frontend mimarisini seçmeden önce sırasıyla netleştirilmesi gerekenler:

• Gerçekte ne kadar etkileşimli? Uygulama özünde bir araç gibi mi hissettiriyor — yoksa bir görünümler dizisi gibi mi?
• Ne kadar uzun ömürlü? Bakım kolaylığı on yıl boyunca önem taşıyor mu, yoksa uygulama kısa ömürlü mü?
• Birden fazla arayüz? Aynı mantık, ortak bir API'yi haklı çıkaran birden fazla frontend'e hizmet ediyor mu?
• SPA'nın maliyetleri hesaba katıldı mı? İki kez tutulan durum, hızla değişen araç zinciri ve iki sistem sorunu hesaba katıldı mı?
• Orta yol incelendi mi? Gerektiği yerlerde etkileşim adaları barındıran sunucu taraflı render yeterli mi?
• Sözleşme olarak API? SPA ise: API, uzun ömürlü bir sözleşmenin özeniyle mi tasarlanıyor?
• Ekip? Ekip hangi yapım biçimine yıllar boyunca güvenilir şekilde hâkim?

Bu sorulara cevap verebilen, frontend mimarisini o sırada yaygın olana göre değil, etkileşim düzeyine ve ömre göre seçmiş olur.

Sıkça Sorulan Sorular

SPA modern standart değil mi? Yaygın standarttır ve bu, onu seçmek için kötü bir gerekçedir. Yaygınlık neyin olağan olduğunu söyler, neyin uygun olduğunu değil. Araç benzeri, yüksek etkileşimli uygulamalar için SPA doğru seçimdir; sayfa benzeri, uzun ömürlü sistemler için ise sunucu taraflı render çoğu zaman daha iyisidir, çünkü daha sade ve daha sakindir.

SPA'ya ihtiyacım olup olmadığını nasıl anlarım? Etkileşim düzeyinden. Uygulama özünde bir araç gibi hissettiriyorsa — tarayıcıda sürekli, ince taneli durum, anında geri bildirim, uygulama benzeri akışlarla — SPA doğaldır. Veri gösteren ve ara sıra değiştiren bir görünümler dizisiyse ihtiyaç kolayca abartılır ve sunucu taraflı yaklaşım yeterlidir.

Bir SPA'nın gizli maliyetleri nelerdir? Başlıca üç tane: sunucuda ve tarayıcıda tutarlı tutulması gereken, iki kez tutulan durum; on yıl boyunca tekrar tekrar uyarlama gerektiren, hızla değişen bir araç zinciri; ve sözleşmeye dönüşen bir API ile gelen iki sistem sorunu. Bu maliyetler gerçektir, ancak SPA standart olduğu için olağan sayılır.

Bir orta yol var mı? Evet ve çoğu zaman en iyisidir: zengin duruma ihtiyaç duyulan yerlerde noktasal etkileşim adaları barındıran sunucu taraflı render. Sistemin zemini sade ve uzun ömürlü kalır, zenginlik ona ihtiyaç duyan az sayıdaki yerle sınırlanır. Birçok yönetim ve portal uygulaması için bu en uygun cevaptır.

Seçim uzun ömürlülük açısından önemli mi? Çok önemli. Sunucu taraflı render edilen bir sistemin daha az hareketli parçası ve hızla değişen SPA araç zincirinden kaçan küçük bir tarayıcı tarafı vardır — daha sakin yaşlanır. Bir SPA ise yıllar boyunca araç zincirinin tekrar tekrar güncellenmesini gerektirir. Bakım kolaylığının on yıl boyunca önem taşıdığı yerde bu ağır basar.

Seçim framework'e bağlı mı? Göründüğünden daha az. Soru React mı, Vue mu ya da sunucu taraflı bir framework mü değil, arayüzün nerede oluştuğu ve kaç sistem inşa ettiğinizdir. Framework'ler bu kararı izler; onun yerini almaz. Framework'e göre karar vermek, aracı sorunun önüne koymak olurdu.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — frontend seçiminin on yıllık bakım kolaylığını neden sessizce belirlediği.
• Yenilikten önce olgun teknoloji — standardın neden bir gerekçe olmadığı ve hızla değişen araç zincirinin neden bir bedeli olduğu.
• Öngörüden önce geri alınabilirlik — sistemin tamamını sabitlemek yerine zenginliği sınırlı ve geri alınabilir tutmak.
• Uzun ömürlü sistemler için API tasarımı — SPA ise: API'yi uzun ömürlü bir sözleşme olarak tasarlamak.

Temelinde Batunet Engineering Method yer alır: etkileşim düzeyine ve ömre göre karar vermek, emek isteyeni küçük tutmak, modayı değil ihtiyacı izlemek.

Son mühendislik ilkesi

Frontend mimarisi, bir kez verilip on yıl boyunca taşınan az sayıdaki karardan biridir — ve standart onu görünüşte zaten cevapladığı için en sık bilinçsizce verilen kararlardan biridir. Tam da bu yüzden onu bilinçli olarak vermeye değer. Single-page application, araç benzeri uygulamalar için güçlü bir araç, sayfa benzeri uygulamalar için pahalı bir dolambaçtır; sunucu taraflı render ise her köşede zengin etkileşime ihtiyaç duymayan geniş orta alan için sakin, uzun ömürlü bir temeldir. En olgun cevap nadiren saf hâliyle biri ya da öteki olur; gerçek etkileşim düzeyini taşıyan en sade yapım biçimidir — ve zenginlik yalnızca bedeline değdiği yerde. Böyle karar veren, aksi hâlde onu belirleyecek olan moda çoktan değiştiğinde bile hâlâ anlaşılır olan bir frontend inşa eder.

Soru, herkesin inşa ettiği gibi inşa edip etmemek değil, uygulamanın gerçekte ne kadar etkileşimli olduğu ve ne kadar yaşaması gerektiğidir. Standart bu soruların hiçbirini cevaplamaz — yalnızca onları örter.