Web Sitesi ile Web Uygulaması Arasındaki Teknik Fark Nedir?

Web sitesi ve web uygulaması farkı, temel olarak kullanıcının sayfayı yalnızca bilgi almak için mi ziyaret ettiği, yoksa sistem içinde veri ve işlevlerle etkileşime mi girdiği üzerinden açıklanabilir. Web sitesi çoğunlukla içerik sunar; web uygulaması ise kullanıcıdan aldığı girdileri işler, sonuç üretir ve çoğu zaman bu verileri saklar.

Ancak bu iki kavram birbirini tamamen dışlayan kesin kategoriler değildir. Bir blog sayfası, yorum, üyelik veya kişiselleştirme özellikleri eklendikçe web uygulamasına özgü davranışlar kazanabilir. Bu nedenle ilk web projesinin kapsamını belirlerken yalnızca “site mi, uygulama mı?” sorusuna değil; etkileşim, veri kalıcılığı ve sunucu taraflı iş mantığı gereksinimlerine de bakmak gerekir.

Web sitesi ve web uygulaması ne anlama gelir?

Web sitesi, tarayıcı üzerinden erişilen ve öncelikle bilgi, haber, yazı, görsel veya kurumsal içerik sunan dijital yapıdır. Ana sayfa, hakkında sayfası, iletişim bilgileri, blog yazıları ve dokümantasyon sayfaları web sitesi kapsamında düşünülebilir. Kullanıcı bu sayfalarda gezinir, içerikleri okur ve çoğu durumda sistemin iç verilerini değiştirmez.

Web uygulaması ise tarayıcıda çalışan, kullanıcının bir işlem gerçekleştirmesine ve sistemin bu işleme göre yanıt üretmesine olanak tanıyan web tabanlı sistemdir. Kullanıcı hesabıyla giriş yapabilir, form doldurabilir, kayıt oluşturabilir, mevcut verileri güncelleyebilir veya farklı sonuçları filtreleyebilir. Görev takip uygulamasında görev eklemek, görevi “devam ediyor” durumuna almak ve yalnızca tamamlanmamış görevleri görüntülemek bu davranışlara örnektir.

Bu tanım, web uygulamasının mutlaka çok karmaşık veya büyük olması gerektiği anlamına gelmez. Basit bir randevu formu, kişisel not sistemi veya kullanıcıların kendi listelerini yönettiği küçük bir panel de web uygulaması mantığı taşıyabilir. Belirleyici nokta, sayfanın yalnızca içerik göstermesi değil, kullanıcının işlemlerinin sistem tarafından değerlendirilip bir sonuca dönüştürülmesidir.

Bu kavramlar kesin teknik sınıflar değildir

Gerçek projelerde web sitesi ve web uygulaması çoğu zaman aynı yapı içinde bulunur. Bir haber platformunun ana sayfası ziyaretçilere içerik sunarken, üyelerin kaydettiği yazıları yönettiği bölüm uygulama gibi çalışabilir. Bir şirketin web sitesi; kurumsal bilgilerin yanında müşteri giriş paneli, destek talebi oluşturma ekranı veya sipariş takip alanı barındırabilir.

Bu yüzden “web sitesi pasiftir, web uygulaması tamamen etkileşimlidir” şeklinde katı bir ayrım yapmak yanıltıcı olabilir. Bir web sitesinde arama kutusu, iletişim formu veya yorum bölümü bulunabilir. Benzer şekilde bir web uygulamasında yardım sayfaları, kullanım kılavuzları ve açıklayıcı içerikler yer alabilir. Projenin türünü anlamak için tek bir özelliğe değil, sistemin genel davranışına bakmak daha doğrudur.

Statik, dinamik, etkileşimli ve veri odaklı neyi anlatır?

“Statik”, “dinamik”, “etkileşimli” ve “veri odaklı” ifadeleri aynı ölçütü açıklamaz. Bu kavramları birbirinin eş anlamlısı gibi kullanmak, özellikle ilk projesinin kapsamını belirlemeye çalışan öğrencilerde yanlış beklenti oluşturabilir.

• Statik içerik: İçeriğin önceden hazırlanmış dosyalardan sunulması ve her ziyaretçiye büyük ölçüde aynı biçimde gösterilmesidir. Tanıtım sayfası veya basit bir dokümantasyon bölümü buna örnek olabilir.
• Dinamik içerik: Sayfanın gösterilecek içeriği isteğe, zamana, kullanıcıya veya veri kaynağına göre oluşturmasıdır. Blog ana sayfasında en yeni yazıların veri kaynağından çekilmesi dinamik üretime örnek verilebilir.
• Etkileşimli sistem: Kullanıcının yaptığı işlemin arayüzde veya sistem davranışında bir değişiklik oluşturmasıdır. Form gönderme, filtreleme, sıralama ve görev durumunu değiştirme etkileşimli davranışlardır.
• Veri odaklı sistem: Çalışmasını kayıtlar, kullanıcı bilgileri, içerikler veya işlem geçmişi gibi verileri okuyup işleme üzerine kuran sistemdir. Kullanıcıların kendi görevlerini sakladığı bir uygulama veri odaklıdır.

Örneğin yalnızca yazıları gösteren bir blog, teknik olarak statik içerik sunabilir. Fakat yazılar bir içerik yönetim sisteminden çekiliyorsa sayfa dinamik biçimde oluşturulabilir. Bu blogda ziyaretçiler yorum yazabiliyorsa etkileşim vardır; yorumlar kullanıcı hesabıyla ilişkilendiriliyor ve veri tabanında tutuluyorsa sistem aynı zamanda veri odaklı bir özellik kazanır.

Dolayısıyla bir projenin “dinamik” olması tek başına onun web uygulaması olduğu anlamına gelmez. Aynı şekilde bir web sitesinde etkileşim bulunması da onu bütünüyle uygulamaya dönüştürmez. Asıl soru şudur: Kullanıcının işlemi yalnızca arayüzde geçici bir değişiklik mi oluşturuyor, yoksa sunucu tarafında işlenip kalıcı bir veriye veya kurala mı dönüşüyor?

Blog sayfası ile görev takip uygulaması nasıl ayrılır?

Bu ayrımı somutlaştırmak için iki örneği karşılaştıralım: Ziyaretçilere yazılar sunan bir blog sayfası ve kullanıcıların görevlerini yönettiği bir görev takip uygulaması. Her ikisi de tarayıcıda açılır, sayfalar gösterebilir ve kullanıcıdan bazı girdiler alabilir. Fakat kullanıcı işlemlerinin kapsamı ve bu işlemlerin sistemde oluşturduğu sonuçlar farklıdır.

Blog sayfasının temel amacı içerik sunmaktır. Ziyaretçi kategori seçebilir, arama yapabilir veya bir yazının ayrıntılarını görüntüleyebilir. Bu işlemlerin bazıları tarayıcıda, bazıları ise sunucu tarafında gerçekleşebilir. Ancak blogun en basit hâlinde ziyaretçinin yaptığı işlem, içerik kayıtlarının sahibi olmasını veya sistemde kişisel bir çalışma alanı oluşturmasını gerektirmez.

Görev takip uygulamasında ise kullanıcı bir aktördür ve sistemde kendisine ait işlemler gerçekleştirir. Kullanıcı giriş yaptıktan sonra yeni görev oluşturabilir, görev başlığı veya açıklaması ekleyebilir, görevi tamamlandı olarak işaretleyebilir ve yalnızca belirli durumdaki görevleri listeleyebilir. Bu davranışlar, uygulamanın yalnızca içerik göstermediğini; kullanıcı, görev ve durum gibi veriler arasında kurallar işlettiğini gösterir.

Statik blog nasıl dinamik davranış kazanır?

Bir blogun başlangıç sürümünde her yazı, önceden hazırlanmış bir sayfa olarak ziyaretçiye sunulabilir. Ziyaretçi yazıyı açar, okur ve başka bir sayfaya geçer. Bu yapı, içerik sunma amacı için yeterli olabilir ve ilk proje açısından daha sınırlı bir kapsam oluşturur.

Sonraki aşamada kategori filtreleme, site içi arama, yorum, üyelik veya kişiselleştirilmiş içerik eklenebilir. Örneğin ziyaretçinin okuduğu yazıları kaydetmesi için kullanıcı hesabı gerekiyorsa sistem artık yalnızca herkese aynı içeriği sunmaz. Kullanıcıya özel kayıtların tutulması, kimlik doğrulama ve veri kalıcılığı gibi yeni teknik gereksinimler doğurur.

Bu dönüşüm, blogun bir anda tamamen farklı bir ürüne dönüştüğü anlamına gelmez. Daha doğru ifade, içerik ağırlıklı yapının uygulama özellikleri kazandığıdır. Bir proje içinde bazı sayfalar bilgi sunmaya, bazı ekranlar ise kullanıcı işlemlerini yönetmeye devam edebilir.

Görev takip uygulamasında teknik kapsam neden büyür?

Görev takip uygulamasında her işlem bir kurala bağlanır. Bir görevin hangi kullanıcıya ait olduğu, başka bir kullanıcının bu görevi görüp göremeyeceği, tamamlanan görevlerin nasıl filtreleneceği ve boş bir görev başlığının kabul edilip edilmeyeceği gibi soruların yanıtlanması gerekir.

Bu nedenle uygulamanın arayüzü tek başına yeterli değildir. Tarayıcıdaki form, kullanıcıdan veriyi alır; sunucu bu veriyi doğrular ve gerekli iş mantığını çalıştırır; veri tabanı ise uygun kayıtları saklar. Kullanıcı daha sonra tekrar giriş yaptığında görevlerini aynı durumda görebiliyorsa burada kalıcı veri yönetimi vardır.

İlk proje için pratik karar çerçevesi şu şekilde kurulabilir:

1. Amacınız çoğunlukla yazı, açıklama veya tanıtım içeriği sunmaksa web sitesi yaklaşımıyla başlayın.
2. Kullanıcıların kendi kayıtlarını oluşturması, değiştirmesi veya takip etmesi gerekiyorsa web uygulaması gereksinimlerini değerlendirin.
3. Yorum, üyelik ve kişiselleştirme gibi özellikleri ayrı ayrı inceleyin; her özellik veri modeli, doğrulama ve yetkilendirme ihtiyacını değiştirebilir.
4. İlk sürümde zorunlu olmayan işlevleri ayırın. Önce içerik sunumunu veya temel görev akışını çalışır hâle getirmek, kapsamı kontrol etmeyi kolaylaştırır.

Bu bakış açısıyla “web sitesi mi, web uygulaması mı?” sorusu ikili bir seçim olmaktan çıkar. Blog sayfası içerik sunumuyla başlayabilir; görev takip uygulaması kullanıcı işlemlerini merkeze alabilir. Projenin teknik yönünü asıl belirleyen, kullanıcının sistemle ne yaptığı ve bu işlemlerin arka planda hangi verileri ve kuralları gerektirdiğidir.

Tarayıcı, sunucu, API ve veri tabanı birlikte nasıl çalışır?

Bir web projesini anlamanın en kolay yolu, tarayıcı ile sunucunun görevlerini birbirinden ayırmaktır. Tarayıcı, kullanıcının isteğini başlatan istemci tarafıdır. Web sunucusu bu isteği karşılar, gerekli işlemleri yürütür ve tarayıcıya bir yanıt gönderir. API, istemci ile sunucu veya farklı yazılım sistemleri arasındaki tanımlı iletişim yüzeyini oluştururken veri tabanı, uygulamanın kalıcı verilerini saklayan ve yöneten katmandır.

Bu parçalar her projede aynı şekilde kullanılmaz. Basit bir blog yazısı doğrudan sunucu tarafından hazırlanıp tarayıcıya gönderilebilir. Buna karşılık görev takip uygulamasında kullanıcının hesabına, görevlerine ve görev durumlarına göre özel veriler alınması gerekir. Bu nedenle istemci, sunucu, API ve veri tabanı arasındaki iletişim daha belirgin hâle gelir.

Tarayıcı istemci olarak ne yapar?

Chrome, Firefox, Safari veya başka bir tarayıcı; kullanıcının bilgisayarında ya da telefonunda çalışan istemci yazılımıdır. Kullanıcı bir adres yazdığında, bir bağlantıya tıkladığında veya görev ekleme düğmesine bastığında sunucuya bir istek gönderilmesini sağlar.

Tarayıcıdan sunucuya giden istek yalnızca “bu sayfayı getir” anlamına gelmez. İstek; hangi adrese gidileceğini, hangi HTTP yönteminin kullanılacağını, gerekli başlıkları ve bazı durumlarda kullanıcı tarafından gönderilen verileri içerebilir. Örneğin blog sayfasını açmak için genellikle bir GET isteği yeterliyken, görev takip uygulamasında yeni görev oluşturmak için kullanıcının yazdığı başlığın sunucuya gönderilmesi gerekir.

• Blog örneğinde: Tarayıcı belirli bir yazının HTML içeriğini, görsellerini ve stil dosyalarını ister.
• Görev takip örneğinde: Tarayıcı, oturum açmış kullanıcıya ait görevleri ister veya yeni bir görevi sunucuya gönderir.
• İstemci tarafında: Gelen yanıt ekranda gösterilir, düğmelerin davranışı yönetilir ve kullanıcı etkileşimleri işlenir.

Web sunucusunun görevi nedir?

Web sunucusu, istemcilerden gelen istekleri karşılayan katmandır. İsteğin hangi adrese yöneldiğini inceler, gereken sunucu taraflı kodu çalıştırır ve uygun yanıtı hazırlar. Bu yanıt bazen hazır bir HTML dosyası, bazen JSON biçiminde veri, bazen de bir hata mesajı olabilir.

Blog sayfasında sunucu, yazının başlığını, metnini ve yayın bilgilerini bir dosyadan veya içerik sisteminden alıp HTML olarak oluşturabilir. Kullanıcı görev takip uygulamasında “Görevlerimi getir” işlemini yaptığında ise sunucu, kullanıcının kimliğini kontrol eder, ilgili görevleri bulur ve sonucu tarayıcıya iletir.

Web sunucusu ile sunucu taraflı uygulama aynı kavram değildir. Web sunucusu istekleri kabul edip yönlendiren temel katmandır; uygulama kodu ise kullanıcı doğrulama, iş kuralları, veri kontrolü ve yanıt hazırlama gibi işlemleri gerçekleştirir. Küçük projelerde bu görevler tek bir yapı içinde birleşebilir, daha büyük sistemlerde farklı katmanlara ayrılabilir.

API hangi noktada devreye girer?

API, iki yazılım parçasının hangi kurallarla iletişim kuracağını belirleyen tanımlı yüzeydir. Tarayıcı ile sunucu arasındaki bu iletişimde hangi adresin kullanılacağı, hangi HTTP yönteminin seçileceği, gönderilen verinin biçimi ve dönen yanıtın yapısı API tarafından belirlenebilir.

Görev takip uygulamasında örneğin /api/gorevler benzeri bir uç nokta, kullanıcının görevlerini döndürebilir. Tarayıcı bu adrese istek gönderir; sunucu da görevleri JSON biçiminde yanıtlayabilir. Kullanıcı yeni görev eklediğinde aynı API’nin farklı bir HTTP yöntemiyle kullanılması mümkün olabilir.

Blog sayfasında ise ayrı bir API kullanılması zorunlu değildir. Sunucu, yazı içeriğini alıp HTML sayfasının içine yerleştirerek tek bir yanıt döndürebilir. Bu durumda tarayıcı, veriyi ayrıca JSON olarak almak yerine hazır sayfayı görüntüler. Bir API bulunması, projenin otomatik olarak daha iyi olduğu anlamına gelmez; API ihtiyacı, istemci ile sunucu arasındaki veri alışverişinin yapısına göre belirlenir.

Veri tabanı neden kullanılır?

Veri tabanı, uygulamanın program kapatıldıktan sonra da korunması gereken bilgilerini yönetir. Kullanıcı hesapları, blog yazıları, görevler, görev durumları ve oluşturulma tarihleri buna örnek olabilir.

Görev takip uygulamasında kullanıcı yeni bir görev eklediğinde bilgi yalnızca tarayıcının belleğinde tutulursa sayfa yenilendiğinde veya cihaz kapatıldığında kaybolabilir. Sunucu bu veriyi veri tabanına kaydederse kullanıcı daha sonra tekrar giriş yaptığında görevlerini yeniden görebilir.

Blog yazısında da veri tabanı kullanılabilir; ancak her blog projesinde aynı düzeyde ihtiyaç bulunmaz. Tek yazılı, nadiren değişen bir tanıtım sayfası dosyalardan oluşabilir. Birden fazla yazının, kategorinin, yorumun ve yazar bilgisinin yönetildiği bir blogda ise veri tabanı daha anlamlı hâle gelir.

Bu nedenle her projede ayrı bir veri tabanı veya ayrı bir API bulunması zorunlu değildir. Projenin içerik sıklığı, kullanıcı sayısı, kişiselleştirme ihtiyacı ve verilerin kalıcı tutulup tutulmayacağı bu kararı etkiler. Temel kavramları kendi hızında tekrar ederek istemci-sunucu ilişkisini pekiştirmek isteyenler, kendi temposunda ilerleyebilecekleri online video eğitimler üzerinden çalışma planı oluşturabilir.

İki farklı veri akışı nasıl görünür?

Aynı web altyapısında blog yazısının görüntülenmesi ile görev listesinin kullanıcıya özel getirilmesi farklı veri akışlarına sahiptir.

• Blog yazısının görüntülenmesi: Kullanıcı yazı adresini açar. Tarayıcı sunucudan ilgili sayfayı ister. Sunucu, yazı içeriğini dosyadan veya içerik kaynağından alır, HTML yanıtını hazırlar ve tarayıcıya gönderir. Tarayıcı bu HTML’yi ekranda gösterir.
• Kullanıcıya özel görev listesinin getirilmesi: Kullanıcı uygulamaya giriş yapar. Tarayıcı, kullanıcının oturum bilgisiyle görevleri isteyen bir istek gönderir. Sunucu kullanıcının kimliğini kontrol eder, veri tabanından yalnızca o kullanıcıya ait görevleri okur ve sonucu API yanıtı olarak döndürür. Tarayıcı gelen verileri liste hâlinde ekrana yerleştirir.
• Yeni görev oluşturulması: Kullanıcı görev başlığını yazar ve gönder düğmesine basar. Tarayıcı bu veriyi sunucuya iletir. Sunucu veriyi doğrular, veri tabanına kaydeder ve işlemin sonucunu tarayıcıya bildirir.

Bu akışları zihinde canlandırırken şu sorular yararlı olur: İsteği kim başlatıyor, veriyi kim hazırlıyor, kalıcı kayıt nerede tutuluyor ve yanıt hangi biçimde dönüyor? Bu sorular, ilk web projesinin yalnızca görsel ekranlardan mı oluşacağını yoksa kullanıcıya özel işlemler ve kalıcı veri mi gerektireceğini anlamayı kolaylaştırır.

Bir HTTP isteği tarayıcıdan sunucuya nasıl gidip döner?

HTTP isteği, tarayıcı ile web sunucusu arasındaki temel iletişim adımıdır. Kullanıcı bir sayfayı açtığında veya uygulama içinde bir işlem yaptığında tarayıcı isteği hazırlar; sunucu bu isteği işler ve HTTP yanıtı gönderir. Basit bir akışı altı adımda inceleyebiliriz:

1. Kullanıcı işlemi başlatır: Kullanıcı adres çubuğuna bir web adresi yazar, bir bağlantıya tıklar veya görev ekleme düğmesine basar.
2. Tarayıcı isteği hazırlar: Tarayıcı hedef adresi, HTTP yöntemini, gerekli başlıkları ve gerekiyorsa gönderilecek verileri belirler.
3. İstek sunucuya ulaşır: İstek ağ üzerinden ilgili web sunucusuna gönderilir. Sunucu, isteğin adresini ve yöntemini inceler.
4. Sunucu taraflı mantık çalışır: Sunucu ilgili dosyayı sunabilir, bir uygulama fonksiyonunu çalıştırabilir, kullanıcı doğrulaması yapabilir veya isteğin biçimini kontrol edebilir.
5. Gerekirse veri okunur: İstenen bilgi kalıcı olarak tutuluyorsa sunucu veri tabanından kayıtları okur ya da yeni veriyi kaydeder. Basit bir statik sayfada bu adım hiç gerçekleşmeyebilir.
6. HTTP yanıtı tarayıcıda işlenir: Sunucu durum kodu, başlıklar ve içerikten oluşan bir yanıt döndürür. Tarayıcı HTML’yi görüntüler, JSON verisini uygulamaya aktarır veya kullanıcıya bir hata mesajı gösterir.

Bu döngüde her istek mutlaka veri tabanına gitmez. Bir görsel dosyasının, sabit bir HTML belgesinin veya basit bir metnin sunulması için yalnızca sunucunun ilgili kaynağı bulup göndermesi yeterli olabilir. Veri tabanı ve API kullanımı, isteğin taşıdığı iş ihtiyacına göre devreye girer.

Python ile çalışan mini HTTP sunucusu

Aşağıdaki örnek, Python’un standart kütüphanesindeki http.server modülünü kullanır. Ek paket kurulumu gerektirmez ve tarayıcıdan gelen isteğe kısa bir metinle yanıt verir.

from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        message = "Merhaba, web sunucusu çalışıyor!"
        body = message.encode("utf-8")
        self.send_response(200)
        self.send_header("Content-Type", "text/plain; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

HTTPServer(("localhost", 8000), Handler).serve_forever()

Bu dosyayı örneğin sunucu.py adıyla kaydedin ve terminalde dosyanın bulunduğu klasöre geçerek python sunucu.py komutunu çalıştırın. Program çalışırken tarayıcıda http://localhost:8000 adresini açın. Sayfada “Merhaba, web sunucusu çalışıyor!” metnini görmeniz gerekir.

Terminal penceresinde program çalışmaya devam ettiği sürece sunucu isteklere yanıt verir. Sunucuyu durdurmak için terminalde genellikle Ctrl+C kısayolu kullanılabilir. Buradaki örnek, gerçek bir kullanıcı sistemi veya veri tabanı içermese de HTTP isteğinin sunucuya ulaşmasını, sunucu taraflı kodun çalışmasını ve yanıtın tarayıcıda görüntülenmesini somut biçimde gösterir.

Sunucu taraflı programlama mantığını adım adım uygularken bireysel yönlendirmeye ihtiyaç duyanlar için birebir Python özel ders desteği, istek-yanıt döngüsü, dosya işlemleri ve temel uygulama mantığı gibi konuları seviyeye göre çalışmaya yardımcı olabilir.

Veri tabanı ne zaman gerekir ve özellikler projeyi nasıl değiştirir?

Bir projede veri tabanı kullanılıp kullanılmayacağı, projenin “web sitesi” veya “web uygulaması” olarak adlandırılmasından çok, verinin nasıl kullanılacağına bağlıdır. Yalnızca sabit metin, görsel ve belge sunan bir tanıtım ya da dokümantasyon sayfasında içerik dosyalar içinde tutulabilir. Bu durumda her ziyaretçi büyük ölçüde aynı bilgiyi görür ve veri tabanı otomatik olarak zorunlu değildir.

Örneğin bir ürün tanıtım sayfasında başlıklar, açıklamalar ve görseller HTML dosyalarında, bir içerik dosyasında veya derleme sürecinin ürettiği statik çıktılarda bulunabilir. Kullanıcının hesap oluşturması, içerik eklemesi veya kendisine özel bir sonuç alması gerekmiyorsa daha sade bir yapı yeterli olabilir. Buradaki önemli nokta, veri tabanını teknik bir prestij unsuru gibi değil, gerçek bir gereksinimin çözümü olarak değerlendirmektir.

Kullanıcıya özel veri kalıcı olarak saklanacaksa

Kullanıcı hesabı, görev ekleme, yorum gönderme veya kişisel ayarları saklama gibi özellikler geldiğinde projenin veri ihtiyacı değişir. Kullanıcının yaptığı işlem yalnızca açık olan sayfada görünmekle kalmamalı; sayfa yenilendiğinde, tarayıcı kapatıldığında veya kullanıcı daha sonra tekrar giriş yaptığında da korunmalıdır. Bu gereksinim, kalıcı veri yönetimini ve çoğu durumda sunucu tarafında çalışan kuralları gündeme getirir.

Görev takip uygulamasını düşünelim. Kullanıcı “Algoritma tekrarını tamamla” adında bir görev eklediğinde uygulama bu görevi önce tarayıcıdaki forma alır. Ardından sunucuya bir istek gönderir. Sunucu, isteğin geçerli bir kullanıcıdan gelip gelmediğini kontrol eder ve görevi veri tabanına kaydeder. Kullanıcı sayfayı yenilediğinde uygulama görev listesini yeniden sunucudan ister. Kullanıcı hesabına tekrar giriş yaptığında da aynı kayıt, hesabıyla ilişkilendirilmiş biçimde getirilebilir.

Bu akışın temelinde üç ayrı ihtiyaç vardır:

• Verinin geçici ekran durumundan ayrılıp kalıcı olarak saklanması.
• Her kaydın doğru kullanıcıyla veya doğru kaynakla ilişkilendirilmesi.
• Verinin okunması, değiştirilmesi ve silinmesi sırasında kuralların uygulanması.

Yalnızca JavaScript ile bir görevi ekranda listelemek, uygulamanın o görevi kalıcı olarak sakladığı anlamına gelmez. Veri yalnızca bellekte tutuluyorsa sayfa yenilendiğinde kaybolabilir. Tarayıcı depolama seçenekleri bazı küçük senaryolarda yardımcı olsa da birden fazla kullanıcı, yetkilendirme, ortak veri kullanımı veya sunucu taraflı doğrulama gerektiğinde tek başına yeterli olmayabilir.

Sunucu taraflı iş kuralları neden önemlidir?

Bir web uygulamasındaki kuralların tamamını tarayıcıya bırakmak güvenilir değildir. Tarayıcıda çalışan kod kullanıcıya gönderildiği için kullanıcı tarafından incelenebilir ve değiştirilebilir. Bu nedenle “Bir kullanıcı yalnızca kendi görevini silebilir”, “Yorum gönderebilmek için oturum açılmış olmalı” veya “Bir görev boş başlıkla kaydedilemez” gibi kurallar sunucu tarafında da kontrol edilmelidir.

Veri tabanı bu kayıtların saklandığı katmandır; sunucu ise bu kayıtlara hangi koşullarda erişilebileceğini belirleyen katmandır. Uygulama büyüdükçe kullanıcı yetkileri, veri doğrulama, hata yönetimi, kayıtların güncellenmesi ve ilişkili verilerin korunması gibi konular daha görünür hâle gelir. Örneğin bir görev tamamlandı olarak işaretlendiğinde yalnızca ekrandaki renk değişmemeli, bu durum kalıcı kayda da doğru biçimde yazılmalıdır.

Yorum sistemi de benzer bir dönüşüm yaratır. Sabit bir blog sayfasında yazının içeriği dosyadan okunup gösterilebilir. Ancak ziyaretçilerin yorum gönderebilmesi için yorum metninin alınması, uygunluk kontrollerinden geçirilmesi, ilgili yazıyla ilişkilendirilmesi ve daha sonra tekrar listelenmesi gerekir. Bu noktada uygulama; form, sunucu, veri saklama ve güvenlik katmanlarını birlikte işletir.

Filtreleme her zaman veri tabanı gerektirir mi?

Hayır. Filtreleme ihtiyacı tek başına veri tabanı kullanmayı zorunlu kılmaz. Küçük ve önceden yüklenmiş bir veri kümesi tarayıcıya gönderilip istemci tarafında filtrelenebilir. Örneğin birkaç düzine doküman başlığından oluşan bir liste, sayfa açılırken yüklenebilir ve kullanıcı arama kutusuna yazdıkça tarayıcıdaki JavaScript ile süzülebilir.

Bu yaklaşımda tüm veri zaten kullanıcının tarayıcısına geldiği için filtreleme hızlı ve basit olabilir. Ancak veri kümesi büyüdüğünde veya sonuçların kullanıcıya göre değişmesi gerektiğinde aynı yöntem verimsizleşebilir. Binlerce kaydı her kullanıcıya göndermek yerine sunucuya yalnızca arama ölçütlerini iletmek ve uygun sonuçları döndürmek daha mantıklı olabilir.

Bu nedenle karar verirken şu sorular sorulmalıdır:

• Filtrelenecek veri küçük ve önceden bilinen bir liste mi?
• Sonuçlar her kullanıcı için aynı mı, yoksa hesaba göre değişiyor mu?
• Veri zaman içinde ekleniyor veya güncelleniyor mu?
• Kullanıcıların bu veriyi oluşturma, düzenleme ya da silme yetkisi var mı?
• Filtreleme işlemi yetki veya gizlilik kuralları içeriyor mu?

İlk soruların çoğuna “küçük, sabit ve herkese açık” yanıtı veriliyorsa istemci taraflı çözüm yeterli olabilir. Kullanıcıya özel, sürekli değişen veya erişim kontrolü gerektiren veriler söz konusuysa sunucu ve veri tabanı ihtimali güçlenir. Yani özellik sayısı arttıkça değil, verinin yaşam döngüsü karmaşıklaştıkça mimari de değişir.

İlk proje için web sitesi mi, web uygulaması mı seçilmeli?

İlk proje seçiminde doğru soru “Hangi framework daha iyi?” değil, “Bu proje hangi problemi çözmeli?” sorusudur. Proje yalnızca içerik sunacaksa sade bir web sitesiyle başlamak; kullanıcıların veri oluşturduğu, işlem yaptığı ve kişisel sonuçlar aldığı bir yapı hedefleniyorsa web uygulaması mimarisini değerlendirmek daha uygundur. Belirsizlik varsa en küçük çalışan kapsam kurulmalı, ihtiyaç doğrulandıkça yeni özellikler eklenmelidir.

Seçim yaparken içeriklerin ne sıklıkta değişeceği, kullanıcı hesabına ihtiyaç olup olmadığı, verinin oturumlar arasında korunup korunmayacağı, sunucu taraflı iş kurallarının gerekip gerekmediği, güvenlik ve bakım yükü birlikte düşünülmelidir. Ayrıca projenin öğrenme hedefi de önemlidir. Amaç HTML, CSS ve temel istemci-sunucu ilişkisini anlamaksa sabit veya sınırlı kapsamlı bir site iyi bir başlangıç olabilir. Amaç form işleme, veri saklama ve yetkilendirme mantığını öğrenmekse küçük bir web uygulaması daha öğretici olacaktır.

Mevcut seviyesini netleştirmek isteyen bir öğrenci, proje kapsamını seçmeden önce ücretsiz yazılım bilgisi testi ile temel konulardaki durumunu görebilir. Böylece eksik olan konuları belirleyip proje hedefini gereğinden büyük tutmadan planlayabilir.

Hangi durumda hangisini seçmeli?

1. Proje yalnızca içerik sunuyorsa web sitesiyle başlayın. Tanıtım metni, blog yazısı, dokümantasyon, etkinlik bilgisi veya kişisel portföy gibi içeriklerde kullanıcıdan veri alınmıyorsa sade bir yapı daha kolay geliştirilebilir ve bakımı daha az zahmetli olur.
2. Kullanıcıya özel veri veya işlem varsa web uygulamasını değerlendirin. Görev ekleme, yorum yazma, profil düzenleme, sipariş takibi veya kişisel ilerleme görüntüleme gibi işlemler verinin kullanıcıyla ilişkilendirilmesini gerektirebilir.
3. İçerik değişim sıklığını dikkate alın. Nadiren değişen birkaç sayfa için dosya tabanlı içerik yeterli olabilir. Sık güncellenen, kategorilendirilen, aranabilen veya birden fazla kişi tarafından yönetilen içerikler için sunucu taraflı bir yönetim yaklaşımı daha uygun olabilir.
4. Sunucu taraflı iş kurallarını erken fark edin. Yetki kontrolü, veri doğrulama, oturum yönetimi veya kullanıcıların yalnızca kendi kayıtlarına erişmesi gibi kurallar varsa proje, basit bir sayfa gösteriminden uygulama mantığına doğru ilerler.
5. Güvenlik ve bakım yükünü kapsamla birlikte değerlendirin. Kullanıcı bilgileri, yorumlar veya kişisel kayıtlar tutulacaksa doğrulama, erişim kontrolü, hata yönetimi ve güvenli veri işleme planlanmalıdır. Gereksiz özellikleri baştan eklemek yerine gerçekten ihtiyaç duyulan akışlar kurulmalıdır.
6. Belirsiz durumda en küçük çalışan kapsamı oluşturun. Önce tek bir blog yazısını gösteren site veya tek kullanıcının görev ekleyip silebildiği küçük bir prototip hazırlayın. Temel akış çalıştıktan sonra hesaplar, filtreleme, kategoriler ve kişiselleştirme gibi özellikleri aşamalı biçimde ekleyin.

Bu karar listesindeki ayrım kesin ve değişmez değildir. Bir blog, başlangıçta yalnızca yazı gösteren bir site olabilir; daha sonra yorumlar, üyelik, yazar paneli, taslak yönetimi ve kişiselleştirilmiş öneriler eklendiğinde uygulama özellikleri kazanabilir. Aynı şekilde bir görev takip uygulaması da ilk sürümünde tek bir liste ve basit bir formdan oluşabilir.

Bu nedenle ilk projede bütün olası özellikleri aynı anda geliştirmek yerine bir kullanıcı akışını baştan sona tamamlamak daha sağlıklıdır. Görev takip örneğinde bu akış “görevi ekle, kaydet, listele ve tamamlandı olarak işaretle” olabilir. Blog örneğinde ise “yazı listesini aç, bir yazıyı seç ve içeriği görüntüle” akışı yeterli bir başlangıç oluşturabilir.

Framework veya programlama dili seçimi de bu temel karardan sonra gelir. Kullanıcı hesabı, kalıcı veri, API, test, dağıtım ve bakım ihtiyaçları netleşmeden yapılan teknoloji seçimi çoğu zaman gereksiz karmaşıklık oluşturur. Öğrenme hedefiyle proje gereksinimleri aynı yönde ilerliyorsa kullanılan araçtan bağımsız olarak daha anlaşılır ve sürdürülebilir bir sonuç elde edilir.

Sık Sorulan Sorular

Her dinamik web sitesi aynı zamanda web uygulaması mıdır?

Hayır. Dinamik içerik, sayfanın veriyi bir kaynaktan alarak değişken biçimde üretildiğini anlatır; bu kaynak bir dosya, içerik sistemi veya veri tabanı olabilir. Kullanıcıların işlem yaptığı, kişisel veri oluşturduğu ve sunucu taraflı kuralların işletildiği yapılar web uygulamasına daha çok yaklaşır. Ancak bu iki kavram arasında kesin ve değişmez bir sınır yoktur.

Bir web uygulaması geliştirmek için veri tabanı zorunlu mudur?

Hayır. Küçük bir uygulama veriyi geçici olarak bellekte tutabilir veya sınırlı bir tarayıcı depolama yöntemi kullanabilir. Fakat kullanıcı verisinin oturumlar arasında korunması, birden fazla kullanıcının aynı sistemi kullanması, yetkilendirme ve kalıcı kayıt ihtiyacı varsa veri tabanı kullanmak genellikle gerekli hâle gelir.

Kullanıcı girişi eklemek bir projeyi otomatik olarak web uygulaması yapar mı?

Tek başına kullanıcı girişi kesin bir sınıflandırma ölçütü değildir. Kullanıcı girişi yalnızca erişim kısıtlamak için kullanılabilir. Buna karşılık hesapla ilişkili görevler, yorumlar, ayarlar veya kişiselleştirilmiş içerikler tutuluyorsa proje uygulama özellikleri kazanır. Belirleyici olan giriş ekranının bulunması değil, giriş yapan kullanıcının sistem içinde hangi işlemleri gerçekleştirdiğidir.

İlk web projesinde blog mu yoksa görev takip uygulaması mı daha uygun olur?

Bu seçim öğrenme hedefinize bağlıdır. Sayfa yapısı, içerik sunumu ve temel tarayıcı işlemlerini öğrenmek istiyorsanız blog daha sade bir başlangıç olabilir. Form işleme, veri kalıcılığı, listeleme ve durum değiştirme mantığını öğrenmek istiyorsanız küçük bir görev takip uygulaması daha kapsamlı pratik sağlar. Her iki projede de ilk sürümü sınırlı tutmak önemlidir.

Web uygulaması geliştirmek için mutlaka bir framework kullanmak gerekir mi?

Hayır. Bir web uygulamasının temelini anlamak için tarayıcı, sunucu, HTTP istekleri, veri işleme ve veri saklama mantığını framework olmadan da öğrenebilirsiniz. Frameworkler tekrar eden işleri kolaylaştırabilir; ancak hangi araca geçileceğine proje gereksinimleri, ekibin bilgisi, bakım ihtiyacı ve öğrenme hedefi birlikte değerlendirilerek karar verilmelidir.

İlk projenizde seçimi teknoloji adından önce veri, kullanıcı ve işlem ihtiyaçlarına göre yaparsanız hem daha küçük bir kapsamla başlayabilir hem de projenin neden web sitesi ya da web uygulaması yönünde ilerlediğini daha net anlayabilirsiniz.