Headless WordPress Nedir, Ne Zaman Mantıklı?

💡 Özet (TL;DR):
Nedir? İçeriği WordPress'in yönettiği, ziyaretçinin gördüğü arayüzün ise REST veya GraphQL üzerinden veri alan ayrı bir uygulamayla oluşturulduğu mimaridir.
Ne zaman mantıklı? Aynı içerik birden fazla kanala gidecekse, arayüz uygulama gibi davranacaksa veya bağımsız yayınlanacaksa ve ekip iki sistemi sahiplenebiliyorsa.
Bedeli ne? Performans ve güvenlik kendiliğinden gelmez. Tema katmanına bağlı eklentiler, önizleme, yönlendirme, meta veriler, formlar ve içerik yenileme akışı ayrıca geliştirilir.

Headless WordPress, WordPress'i içerik yönetimi için tutup ziyaretçinin gördüğü arayüzü ayrı bir uygulama olarak geliştirdiğiniz mimaridir. Aynı içeriği birden fazla ürüne taşımak, arayüzü uygulama gibi kurgulamak veya frontend'i bağımsız yayınlamak gerektiğinde doğru seçim olabilir. Basit bir blogu ya da kurumsal siteyi sırf hız için headless yapmak ise çoğu zaman bu ek yükü haklı çıkarmaz.

Klasik WordPress, olgun bir içerik yönetim sistemini, tema yapısını ve eklenti ekosistemini tek kurulumda bir araya getiriyor. Asıl avantajı da bu bütünlük. Headless mimari ancak projenin dağıtım ve ürün ihtiyaçları, WordPress'in hazır sunduğu bu kolaylıktan daha değerliyse anlam kazanıyor.

Headless WordPress Nedir?

İçerik yönetimiyle sunum katmanının birbirinden ayrıldığı mimariye genel olarak Headless CMS deniyor. Headless WordPress'te yönetim paneli, içerikler, kullanıcılar ve medya WordPress'te kalıyor. İçerik, yerleşik REST API veya bir GraphQL eklentisi üzerinden sunuluyor. Yönlendirme ve sayfayı oluşturma sorumluluğunu ise ayrı frontend üstleniyor. WordPress REST API belgesi, bu arayüzün WordPress içeriğini özel frontend'lere ve başka uygulamalara taşımak için kullanılabileceğini açıklıyor.

Merkezi içerik arşivi tek bir API kanalıyla üç ayrı sunum yüzeyini besliyor

Neden Headless WordPress?

Headless WordPress'in Avantajları

Headless WordPress aşağıdaki avantajlarla birlikte geliyor:

Hazır bir tema değil, kurumunuza özel yeni bir tasarım yapılacaksa frontend ekibinin WordPress tema geliştirme bilgisi olması gerekmez. Frontend için istenen teknoloji kullanılabilir. Farklı cihazlar için yapılacak tasarımlarda farklı teknolojiler tercih edilebilir.
Frontend ve backend bağımlılığı ortadan kalkar. Tek bir frontend uygulaması ile birden fazla kaynaktan veri alabilir, farklı yerlerde kullanabilirsiniz.
Frontend ve backend ölçeklemeleri ayrı ayrı yapılabilir.
Farklı kanallara tek merkezden veri sağlamanızı sağlar. Hem web siteniz hem de mobil uygulamanız aynı kaynaktan beslenebilir.

Karşılaştırma: Klasik WordPress vs. Headless WordPress

Özellik	Klasik WordPress	Headless WordPress
Geliştirme Hızı	İhtiyacı karşılayan tema ve eklentiler varsa hızlıdır	Frontend ve entegrasyonlar özel olduğu için başlangıçta daha fazla iş ister
Sayfa Yüklenme Hızı	Hafif bir tema ve doğru cache yapısıyla hızlı olabilir	SSG, SSR ve CDN ile hızlı olabilir, ancak sonuç uygulamaya bağlıdır
Tasarım Esnekliği	Tema, blok ve eklenti ekosistemi içinde ilerler	Frontend üzerinde daha fazla kontrol verir, fakat kodun sorumluluğu ekibe geçer
Güvenlik	Tema, eklenti ve sunucu katmanlarının birlikte korunması gerekir	WordPress'in doğrudan görünürlüğünü azaltabilir, fakat API, frontend bağımlılıkları, erişim anahtarları ve yayın süreçleri yeni yüzeyler açar
Çoklu Kanal	API ve entegrasyonlarla mümkündür	Aynı içerik API'sini kullanan farklı istemcileri doğal olarak destekler

Hangi Durumlarda Headless WordPress Uygun Değil?

Headless düzeninde yönlendirme, önizleme ve eklenti işlevleri açık bir entegrasyon tezgâhında yeniden kuruluyor

Headless WordPress'in Dezavantajları

Headless WordPress hem bütçe hem de zaman açısından daha maliyetli bir çözüm. Peki neden?

Headless WordPress ile birlikte klasik WordPress'in sağladığı "temaları kur, eklentileri kur, ayarları yap, işte hazır site" kolaylığından vazgeçmeniz gerekir. Headless WordPress genellikle frontend için ayrı bir geliştirme ekibiyle çalışmanızı, en azından full-stack bir geliştiricinin frontend'i ayrıca kodlamasını gerektirir. Backend tarafı için de Headless WordPress yönetimi konusunda tecrübeli, gerektiğinde buna yönelik eklentiler yazabilecek bir ekibe ya da geliştiriciye ihtiyaç duyabilirsiniz.
Backend için ayrı, frontend için ayrı bir sunucu altyapısı yönetmeniz gerekebilir. Küçük yapılarda ikisinin de aynı sunucu üzerinde barındırılması mümkündür, ancak o derece küçük bir yapıda Headless WordPress'e gerçekten ihtiyacınız var mı, bu da bir soru işaretidir.
WordPress eklentilerinin tamamı headless yapıda aynı şekilde davranmaz. Backend'de veri yöneten eklentiler, verileri API üzerinden sunuluyorsa çalışmaya devam edebilir. Tema üzerinden HTML veya script ekleyen, görsel sayfa düzenleyen ya da sayfayı WordPress'in oluşturduğunu varsayan eklentiler ise özel frontend entegrasyonu ister. ACF'nin Headless WordPress rehberi bu ayrımı daha ayrıntılı ele alıyor.

Geliştiricilerin Bilmesi Gerekenler

Bu web sitesini klasik yapısından ilk kez ayırdığımda, onu bir headless WordPress mimarisi üzerine kurmuştum. Arka tarafta GraphQL üzerinden hizmet veren bir WordPress altyapısı, ön tarafta ise Next.js (React.js) ile yazılmış bir arayüz yer alıyordu. (Sitenin şu anki güncel hali tamamen statik bir Nuxt projesidir).

Klasik bir özel tasarım WordPress teması hazırlasam 3-4 günde bitecek o ilk headless geçişi, her şeyi sıfırdan kurmak gerektiği için neredeyse bir ay sürdü. Aşağıda, tema ve eklenti katmanına bırakamayıp kendim yönetmek zorunda kaldığım işlerden bazılarını listeledim:

REST API'nin daha hantal olacağını düşündüğüm için GraphQL tabanlı bir API yapısı oluşturdum (eklenti yardımıyla).
Klasik WordPress'te özel yazı tipleri, çoklu dil desteği, SEO ve özel alanlar gibi konularda eklentileri kurup birkaç ayar yaparak yola devam etmek mümkün. Headless yapıda ise bunların sorgularıyla tek tek uğraşıyor, ön yüzdeki entegrasyonlarını da kendiniz kodluyorsunuz. Örneğin Yoast SEO kurup ayarları yaptığınızda iş bitmiyor. Frontend tarafında ilgili meta etiketlerini sizin oluşturmanız gerekiyor.
Bir eklentinin normalde WordPress teması üzerinden eklediği kod veya script, ayrı frontend'e kendiliğinden gelmez. Gereken veriyi API üzerinden sunmanız ve karşılığını frontend'de oluşturmanız gerekir.
Yoast'un yönlendirme özelliği veya Redirection eklentisi ile kolayca yönetebileceğiniz yönlendirme işlemleri için frontend tarafında ciddi kod yazmanız gerekiyor. Ziyaretçiyi karşılayan taraf frontend olduğu için yönlendirmeleri de orası yapmalıdır. Bunun için hem frontend hem de backend tarafında entegre kod yazmalısınız.
Klasik WordPress'te Redirection eklentisi 404 hatalarını yakalayıp kayıt tutarken, headless yapıda 404 durumunda bu kaydı manuel oluşturmanız gerekir. Bunun için de hem frontend hem de backend tarafında ekstra kod yazmanız gerekecektir.
Normalde eklentilerle kolayca gerçekleştirdiğiniz form gönderme işlemleri artık daha zor bir hal alıyor. Frontend içerisine statik olarak yazılmış formlar yerine backend'den yönetilebilir dinamik formlar oluşturmak istiyorsanız formun gösterimi, doğrulaması ve gönderimi için ekstra kod yazmanız gerekir.
WordPress'in önizlemesi artık ziyaretçinin göreceği sayfayı kendiliğinden göstermez. Taslakları önizlemek için WordPress ile frontend arasında kimlik doğrulamalı bir akış kurmanız ve yayında olmayan içeriği doğru sayfada göstermeniz gerekir.
Frontend sayfaları önceden oluşturuyor veya cache'liyorsa, WordPress'te yayınlanan içerik ziyaretçiye hemen ulaşmayabilir. Bir webhook veya yeniden doğrulama akışı kurmanız, bu akış çalışmadığında da haberdar olmanız gerekir.
Artık bir eklenti yükleyip hemen kullanmaya başlayamayacaksınız. Eğer çok elzemse, hem frontend hem de backend tarafında entegrasyon için ekstra kod yazmanız gerekebilir. Bazı durumlarda eklentiyi entegre etmeye uğraşmaktansa işlevi sıfırdan kodlamak daha mantıklı olabilir.

Yolun ortasında "nereden bulaştım" dediğim anlar olsa da hem öğrenmek istediğim hem de süreçten keyif aldığım için devam ettim. Şunu rahatlıkla söyleyebilirim: Headless WordPress, kişisel bir web sitesi veya basit bir kurumsal site için gereğinden ağır bir çözüm. Aynı içeriğin birden fazla ürün veya kanalda kullanılması, frontend'in uygulama gibi davranması, bağımsız yayın ihtiyacı, ölçülmüş bir performans ya da ölçekleme sorunu ve iki sistemi yönetecek bir ekip varsa değerlendirmeye değer. Yüksek trafik veya e-ticaret etiketi tek başına yeterli değil. Headless e-ticarette sepet, oturum, ödeme ve eklenti entegrasyonları da özel frontend'in sorumluluğuna geçiyor.

Headless WordPress Geliştirmesi

Bu deneyim full-stack bir çalışmaydı. WordPress backend tarafının da Next.js frontend tarafının da kodunu kendim yazdım. Zorlayıcı olmasına rağmen keyifli bir yanı da var. Bugün bazı işler hâlâ meşakkatli, ancak neyi nasıl yapacağımı biliyorum. Yukarıda sözünü ettiğim adımların birçoğu için ayrı rehberler hazırlamayı düşünüyorum. Yine de bu yazılar tek başına yeterli olmayacaktır. Farklı kaynaklardan araştırma yapmanız ve saatlerce kafa yormanız gerekecektir.

Serinin takip eden yazılarında görüşmek üzere, hoşça kalın.