Web Framework Nedir, Teknoloji Seçimi Neden Bu Kadar Belirleyici?
Framework, bir web uygulaması yazarken tekrar tekrar çözülmesi gereken problemlerin hazır ve denenmiş çözümlerini sunan iskelet yapıdır. Adreslerin hangi koda yönleneceği, isteklerin nasıl işleneceği, veritabanıyla nasıl konuşulacağı, kullanıcı oturumlarının nasıl yönetileceği, formların nasıl doğrulanacağı, arka plan görevlerinin nasıl kuyruklanacağı; bunların hepsi framework'ün getirdiği hazır cevaplardır. Bir framework kullanmak, tekerleği yeniden icat etmemek değil; binlerce projede test edilmiş bir tekerlekle yola çıkmaktır.
Teknoloji seçiminin bu kadar belirleyici olmasının sebebi, kararın tek seferlik olmamasıdır. Framework seçimi; ekibinizi kimlerden kuracağınızı, projeyi ne hızda geliştirebileceğinizi, hangi entegrasyonların kolay hangilerinin zahmetli olacağını, sitenizin arama motorlarında nasıl davranacağını ve beş yıl sonra sistemi kimin sürdürebileceğini aynı anda etkiler. Yanlış seçim genellikle ilk ay kendini belli etmez; yanlış seçimin faturası, projenin ortasında "bunu bu framework'le yapamayız" cümlesiyle kesilir.
Sahada en sık gördüğümüz üç hatalı seçim gerekçesi şudur: teknolojinin o dönem popüler olması, ekibin yalnızca tek bir aleti biliyor olması ve karar veren kişinin son okuduğu makaleden etkilenmesi. Popülerlik bir bilgi taşır ama tek başına kriter olamaz; çünkü sizin projenizin gereksinimleri, o teknolojinin ünlü olduğu kullanım senaryosuyla aynı olmayabilir. İçerik ağırlıklı bir kurumsal siteyi tek sayfalık bir uygulama olarak kurmak da, karmaşık ve etkileşimli bir paneli klasik sayfa yenilemeleriyle yazmak da; aynı hatanın iki farklı yönüdür.
Marmaragen olarak 2015'ten beri İstanbul Maltepe'den hizmet veriyoruz ve 150'yi aşkın projede birbirinden çok farklı teknoloji yığınlarıyla çalıştık. Bu çeşitlilik bize belirli bir framework'ü savunma zorunluluğundan kurtaran bir tarafsızlık kazandırdı: elimizde tek bir çekiç olmadığı için her problemi çivi görmek zorunda değiliz. Bu sayfada seçim kriterlerimizi, kullandığımız framework'leri, full-stack kurgularımızı ve mimari ilkelerimizi açık biçimde paylaşıyoruz.
Marmaragen Framework Yaklaşımı
Seçim danışmanlığı: performans, ölçeklenebilirlik ve topluluk desteği
Framework kararını üç ana eksende değerlendiriyoruz. Birincisi performans: projenin yük karakteri nedir? Ağırlıklı olarak okunan içerik mi sunulacak, yoksa yoğun yazma işlemi ve gerçek zamanlı etkileşim mi var? İlk yükleme süresinin kritik olduğu, arama motorlarının içeriği görmesi gereken bir proje ile kullanıcının uzun süre içinde kaldığı bir panel farklı çözümler ister.
İkincisi ölçeklenebilirlik: proje büyüdüğünde ne olacak? Yatay ölçekleme kolay mı, arka plan görevleri ve kuyruklar için olgun bir altyapı var mı, kod tabanı büyüdükçe düzenli kalabiliyor mu? Bir framework'ün küçük projede hızlı olması, büyük projede de rahat olacağı anlamına gelmez.
Üçüncüsü topluluk desteği ve süreklilik: framework aktif olarak geliştiriliyor mu, güvenlik yamaları düzenli mi, sürüm yükseltme yolu öngörülebilir mi, karşılaştığınız bir sorunun cevabı zaten yazılmış mı ve Türkiye'de bu teknolojiyi bilen geliştirici bulmak kolay mı? Son madde çoğu zaman en çok göz ardı edilen ama en pahalıya patlayanıdır: bakımını yapacak kimseyi bulamadığınız bir teknoloji, ne kadar zarif olursa olsun sizin için doğru seçim değildir. Bu üç ekseni projenizin somut gereksinimleriyle çarpar, kararın gerekçesini yazılı olarak sunarız.
Full-stack kurgular: tek ekip, uçtan uca sorumluluk
Arayüz ve sunucu tarafını ayrı firmalara böldüren projelerde en çok kaybedilen şey sorumluluktur; bir hata çıktığında herkes diğerini işaret eder. Biz full-stack çalışıyoruz: aynı ekip veri modelini de kuruyor, servis katmanını da yazıyor, arayüzü de geliştiriyor. Bu, teknoloji kararlarının bütünsel alınmasını sağlar — sunucu tarafında verilen bir karar arayüzü zorlamıyor, arayüzün ihtiyacı sunucu tarafında geç fark edilmiyor.
Sürdürülebilirlik: kod bugün değil, iki yıl sonra ucuz olmalı
Bir projenin gerçek maliyeti ilk teslimde değil, sonraki iki yılda ortaya çıkar. Bu yüzden hızlı yazılan değil, kolay değiştirilebilen kodu hedefliyoruz. Klasörleme ve isimlendirme standartları, tutarlı katmanlar, otomatik testler, statik analiz ve kod incelemesi; süslü değil, tasarrufludur. Yeni bir geliştiricinin projeye dahil olup birkaç gün içinde katkı verebilmesi, bizim için ölçülebilir bir kalite göstergesidir.
Framework Seçimi ve Geliştirme Sürecimiz: Adım Adım
Teknoloji kararını bir toplantıda sezgiyle değil, ölçülebilir kriterlerle veriyoruz. Süreç, kararın gerekçesini belgeleyecek ve ilerleyen aylarda "neden bunu seçmiştik?" sorusunu cevaplayabilecek şekilde işler:
- Gereksinim ve kısıt analizi — Projenin işlevsel ihtiyaçları, beklenen trafik, SEO ve içerik gereksinimi, entegre olunacak sistemler, güvenlik ve mevzuat kısıtları, bütçe ve teslim takvimi çıkarılır. Ekibinizin mevcut yetkinlikleri ve devir planınız da bu aşamanın parçasıdır.
- Aday teknolojilerin karşılaştırılması — İki üç aday framework, projenin somut kriterleri üzerinden puanlanır. Performans profili, ölçekleme yolu, ekosistem olgunluğu, güvenlik geçmişi ve uzun vadeli bakım maliyeti kıyaslanır; karar tablosu ve gerekçesi yazılı olarak paylaşılır.
- Mimari kurgu ve iskelet — Seçilen framework üzerinde katman yapısı, modül sınırları, veri erişim stratejisi, hata yönetimi ve yapılandırma düzeni kurulur. Kod standartları, klasörleme ve test yaklaşımı belirlenir; proje iskeleti ilk günden doğru oturur.
- Sprint temelli geliştirme — Modüller öncelik sırasına göre geliştirilir; her sprint sonunda çalışan ve gösterilebilir bir sürüm çıkar. Kod incelemesi, otomatik testler ve statik analiz her adımda çalışır; teknik borç birikmeden temizlenir.
- Yayın, ölçüm ve sürüm bakımı — Uygulama otomatik hat üzerinden yayına alınır, performans ve hata metrikleri izlenir. Framework ve bağımlılık sürümleri düzenli aralıklarla güncellenir; güvenlik yamaları birikmeye bırakılmaz.
Bir noktayı özellikle vurgulayalım: bu süreçte hiçbir framework'ün savunuculuğunu yapmıyoruz. Bir teknolojiyi önerdiğimizde bunun gerekçesini rakamlarla ve somut kısıtlarla açıklıyor, uygun olmadığı durumları da aynı açıklıkla söylüyoruz. Kimi zaman en doğru cevap, ekibinizin zaten bildiği ve yıllardır sorunsuz kullandığı teknolojide kalmaktır; yeni bir yığına geçmenin öğrenme maliyeti, elde edilecek teknik kazancı aşabilir. Karar tablosunu birlikte okuyup birlikte karar veriyoruz.
Çalıştığımız Framework'ler
Aşağıdaki beş framework'ün her birini üretim ortamında kullandık. Hangisinin hangi senaryoda öne çıktığını deneyimle biliyoruz.
Laravel (PHP)
İş uygulamalarında ihtiyaç duyulan hemen her şeyi olgun biçimde sunar: ORM katmanı, kuyruk yönetimi, zamanlanmış görevler, olay sistemi, yetkilendirme ve bildirim altyapısı. Kurumsal portallar, üyelik ve abonelik sistemleri, sipariş ve stok yönetimi gibi projelerde hızlı ve öngörülebilir bir geliştirme sağlar. Türkiye'de geliştirici havuzunun geniş olması, projenin uzun vadeli bakımı ve devri açısından da somut bir avantajdır.
Django (Python)
"Bataryalar dahil" felsefesiyle gelir; yönetim paneli, kimlik doğrulama ve veri katmanı kutudan çıkar. Veri yoğun iç sistemlerde, raporlama ve içerik yönetimi ağırlıklı projelerde geliştirme süresini belirgin şekilde kısaltır. Python ekosistemiyle aynı çatı altında olması; veri işleme, analitik veya otomatik hesaplama bileşeni içeren projelerde ek bir güç sağlar. Güvenlik varsayılanlarının sıkı olması da kurumsal projelerde tercih sebebimizdir.
Express.js (Node.js)
Minimal ve esnek yapısıyla, ne yaptığını bilen ekiplerin elinde çok verimlidir. Servis katmanları, API sunucuları ve gerçek zamanlı bileşenler için tercih ediyoruz. Hazır yapı dayatmaması, mimariyi projeye göre kurmayı mümkün kılar; ancak aynı özgürlük, disiplin uygulanmazsa dağınıklığa da yol açabilir. Bu yüzden Express projelerinde katman ve klasör standartlarını en baştan yazılı hale getiririz; daha büyük ve kurumsal servislerde NestJS gibi yapılandırılmış bir çerçeveye geçmeyi öneririz.
Next.js (React)
Arama motorlarının okuyabildiği hızlı bir ilk yükleme ile uygulama akıcılığını aynı anda isteyen projelerin cevabıdır. Sayfaları sunucuda üretme (SSR) ve statik olarak önceden oluşturma yeteneği sayesinde içerik siteleri, e-ticaret vitrinleri ve pazarlama sayfaları hem hızlı açılır hem de teknik SEO açısından sağlam olur. Görsel optimizasyonu, kod bölme ve yönlendirme gibi konuları hazır sunması, performans işini baştan kolaylaştırır.
Nuxt.js (Vue)
Next.js'in Vue dünyasındaki karşılığıdır ve benzer avantajları Vue ekosistemine getirir. Ekibiniz Vue biliyorsa ya da mevcut arayüzleriniz Vue ile yazılmışsa, sunucu tarafı üretim ve SEO kazanımlarını sıfırdan öğrenme maliyeti olmadan elde etmenizi sağlar. Sade yapısı ve okunabilir söz dizimi, ekip devri gereken projelerde ayrıca avantajlıdır. Arayüz katmanı hakkında ayrıntılar için frontend geliştirme sayfamıza göz atabilirsiniz.
Full-Stack Kurgular ve Hangi Projede Hangisi
Framework'ler tek başına değil, bir bütün olarak çalışır. Sıklıkla kurduğumuz üç kurguyu ve hangi senaryoya uyduklarını paylaşalım.
Next.js ile SSR odaklı kurgu: İçeriğin arama motorlarında görünmesi kritik, aynı zamanda kullanıcının etkileşimli bir deneyim beklediği projelerde tercih ediyoruz. Kurumsal siteler, ürün vitrinleri, kampanya sayfaları ve içerik ağırlıklı platformlar bu kurguda hem hızlı açılır hem de akıcı gezinme sunar. Veri katmanı ayrı bir servis olarak kurulduğunda, aynı veri mobil uygulamayı da besleyebilir.
Laravel + Vue ile MVC kurgusu: İş kurallarının ağır bastığı, kullanıcı rollerinin çeşitli olduğu ve yönetim tarafının geniş olduğu projelerde çok verimlidir. Sunucu tarafı sayfaların sağlamlığını korurken, gerektiği yerde Vue bileşenleriyle zengin etkileşim eklenir. Sipariş yönetimi, bayi portalı, rezervasyon sistemi ve üyelik platformları için sık kurduğumuz bir yapıdır.
Django + React ile API-first kurgu: Aynı iş mantığının web, mobil ve dış paydaş sistemleri tarafından tüketileceği projelerde arayüz ile servisi net biçimde ayırırız. Django tarafı veri modelini, kuralları ve servis uçlarını taşır; React tarafı bunları tüketen arayüzü kurar. Bu ayrım, ekiplerin paralel çalışmasını ve ileride yeni bir istemci eklemenin kolay olmasını sağlar. Servis katmanının tasarımını API geliştirme sayfamızda ayrıntılı anlatıyoruz; sunucu tarafı mimarisi için backend geliştirme sayfamıza bakabilirsiniz.
Bu üç kurgunun hiçbiri diğerinden mutlak olarak üstün değildir; her biri belirli bir dengeyi tercih eder. SSR odaklı kurgu görünürlük ve ilk yükleme hızını önceler, MVC kurgusu geliştirme hızını ve sadeliği önceler, API-first kurgu ise esnekliği ve çoklu istemci desteğini önceler. Sizin için doğru olanı belirlerken sorduğumuz sorular basittir: bu ürünü kim, hangi cihazdan kullanacak; içeriğin aramada bulunması ne kadar kritik; önümüzdeki iki yılda yeni bir istemci eklenecek mi; sistemi kim sürdürecek? Cevaplar netleştiğinde tercih de kendiliğinden netleşir.
Clean Architecture, SOLID ve Modüler Yapı
Framework seçimi doğru olsa bile, iyi bir mimari olmadan proje zamanla yönetilemez hale gelir. Framework size bir iskelet verir; o iskeletin içine iş mantığınızı nasıl yerleştirdiğiniz sizin sorumluluğunuzdur.
Clean architecture yaklaşımının bizim için pratik anlamı şudur: işinizin kuralları, kullandığınız framework'ten ve veritabanından mümkün olduğunca bağımsız yaşamalıdır. Bir siparişin hangi koşullarda iptal edilebileceği bilgisi; bir denetleyicinin içinde, bir şablonun ortasında ya da bir veritabanı tetikleyicisinde dağınık durmamalı, tek ve belirgin bir yerde bulunmalıdır. Bu ayrım sayesinde kuralı test etmek kolaylaşır, aynı kural farklı arayüzlerden aynı şekilde çalışır ve ileride teknoloji değişse bile işinizin bilgisi yerinde kalır.
SOLID ilkelerini akademik bir süs olarak değil, günlük kararlar için pusula olarak kullanıyoruz. Her sınıfın tek bir sorumluluğu olması, yeni bir davranışın mevcut kodu değiştirmeden eklenebilmesi, bağımlılıkların somut sınıflara değil arayüzlere verilmesi; bunların hepsi tek bir sonuca hizmet eder — değişikliğin maliyetini düşürmek. Bir e-posta sağlayıcısını değiştirmek tek bir dosyaya dokunmayı gerektiriyorsa mimari işini yapıyordur; on beş dosyayı gerektiriyorsa yapmıyordur.
Modüler yapı tarafında ise projeyi teknik katmanlara değil iş alanlarına göre bölmeyi tercih ediyoruz. "Siparişler", "üyelik", "raporlama" gibi modüller kendi içlerinde bütün, dışarıya karşı net arayüzlü olur. Bu, ekip büyüdüğünde farklı kişilerin birbirinin ayağına basmadan çalışabilmesini sağlar; ileride bir modülü ayrı bir servise taşımak gerekirse de sınırlar zaten çizilmiş olur. Bu disiplinin karşılığını, projeye altı ay sonra dönüp yeni bir özellik eklediğimizde net biçimde alıyoruz.
Ekosistem: Paket Yönetimi, Test Altyapısı ve Sürüm Bakımı
Bir framework'ü seçerken aslında onun ekosistemini de seçersiniz. Hazır paketler, kütüphaneler, geliştirme araçları ve topluluk çözümleri; günlük iş hızınızı framework'ün kendisi kadar etkiler. Ancak bu zenginlik iki ucu keskin bir bıçaktır. Her hazır paket, projenize dışarıdan giren bir bağımlılıktır: bakımı bırakılabilir, güvenlik açığı barındırabilir, sürüm yükseltmede sizi kilitleyebilir. Bu yüzden paket seçimini de bir karar olarak ele alıyoruz — bakım geçmişi, açık sorun sayısı, son güncelleme tarihi ve gerçekten ihtiyaç duyulup duyulmadığı değerlendirilmeden hiçbir bağımlılık projeye girmiyor. Birkaç satırla yazılabilecek bir işlev için koca bir kütüphane eklemek, kısa vadede zaman kazandırır, uzun vadede yük olur.
Test altyapısı da framework seçiminin sık atlanan bir boyutudur. Birim testleri, servis uçlarının uçtan uca doğrulanması ve veritabanı içeren senaryoların tekrarlanabilir biçimde çalıştırılması; framework'ün hazır sunduğu araçlarla kolaylaşır ya da zorlaşır. Testleri projenin sonuna bırakılan bir külfet değil, geliştirmenin güvenlik ağı olarak kuruyoruz. Kritik iş kurallarını ve para akışını ilgilendiren işlemleri mutlaka test altına alıyoruz; çünkü altı ay sonra yapılan bir düzeltmenin başka bir kuralı sessizce bozmadığından ancak böyle emin olunabiliyor.
Sürüm bakımı ise projenin ömrünü belirler. Framework ve bağımlılık güncellemelerini yılda bir kez toplu olarak yapmak, her seferinde büyük bir kriz üretir; oysa düzenli aralıklarla küçük adımlarla ilerlemek riski dağıtır. Bakım anlaşmalarımızda güvenlik yamalarını takip eder, kullanımdan kaldırılacağı ilan edilen yapıları önceden değiştirir ve büyük sürüm geçişlerini planlı biçimde uygularız. Böylece "güncelleyemiyoruz, çünkü her şey kırılır" noktasına hiç gelinmez. Barındırma ve dağıtım tarafındaki gereksinimleri de bu planın parçası olarak web hosting hizmetimizle birlikte yönetiyoruz.
Framework Geçişleri ve Eski Projelerin Modernizasyonu
Bize gelen taleplerin önemli bir kısmı "projemizi şu teknolojiye taşıyalım" cümlesiyle başlar. İlk yaptığımız şey bu cümleyi sorgulamaktır; çünkü şikâyet edilen sorunların çoğu framework'ten değil, mimariden ve kod kalitesinden kaynaklanır. Yavaş açılan bir site, güncellenmemiş bir framework yüzünden değil, indekssiz sorgular ve optimize edilmemiş görseller yüzünden yavaş olabilir. Böyle bir durumda teknoloji değiştirmek, sorunu yeni bir dile tercüme etmekten öteye gitmez.
Denetim sonucunda geçişin gerçekten gerekli olduğuna karar verirsek — örneğin kullanılan sürüm artık güvenlik güncellemesi almıyorsa, ekosistem terk edilmişse ya da ihtiyaç duyulan yetenekler mevcut yapıda karşılanamıyorsa — geçişi büyük patlama şeklinde değil, kademeli olarak planlarız. Yeni yapı eski sistemin yanında kurulur, modüller birer birer taşınır ve her taşınan parça yayına alınır. Böylece işletme çalışmaya devam eder, risk küçük parçalara bölünür ve "yeni sistem bitene kadar hiçbir şey gelişmiyor" tuzağına düşülmez. Geçiş boyunca içerik, adres yapısı ve arama motoru sıralamalarının korunması için yönlendirme planı da baştan hazırlanır; teknoloji yenilenirken görünürlük kaybetmek kabul edilebilir bir bedel değildir. Yenilenen arayüz ve kurumsal görünüm ihtiyaçları için web tasarım, uygulama tarafındaki geliştirmeler için web yazılım hizmetlerimizle bütünleşik ilerliyoruz.
Framework Projelerinde Fiyatı Belirleyen Faktörler
Framework tabanlı projelerde maliyet, seçilen teknolojinin adından çok projenin kapsamına ve mimari beklentilere bağlıdır. Teklifimizi şekillendiren ana kalemler şunlardır:
- Modül sayısı ve iş kurallarının karmaşıklığı — Kaç iş alanı olduğu, onay akışlarının derinliği ve rol çeşitliliği doğrudan geliştirme süresine yansır.
- Sunucu tarafı üretim ihtiyacı — SSR veya statik üretim gerektiren projelerde altyapı kurulumu, önbellekleme ve yeniden üretim stratejisi ek mühendislik demektir.
- Arayüz karmaşıklığı — Özel tasarlanmış bileşenler, etkileşimli tablolar, grafikler ve çok adımlı formlar; hazır şablonlara göre daha fazla efor gerektirir.
- Entegrasyon sayısı — Ödeme, kargo, ERP, muhasebe ve harita gibi her dış sistem kendi test ve hata senaryolarıyla ayrı bir kalemdir.
- Mimari olgunluk beklentisi — Test kapsamı, modüler ayrıştırma derinliği ve dokümantasyon seviyesi; ilk maliyeti artırır, uzun vadeli bakım maliyetini düşürür.
- Mevcut sistemin durumu — Geçiş ve modernizasyon projelerinde eski kodun kalitesi, veri taşıma karmaşıklığı ve dokümantasyonun varlığı belirleyicidir.
- Ekip devri ve eğitim — Projeyi kendi ekibinizin sürdürmesini istiyorsanız, teknik dokümantasyon ve eğitim ayrı bir hizmet kalemi olarak planlanır.
Analiz sonrasında kalem kalem yazılmış, kapsamı net bir teklif alırsınız; teknoloji kararının gerekçesi de bu teklife eklenir. Planlarımızı inceleyebilir veya doğrudan arayarak projenize özel teklif isteyebilirsiniz.
Neden Marmaragen?
- 8+ yıl deneyim, 150+ proje: 2015'ten beri İstanbul Maltepe'den Türkiye geneline hizmet veriyoruz; 250'den fazla müşteriyle çalıştık.
- Teknoloji tarafsızlığı: Beş ayrı framework'te üretim tecrübemiz var; önerimiz bildiğimiz tek alete göre değil, projenizin gereksinimlerine göre şekilleniyor.
- Gerekçeli karar: Seçimin nedenini karar tablosuyla birlikte yazılı olarak veriyoruz; "böyle daha iyi" demiyoruz, hangi kriterde neden öne çıktığını gösteriyoruz.
- Full-stack tek ekip: Veri modeli, servis katmanı ve arayüz aynı ekipte; sorumluluk bölünmüyor, sorun çıktığında firmalar arasında top çevrilmiyor.
- Sürdürülebilir mimari: Clean architecture ve SOLID ilkeleriyle, altı ay sonra da hızla geliştirilebilen kod tabanları bırakıyoruz.
- Risksiz geçiş planlaması: Modernizasyon projelerinde kademeli taşıma ve yönlendirme planıyla hem işletmeyi hem arama motoru görünürlüğünü koruyoruz.
- Kod ve bilgi sizde kalır: Kaynak kod, teknik dokümantasyon ve gerekirse ekip eğitimi teslimin parçasıdır.