Üniversite Sitelerinde Headless Drupal Ne Zaman Kullanılmalı?

Headless Drupal'da içerik Drupal'da yönetilir, ziyaretçinin gördüğü sayfaları ise ayrı bir uygulama oluşturur. Bu ayrım, bağımsız bir ön yüz geliştirmek isteyen kurumlara esneklik sağlayabilir; içerik yayımlamaya odaklanan bir üniversite sitesinde ise ek geliştirme ve bakım yükü getirebilir. Bu yazıda geleneksel, hibrit ve tam ayrık Drupal yapılarını karşılaştırıyor, hangi ihtiyaçların hangi yaklaşımla karşılanabileceğini ve karar vermeden önce sorulması gereken soruları ele alıyoruz.

Yeni web sitesi toplantılarında sık duyulan bir öneri var: "Siteyi headless yapalım, daha modern olur." Oysa mimariyi seçmek için modern görünme isteğinden daha somut gerekçelere ihtiyaç vardır. Sitenin hangi işlevleri sunacağı, editörlerin nasıl çalışacağı ve yayından sonra bakımını kimin üstleneceği birlikte değerlendirilmelidir.

Headless Drupal nedir

Headless Drupal, içeriğin Drupal'da yönetildiği, ziyaretçiye sunulan sayfaların ise ayrı bir ön yüz uygulaması tarafından oluşturulduğu mimaridir. Drupal içeriği saklar, düzenler ve bir API üzerinden diğer uygulamaların kullanımına sunar. Web sitesi, mobil uygulama ya da kampüs ekranı bu içeriği alarak kendi arayüzünde gösterir.

API, yazılımların belirli kurallar çerçevesinde veri alışverişi yapmasını sağlayan arayüzdür. Bu yapıda diğer uygulamalar, ihtiyaç duydukları içeriği Drupal'ın API'sinden alır.

Bir restoran benzetmesi konuyu anlamayı kolaylaştırır. Geleneksel bir restoranda mutfak ve salon aynı binadadır; aşçı yemeği tabağa koyar, garson da yandaki salona taşır. Headless yapıda ise tek bir merkez mutfak vardır. Yemek oradan farklı salonlara, paket servise ve kampüs kafeteryasına gider; her biri kendi sunumunu yapar. Drupal mutfaktır; salonlar ise web sitesi, mobil uygulama ve diğer ekranlardır.

"Headless" kelimesi İngilizcede "başsız" anlamına gelir. Buradaki "baş", ziyaretçinin gördüğü ön yüzü ifade eder. Ön yüz Drupal'dan ayrılır; içerik yönetimi ise Drupal'da kalır.

Headless ve decoupled arasındaki fark

Bu iki terim çoğu zaman birbirinin yerine kullanılır; aralarındaki ayrım her kaynakta aynı biçimde yapılmaz. Bu yazıda decoupled (ayrık) kavramını, ön yüzün içerik yönetiminden kısmen ya da tamamen ayrıldığı yapılar için kullanıyoruz. Headless ise ziyaretçiye sunulan ön yüzün tamamen ayrı bir uygulamada çalıştığı modeli ifade ediyor.

Bu kullanıma göre her headless yapı ayrıktır, ancak her ayrık yapı tamamen headless değildir. Drupal belgelerinde bu mimarileri anlatmak için sıklıkla "decoupled Drupal" ifadesi kullanılır.

Drupal mimarilerinin karşılaştırılması

Seçenekler, siteyi tamamen Drupal'da tutmak ya da ön yüzü bütünüyle ayırmakla sınırlı değildir. Drupal'ın sayfa oluşturma işini koruyup yalnızca belirli işlevleri ayırmak veya başka kanallara API üzerinden içerik sunmak da mümkündür.

Geleneksel Drupal

Drupal hem içeriği yönetir hem de ziyaretçiye sunulan sayfaları oluşturur. Editör haberi yazar, önizler ve kurumun yapılandırılmış onay sürecine göre yayımlar. Menüler, formlar, arama ve çok dillilik, Drupal çekirdeği ile ihtiyaç duyulan ek modüller kullanılarak sağlanabilir. Önizlemenin kapsamı ve editörün sayfa düzeni üzerindeki yetkisi kuruluma bağlıdır. Erişilebilirlik de tema, bileşenler ve içerik üzerinde ayrıca çalışılmasını gerektirir.

Hibrit Drupal

Bu yazıda hibrit terimini iki karma kullanım için kullanıyoruz. İlkinde Drupal sayfanın büyük kısmını oluşturur, program arama aracı veya etkileşimli kampüs haritası gibi bölümler ayrı JavaScript bileşenleriyle çalışır. Buna aşamalı ayrıştırma (progressive decoupling) denir. İkincisinde web sitesi Drupal'da kalırken mobil uygulama gibi diğer kanallar aynı içeriği API üzerinden alır. Bu ikinci kullanım, web sayfasının herhangi bir bölümünü ayırmayı zorunlu kılmaz.

Tam ayrık Drupal

Ziyaretçiye sunulan web sayfalarını ayrı bir ön yüz uygulaması oluşturur. Drupal ise içerik yönetimini, editör ekranlarını, yetkilendirmeyi ve yayın iş akışlarını yürütür; içeriği API üzerinden sunar. Bu yaklaşım ön yüz teknolojisi ve geliştirme süreci üzerinde daha fazla kontrol sağlar. Ancak Drupal'ın sayfa oluşturma katmanına bağlı özelliklerin ayrı ön yüzle nasıl çalışacağı ayrıca planlanmalıdır.

İçeriğin API ile nasıl aktarıldığını ve JSON:API ile GraphQL arasındaki farkı Drupal ile mobil uygulama geliştirme yazısında ayrıntılı olarak ele alıyoruz.

Headless yapı ne kazandırır

Ayrık mimarinin sağlayabileceği başlıca avantajlar şunlardır. Bunların bazıları, siteyi tamamen headless yapmadan, hibrit bir kurulumla da elde edilebilir.

• Aynı içeriği birden çok kanalda kullanmak. Drupal'a bir kez girilen duyuru, uygun API bağlantılarıyla web sitesinde, mobil uygulamada ve kampüs ekranlarında gösterilebilir. Böylece aynı metnin farklı sistemlerde ayrı ayrı güncellenmesi gerekmez.
• Ön yüzü içerik yönetiminden ayrı geliştirmek. İçerik modeli ve API yapısı ihtiyacı karşılamaya devam ettiği sürece, tasarım değişiklikleri editör ekranlarını yeniden kurmadan yapılabilir. Yeni tasarım farklı içerik alanları gerektiriyorsa iki tarafın birlikte güncellenmesi gerekir.
• Etkileşimli araçlar geliştirmek. Anında filtrelenen program listeleri veya ders planlama araçları, ekibin deneyimli olduğu ön yüz teknolojileriyle geliştirilebilir. Bu tür araçlar için bütün siteyi ayırmak şart değildir.
• Ekiplerin daha bağımsız çalışmasını sağlamak. Drupal ve ön yüz ekipleri, üzerinde anlaşılmış API yapısı sayesinde geliştirmelerini ayrı takvimlerle yürütebilir. İçerik modeli, yetkilendirme, önizleme ve yayın sonrası güncellemeler gibi ortak konularda koordinasyon yine gereklidir.

Headless yapının geliştirme ve bakım maliyetleri

Karar verirken ilk geliştirme bedelinin yanında editörlerin günlük işlerini ve uzun vadeli bakım ihtiyacını da hesaba katmak gerekir.

• Önizleme ayrıca entegre edilir. Drupal'ın kendi önizlemesi, ayrı ön yüzün nasıl görüneceğini kendiliğinden göstermez. Editörlerin taslakları gerçek tasarım içinde inceleyebilmesi için ön yüz ile Drupal arasında güvenli bir önizleme bağlantısı kurulmalıdır.
• Sayfa düzenleme yetkisi tasarıma bağlıdır. Editörlere uygun bileşenler ve görsel düzenleme araçları sunulmazsa, bir bölüm eklemek veya yerini değiştirmek için geliştirici desteği gerekebilir. Bu bağımlılık headless yapının zorunlu bir sonucu değildir; editör deneyiminin nasıl kurulduğuna bağlıdır.
• SEO ve erişilebilirlik için görevler netleştirilir. Ön yüz ekibi sayfa çıktısından, gezinme davranışlarından ve bileşenlerden sorumludur. SEO verileri Drupal'da yönetilmeye devam edebilir; yönlendirmeler ve site haritası için de uygun entegrasyonlar gerekir. İçerik ekibinin erişilebilir içerik üretme sorumluluğu devam eder.
• Mevcut özellikler ön yüze bağlanır. Menü, form, arama ve çok dillilik altyapısı Drupal'da kullanılmaya devam edebilir. Ancak bunların ayrı ön yüzde gösterilmesi ve çalışması için ek entegrasyon veya geliştirme gerekebilir.
• Her iki yazılım katmanının da bakımı gerekir. Drupal ve ön yüz uygulamasının güvenlik güncellemeleri, bağımlılıkları, dağıtım süreçleri ve izlenmesi planlanmalıdır. Bunları tek bir yetkin ekip yönetebilir; yine de iki katmanın bakım maliyeti bütçeye yansır.

Hız konusunda da yaygın bir yanılgı var. Headless yapı kendiliğinden daha hızlı değildir; performans, sayfaların nasıl oluşturulduğuna, önbelleğe alındığına, API isteklerine ve altyapı kapasitesine bağlıdır. Geleneksel Drupal da uygun yapılandırmayla yoğun trafiği karşılayabilir; bunun beklenen yük altında test edilmesi gerekir. İlgili yöntemleri üniversiteler için Drupal performans optimizasyonu yazısında ele alıyoruz.

Üniversite sitesi için uygun mimariyi seçmek

Aşağıdaki örnekler bir başlangıç noktası sunar. Son karar, işlevler, editör ihtiyaçları, ekip yetkinliği ve bakım bütçesi birlikte değerlendirilerek verilmelidir.

Headless yapının anlamlı olduğu durumlar

Tam ayrık yapı; bağımsız geliştirilmesi gereken bir ön yüz, yoğun etkileşim sunan bir web uygulaması veya farklı arayüzlerden oluşan bir yayın ekosistemi için anlamlı olabilir. Tek bir web sitesi de bu ihtiyaçlara sahip olabilir. Buna karşılık, çok sayıda kanala içerik sunmak tek başına tam ayrık mimari gerektirmez. Belirleyici olan, ayrımın somut bir ihtiyacı karşılaması ve kurum içi bir ekip ya da uzun vadeli hizmet sağlayıcı tarafından sürdürülebilmesidir.

Geleneksel Drupal yapısının yeterli olduğu durumlar

Sitenin asıl işi içerik yayımlamaksa, web ekibi küçükse ve fakültelerin kendi sayfalarını kolayca güncellemesi gerekiyorsa geleneksel Drupal güçlü bir başlangıç seçeneğidir. Birden çok birim sitesini ortak kod tabanıyla yönetme yaklaşımını Drupal multisite ile üniversite web sitelerinin yönetimi yazısında ele alıyoruz. Çoklu site yönetimi ile ön yüzün ayrılması farklı mimari kararlardır.

Web sitesi ve mobil uygulama için hibrit yaklaşım

Bir kurumun ihtiyacı, web sitesini Drupal'da tutarken mobil uygulamada da aynı içeriği kullanmak olabilir. Bunun için web sitesinin ön yüzünü bütünüyle ayırmak gerekmez. Drupal hem web sayfalarını oluşturur hem de uygulamaya API üzerinden içerik sunar. Editörler alışık oldukları ortamda çalışmayı sürdürür. Güncellemelerin uygulamaya ne zaman yansıyacağı ise veri yenileme ve önbellek kurallarına bağlıdır.

Drupal Canvas bu kararı nasıl etkiliyor

Görsel sayfa düzenleme ihtiyacı da mimari seçiminde rol oynar. Ancak esnek sayfa tasarımları için ayrı bir ön yüz uygulaması kurmak zorunlu değildir. Drupal Canvas, bu ihtiyacı Drupal içinde karşılamak için değerlendirilebilecek seçeneklerden biridir.

28 Ocak 2026'da yayımlanan Drupal CMS 2.0, Drupal Canvas'ı varsayılan görsel düzenleme deneyimi olarak sunar. Bu, Drupal çekirdeği üzerine kurulu Drupal CMS ürününün özelliğidir; mevcut her Drupal sitesinde kendiliğinden etkinleşmez. Editörler hazır bileşenleri sürükleyip bırakarak sayfa oluşturabilir ve değişiklikleri anında görebilir. Canvas'ın kod bileşenleriyle React/JSX kullanmak da mümkündür. Böylece bazı projelerde görsel düzenleme ihtiyacı, bağımsız bir ön yüz uygulaması kurmadan karşılanabilir.

Canvas, tamamen ayrık projelerde de kullanılabilir. Drupal belgeleri, kod bileşenleri ve komut satırı aracı ile harici JavaScript bileşenlerine dayanan iki yaklaşımı açıklar. Seçim yapılırken önizleme, sayfa oluşturma yöntemi, bileşen uyumluluğu ve bakım ihtiyacı projeye göre değerlendirilmelidir. Üniversite siteleri açısından genel çerçeveyi Drupal Canvas nedir yazısında bulabilirsiniz.

Karar vermeden önce sorulacak altı soru

Bu sorular, ayrık yapının sağlayacağı faydayı geliştirme ve bakım yüküyle karşılaştırmaya yardımcı olur. Özellikle somut kullanım ihtiyacı ve uzun vadeli bakım sorumlusu netleşmeden tam ayrık yapıya karar verilmemelidir.

1. İçerik hangi kanallarda kullanılacak ve ne tür bir arayüz gerekiyor? Mobil uygulama veya kampüs ekranları API kullanımını gerekçelendirebilir. Tek kanallı bir projede ise bağımsız ön yüzün hangi işlevi ya da geliştirme ihtiyacını karşılayacağı açıklanmalıdır.
2. Ön yüzü yayından sonra kim yönetecek? Kurum içinde veya hizmet sağlayıcı tarafında, bakım ve geliştirmeyi önümüzdeki yıllarda üstlenecek bir ekip ve bütçe var mı?
3. Editörler sayfa düzenini kendileri değiştirebilmeli mi? Gereken bileşenler ve görsel düzenleme araçları sağlanacak mı, yoksa belirli değişikliklerde geliştirici desteği mi gerekecek?
4. Yayın öncesi önizleme ve onay ne kadar kritik? Birden çok birimin onay verdiği süreçlerde, taslakların doğru görünümle incelenmesi önemlidir. Bu süreçleri üniversiteler için Drupal içerik onay iş akışı yazısında ele alıyoruz.
5. SEO ve erişilebilirlik görevleri nasıl paylaşılacak? Ön yüz, Drupal ve içerik ekiplerinin sorumlulukları ile test ve kabul ölçütleri tanımlandı mı?
6. Bakım bütçesi iki yazılım katmanını destekliyor mu? İlk geliştirme maliyetinin yanında yıllık bakım, güvenlik güncellemeleri, barındırma ve entegrasyon testleri de hesaba katılmalıdır.

Headless yapıya geçmeden önce içeriği yapılandırmak

İçeriği farklı kanallarda verimli biçimde kullanabilmek için bilgilerin uygun alanlarda tutulması gerekir. Bir programın bütün bilgileri tek bir metin kutusuna yazılmışsa, mobil uygulama kontenjanı veya başvuru tarihini ayrı bir veri olarak doğrudan alamaz. Başlık, süre, eğitim dili, kontenjan ve başvuru tarihi ayrı alanlarda tutulduğunda her kanal ihtiyaç duyduğu bilgiyi kullanabilir.

İçeriği yapılandırmak, headless yapıya geçilmediğinde de yararlıdır. Arama ve filtreleme için daha düzenli veri sağlar, tutarlı sayfa şablonlarını destekler ve ileride eklenecek bir mobil uygulamaya hazırlık oluşturur. Bu nedenle ilk adım çoğu zaman mevcut içerik modelini gözden geçirmektir.

Drupal4edu'nun arkasındaki Drupart ekibi, TED Üniversitesi, Özyeğin Üniversitesi ve Kadir Has Üniversitesi gibi kurumlar için Drupal platformları geliştiriyor. Mimariyi değerlendirirken içeriğin kullanılacağı kanalları, arayüz ihtiyaçlarını, editörlerin çalışma biçimini ve yayından sonraki bakım kapasitesini birlikte ele alıyoruz. Yaklaşımımız hakkında daha fazla bilgiyi eğitimde Drupal sayfasında bulabilirsiniz.

Headless Drupal hakkında sık sorulan sorular

Son güncelleme: 13.10.2026 16:27