Frontend ve backend nedir: kural hangi yarıda yazılır

Frontend ve backend bir yazılımın iki yarısıdır: ön yüz ziyaretçinin cihazında ekranı çizer, arka uç sunucuda kayıtları ve kuralları tutar. Bir kuralın hangi yarıya yazılacağı, aynı cevabın her yüzeyde ve her kişide aynı çıkması gerekip gerekmediğine göre karara bağlanıyor. Resterm’in ısıtıcı seçim yazılımı, girilen ısıtma ihtiyacına uygun elektrikli ısıtıcıyı seçen mühendislik hesabını sunucu tarafında çalıştırıyor.

Teklifte ya da ekip ilanında bu iki adı yan yana gördüğünüzde asıl soru hangi yarının daha önemli olduğu değil. Yanlış yarıya yazılan bir kural ekranda doğru görünüyor ve yanlışlığı ancak ikinci bir yüzey açıldığında ortaya çıkıyor. Aşağıdaki bölümler önce iki yarının ne iş yaptığını, sonra kuralın hangisine yazıldığını yayındaki işler üzerinden gösteriyor.

Ön yüz ziyaretçinin cihazında, arka uç sunucuda çalışır

Ayrımı yapan şey işin nerede koştuğu. Ön yüzün kodu ziyaretçinin cihazına iner ve orada çalışır: açılan web tarayıcısı sayfayı kurar, telefondaki uygulama ekranı çizer. Arka ucun kodu ziyaretçiye hiç inmez; sunucuda durur ve orada çalışır. Aradaki fark bir hız farkı değil, bir yetki farkı.

Ziyaretçinin cihazında çalışan kod, o ziyaretçinin gördüğü şeyi biçimlendiriyor. Sunucuda çalışan kod ise bütün ziyaretçiler için geçerli olan cevabı üretiyor. Aynı soruyu iki kişi sorduğunda cevabın aynı çıkması gerekiyorsa, cevabı üreten yerin ikisinin de cihazının dışında olması gerekiyor.

Arka ucun işi de kayıt saklamakla bitmiyor. Kayıtları tutmanın yanında kimin hangi kaydı okuyabileceğine karar veriyor. Yetki sorusu ön yüzde cevaplanamıyor, çünkü ön yüz ziyaretçinin kendi cihazında çalışıyor ve o cihazda çalışan hiçbir şey kendi yetkisini kendine veremez. Bir ekran bir alanı gizleyebilir; o alanın okunmasını engelleyemez.

Terimlerin Türkçesi ön yüz ve arka uç. Ama teklifler, ekip ilanları ve yazılımcıların kendi konuşması İngilizce adları kullanıyor; arama da öyle yazılıyor. Bu yazı ikisini burada eşleştiriyor ve devamında Türkçelerini kullanıyor.

Bir ayrıntı yanlış anlaşılmaya açık: “ekranı çizmek” küçük bir iş gibi duruyor. Değil. Ön yüz aynı zamanda bir girdi toplama yüzeyi: alanları gösteriyor, hangi alanın boş kaldığını söylüyor, uzun bir formu adımlara bölüyor, seçilen filtreyi açık tutuyor. Bunların hepsi o ziyaretçinin o anki oturumuna ait işler ve oturum kapandığında birlikte kapanıyorlar.

Teklifteki iki kalem, tek uygulamanın iki tarafı

Teklifte frontend ve backend diye iki satır gördüğünüzde en kolay kurulan yanlış şu: iki ayrı sistem satın alındığı sanılıyor. İki satır bir iş bölümünü gösteriyor, iki ürünü değil.

Tanıtım sayfalarıyla iki talep akışını aynı uygulamada taşıyan Diotek’in klima ve havalandırma sitesinde bu birliktelik gözle görülüyor. Tanıtım sayfaları, keşif randevusu formu ve servis talebi formu tek bir Laravel uygulamasının içinde duruyor. Sayfadan sayfaya geçişi ziyaretçinin cihazı yapıyor; hangi adrese ne basılacağı ve bir formun kabul edilip edilmeyeceği sunucu tarafında kalıyor. Ortada tek bir uygulama var.

Ayrı sunucu sorusu da buradan çıkıyor. İki yarının ayrı makinelerde durması bir zorunluluk değil. Bir uygulamanın ön yüzü, o uygulamanın ürettiği sayfanın ziyaretçinin cihazında işleyen tarafı; bunun için ikinci bir makine kiralanmış olması gerekmiyor.

İki yarıya ayrı kalem yazılmasının nedeni maliyeti ikiye katlamak değil, iki farklı işin ayrı ayrı yapılması. Biri ekranı kuruyor, öteki kuralı işletiyor. Hangi işin hangi kaleme düştüğünü okumak da teklifi okumanın bir parçası: bir kalemde “ekran” sayılıyorsa orada bir kural beklemeyin.

Ayrımı somut tutmak gerekiyor. Ziyaretçinin cihazında duran şey ekranın o anki hâli: açık olan sekme, doldurulmuş alanlar, seçilmiş filtre. Sekme kapandığında bunlar gidiyor. Bir sonraki açılışta ekran yeniden kuruluyor ve kurulurken okuduğu şey sunucu tarafındaki kayıt oluyor.

Bu son cümlenin bir sınırı var ve yazının ilerisinde açılıyor: kayıt her işte sunucu tarafında durmuyor.

Kural hangi yarıda yazılır: Resterm’de hesap ekranda durmuyor

Tanım burada bitiyor, karar başlıyor. Bir yazılımda iş yapan her şeyin altında bir kural var: hangi fiyat geçerli, hangi ürün uygun, hangi talep kabul edilebilir. O kuralın hangi yarıya yazıldığı bir üslup tercihi değil; sistemin verdiği cevabın ne kadar güvenilir olduğunu belirleyen bir karar.

Isıtma ihtiyacından elektrikli ısıtıcı seçen Resterm yazılımında karar en net görülüyor. Kullanıcı bir katalog kodu girmiyor; ısıtılacak işin ısıtma ihtiyacını giriyor. Girdi değişince ekranın işi de değişiyor: ortada bir arama yüzeyi yok, bir ihtiyacın tarifi var.

Hangi ısıtıcının o ihtiyacı karşıladığına mühendislik hesabı karar veriyor ve o hesap sunucu tarafında çalışıyor. Ekranın işi böylece ikiye iniyor: ihtiyacı almak ve hesabın seçtiği ürünü göstermek. Seçim kuralı ekranda yazılı değil. Ekran kuralın çıktısını taşıyor, kuralın kendisini taşımıyor.

Bunun pratikteki karşılığı teklifi hazırlayan kişide görünüyor. Teklifi hazırlayan çoğunlukla hesabı yapan kişi değil. Kural tek bir yarıda durduğu için, hesabı bilmeyen biri de aynı ısıtma ihtiyacı girdisinden aynı ürüne varıyor. Kural ekranda yazılı olsaydı her yüzey kendi kopyasını taşırdı ve kopyaların zamanla birbirinden ayrışmadığını kimse güvence altına alamazdı.

Karşı durum da aynı projeden okunuyor. Girdi bir ürün kodu olsaydı ekranın işi arama olurdu ve ortada bir yarıya yazılacak seçim kuralı kalmazdı. Yani bölünme ancak bir kural varsa bir karar. Kuralsız bir katalogda “hesap hangi yarıda” sorusu cevapsız değil, konusuz. Kendi işinize bakarken sıra da bu: önce bir kuralınız olup olmadığını, sonra onun nerede durduğunu sorun.

Ekranda anında değişen fiyat ile kayda geçen fiyat

Hız bu ayrımı en çok bulandıran şey. Bir demoda ekran anında tepki veriyorsa, işin orada yapıldığı sanılıyor.

Donanım ve renk birleşiminin kendi kaydında durduğu KGM SsangYong online satış kanalında tepki gerçekten anında. Ziyaretçi donanımı ya da rengi değiştirdiğinde rakam ve aracın görseli gecikmeden yenileniyor; bu yenileme ziyaretçinin kendi ekranında oluyor.

Gösterilen değer o cihazda üretilmiyor. Her donanım ve renk birleşiminin ayrı fiyatı, ayrı görseli ve ayrı satış koşulu sunucu tarafında kayıtlı duruyor. Ekranın yaptığı iş, o kayıtlardan hangisinin gösterileceğini seçmek. Ortada bir hesap adımı yok; önceden yazılmış bir cevabın okunması var.

Ayrımın en kolay görüldüğü yer sınırın kendisi. Katalogda tanımı olmayan bir birleşimi ziyaretçi ekranda kuramıyor. Ziyaretçinin seçebildiği her birleşim, arka uçta kendi kaydı olduğu için seçilebiliyor. Ön yüzün neyi gösterebileceğini arka uç belirliyor ve bu bir ekran tasarımı kısıtı değil, kaydın var olup olmaması sorusu.

Hız ile kural sahipliğini birbirine karıştırmanın bedeli satın alma kararında çıkıyor. Hızlı bir ekran gördüğünüzde sormanız gereken şey tepkinin süresi değil, gösterilen değerin nereden okunduğu. İki sistem aynı hızda davranabilir: biri değeri kayıttan okur, öteki ekranda hesaplar. İkincisinde aynı aracı iki ayrı yüzeyde iki ayrı fiyatla görmeniz mümkün hâle gelir ve hangisinin geçerli olduğunu söyleyecek bir yer kalmaz.

Karşı durum aynı soruyu tersten gösteriyor. Fiyatı tek bir ürün kaydında duran bir katalogda, ekranın hızlı davranması için arka uçta ayrı bir birleşim kaydı gerekmiyor. Hazır sepet yazılımları satılan her şeyi tek bir katalog satırı sayarak tam bu varsayımla çalışıyor; birleşim kaydı gerektiren bir ürün yapısına girildiğinde de tam orada tıkanıyor. Yani soru “ekran mı hesaplıyor” değil, “satılan şeyin bir kaydı var mı”.

Sayfa baştan yüklenmiyorsa işi hangi yarı yaptı

Ön yüzün işi en çok şu davranışta abartılıyor: filtreyi değiştiriyorsunuz, liste yenileniyor, sayfanın tamamı yeniden gelmiyor.

Plastik işleme makinelerinin tek tek ilan olarak listelendiği Plastik ve Makina platformunda bu davranış bir tasarım koşulu. Filtre her değiştiğinde sayfanın baştan yüklenmesi arama akışını keser; liste bu koşul gözetilerek kuruldu.

Filtre değiştiğinde yenilenen şey listenin durduğu alan. Sayfanın geri kalanı yerinde kalıyor; ekranın yalnız o bölümü yeni içerikle doluyor. Okurun gördüğü iş bu ve ön yüzün payı da burada bitiyor.

Hangi ilanların açık filtreye uyduğu sorusu sunucu tarafında cevaplanıyor. İlan kayıtlarını MySQL tutuyor, sık istenen okumaların yükünü Redis önbelleği üstleniyor. Ziyaretçinin cihazı hangi makinenin filtreye uyduğuna karar vermiyor; kendisine ulaşan cevabı ekranın doğru yerine yerleştiriyor.

Bu bölümün asıl konusu iki cümlenin aynı sayılması. “Sayfa yenilenmedi” ile “kararı ön yüz verdi” aynı cümle değil. Filtre ön yüzde açılıp kapanıyor, cevabı arka uçta oluşuyor. Bir ekran davranışının akıcı olması, o ekranın yetkili olduğunu göstermiyor.

Filtrenin kendisi de bir ekran anahtarından fazlası. Sıfır ve ikinci el durumu aynı eksende taşınıyor ve alıcı ikisini tek arama içinde karşılaştırıyor. Yani filtre bir görünüm tercihi değil, listeye sorulan sorunun parçası. Soru ön yüzde sorulsa da sorunun cevabı kayıtların durduğu yerde üretiliyor.

Gerçekten yalnız ön yüzün çalıştığı yüzeyler de var; basılı kataloğu ve menüyü yazılıma taşıdığımız yazıda böyle bir yüzey duruyor. Ölçü yine aynı: ekranda değişen şey zaten cihaza inmiş bir içerikse iş ön yüzde kalıyor, yeni bir cevap gerekiyorsa kararın yeri değişiyor.

Çizgi her işte aynı yerden geçmiyor

Buraya kadarki bölümlerde kayıt hep sunucu tarafında durdu. O cümle bir tanım değil.

Kapsama alanının dışında da çalışmaya devam eden AlgoKlima saha uygulaması bunu gösteriyor. AlgoKlima bizim kendi ürünümüz; yayında ve geliştirmesi sürüyor. Teknisyen sahada, kapsama alanının dışında servis kaydını açıyor ve işi bitirince kapatıyor. Kaydı ilk alan yer telefonun yerel kuyruğu oluyor ve uygulama ağ gelmesini beklemiyor.

Yani kayıt bir süre ön yüzde yaşıyor. Teknisyenin telefonu o kaydın durduğu tek yer oluyor ve bağlantı dönene kadar öyle kalıyor. Kuyruğun sonra hangi sırayla boşaldığı ve iki taraftan gelen değişikliklerin nasıl tek kayıtta birleştiği ayrı bir konu; onu bağlantı yokken çalışan saha uygulamalarını anlattığımız yazıda açıyoruz.

Buradan çıkan sonuç tanımın kendisini değiştiriyor. “Kayıt arka uçta durur” cümlesi, bağlantının her zaman var olduğu varsayımının kısaltması. Varsayım geçerliyken cümle doğru çalışıyor. Varsayım düştüğünde çizgi yer değiştiriyor ve ön yüz geçici olarak kaydın tek sahibi oluyor. Bu yüzden ayrımı bir tanım listesi olarak öğrenmek yetmiyor; hangi varsayımın altında konuşulduğunu bilmek gerekiyor.

Aynı üründe ikinci bir ayrıntı var. Ofis paneli web’de, saha uygulaması telefonda çalışıyor. İkisi de birer ön yüz ve ikisi de aynı müşteri ile aynı cihaz kaydını okuyor. Yani yarı sayısı ikide kalmıyor: yüzey çoğalabiliyor, kuralın sahibi çoğalmıyor. Bölünen şey ekran.

Kaydın ilk nerede yazılacağı sorusu bu yazının kapsamının dışında kalıyor. O soru koddan önce kapatılan kararlar arasında ve kaydın neye bağlanacağının koddan önce karara bağlandığı sistem mimarisi çalışmasının konusu.

Hangi iş hangi yarıda durur: dört yüzey yan yana

Aynı soruyu dört ayrı sektörde yan yana okumak, kuralın nereye yazıldığını tek ekranda görünür kılıyor. Satırların hepsi yayındaki işlerden ve sütunlar aynı üç soruyu soruyor.

Son satır öteki üçünden ayrı duruyor ve bilerek “bölünmüş” diyor. Tablo tek yönlü bir kural dayatmıyor: işlerin çoğunda kural arka uçta yazılı çıkıyor, ama bu bir doğa yasası değil, işin koşullarının sonucu.

İlk üç satırın ortak yanı, cevabın kime sorulduğuna göre değişmemesi. Aynı ısıtma ihtiyacı, aynı donanım ve renk birleşimi, aynı filtre kümesi; üçünde de cevabın her yüzeyde aynı çıkması gerekiyor. Son satırda belirleyici olan şey kuralın kime ait olduğu değil, bağlantının o anda olup olmaması.

Tablonun okura bıraktığı iş, kendi işinin hangi satıra daha yakın olduğuna bakmak. Bir kuralınız varsa ve o kural herkes için aynıysa, ilk üç satırın mantığı sizin de mantığınız. Ekibiniz işin bir bölümünü kapsama alanının dışında yapıyorsa, son satır sizin sorunuz.

Ölçüt: aynı cevap her yüzeyde aynı çıkmak zorunda mı

Buraya kadarki bölümlerin ortak sorusu tek cümleye iniyor: aynı cevabın her yüzeyde ve her kişide aynı çıkması gerekiyor mu?

Cevap evetse kural arka uca yazılıyor. Resterm’de aynı ısıtma ihtiyacı girdisi her kullanıcıda aynı ürünü seçmek zorunda ve bu yüzden hesap tek yerde duruyor. Kural ön yüzde olsaydı her yüzeyin kendi kopyası olurdu; kopyaların aynı kaldığını da kimse söyleyemezdi.

İkinci kanıt başka bir sektörde ve başka bir kayıt tipinde duruyor. KGM SsangYong online satışta bir donanım ve renk birleşiminin satış koşulu ziyaretçiye göre değişmiyor. Aynı birleşimi iki kişi iki ayrı cihazda açtığında aynı koşulu görüyor, çünkü gördükleri şey bir kayıt.

Üçüncü uygulama ekran davranışını cevaptan ayırıyor. Plastik ve Makina’da listenin hangi ilanları döndüreceği her ziyaretçi için aynı kurala bağlı. Filtrenin açılıp kapanması bir ekran işi, filtreye verilecek cevap bir kayıt işi. İkisi aynı ekranda görünüyor diye aynı yarıya ait olmuyor.

Ölçütün tek bir projede en açık yazılı hâli Diotek’te duruyor: iki talep tipinin doğrulama kuralları tek yerde tutuluyor ve bu yüzden tip ayrımı ziyaretçinin cihazında çalışan koda hiç geçmiyor. Mekanizmayı keşif randevusu ile servis talebinin ayrı kayıtlara düştüğü yazıda açtık; burada yalnız ölçütün çalışan karşılığı olarak duruyor.

Ölçüt “hayır” da diyebiliyor. Yalnız o anda o ekranı açan kişinin gördüğünü biçimlendiren işler ön yüze ait: bir listenin görüntüleme sırası, bir panelin açık sekmesi, uzun bir formun kaç adıma bölündüğü. Bunlar kimseye karşı savunulması gereken cevaplar değil; bir kişinin o anki okuma konforuna ait tercihler.

AlgoKlima ölçütün kenarında duruyor. Kayıt bir süre ön yüzde kalabiliyor, ama bunun nedeni kuralın sahibinin değişmesi değil, bağlantının orada olmaması. Yani ölçütü uygularken ikinci bir soru gerekiyor: bu iş hep bağlantı varken mi yapılıyor?

Kendi işinizdeki kuralı bu tek soruyla sınayın. Cevabınız evetse, o kuralın hangi yarıda yazıldığı teklifte konuşulacak ilk şey. Tanıtım sayfalarıyla işin yürüdüğü bölümlerin tek uygulamada birleştiği web yazılımı çalışmalarımızda ekran çizilmeden önce cevabını aradığımız soru da bu.