Back-End Nedir? Web Sitesi Geliştirmede Arka Uç Kodlama Aşaması

Bir web sitesinin görünen yüzü tasarımdır; ancak formu kaydeden, siparişi işleyen ve kullanıcıyı tanıyan kısım back-end katmanıdır. Bu yazıda back-end kavramını yazılımcı olmayan bir yönetici gözüyle anlatıyorum. Sunucu, veritabanı, API, kimlik doğrulama ve diller konusunda teklif alırken ya da ekibinizle konuşurken işinize yarayacak bir çerçeve kuruyorum. Kariyer yol haritası değil; kavramsal bir harita.

Back-end nedir ve bir web sitesinde ne işe yarar?

Back-end, bir web sitesinin kullanıcıya görünmeyen sunucu tarafıdır: gelen isteği karşılayan, iş kurallarını çalıştıran, veriyi veritabanında saklayan ve sonucu tarayıcıya gönderen kod ve altyapının bütünüdür. Türkçede arka uç diye de geçer. Form kaydı, üyelik, ödeme ve yönetim paneli bu katmanda çalışır.

Basit bir benzetme yapayım. Restoranda salon, menü ve servis front-end gibidir; müşteri onları görür. Mutfak, depo ve kasa ise back-end gibidir. Müşteri mutfağı görmez, ama yemek geç gelirse ya da yanlış gelirse sorunun çoğu oradadır.

Sahada gördüğüm en yaygın yanılgı şu: işletmeler web sitesini yalnızca tasarım olarak değerlendiriyor. Oysa lead kaybı, yavaş sayfa ve güvenlik açığı gibi sorunların önemli kısmı arka tarafta başlıyor. Bu yüzden teklif karşılaştırırken back-end kapsamını ayrıca sormanızı öneririm.

Front-end ile back-end arasındaki fark nedir?

Front-end, tarayıcıda çalışan ve kullanıcının gördüğü her şeydir: HTML, CSS, JavaScript, butonlar ve animasyonlar. Back-end ise sunucuda çalışır ve kullanıcının göremediği işleri üstlenir. İkisi sürekli konuşur; biri soruyu sorar, diğeri cevabı hazırlar.

Bu tablodaki son satır önemli. Tarayıcıya giden her kodu kullanıcı açıp okuyabilir. Dolayısıyla fiyat hesabı, indirim kontrolü veya yetki kontrolü gibi kritik kuralları yalnızca front-end tarafında bırakmak ciddi bir risktir. Bu kuralların son sözü her zaman back-end tarafında olmalıdır. Ön yüz tarafını ayrı bir yazıda ele alıyorum; burada odak arka taraf.

Bir ziyaretçi sayfayı açtığında arka planda neler olur?

Tarayıcıya adres yazdığınız an, kısa ama kalabalık bir yolculuk başlar. Bu yolculuk çoğu zaman bir saniyenin altında biter. Bu yolculuğu bilmek, bir sorunun nerede çıktığını anlamanızı kolaylaştırır. MDN belgeleri de sunucu tarafı programlamayı bu istek ve yanıt döngüsü üzerinden anlatır.

1. Tarayıcı, alan adının hangi sunucuya işaret ettiğini DNS üzerinden öğrenir.
2. Sunucuya HTTPS ile güvenli bir bağlantı açar ve isteğini gönderir.
3. Web sunucusu isteği karşılar, uygulama koduna iletir.
4. Uygulama gerekirse oturumu kontrol eder, veritabanından veri çeker.
5. İş kuralları çalışır; örneğin stok düşer ya da sistem formu kaydeder.
6. Uygulama sonucu HTML veya JSON olarak paketler ve tarayıcıya gönderir.
7. Tarayıcı gelen yanıtı işler ve sayfayı ekrana çizer.

İlk adımı merak ederseniz DNS sorgulama aracıyla kendi alan adınızın hangi adrese gittiğini görebilirsiniz. Üçüncü ve altıncı adımlar arası tamamen back-end alanıdır. Sayfa geç açılıyorsa zamanın çoğu genelde bu aralıkta gider.

Sunucu tam olarak ne iş yapar, hosting ile ilişkisi nedir?

Sunucu, sürekli açık duran ve gelen isteklere cevap veren bir bilgisayardır. Hosting ise bu bilgisayarın kaynağını kiralamanın ticari adıdır. Yani hosting paketi aldığınızda aslında bir sunucunun bir parçasını ya da tamamını kullanıyorsunuz.

Sık karşılaştığım dört model var:

• Paylaşımlı hosting: aynı sunucuyu yüzlerce siteyle bölüşürsünüz; ucuzdur ama komşu sitelerin yükünden etkilenirsiniz.
• VPS: sanal olarak ayrılmış bir sunucudur; kaynaklarınız size aittir ama yönetim sorumluluğu da artar.
• Bulut: ihtiyaç arttıkça kaynak ekleyebildiğiniz, kullandıkça ödediğiniz yapıdır.
• Sunucusuz (serverless): kodu fonksiyonlar hâlinde yüklersiniz; sunucuyu sağlayıcı yönetir.

Sunucunun üzerinde birkaç katman daha bulunur. Nginx veya Apache gibi bir web sunucusu isteği karşılar. Arkasında uygulama çalışır; en altta da veritabanı durur. Kurumsal bir tanıtım sitesi için paylaşımlı hosting çoğu zaman yeter. Öte yandan üyelik, ödeme ve yoğun kampanya trafiği varsa VPS veya bulut tarafına geçmek genelde daha sağlıklı olur. Benim tavsiyem, hosting kararını fiyattan önce trafik ve iş kuralı ihtiyacına göre vermeniz.

Veritabanı back-end katmanının neresinde durur?

Veritabanı, sitenin hafızasıdır. Ürünler, blog yazıları, üyeler, siparişler ve form kayıtları burada durur. Sayfa kapansa da, sunucu yeniden başlasa da veri kaybolmaz; çünkü veritabanı kalıcı depolama için tasarlanmıştır.

Back-end kodu veritabanıyla doğrudan konuşur. Örneğin bir ürün sayfası açıldığında uygulama "bu slug'a sahip ürünü getir" diye sorgu gönderir. Gelen veriyi şablonla birleştirir ve sayfayı üretir. WordPress gibi bir CMS kullansanız bile arka planda bu döngü aynen işler.

Yöneticilerin bilmesi gereken üç kavramı kısaca özetleyeyim. Birincisi tablo: aynı türden kayıtların durduğu yapı, örneğin "siparişler". İkincisi indeks: sık aranan alanlarda aramayı hızlandıran fihrist. Üçüncüsü ilişki: bir siparişin hangi müşteriye ait olduğunu gösteren bağ.

Sahada en sık gördüğüm sorun, indeks eksikliği yüzünden kayıt sayısı büyüdükçe yavaşlayan panellerdir. İlk yıl her şey hızlıdır; ancak on binlerce kayıttan sonra listeler dakikalarca bekletir. Bu, tasarımla çözülen bir sorun değildir.

İlişkisel ve NoSQL veritabanı arasında nasıl seçim yaparsınız?

İlişkisel veritabanları, veriyi satır ve sütunlardan oluşan tablolarda tutar; siz de SQL diliyle sorgularsınız. MySQL, MariaDB ve PostgreSQL bu ailenin en bilinen üyeleridir. NoSQL ise daha esnek yapıları kapsayan geniş bir şemsiyedir: belge tabanlı MongoDB, anahtar değer tabanlı Redis bunlara örnektir.

Pratikte çoğu kurumsal projede ikisini birlikte görürsünüz. Ana veri ilişkisel bir veritabanında durur; Redis gibi bir NoSQL aracı ise hız için yanında çalışır. Bu nedenle "hangisi daha iyi" yerine "hangi veri nerede durmalı" sorusunu sormanızı öneririm. Para ve stok gibi hata kaldırmayan veriler için ilişkisel yapıyı tercih ederim.

API nedir ve back-end neden API üzerinden konuşur?

API, iki yazılımın birbiriyle konuşmak için kullandığı kurallı kapıdır. Bir yazılım belirli bir adrese istek gönderir, diğeri tanımlı bir biçimde cevap verir. Günümüzde bu cevap çoğunlukla JSON biçimindedir.

Back-end iki yönde API kullanır. Birinci yönde kendi API'sini sunar: mobil uygulamanız, ön yüzünüz veya iş ortaklarınız bu kapıdan veri alır. İkinci yönde başkalarının API'sini tüketir: ödeme altyapısı, kargo firması, e-fatura sağlayıcısı, CRM ve reklam platformları gibi.

Somut bir örnek vereyim. Bir müşteri sitenizde sipariş verdiğinde back-end önce ödeme sağlayıcısının API'sine gider. Onay gelince siparişi kaydeder, ardından e-fatura sistemine veri yollar. Son olarak kargo firmasının API'sinden takip numarası alır. Kullanıcı bunların hiçbirini görmez; yalnızca "siparişiniz alındı" ekranını görür.

E-ticaret projelerinde işin büyük kısmı bu entegrasyonlarda geçer. E-ticaret danışmanlığı verirken ilk sorduğum sorulardan biri de hangi sistemlerin birbirine bağlanacağıdır. Çünkü her entegrasyon, bakımı gereken yeni bir bağımlılık demektir.

REST, GraphQL ve webhook arasındaki fark ne?

Bu üç terim teklif ve teknik dokümanlarda sık geçer. Aralarındaki farkı kısaca bilmek, ekibinizle aynı dili konuşmanızı sağlar.

• REST: her kaynağın bir adresi vardır, örneğin /siparisler/125. İstemci GET ile okur, POST ile ekler, PUT ile günceller, DELETE ile siler. En yaygın yaklaşımdır.
• GraphQL: tek bir adrese sorgu gönderirsiniz ve hangi alanları istediğinizi siz belirlersiniz. Ön yüzün çok farklı veri ihtiyaçları varsa işe yarar.
• Webhook: yön terstir; karşı sistem bir olay olduğunda sizin adresinize haber verir. Örneğin ödeme onaylanınca sağlayıcı sizin sunucunuza bildirim yollar.

Webhook konusunda bir uyarım var. Gelen bildirimin gerçekten o sağlayıcıdan geldiğini doğrulamak gerekir; çoğu sağlayıcı bunun için imza veya gizli anahtar kullanır. Bu kontrolü atlayan bir sistemde, sahte bir istek siparişi "ödendi" olarak işaretleyebilir. Ödeme entegrasyonlarında gördüğüm en kritik açık türlerinden biri budur.

Kısacası REST çoğu kurumsal proje için yeterli ve anlaşılır bir başlangıçtır. GraphQL'i ancak gerçek bir ihtiyaç varsa tercih etmenizi öneririm.

Kimlik doğrulama ve yetkilendirme nasıl çalışır?

Pek çok ekip bu iki kavramı karıştırır. Kimlik doğrulama "sen kimsin?" sorusudur; kullanıcı adı ve parola bu soruyu cevaplar. Yetkilendirme ise "bunu yapmaya iznin var mı?" sorusudur; giriş yapmış bir kullanıcının hangi sayfaları görebileceğini belirler.

Giriş yaptıktan sonra sunucunun sizi her istekte tanıması gerekir. Bunun iki yaygın yolu var. Birincisi oturum (session): sunucu bir oturum kaydı tutar, tarayıcıya da bir çerez verir. İkincisi token: sunucu imzalı bir anahtar üretir, istemci bu anahtarı her istekte taşır. JWT bu yöntemin bilinen bir biçimidir.

Kurumsal projelerde sık gördüğüm diğer parçalar şunlar:

• Google veya Microsoft hesabıyla giriş (OAuth tabanlı tek oturum açma).
• Yönetim paneli için iki adımlı doğrulama.
• Rol tabanlı yetki: editör, muhasebe, yönetici gibi ayrı haklar.
• Başarısız girişlerde hız sınırı ve geçici kilit.

Asıl risk genelde yetkilendirmededir. Kullanıcı adresi değiştirip /siparis/126 yazdığında başkasının siparişini görebiliyorsa, giriş sistemi ne kadar güçlü olursa olsun veri sızar. OWASP Top 10 listesinde bozuk erişim kontrolü bu yüzden ilk sırada yer alıyor.

Parolaları ve kişisel verileri nasıl korursunuz?

Parolayı düz metin olarak saklamak, bugün kabul edilebilir bir durum değildir. Doğru yöntem, parolayı geri çevrilemeyen bir özet fonksiyonundan geçirip yalnızca bu özeti saklamaktır. OWASP parola saklama rehberi bu iş için Argon2id, bcrypt gibi yavaş ve tuzlu algoritmaları öneriyor.

Kullanıcılarınıza da güçlü parola kullanmayı kolaylaştırabilirsiniz. Örneğin şifre oluşturucu ile rastgele ve uzun parolalar üretmek birkaç saniye sürer. Ancak asıl koruma sunucu tarafındaki saklama yöntemidir.

Kişisel verilerde de benzer bir mantık geçerli. Türkiye'de KVKK, Avrupa'da GDPR kapsamında şu soruları back-end ekibinizle konuşmanızı öneririm:

• Hangi veriyi gerçekten topluyoruz, hangisine ihtiyacımız yok?
• Veri hangi ülkedeki sunucuda duruyor?
• Form kayıtları ne kadar süre saklanıyor, sonra siliniyor mu?
• Yedekler de şifreli mi, kimler erişebiliyor?

Bu sorular teknik gibi görünse de sorumluluk işletmeye aittir. Dolayısıyla cevaplarını yazılı olarak almanız, olası bir denetimde işinizi kolaylaştırır.

Back-end dilleri hangileri ve aralarındaki fark ne?

Back-end tarafında tek bir doğru dil yok. Her dilin güçlü olduğu bir ekosistem, bir topluluk ve bir işe alım piyasası var. Burada derin bir karşılaştırma yapmayacağım; yalnızca bir yöneticinin bilmesi gereken genel tabloyu çiziyorum.

• PHP: WordPress, Laravel ve pek çok hazır sistemin dili. Hosting desteği çok yaygın.
• JavaScript ve TypeScript (Node.js): ön yüz ile aynı dil; gerçek zamanlı işlerde ve API servislerinde sık karşıma çıkıyor.
• Python: Django ve FastAPI ile web tarafında, ayrıca veri ve yapay zeka işlerinde güçlü.
• Java ve C#: bankacılık, kamu ve büyük kurumsal sistemlerde yaygın; uzun ömürlü projelerin gözdesi.
• Go: yüksek eş zamanlı yük taşıyan servislerde ve altyapı araçlarında öne çıkıyor.

Benim önerim şu: dili, projenin ihtiyacına ve ekibin bildiğine göre seçin. Moda olduğu için seçilen bir dil, üç yıl sonra geliştirici bulamadığınız bir yük hâline gelebilir. Üstelik sitenizin yıllarca bakım alacağını unutmayın; bakım yapacak kişiyi bulabilmek, dilin teknik üstünlüğünden daha önemlidir.

Framework, CMS ve özel yazılım kararını neye göre verirsiniz?

Back-end kurarken üç yoldan birini seçersiniz. Hazır bir CMS kullanırsınız, bir framework üzerine özel geliştirme yaparsınız ya da ikisini karıştırırsınız. Her yolun bedeli farklıdır.

CMS, yani WordPress gibi içerik yönetim sistemleri, hızlı başlangıç sunar. Blog, kurumsal sayfalar ve basit formlar için çoğu zaman yeterlidir. Buna karşılık eklenti sayısı arttıkça güvenlik yüzeyi ve güncelleme yükü de büyür.

Framework, yani Laravel, Django veya Express gibi yapılar, özel iş kurallarını temiz biçimde kodlamanızı sağlar. Kimlik doğrulama, yönlendirme ve veritabanı erişimi gibi ortak işleri hazır verir. Böylece ekip her şeyi sıfırdan yazmaz.

Özel yazılım ise yalnızca gerçekten size özgü bir süreç varsa anlamlıdır. Örneğin bayi fiyatlandırması, karmaşık teklif hesaplaması ya da çok şubeli stok yönetimi gibi.

Web tasarım projelerinde benim yaklaşımım basit: içerik ağırlıklı kısımlar için sağlam bir CMS, özgün iş kuralları için framework tabanlı modüller. Yani her şeyi eklentiyle çözmeye çalışmak da, her şeyi sıfırdan yazmak da genelde pahalıya patlar.

Önbellek, kuyruk ve arka plan işleri ne işe yarar?

Back-end tarafında hız ve dayanıklılık için ekipler üç yardımcı araca sık başvurur. İsimleri teknik görünse de mantıkları oldukça sezgiseldir.

Önbellek (cache): sık istenen bir sonucu her seferinde yeniden hesaplamak yerine hazır tutar. Örneğin ana sayfadaki sistem ürün listesini dakikada bir kez üretir, aradaki binlerce ziyaretçiye hazır kopya gider. Sayfa önbelleği, nesne önbelleği ve CDN bu ailenin farklı katmanlarıdır.

Kuyruk (queue): hemen yapılması gerekmeyen işleri sıraya koyar. Kullanıcı formu gönderdiğinde e-posta gönderimi, CRM kaydı ve PDF üretimi kuyruğa girer; kullanıcı ise beklemeden teşekkür sayfasını görür.

Zamanlanmış işler (cron): belirli saatlerde kendiliğinden çalışan görevlerdir. Gece raporları, eski kayıtların temizliği ve kur güncellemesi bu gruba girer.

Bu araçların önemi özellikle kampanya dönemlerinde ortaya çıkar. Reklam trafiği ani yükseldiğinde önbelleksiz bir site ilk dakikalarda yavaşlar. Dahası harici bir servis yanıt vermezse kuyruksuz bir form kaydı kaybolabilir. Dolayısıyla bu parçalar lüks değil, sigorta gibidir.

Back-end site hızını ve SEO performansını nasıl etkiler?

Sayfa hızını çoğu zaman görsel boyutu ve JavaScript ile ilişkilendiririz. Oysa zincirin ilk halkası sunucudur. Tarayıcı, sunucudan ilk baytı almadan hiçbir şey çizemez. Bu süreye TTFB, yani ilk bayta kadar geçen süre denir.

web.dev'in TTFB rehberine göre 0,8 saniye veya altındaki değerler iyi, 1,8 saniyenin üzerindekiler ise zayıf kabul ediliyor. Yavaş veritabanı sorguları, önbelleksiz sayfalar, yetersiz sunucu ve uzak veri merkezi bu süreyi uzatan başlıca etkenlerdir.

SEO tarafında back-end kararlarının etkisi hızla sınırlı değil. Şu konular da doğrudan arka tarafta çözüme kavuşur:

• Doğru HTTP durum kodları: silinen sayfa için 404 veya 410, taşınan sayfa için 301.
• Kalıcı ve temiz URL yapısı, kanonik etiketlerin tutarlı üretimi.
• Otomatik güncellenen XML site haritası.
• Sunucu tarafında üretilen HTML, yani botların boş sayfa görmemesi.

Hızın sıralamaya etkisini site hızı ve SEO yazısında, ölçüm adımlarını da Lighthouse ile performans testi rehberinde ayrıntılı anlattım. Yönlendirme zincirlerini kontrol etmek için yönlendirme denetleyici aracını da kullanabilirsiniz.

Back-end güvenliğinde en sık yapılan hatalar neler?

Güvenlik açıklarının çoğu karmaşık saldırılardan değil, basit ihmallerden doğar. Sahada en sık karşılaştığım hataları şöyle sıralayabilirim:

1. Kullanıcıdan gelen veriyi doğrulamadan veritabanı sorgusuna koymak (SQL enjeksiyonu).
2. Yetki kontrolünü yalnızca menüde gizlemekle sınırlı tutmak.
3. Güncellenmeyen CMS, eklenti ve kütüphaneler.
4. Web kök dizininde unutulan yedek dosyaları ve test betikleri.
5. Hata sayfalarında sunucu yolunu ve veritabanı bilgisini göstermek.
6. API anahtarlarını ve parolaları kodun içine yazmak.
7. Giriş ve form uç noktalarında hız sınırı olmaması.

Bu listenin güzel tarafı, maddelerin çoğunun düşük maliyetle kapanabilmesidir. Hazır sorgu (prepared statement) kullanımı enjeksiyonu büyük ölçüde engeller. Gizli anahtarları ortam değişkenlerine taşımak birkaç saatlik iştir. Düzenli güncelleme ise bir süreç disiplinidir.

Benim önerim, yılda en az bir kez dışarıdan bağımsız bir göz ile güvenlik kontrolü yaptırmanız. Özellikle ödeme alan veya kişisel veri toplayan sitelerde bu kontrol, olası bir sızıntının maliyetine kıyasla oldukça ucuzdur.

Loglama, izleme ve yedekleme neden back-end işinin parçası?

Bir site yayına alındığında back-end işi bitmez; aslında asıl iş o zaman başlar. Sorun çıktığında ne olduğunu anlamak için kayıt, sorun büyümeden haber almak için izleme ve felakette geri dönmek için yedek gerekir.

Loglama: sunucunun ve uygulamanın tuttuğu olay kayıtlarıdır. Hangi istek hata verdi, hangi sorgu yavaş çalıştı, kim hangi saatte panele girdi gibi soruları bu kayıtlar cevaplar.

İzleme: sitenin açık olup olmadığını, yanıt süresini ve sunucu kaynaklarını sürekli kontrol eden sistemdir. Site kapandığında sizi bir müşteri değil, bir alarm uyarmalıdır.

Yedekleme: veritabanının ve dosyaların düzenli kopyasıdır. Ancak yedeğin varlığı tek başına yetmez. Yedeğin sunucudan ayrı bir yerde durması ve düzenli olarak geri yükleme testinden geçmesi gerekir.

Bir de şu noktayı ekleyeyim: form bildirimleri e-posta ile geliyorsa, e-postanın ulaşıp ulaşmadığını da izlemek gerekir. Alan adı doğrulama kayıtları eksik olduğunda bildirimler spam klasörüne düşebilir. Bu konuyu kurumsal e-posta altyapısı yazısında ayrıntılı işledim.

Bir iletişim formu gönderildiğinde back-end neler yapar?

Kavramları somutlaştırmak için basit bir iletişim formunun yolculuğunu adım adım izleyelim. Bu örnek, yukarıdaki parçaların nasıl birleştiğini gösteriyor.

Ziyaretçi formu doldurup gönder butonuna bastığında tarayıcı verileri HTTPS üzerinden sunucuya yollar. Back-end önce isteğin gerçek bir kullanıcıdan gelip gelmediğini kontrol eder; bunun için hız sınırı ve bot koruması devreye girer. Ardından alanları doğrular: e-posta biçimi doğru mu, telefon numarası anlamlı mı?

Doğrulama geçince uygulama kaydı veritabanına yazar. Bu aşamada reklam kaynağı bilgisi, yani UTM parametreleri veya tıklama kimliği de kayda girer. Böylece hangi kampanyanın lead getirdiği sonradan ölçülebilir hâle gelir. Kampanya bağlantılarını düzenli etiketlemek için UTM oluşturucu işinizi kolaylaştırır.

Bu noktada yinelenen kayıt kontrolü de önemlidir. Aynı kişi formu iki kez gönderirse, satış ekibinin iki ayrı lead görmemesi gerekir. Ayrıca spam kayıtlarını erken ayıklamak, CRM verisinin temiz kalmasını sağlar.

Sonra kuyruk devreye girer: satış ekibine bildirim gider, müşteriye otomatik yanıt gider, kayıt CRM'e aktarılır. Kullanıcı ise bu işlerin bitmesini beklemeden teşekkür sayfasını görür. Formun ön yüz tasarımı ne kadar iyi olursa olsun, bu zincirde tek bir halka koparsa lead sessizce kaybolur.

Kurumsal bir site için back-end kapsamını nasıl tanımlarsınız?

Teklif alırken "site yapılacak" demek yetmez. Back-end kapsamını baştan yazıya dökmek, hem bütçe sürprizlerini hem de teslim sonrası tartışmaları azaltır. Kullandığım kontrol listesi şöyle:

1. Hangi verileri saklayacaksınız: ürün, üye, sipariş, form, içerik?
2. Hangi dış sistemlerle entegrasyon gerekiyor: ödeme, kargo, e-fatura, CRM?
3. Kimler panele girecek ve hangi yetkilerle?
4. Hosting nerede olacak, kimin adına kayıtlı olacak?
5. Yedekleme sıklığı ve geri yükleme sorumluluğu kimde?
6. Güncelleme ve güvenlik yamaları hangi sıklıkla gelecek?
7. Kaynak kod, veritabanı ve sunucu erişimi size teslim edilecek mi?
8. Beklenen trafik ve kampanya dönemleri ne kadar?

Yedinci madde özellikle kritik. Kodun ve veritabanının sahipliği sizde değilse, ajans veya yazılımcı değiştirdiğinizde sıfırdan başlamak zorunda kalabilirsiniz. Bu yüzden erişim bilgilerinin işletme adına tutulmasını her projede şart koşarım.

Büyük ve çok ekipli sitelerde mimari seçimler de gündeme gelir. Ön yüzün parçalara bölündüğü yapıları micro frontend yazısında ayrıca anlattım.

Back-end kararları pazarlama sonuçlarını nasıl etkiler?

Pazarlama tarafında çalışan biri olarak şunu açıkça söyleyebilirim: reklam bütçesinin verimi, çoğu zaman sunucu tarafındaki küçük kararlara bağlı. Dönüşüm kaydı eksik düşüyorsa, reklam platformu yanlış kitleye optimize olur. Sayfa kampanya anında yavaşlıyorsa, ödediğiniz tıklamaların bir kısmı boşa gider.

Örneğin sunucu taraflı dönüşüm gönderimi, çerez kısıtlamaları arttıkça daha önemli hâle geldi. Formdan gelen kaydı tıklama kimliğiyle eşleştirip reklam platformuna geri bildirmek, tamamen back-end işidir. Bu altyapı kurulmadan kampanya optimizasyonu kör uçuşa döner.

Benzer şekilde SEO çalışması da arka taraf sağlam olmadan kalıcı sonuç vermez. SEO danışmanlığı sürecinde ilk baktığım yerlerden biri durum kodları, yönlendirmeler ve sunucu yanıt süresidir. Yani back-end, pazarlama ekibinin göremediği ama her gün sonucunu hissettiği katmandır.

Sonuç: görünmeyen katmana doğru soruları sorun

Back-end, bir web sitesinin güvenilirliğini, hızını ve büyüme kapasitesini belirleyen görünmez katmandır. Sunucu, veritabanı, API, kimlik doğrulama ve dil seçimi birbirinden bağımsız kararlar değildir; hepsi aynı zincirin halkalarıdır.

Yazılımcı olmanız gerekmiyor. Ancak doğru soruları sormanız gerekiyor: veri nerede duruyor, kim erişebiliyor, yedek var mı, entegrasyonlar koparsa ne oluyor, kod kimin? Bu soruların net cevabı yoksa, projeniz ne kadar güzel görünürse görünsün risk altındadır.

Son bir not ekleyeyim: back-end katmanını tek seferlik bir yatırım olarak görmeyin. Tarayıcılar, ödeme sağlayıcıları ve güvenlik standartları sürekli değişiyor. Dolayısıyla bütçenizi planlarken ilk kurulumun yanına yıllık bakım payını da koymanızı öneririm. Bu pay, sitenizin ilk günkü hızını ve güvenliğini yıllarca korumasının en ucuz yoludur.

Kendi projenizde back-end kapsamını birlikte netleştirmek isterseniz iletişim sayfasından bana ulaşabilirsiniz. İhtiyacınızı dinler, gereksiz karmaşayı ayıklayıp sade bir yol haritası çıkarırım.