Smashing Magazine İçeriği Nasıl Yönetiyor: WordPress'ten JAMstack'e Geçiş

Bu makale, modern web projelerini otomatikleştirmek için hepsi bir arada bir platform olan Netlify'daki sevgili dostlarımız tarafından desteklenmiştir. Teşekkür ederim!

Geliştiriciler WordPress hakkında her konuştuğunda, pazar payı yüzdeleri değişir. “ Tüm sitelerin %20'si WordPress'te! ” “ Tüm sitelerin %40'ı WordPress'te! ” Yüzde ne olursa olsun, mesaj aynıdır: benimseme açısından WordPress MUHTEŞEMDİR.

Öyleyse neden bu tür bir benimseme ile WordPress kullanan bir site JAMstack'e geçmeyi düşünsün? Bu iki bölümlük makale dizisinde, tam da şu anda okuduğunuz sitenin örnek olayını kullanarak gerçek bir WordPress geçişinin nasıl göründüğünü ele alacağız.

Kazançları ve kayıpları, daha önce bilseydik istediğimiz şeyleri ve neye şaşırdığımızı konuşacağız. Ardından, olası bir geçiş yolunun teknik bir gösterimi ile takip edeceğiz - WordPress'in tamamen dışında değil - ancak her iki dünyanın en iyisine sahip olabilmeniz için ayrıştırılmış WordPress'i nasıl sunabilirsiniz: size her şeyi veren bir WordPress JAMstack uygulaması daha iyi performans ve güvenlik ile gösterge panelinin ve işlevselliğinin gücü.

Hadi kazalım!

Niye ya?

2015 yılında, Netlify kurucu ortağı Mathias Biilmann ve Smashing'in kurucusu Vitaly Friedman, alışveriş hakkında konuştu. JAMstack mimarisi tur atmaya başladığında, Smashing yığın fikriyle daha fazla ilgilenmeye başladı. Vitaly ve Markus (Smashing'in eski genel müdürü), Matt'e Smashing'in geleneksel WordPress/LAMPstack sitelerinden bir JAMstack mimarisine geçmesi durumunda ne olacağını sordu.

Bir deney olarak, Matt tüm HTML'yi Smashing'den aldı ve içeriği bir CDN'den statik olarak teslim ederek Netlify'da barındırdı. Sonuçlar ikna ediciydi - statik sürüm ortalama olarak altı kat daha hızlı!

Bu tür mimari, kısmen sayfalar ziyaret ettiğinizde istek üzerine derlenmediği için çok iyi çalışır. Önceden oluşturulmuş içeriği doğrudan bir İçerik Dağıtım Ağı'ndan sunduğunuz için site zaten "oradadır" ve kullanıcı için hazırdır.

CDN üzerinden hizmet verdiğiniz için, içeriği dünyanın her yerine, potansiyel ziyaretçilere daha yakın şekilde dağıtabilirsiniz. Tüm okuyucuları için hızlı olmak isteyen herhangi bir çevrimiçi yayın durumunda hayati önem taşıyan merkezi bir çıkış noktası yoktur.

Böylece sahne kuruldu. Smashing Magazine, JAMstack'e, özellikle de bir platform olarak Netlify'a geçti. 10 yıllık faaliyetinde Smashing, küçük bir çevrimiçi yayından kitap, konferans bileti ve atölye gibi şeyler satan devasa bir WordPress bloguna dönüştü.

Bu sitenin birkaç parçası vardı:

• WordPress blogu
• Raylar işleri panosu
• Shopify mağazası
• Konferans sitesi için başka bir CMS

Netlify geçişe ilk başladığında, site 20 bin yorum ve binlerce makalenin ağırlığı altında bazı performans sorunları yaşıyordu. Smashing, yeni bir abonelik planının bir parçası olarak kimlik doğrulamanın yanı sıra daha modern bir görünüm için yeniden tasarımla da ilgilendi.

Güvenilirlik

Smashing, diğer platformların hayalini kurduğu şeyi düzenli olarak gerçekleştirir: muazzam bir topluluk aracılığıyla geniş çapta paylaşılan makaleler. Bununla birlikte, bir gönderi için trafiğin bir devrilme noktasına ulaşıldığında, Smashing'in düzenli olarak kesintilerle ilgili sorunları vardı. Bunu azaltmak için, WordPress eklentilerinin yoğun kullanımı yığınlarına dahil edildi, ancak yine de iyi çalışma süresi ölçümlerini korumak için mücadele ettiler.

Netlify'a geçmek, Smashing ekibinin veritabanı bağlantı hataları almaktan kaçınmasına ve bir makale çok miktarda trafik gördüğünde bile kesinti süresi konusunda endişelenmemesine izin verdi. Niye ya? Çünkü sunucu olmadan hizmet verirken, önceden oluşturulmuş içeriğin oluşturulması ve sunulması gerekmez - zaten var, görüntülenmeye hazır. Statik sayfanın tamamı dışında hiçbir şey istenmiyor.

CDN üzerinden hizmet vermek, Smashing'in güvenlik açısından biraz daha rahat uyumasını da sağladı. wp-login.php uzun zamandır bir güvenlik açığı ve saldırı vektörü kaynağı olmuştur. Önceden oluşturulmuş içeriğe aynı şekilde erişilemez ve güvenlik açıkları her yerde bulunmaz.

önbellek geçersiz kılma

Smashing, çeşitli sonuçlar ve birçok sorunla her WordPress önbelleğe alma eklentisi arasında geçiş yapmıştı. Smashing'den Vitaly Friedman şöyle diyor:

“Başlıca sorunlarımız, iki haftada bir sürekli karşılaştığımız 'Veritabanı Bağlantısı Kurma Hatası' ile ilgiliydi ve kelimenin tam anlamıyla her bir WordPress önbelleğe alma eklentisini denedik. Performans oldukça iyiydi (genel olarak), ancak daha da geliştirmek istiyorduk. Ayrıca Üyeliği başlatmak ve konferanslar, iş ilanları, makaleler, kitaplar, e-Kitaplar gibi tüm farklı teklifleri tek bir platformda birleştirmek istedik ve WordPress oyun içindeyken bunu başarmak oldukça zordu.”

Netlify'a geçiş, Smashing ekibinin önbelleğe alınmış ve performanslı içeriği ekstra ek yük olmadan sunarken anında önbellek geçersizliğini görmesine izin verdi.

Bir siteyi dağıttığınızda, HTML dosyaları Netlify'ın CDN'sinde barındırılır. Yüksek önbellek isabet oranı ve hızlı ilk bayta ulaşma süresi için optimize edilmiştir ve değişen tüm HTML dosyalarını anında geçersiz kılabilir . Netlify ayrıca CSS dosyaları, resimler, yazı tipleri veya JS dosyaları gibi varlıklara olan tüm bağlantıların parmak izini alır ve onları sonsuza kadar önbelleğe alan önbelleğe alma başlıklarıyla Smashing'e hizmet eder. Parmak izi, benzersiz olduklarını ve yeni bir sürümü güncellerseniz bunun yerine daha yeni sürümün sunulacağını garanti eder.

iş akışı

Mevcut kuruluma bakıldığında, geçişin büyük bir nedeni sadece mevcut mülkleri birleştirmekti. Tüm bu farklı teknoloji yığınları ve kurulumları arasında geçiş yapmak, mühendisleri görevlendiren zorlu bir bakım sorunu haline geldi.

Daha önce altyapıları çok farklı sistemler arasında bölündüğünde, bu geçiş süreci de her şeyi birleştirdi , ana siteyi, konferans sitesini, abonelikleri ve e-ticaret bölümünü farklı yığınlarla ayrı ayrı tutmak yerine birlikte çalışır halde tuttu. Bu, geliştirme maliyetlerini düşük tutmaya ve geliştirici deneyiminin tüm mülkler üzerinde tutarlı bir şekilde çalışmasına yardımcı oldu.

WordPress geçiş parçasının en büyük ve en hassas olduğu kanıtlandı. Netlify, yalnızca içeriğin korunması gereken gömülü olduğunu veya zaman zaman eklentiler tarafından değiştirildiğini bulmak için verileri WP dışa aktarıcısından dışa aktarmaya çalıştı. Sitede bulunanlarla eşliği korumak için, makaleler, varlıklar, yorumlar ve ana sayfaya göre ayrılmış bir dizi kazıyıcı yazılmıştır.

Yazılıp dönüştürüldüğünde GitHub'da yeni bir depoya yüklendi ve bunun yerine Netlify CMS kullanıldı. Netlify CMS'yi benzersiz yapan şey, hafif olması ve içerik düzenleyicilerini Git iş akışına entegre etmesidir - yani, kelimenin tam anlamıyla bir veritabanı yerine git deposundan markdown dosyalarını çekip sunacağı anlamına gelir. Ayrıca Netlify CMS, platformdan bağımsızdır ve GitHub'da depolanan (neredeyse) tüm statik site oluşturucular ve sitelerle çalışır.

O sırada Sara Soueidan, Smashing için yeniden tasarımlarında serbest çalışan bir ön uç geliştirici olarak çalıştı. Ön uç mimarisini oluşturmak için bir bileşen kitaplığı oluşturdu ve CMS ile çalışırken bile doğrudan git üzerinde çalıştığı için çalışmanın ne kadar basit olduğunu belirtti.

“Depoya gönderdiğim her şey doğrudan model kitaplığına uygulanıyor, bu da iki farklı bileşen kümesini sürdürmek zorunda olmadığınız anlamına geliyor... bu tür bir süreklilik harikaydı! Tek yapmam gereken HTML, CSS ve JavaScript yazıp depoya göndermek ve her şey sihir gibi çalışıyor. İş akışı harikaydı.”

Tüm bunlar, Netlify CMS'nin bazen bu kadar yüksek trafik ve ölçek kullanım durumu için çok hafif olabileceğini söyledi. Smashing'in düzenli olarak konuk yazarları ve tam bir editör kadrosu vardır. WordPress'in sunduğu zengin özelliklerden bazıları, bu tür işbirlikçi ortamlar için gerçekten yararlıdır.

Bu nedenle, aşağıdaki öğreticide, içerik oluşturucular için WordPress panosunun avantajlarından yararlanmaya devam edebileceğiniz, ancak WordPress'i API aracılığıyla kullanabileceğiniz ve geliştirmenin git-merkezli bir iş akışına dayanmasını bu kadar kolay hale getirebileceğiniz başsız bir modelde size yol göstereceğiz . geliştiricilerin de sürdürmesi için. Bizi izlemeye devam edin!

Çerçeve Seçenekleri

Matt Biilmann'ın yarattığı ilk prototipte, performansa çok odaklandığı için her şeyi Hugo ile eşleştirilen minimal Preact'te yazdı. Sadece sahne kullandı ve her şeyi çok hafif tuttu. Smashing'in geliştiricisi Ilya Pukhalski tarafından sürdürülmek üzere projeyi devre dışı bıraktığında, Preact'in React'in ekosistemine girmek için eksik olan bazı özelliklerden yoksun olduğunu gördü. Sonunda, Redux ve diğer kütüphanelerin faydaları maliyetinden daha ağır bastı.

Şimdi düşününce Matt, o sırada pek pazar payına sahip olmayan Vue'yu kullanacağını söylüyor (yemin ederim, ondan bunu söylemesini istemedim). Bariz soruyu sordum: neden Svelte olmasın? Performans odaklı insanlar bu kütüphaneye ulaşma eğilimindedir. Svelte'nin henüz Vue'nun sahip olduğu ekosisteme tam olarak sahip olmadığını belirtti.

Matt, Hugo'yu hâlâ kullanıp kullanmayacağını düşündüğünde, Hugo'yu sevdiğini söylüyor, ancak bu proje için özellikle zorlandığı şey, yeterince eklenti sistemine sahip olmamasıydı - banner reklamlar ve benzeri şeyler yaratmak. doğanın Hugo ile yeterince programlanabilir olmadığını ve bunu başarmak için senaryolar enjekte etmesi gerektiğini söyledi. Bu komut dosyaları, oluşturma sürecini yavaşlatma eğilimindeydi. Bununla birlikte, netlify.com adresindeki kendi sitemiz için hala Hugo'yu kullanıyoruz ve onu seviyoruz - bu uyarı, özellikle Smashing'in sitesinin ihtiyaçları için son derece özeldir.

Tekrar yapabilseydi, eklentiler ve diğer genişletilebilir komut dosyaları oluşturma açısından zengin yeteneklere sahip olan Eleventy'yi seçebilirdi. Veya, Vue kullanıyor olsaydı, Nuxt ona bazı güzel eklenti yetenekleri sunarken, bu çerçeve için iyi bir seçim olmasına izin vererek, sunucu tarafı oluşturma, yönlendirme ve statik oluşturma sunardı.

Büyük Siteler İnşa Etme

Smashing kadar büyük bir siteyle çalışırken ortaya çıkan bir sorun vardı ve belki bunun ne olduğunu zaten anlayabilirsiniz, biz sadece ona değindik. Bir CDN'de sunulan önceden oluşturulmuş sayfalardan oluşan herhangi bir büyük siteyle, performansın hala harika olduğu doğrudur, çünkü kullanıcılar için anında hiçbir şey oluşturmuyoruz.

Ancak bu fayda, yalnızca site önceden oluşturulmuşsa gerçekleşebilir ve bu süreç zaman alıcı olabilir. Daha geleneksel siteler, siz talep ettiğinizde sayfaları oluşturacak olsa da, kullanıcının ihtiyaç duyması ihtimaline karşı, kelimenin tam anlamıyla her bir sayfayı önceden oluşturuyoruz. Performansı süper hızlı hale getirir! Ancak bu süre artık geliştirme ve yayınlama zamanına aktarılmıştır - her sayfanın oluşturulması zaman alabilir.

Bu, daha küçük sitelerle ilgili bir sorun değil, ancak Smashing Magazine ölçeğinde, o zaman hakkında biraz daha düşünmemiz gerekiyor, özellikle de insanların günlük olarak aktif olarak içerik oluştururken üretkenliği yüksek tutabilmeleri için.

Netlify'ın yaptığı, halihazırda barındırdıkları 1000'lerce makalenin çoğunu taşıyan büyük bir /production-articles klasörü oluşturmaktı. Daha sonra aktif olarak oluşturulmakta ve editlenmekte olan makalelerin yerleştirilebileceği content/articles adında ayrı bir çalışma dizini yapılmıştır.

Bu derleme süreci, sitede çalışan herkesin, yerel geliştirme için daha küçük bir makale grubuyla, tüm derlemeyi beklemekle engellenmeden çalıştığı anlamına geliyordu. Bu süreç, üretim makalelerini hazırlamak için bir yudum görev tarafından yönetildi ve Hugo'yu yalnızca aktif olarak üzerinde çalışılanları halletmek için serbest bıraktı.

Bu yaklaşımın dezavantajlarından biri, hala tüm yapının çalıştırılmasını gerektirmesi ve süreci yavaşlatmasıdır. Daha küçük bir yayında, bu muhtemelen daha az önemli olurdu, ancak Smashing ölçeğinde yayın sürecini yavaşlatıyor.

Açık Kaynak API'leri

Başlangıçta, Smashing'in diğer şeylerin yanı sıra mevcut e-ticaret çözümlerini taşımak, yorumları WordPress dışında ele almak ve yetkilendirme için işlevsellik eklemekle ilgilendiğinden bahsetmiştik. Tüm bu işlevsellik parçaları, Netlify'ın bakımını yaptığı açık kaynaklı çözümlerle oluşturuldu ve bunları durum bilgisi olmayan API'lere böldü:

• GoTell
  Çok sayıda yorumu işlemek için bir API ve derleme aracı.
• GoTicaret
  Siparişleri ve ödemeleri işleyen e-ticaret siteleri için Go tabanlı küçük bir API.
• GoTrue
  Projeler için kullanıcı kaydı ve kimlik doğrulaması yapmak için bağımsız bir API hizmeti olarak hareket edebilen, Golang'da yazılmış küçük bir açık kaynaklı API. OAuth2 ve JWT'ye dayalıdır ve kullanıcı kaydı, kimlik doğrulama ve özel kullanıcı verilerini işleyecektir.

Bu parçaların her biri, kendi geçişlerini ve benzersiz faktörlerini gerektirdi ve bu makalenin kapsamı dışında olsalar da, hepsi Matt'in birlikte yazdığı “ JAMstack'te Modern Web Geliştirme ” adlı ücretsiz bir kitapta ele alındı. Ayrıca, sonraki gönderilerde, bunun gibi bazı derin dalışlar yapacağız - kullanılabilir örneklerle birlikte - arama ve kimlik doğrulama konusunda.

Çözüm

Göç yüzerek gitti. Harika mı? Şey… iyi gitti. Smashing, kendi başarısı için cezalandırılmadı - popüler bir makale ortaya çıktığında, içeriği tutarlı bir şekilde sunabiliyorlardı, artık büyük yüklerden kaçmıyorlardı. Bununla birlikte, JAMstack altyapısına geçiş, daha iyi performans ve güvenlik getirdi.

Smashing Magazine'in eski CEO'su Markus Seyfferth şunları kaydetti:

"İlk yükleme süresi eskisinden çok daha hızlı... önce HTML dosyasının sunulmasını 800ms için beklemek zorunda kaldık ve şimdi 80ms ."

Bu süreç başarılı oldu ve her büyük mühendislik projesi gibi, yol boyunca dersler alındı. Bu serinin bir sonraki makalesinde, öğrendiklerimize göre önereceğimiz şeyler için bir eğitim ve demo üzerinden geçeceğiz. WordPress geliştirmenizi modernize etmek ve JAMstack'in performans ve güvenlik avantajlarından yararlanmak istiyorsanız okumaya devam edin!