Başsız WordPress: Nedir ve İhtiyacınız Var mı?

Servebolt'ta WordPress ve ekosisteminin büyük savunucularıyız. İstatistikler yıldan yıla gösterilmeye devam ettiği için, onu gerçekten en iyi içerik yönetim sistemi olarak bulduğumuz için kendi sitelerimiz için de kullanıyoruz. Açık kaynaklıdır, çok yönlüdür ve basitçe ifade edersek, internetteki tüm web sitelerinin %40'ından fazlasına neden güç verdiğini anlamak inanılmaz derecede kolaydır.

WordPress'i çevreleyen ekosistemin ve geliştirici topluluğunun ne kadar büyük olduğu düşünüldüğünde, insanların WordPress'i farklı şekillerde kullanması şaşırtıcı değil. Böyle bir yaklaşım, WordPress'i başsız bir CMS olarak kullanmaktır - kısacası, popülerliği artan başsız WordPress olarak adlandırılır.

Bu kılavuzda, başsız WordPress hakkında bilmeniz gereken her şeyi, avantajlarını, dezavantajlarını ve daha fazlasını ekibimizin ilk elden deneyiminden ayıracağız.

Başsız WordPress Nedir?

Başsız WordPress'i anlamak için, monolitik WordPress'in ne olduğunu bilmeniz gerekir. Monolitik veya geleneksel biçimindeki WordPress, bildiğiniz gibi WordPress'tir. Sitenizdeki tüm içerikleri yönetmek için kullanabileceğiniz bir içerik yönetim sistemidir.

Genel olarak, WordPress, web sitenizi tasarlamanıza izin veren arka uca (içerik yönetim sistemi) ve sunum katmanına sahiptir. Bununla birlikte, başsız WordPress siteleri, içerik yönetim sistemi olarak WordPress'e dayanan ve içeriği görüntülemek için farklı bir ön uç yığını kullanan sitelerdir.

Bu, geliştirme açısından daha fazla esneklik sağlar. Esasen, REST API'nin yardımıyla, WordPress'i Vue.js veya React gibi bir çerçevede ayrı olarak oluşturulmuş bir ön uçla eşleştirirken içerik yönetimi işlevi için kullanabilirsiniz (sadece birkaçını belirtmek gerekirse, bir dizi başka şey vardır). çerçeveler ve ön uç araçları mevcuttur).

WordPress, tüm ön uç düzenleme araçları ve arka uç içerik yönetimi (düzenleme) işlevleri birleştiğinden, birleşik CMS mimarisi olarak kabul edilir. Bu, geliştiricilerden, editörlerden, metin yazarlarından ve daha fazlasından oluşan ekiplerin hem sunum katmanını hem de içeriği yönetmesine olanak tanır. Sunum katmanının ve içeriğin - adından da anlaşılacağı gibi - ayrıştırıldığı ayrıştırılmış bir mimariyi izleyen başsız WordPress web sitelerinin aksine .

REST, GraphQL ve Düz Dosya Entegrasyonu

Başsız bir CMS kurulumu, içeriği oluşturmak için API'leri ve CDN'leri kullanır. Ve şu anda üç seçenek mevcut – REST API, Flat-File entegrasyonu ve GraphQL.

WordPress, ön ucu CMS'ye bağlamanıza izin vermek için REST API'sini kullanır. REST API, sunucuların ve istemcilerin birbirleri arasında veri aktarmasına izin veren tek tip bir arabirim sağlayan, REST mimarisi kısıtlamalarını izleyen bir uygulama programlama arabirimidir. REST, geliştiricilerin belirli verileri ortaya çıkarmasına ve kullanmasına izin verir, REST uç noktasında doğrudan mevcut veriler yoksa, ek geliştirmeye ihtiyaç duyacaktır.

Başka bir alternatif GraphQL'dir (QL, Sorgu Dili'nin kısaltmasıdır). GraphQL, tıpkı bir veritabanında olduğu gibi, belirli alanlar ve ilişkilerle API'leri sorgulamayı kolaylaştırır. Bu önemli bir gelişmedir ve WordPress'te GraphQL API'sini kullanıma sunan bir eklenti vardır . Bu, GraphQL'nin zaten erişimi olduğundan, CMS'nin içeriğinden yararlanmak için ekstra geliştirmeye gerek olmadığı anlamına gelebilir, daha karmaşık kısım onu ​​elde etmek için doğru verimli sorguları istemektir.

Diğer seçenek düz dosya entegrasyonudur. Düz dosya entegrasyonu, normalde REST veya GraphQL aracılığıyla verilen verileri bir .JSON dosyası olarak dışa aktarmanıza olanak tanır, böylece sunucunun onu önbelleğe almasına izin verir ve her istekte oluşturulmasına gerek kalmaz, bu da onu çok daha hızlı hale getirir. Bu yöntemin kullanılması, veritabanında yapılan her değişiklikle otomatik olarak yeni bir .JSON dosyası kümesi oluşturur. Bu normalde ısmarlama bir uygulamadır ve yalnızca bir eklenti değildir. Bu nedenle, onu kurmak için bir geliştiriciye ihtiyaç vardır.

Başsız WordPress'in iyi ve kötü yanları

Artık başsız WordPress'in ne olduğunu ve geleneksel bir WordPress kurulumundan nasıl farklı olduğunu bildiğinize göre, bir karar vermeden önce bilmeniz gereken olumlu ve olumsuz yönleri burada bulabilirsiniz.

Esnek geliştirme, WordPress'i içerik yönetim sisteminiz olarak kullanmaya devam ederken, WordPress'i ayrıştırmak, geliştiricilerinize tercih edilen ön uç teknolojileriyle, yani Next.js gibi çerçevelerle oluşturma esnekliği sağlar . Yüzey seviyesinde bu, inşa etmek için çok daha fazla özgürlük anlamına gelir.

Yüzeyde, bu harika. Ancak bu aynı zamanda, site haritaları ve kalıcı bağlantılar gibi temel işlevler için tekerleği yeniden icat ederek yazı ve sayfa içeriğinin canlı önizlemelerinin çalışmasını sağlamanız anlamına gelir.

Ve WordPress'in bildiği editoryal iş akışının çoğunu kaybedersiniz . Yeni sayfalar oluşturmak genellikle önemli ölçüde daha karmaşık hale gelir ve geliştiricilerin, işler yolunda gitmediğinde hata ayıklamak için beklemede olmasını gerektirir .

WordPress arka ucuyla mobil uygulamalar oluşturma

Sıklıkla gözden kaçan bir kullanım durumu, WordPress'i ayırdığınızda, onu yalnızca arka uç için kullanarak mobil uygulamalar oluşturabilmenizdir.

Uygulamalar karmaşıktır, sıfırdan (yani, WordPress ile veya WordPress olmadan) web siteleri oluşturmaktan çok daha karmaşıktır - bu nedenle, bu rotayı takip ederseniz, içerik API odaklı olacak olsa da, geri kalanının çoğu yerel cihaz özelliklerine bağlı olacaktır. React Native gibi çerçevelerin yardımıyla. İşte AppPresser'dan Scott Bollinger'dan mobil uygulamalar oluşturmanın farklı yollarının harika bir karşılaştırması. Bunlardan biri, tahmin edebileceğiniz gibi, kutudan başlamak isteyenler için bunun harika bir uygulaması olan AppPresser. Doğal/hibrit iOS ve Android mobil uygulamalarına güç sağlamak için WordPress eklentileri, temaları ve REST API'sini kullanan WordPress tarafından desteklenmektedir.

Bunun gibi bir çözümle başlamak, aylarca olmasa da haftalarca süren geliştirme süresinden tasarruf etmenizi sağlar ve nihai olarak, ekibinin yıllarca müşteri projelerinde çalışmaktan ve platformu geliştirmek için üretimde test etmekten yıllara dayanan şirket içi deneyimine dayanır.

Takaslarla daha iyi performans.

Başsız geliştirmenin üç ana yolu vardır.

1. İstemci tarafı : Her şey, erişirken sunucudan yüklenen içerikle javascript kullanılarak tarayıcıda oluşturulur. Örneğin, motor olarak React'i kullanmak, verileri örneğin REST API aracılığıyla alır. Sayfa değiştirildiğinde, API'ye daha fazla veri isteği olur ve istemcide yeni bir sayfa oluşturulur. En sık Tek Sayfa Uygulamalarında (SPA) kullanılır
2. Statik Yayınlandı : Her şey sunucuda zaten oluşturulmuş ve HTML, CSS ve JS olarak dışa aktarılmıştır. Sayfayı dinamik olarak oluşturmayıp yalnızca statik dosyalar sunduğundan, bu çok düşük güçlü bir sunucuda veya CDN'de saklanabilir. Bu yöntem yıldırım hızındadır. Bu genellikle Next.js gibi bir şeyle yapılır. Sayfa değiştirildiğinde, sunucudan yeni bir HTML sayfası indirilir ve gösterilir. Broşür siteleri veya belgeler gibi sıklıkla değişmeyen sitelerde sıklıkla kullanılır.
3. İzomorfik Sayfalar : Erişilen ilk web sayfası HTML olarak Sunucu Tarafı İşlenir (SSR)'dir, ancak sonraki tüm sayfalar istemci yapabiliyorsa istemci tarafında oluşturulur. İstemci sayfayı oluşturamazsa, sunucudan isteyecektir. Çoğunlukla Aşamalı Web Uygulamalarında (PWA), son derece dinamik sitelerde veya daha eski web tarayıcılarına hizmet etmesi gereken sitelerde kullanılır. Bunun için genellikle Svelte.kit gibi bir çerçeve kullanılır.

Yöntem #1 ve #3, HTML'yi oluşturmak için düz veri dosyalarını kullanabilir, bu da onları statik yayınlanmış bir siteyle karşılaştırılabilir hale getirebilir, ancak REST veya GraphQL kullanmak, her istekte JSON içeriği oluşturması gerekebileceğinden onları biraz yavaşlatacaktır.

Kullanıcı tarafından oluşturulan içerik (formlar veya yorumlar) gibi şeylere ihtiyaç duyulursa, bu üç çalışma şekli standart WordPress'ten çok daha karmaşık hale gelir.

Örnek olarak bir iletişim formunu ele alalım, formun istemci tarafında çalışması ve bilgilerini Javascript/AJAX aracılığıyla sunucuya geri gönderebilmesi için oluşturulması gerekir, burada daha sonra kontrol edilir, temizlenir ve kişiye eklenir. eklenti yönetim sistemi oluşturur. Bu tamamen farklı bir çalışma şekli olduğundan, bunu sağlamak için iletişim formu eklenti üreticisine güvenemez veya bal kapları ve diğer spam koruması gibi şeylerin çalışmaya devam edeceğini garanti edemez. Bir REST uç noktası oluşturmak ve her şeyin gerektiği gibi çalışmasını sağlamak için bir geliştiriciye ihtiyaç duyabilir. Çok daha karmaşık.

REST uç noktaları zaten mevcut olduğu için yorumlar teorik olarak çok daha kolaydır, ancak yine de bir geliştiricinin onaylanan yorumları almasını ve bunları iş parçacığı düzeninde sunmasını, onay sürecine yeni yorumlar yüklemesini mümkün kılmasına ihtiyaç olacaktır. , ve elbette spam ile ilgilenin.

Başsız bir şekilde geliştirirken, WordPress ile kutudan çıkan veya birkaç eklenti ile mümkün olan aynı hedeflere ulaşmak için yapılacak daha çok şey var.

Gelişmiş güvenlik algısı ?

Başsız WordPress'in güvenliğini çevreleyen birçok yanlış bilgi var. Bir CDN ile statik bir site kurulumu çalıştırmak, DDoS saldırılarına karşı iyi bir önleyici tedbirdir. Ancak nihayetinde, gerekli sistemleri (yani Cloudflare, vb.) devreye sokmazsanız, herhangi bir sunucu bir DDoS saldırısının kurbanı olabilir. Ayrılmış WordPress kurulumları, ön uç standart etki alanında olacak şekilde ayrı bir etki alanına veya alt etki alanına yüklenmiş WordPress ile çalışır.

Örneğin, bu web sitesini kullanacak olsaydık, wp.servebolt.com'u ekibimizin blog yazıları yayınlaması ve sitenin bölümlerini yönetmesi için bir alan olarak kurarken, genel olarak erişilebilir sitemiz olarak Ve örneğin, örnek olarak bir Next.js ön ucunu kullanmak , her istek üzerine sayfa HTML'sinin oluşturulduğu SSR'yi (sunucu tarafı oluşturma) veya sayfa HTML'sinin oluşturulduğu SSG'yi (statik oluşturma) kullanma seçeneğiniz olduğu anlamına gelir. oluşturma zamanında oluşturulur. Statik oluşturma, HTML'nin her istek için yeniden kullanılmasına ve bir CDN tarafından önbelleğe alınmasına izin verir.

Her iki durumda da sunum katmanı, WordPress çalıştıran içerik katmanıyla iletişim kurmaya ve ondan içerik istemeye devam eder. Bu, başsız WordPress kurulumunuz için içerik yönetimi katmanını barındırdığınız alanın hala WordPress çalıştıracağı anlamına gelir.

Bunu özetlemek gerekirse, güvenliğin başsız WordPress web sitelerinde ve geleneksel kurulumda çalışan sitelerde daha iyi olup olmadığının cevabı, olabileceğidir. Basitçe söylemek gerekirse, daha az yaygın bir kurulum olduğu için. Bununla kastettiğimiz şey, bazılarının WordPress çalıştıran sitelerde güvenlik sorunları olduğu algısını boyamaya çalışmasının gerçek nedeni, pek çok sitenin WordPress çalıştırmasıdır ve işler tamamen esnektir, bu nedenle elbette, bir şey inşa edebilir veya kurabilirsiniz. güvenilir değil, başsız ve neredeyse başka herhangi bir yığınla inşa ederseniz aynı şey geçerlidir.

Servebolt'ta yaptığımız gibi güvenlik, ölçeklendirme ve performansta yeterlilik getiren bir WordPress barındırma sağlayıcısı ile çalıştığınızda, WordPress ile yapabileceğiniz her şeyden ödün vermeden sitelerinizi güvende tutmak oldukça mümkündür – pahalı geliştirmelere katlanmak zorunda kalmak sıfırdan yeniden inşa etmek için maliyetler.

Başsız ile karşılaşmanız muhtemel daha fazla dezavantaj

Başsız WordPress'in maliyetleri

Buna zaten kısaca değindik, ancak kısaca, başsız WordPress oldukça pahalı olabilir. Sadece geliştirme maliyeti açısından değil, belki daha da önemlisi zaman açısından.

Ekibiniz, kurum içindeki mühendislere (veya bir ajansa) dayanmak zorunda kalmadan hızlı hareket etme ve yineleme yeteneğini kaybeder.

Sitelerini statik olarak görmeyen hızlı tempolu ekipler için bu, buna değmeyecek bir takastır. Başsız WordPress'i kendi bünyesinde yönetmek için kaynaklara sahip olan 8 haneli şirketlerin nasıl başsız bir kuruluma geçme ve nihayetinde geri dönme seçimini nasıl yaptıklarını ilk elden gördük, çünkü dayanamayacakları şey buydu. zaman kaybı, hızlı hareket etme esnekliği ve nihayetinde ekiplerindeki bir avuç kişiden daha fazlasını sitelerinde çalışmak için kontrol etmelerini sağlar.

Ne yaptığını bilen iyi geliştiriciler bulmak zor olabilir

Headless WordPress hala nispeten yeni bir kurulum. Bu nedenle, JavaScript'e (ve React, Vue, Svelte, Gatsby gibi çerçevelere) aşina olan JavaScript geliştiricilerini bulmak hiçbir şekilde özellikle zor olmasa da - ve belki de şu anda harika WordPress geliştiricileri bulmaktan daha kolay, aslında ön uç katmanını entegre etmeye aşina olanlar. Tüm en iyi uygulamalara uyan geleneksel bir şekilde WordPress'in gelmesi daha zor olma eğilimindedir.

Tam sayfa kenar önbelleğe almaktan her zaman daha hızlı değil

Daha hızlı bir web sitesine giden daha kolay ve muhtemelen daha iyi yollar vardır.

Başsız mimariyi düşünen çoğu şirket, önemli ölçüde daha kapsamlı bir karar vermeden önce barındırmalarını düzeltmelidir. Bunu yapmak çok daha kolay olmakla kalmaz, aynı zamanda büyük bir ön yatırım yapmadan önemli iyileştirmeleri hızla göreceksiniz. Sitenizi yeniden inşa etmeye yatırım yapmadan ve mevcut durumunda WordPress kurulumunuzun tüm avantajlarından ödün vermeden.

Başsız WordPress'ten Ne Zaman Kaçınmalısınız?

Genel bir kural olarak, başsız WordPress, WordPress ile inşa edilen çoğu işletme için uygun değildir. Kısacası, olanlar:

• İki ayrı katmanı (içerik ve sunum katmanı) korumaktan kaçınmak dileğiyle.
• WordPress'in bildiği editoryal ve içerik yönetimi iş akışından vazgeçmek istemeyin.
• Sürekli olarak geliştiricilerinize güvenmek zorunda kalmadan ekiplerinin kontrol ve çalışma esnekliğine sahip olmasına izin verin.
• Kaynaklardan tasarruf etmek ister (zaman ve para).
• Sistemin nasıl yapıldığına dair doğru seçimleri yapacak deneyimli geliştiricilere sahip olmayın.
• Geçici işçi kiralamak mı istiyorsunuz yoksa gelecekteki gelişmeleri göz önünde bulundurarak bir acenteye sitenizi geliştirmesini mi istiyorsunuz?

Başsız WordPress Kimler İçin İyidir?

Başsız WordPress, aşağıdaki durumlarda ekibiniz için iyi bir seçenek olabilir:

• Geliştirme ekibiniz JavaScript çerçeveleri oluşturma konusunda yeteneklidir ve bir WordPress geliştiricisi bulmak bir seçenek değildir (ne sebeple olursa olsun). Ancak WordPress'i bir içerik yönetim sistemi olarak kullanmaya devam etmek istiyorsa, başsız WordPress iyi bir seçenek olabilir.
• Ekibiniz, önceden oluşturulmuş bir SaaS platformunun tasarımı arasında süreklilik gibi belirli şeyleri başarmak istiyor, bu da bunları yeniden oluşturmayı ve WordPress'te korumayı daha fazla işe yarayacak. Bu durumda içerik ve sunum katmanını ayırmak iyi bir seçenek olabilir.
• WordPress temalarının sınırları içinde inşa etmemeye kararlısınız ve özellikle eklentilerin sunduğu herhangi bir ek işlevselliğe güvenmiyorsunuz.
• Bir işveren olarak, teknik personelinizi sürekli olarak en son becerilerle eğitmek ve onlara bu bilgiyi vererek bilmek istiyorsanız, sizinle daha uzun süre kalmaları daha olasıdır.
• Amacınız yığının tüm bölümlerinde n'inci derece optimizasyonlar gerçekleştirmektir .

Headless WordPress ile Oluşturulan Web Sitelerine Örnekler

sağlık hattı

TechCrunch

cephe

geri bağlantı

Rudis

Eylem Sonrası Raporu – Headless'ı Çözüm Olarak Değerlendirmek

Bazıları kafasız keşfetmek istiyor çünkü çok az kişinin üzerinde çalıştığı parlak yeni şey bu. Başka türlü elde edilemeyecek belirli bir soruna gerçekten en iyi çözüm olduğu için değil. Bir yan ürün olarak, başsız yaklaşımı benimseyen sitelerin çoğu , zorunluluk olmaksızın aşırı mühendislik kategorisine girer .

Başsız WordPress'in heyecan verici uygulamaları ve harika bir seçim olabileceği senaryolar olduğunu söylemeye gerek yok. Takımların elde etmek istedikleri sonucu yönlendiren inanılmaz web siteleri oluşturmalarına olanak tanıyan şeyin seçim olduğu yerler.

Hala başsız WordPress'in ekibinizin aradığı şeyle uyumlu olup olmadığını merak ediyor musunuz? Bizimle bir telefon görüşmesi yapmaktan çekinmeyin ; yaşadığınız ve çözmek için başsız WordPress'i uygulamayı düşündüğünüz sorunlar hakkında konuşmaktan memnuniyet duyarız.

Veya bu kılavuz tüm sorularınızı yanıtlamışsa ve Servebolt yaklaşımını denemeye hazırsanız:

Deneysel olarak daha hızlı yönetilen barındırma ile ilgileniyor musunuz? WordPress barındırma yaklaşımımızı deneyin :

• Ölçeklenebilirlik: Gerçek kullanıcı iş yükü testlerinde Servebolt, ortalama 65 ms'lik yanıt süreleri, ikinci en iyiden 4,9 kat daha hızlı yanıt süreleri sağladı.
• En hızlı global yükleme süreleri: 1.26 saniyelik ortalama sayfa yükleme süreleri, bizi global WebPageTest sonuçları listesinin en üstüne yerleştiriyor.
• En yüksek bilgi işlem hızı: Servebolt sunucuları, daha önce duyulmamış veritabanı hızları sağlar, saniyede ortalamadan 2,44 kat daha fazla sorgu işleyerek ve ikinci en iyiden 2,6 kat daha hızlı PHP çalıştırarak!
• Mükemmel güvenlik ve çalışma süresi: Tüm monitörlerde %100 çalışma süresi ve SSL uygulamamızdaki A+ derecesi ile sitenizin çevrimiçi ve güvenli olduğundan emin olabilirsiniz.