DE{CODE}: WordPress Geliştiricileri için Headless 101

Başsız geliştirme, geleneksel WordPress geliştirmeden daha güçlü ve hatta daha eğlenceli olabilir. Ancak, ortaya çıkan bu yığında pek çok yeni seçenek varken, başlamanın en iyi yolu nedir? Bu atölye çalışması, inşaatçılara bir WordPress projesini başsız için yükleme ve optimize etme yoluyla, ilk sayfanızı ayrılmış bir ön uçta şablon haline getirmeye kadar yol gösterecektir.

Oturum Slaytları

Tam Metin Transkript

GRACE ERIXON : WordPress Geliştiricileri için Headless 101'e hoş geldiniz. Benim adım Grace Erixon ve burada WP Engine'de yardımcı geliştirici savunucusuyum. Bana katılan Haus'tan Steve. Bugün size başsız WordPress'in ne olduğu ve onu kullanmaya nasıl başlayabileceğiniz hakkında hızlı bir giriş yapacağız.

Başsız bir WordPress web sitesi mimarisinin ne olduğunu anlamak için, geleneksel bir WordPress mimarisinin nasıl göründüğü konusunda hepimizin aynı fikirde olduğundan emin olmamız önemlidir. Geleneksel olarak, WordPress gibi bir CMS, bir web sitesinin hem ön ucunu hem de arka ucunu yönetirdi.

Geleneksel bir mimaride yayıncı, blog gönderileri ve WordPress içindeki sayfalar gibi içerikler oluşturur ve yönetir. Geliştirici, PHP ve WordPress'in tema API'sini kullanarak sitenin nasıl göründüğünü ve çalıştığını kontrol etmek için kod yazar. Ardından WordPress, ziyaretçiye gönderilen HTML sayfasını oluşturur.

Bu birleşik CMS mimarisinde WordPress, yayıncılara içerik yönetimi yetenekleri sağlar. Ayrıca HTML sayfalarının web sitesi ziyaretçilerine sunulmasından da sorumludur. Başsız bir CMS, ön ucun ve arka ucun ayrı ayrı yönetildiği, ayrıştırılmış bir mimari kullanır. Başsız bir mimaride, yayıncı, geleneksel bir WordPress mimarisinde olduğu gibi, WordPress'te içerik oluşturmaya ve yönetmeye devam eder.

Geliştirici, WordPress'ten veri çekmek için WPGraphQL veya REST API'yi kullanmanın yanı sıra sitenin JavaScript'te nasıl göründüğünü ve çalıştığını kontrol etmek için kod yazar. Faust.js, Next.js, Nuxt.js veya SvelteKit gibi bir çerçeve genellikle bu ön uç uygulamasını çalıştırmak için kullanılır. Ardından, ön uç JavaScript uygulaması, web sitesi ziyaretçisine gönderilen HTML sayfalarını oluşturur ve sunar.

Geleneksel bir mimariden farklı olarak, WordPress artık HTML sayfaları oluşturmaktan sorumlu değildir. Bu nedenle, WordPress arka ucu ile ön uç JavaScript uygulaması arasındaki içerik alışverişi etkileşimi, API katmanı aracılığıyla gerçekleşir. API katmanı için iki seçenek, WordPress REST API veya WPGraphQL'dir.

REST API, WordPress ile birlikte gelir. Ancak, REST her kaynağın kendi uç noktasına sahip olmasını gerektirdiğinden, gerektirdiği veri erişim modeli yavaş olabilir. Örneğin, tamamen modellenmiş bir postu yeniden oluşturmak için birden fazla gidiş-dönüş gerekir. Bir gönderinin içeriğini, yazarını ve kategorisini almak istiyorsanız, üç ayrı API çağrısı gerekir.

Buna karşılık, WPGraphQL, bir gönderinin içeriğini, yazarını ve kategorisini tek bir istekte istememize olanak tanır. Bu nedenle WPGraphQL tercih ettiğimiz API katmanıdır. WPGraphQL, WordPress siteniz için genişletilebilir bir GraphQL şeması ve API sağlayan ücretsiz bir eklentidir. WPGraphQL, REST API'sinden daha hızlıdır çünkü tam olarak istenen verileri alır ve sorgu optimizasyonu, daha az veri indirme, daha verimli veri yükleme ve tek bir isteğe dahil edilen birden çok kaynak aracılığıyla daha az işlevin yürütülmesine neden olur.

Başsız bir mimari, geliştiricilere JavaScript çerçevelerinin en popüler olduğu herhangi bir ön uç teknoloji yığını arasından seçim yapma özgürlüğü verir. En popüler ön uç JavaScript çerçevelerinden bazıları React, Vue.js ve Svelte'dir. Her zaman yeni çerçeveler piyasaya sürülüyor, bu nedenle bu liste kapsamlı olmaktan çok uzak.

Bu JavaScript çerçevelerinin çoğu, yönlendirme, sunucu tarafı oluşturma ve daha fazlası gibi şeyler için çözümler ekleyen meta çerçevelerle birlikte kullanılır. React, Next.js ile birlikte kullanılır, Vue.js, Nuxt.js ile birlikte kullanılır ve Svelte, SvelteKit ile birlikte kullanılır. Gatsby başka bir popüler meta çerçevedir.

WP Engine, React ve Next.js üzerine inşa edilmiş bir JavaScript çerçevesi olan Faust.js'yi geliştirmiştir. Faust, başsız WordPress web uygulamalarını desteklemek için özel olarak oluşturuldu. Kutudan çıkar çıkmaz kimlik doğrulama ve post önizlemeleri destekler, WordPress verilerine erişmek için uygun yerleşik React kancaları sağlar ve daha fazlasını sağlar.

Başsız bir WordPress mimarisinin ne anlama geldiğinden ve kullanacağınız teknoloji türlerinden bahsettik. Ama neden başsız olmayı seçeceğinize hızlıca değinelim. WordPress'in kendisi ağır bir CMS'dir ve hızlı bir dil olmayan PHP kullanır. Başsız WordPress, JavaScript aracılığıyla koruyucu dilleri kullanır ve API çağrıları aracılığıyla yalnızca gerekli dosyaları yükler. Çok daha hafiftir, bu nedenle siteniz daha hızlı yüklenir.

Başsız WordPress, verileriniz ön uç teslimatınızdan ayrı yaşadığı için içeriğinizin riskini de en aza indirir. Web saldırılarına daha az maruz kalır. Başsız WordPress mimarisinin ana avantajı, yayıncıların WordPress'in sağladığı harika yayınlama deneyiminden yararlanmaya devam etmesine izin verirken, aynı zamanda geliştiricilerin ve web sitesi ziyaretçilerinin modern JavaScript uygulamalarının masaya getirdiği teknik yeteneklerden yararlanmalarına izin vermesidir.

Şimdi, gerçek bir başsız sitenin kodunu inceleyelim. Yeni Atlas Blueprints başsız WordPress sitesinin bir incelemesini önceden kaydettim. Atlas'taki yeni Blueprints özelliği, tamamen başsız bir WordPress sitesini çalışır duruma getirmenin gerçekten kolay bir yolunu sunuyor. Uygulamanızı sıfırdan daha hızlı başlatmak için başlangıç ​​kodu, eklentiler, içerik modelleri ve sayfa yapısı ile birlikte gelirler.

O halde yeni bir Blueprint sitesi oluşturalım, böylece kodu inceleyebiliriz. WP Engine'in kontrol panelinin içinden Atlas'a gideceğiz. Uygulama Oluştur'a tıklayın. Blueprint ile Başlat'ı seçin. Ve sonra hangi planı kullanmak istediğimizi seçeceğiz. Portföy planını seçeceğim.

Ardından, WP Engine hesabınızı GitHub hesabınıza bağlayacak ve bu planı yeni bir havuza kopyalayacaksınız. Bunun oluşturulması birkaç saniye sürecektir. Son olarak, yeni oluşturduğunuz deponun adını, en yakın bulunduğunuz bölgeyi seçeceksiniz ve ardından Uygulama Oluştur'a tıklayacaksınız.

Şimdi, Atlas URL'sine tıklarsanız, başsız WordPress sitemizin nasıl göründüğüne bakabiliriz. Özellikle Gönderiler sayfasıyla ilgileniyoruz. Gördüğünüz gibi site, en son gönderilerin tümünü bu Blog sayfamıza çekiyor. Ayrıca her gönderinin kendi bireysel görüntüleme sayfası vardır. Ancak tüm bu veriler nereden geliyor?

WP Engine kontrol paneline geri dönersek, WP Admin için bir düğme görürüz. Başsız WordPress sitemiz için arka uç var. Gönderiler'e tıklarsam, web uygulamasının çektiği listenin aynısını görürsünüz. Artık Blueprint'imizin klonlandığı GitHub deposunu açabiliriz. Ve bu depoyu yerel ortamımıza kopyalayalım.

Daha sonra bu repoyu en sevdiğim kod editörüm olan Visual Studio Code'da açacağım. Proje dizinine girerek, blog sayfasının dosyası SRC'de, sayfalarda, yazılarda, Index.js'de bulunabilir. Bu proje React, Next.js, Faust.js ve WPGraphQL kullanılarak oluşturulmuştur. React'e ve hatta JavaScript'e aşina değilseniz, bu ilk başta kafa karıştırıcı görünebilir.

İlk bölümde, dosya sadece ihtiyaç duyduğu şeyleri iç ve dış kaynaklardan alıyor. Post düğümleri ön geçiş alanlarını tanımlayan ikinci bölüm, ihtiyacımız olan her veri parçasının listelendiği yerdir. Bunu ön geçiş yoluyla çalıştırmak, verilerin ihtiyaç duyduğumuzda orada olmasını ve ardışık taleplerin gerçekleşmemesini sağlar.

Sonra sayfa fonksiyonumuz var. İlk başta, ihtiyacımız olan verileri birkaç farklı değişkende, yani genel ayarlarda ve sayfalara ayrılmış bir gönderi listesinde topluyor. return ifadesinin içindeki etiketler, web sayfasında görsel olarak oluşturulacak kodlardır. İlk olarak, başlık için bileşene sahibiz. Ardından, bu ana bileşenin içinde, bir giriş başlığı bileşenimiz var ve bu, sayfanın üst kısmında Son Yazılar yazan büyük başlığı gösteren bileşendir.

Son olarak, sayfalandırılmış gönderi listesini bir parametre olarak kabul eden post bileşenine ulaşıyoruz. Post bileşeninin bu bilgilerle ne yaptığına bakalım. Burada, aldığı gönderiler listesinde yer alan her gönderide döngü halindedir. Her gönderi için, en son gönderinin sayfasındaki kart benzeri görünümü görüntüler. Bu ilk olarak, bireysel blog gönderisinin sayfasına bir bağlantıyla sarılı bir öne çıkan görsel bileşeni, gönderinin başlığının bir başlığı ve gönderinin tarihi ve yazarını içeren bir gönderi bilgisi bileşeninden oluşur.

Tüm gönderileri görüntüleyen Index.js dosyasına geri döndüğümüzde, istenirse daha fazla gönderi ve bir alt bilgi almak için sayfanın altındaki Daha Fazla Yükle bileşenini görüntüleyerek bunu bitiriyoruz. Son işlev olan getStaticProps, işlev tarafından döndürülen destekleri kullanarak derleme zamanında bu sayfayı önceden oluşturmasını söyleyen bir Next.js statik site oluşturma işlevidir. Ve bu kadar.

Headless kurulumunu bizim için hallettiği için Blueprints'e teşekkürler. WPGraphQL kullanarak WordPress arka ucundan veri almak ve React bileşenlerini kullanarak gönderileri görüntülemek için gönderi sayfasına girenleri parçalamak kolaydı. İzlediğiniz için teşekkürler. Beni Twitter @graceerixon'da bulabilirsiniz.

Headless WordPress hakkında daha fazla içerik için Developers.wpengine.com adresini ziyaret edin. Faust.js kullanarak ilk Headless WordPress sitenizi sıfırdan nasıl oluşturacağınıza dair bir eğitimimiz var ve şu anda bir Headless 101 serisi içerik üzerinde çalışıyoruz. Ücretsiz bir Sandbox hesabına kaydolursanız, Atlas'ın sunduğu tüm araçlara sahip olabilirsiniz. Şimdi, Haus'un leoburnett.com projesi için neden Headless WordPress'i seçtiği hakkında daha fazla konuşmak için Steve'e ileteceğim.

STEVE SCAVO: Teşekkürler, Grace. Merhaba, ben Haus CTO'su Steve Scavo. Los Angeles, California'dan bir yaratıcı teknoloji stüdyosu ve ajansıyız. Bu konuşmanın başlığı uygun bir şekilde WordPress Geliştiricileri için Headless 101'dir. Ve açıkça söylüyorum, meslek olarak bir WordPress geliştiricisi değilim, ama bence bu, kafasız bir mimarinin güzelliğinin bir parçası.

Dolayısıyla, WordPress'ten yararlanması gereken WordPress olmayan geliştiriciler için bu Headless 101'i kolayca adlandırabilirdik. Bu da uygun bir başlık olabilirdi. Başsız olmanın güzel yanı da bu. Göreceğiniz gibi, her yönden bir kazan-kazan.

Peki neden kafasız? Bahsedebileceğimiz pek çok üst düzey neden var, ancak gerçek üretim örneklerinden ve parladığı zaman gerçek dünya örneklerinden bu tür konuşmanın gerçekten yardımcı olduğunu düşünüyorum. Leo Burnett için başsız bir mimari altında başsız kullanarak yaptığımız bir projeyi sergilemek istiyorum. Bağlam açısından, Leo Burnett, Chicago dışında ünlü bir reklam ajansıdır, ancak dünya çapında ve küresel olarak birçok ofisi vardır. Yani çok içerikleri, çok işleri var.

Eski site tek bir WordPress teması üzerinde çalışıyordu. Gerçekten parçalıydı, biraz yavaştı, iyi performans göstermedi. Güncellemesi zordu ve Leo Burnett'in iletmek istediği türden bir kaşe ve markalaşmayı pek sergilemedi. Tasarım perspektifinden çalışmaya başladığımız şey buydu. Ve yığınlarını gerçekten modernize etmek için başsızı seçtik.

Sadece canlı ve taze hissetmesini ve gerçekten harika bir kullanıcı deneyimi ve kullanıcı arayüzünü bir araya getirmek için ihtiyacımız olan bu tür bir yeteneğe sahip olmasını istedik. Yayın güçlerini artırmak istedik. İçerik yayınlayabilecekleri tempoyu artırmak istedik. Marka kimliğini yeniden oluşturmak ve bir kullanıcı arayüzüne ve bir etkileşime sahip olmak istedik, web sitesinde gerçekten Leo Burnett'i yayan his ve tüm bu küçük dokunuşlar ve iletmek istedikleri tüm bu küçük dokunuşlar ve bir tür editoryal, tipografik ve etkileşim noktaları.

Ve kod tabanını ve web sitesini geleceğe hazırlamak istedik. Biz sadece sitenin önümüzdeki 12 ay boyunca alakalı olmasını istemedik. Belki de önümüzdeki on yıl için alakalı olmasını istiyoruz. Ve bence bu başsız mimari, bu başsız yığın gerçekten de bunu yapıyor.

Headless ile ilgili ilk sorunlardan biri, barındırma, dağıtım ve altyapı ile ilgili her zaman birçok kararın olması ve bu her zaman büyük bir acı noktası olmuştur. Dolayısıyla bu yığın kararları her zaman geliştiriciye bırakılmıştır. Ve etrafı araştırıyorsunuz ve etraflıca düşünüyorsunuz, tamam, hangi üçüncü taraf, belki CI/CD uygulamasını kullanmanız gerekiyor? Bunu AWS'de barındıracak mıyız? Bunu nasıl yaparız? Hangi hizmetler? Ve sonra, bu tür potansiyel olarak – bu akış etrafında geçici çözümler uygularsınız.

Atlas ve WordPress Engine Atlas platformu bunu gerçekten çözüyor. İşte burada devreye giriyor. Tüm bu nedenlerden dolayı Atlas'ı seçtik ve bu yönetilen hizmet altyapısına sahipler. CI/CD boru hattını standartlaştırırlar. Bunun hakkında gerçekten düşünmene gerek yok.

Temelde tek bir tıklama akışına kadar olan ortamlar arasında veri geçişleri var. Bu, QA'dan aşamalandırmaya ve üretime geçişte tarihsel olarak her zaman büyük bir sorun olmuştur. Esasen WordPress Motoru ve Atlas platformu bunu tek bir tıklamaya indirdi.

Ve sonra mikro hizmetler ve DevOps ile ilgili bu yorgunluk var. Bir geliştirici olarak ne kadar düşünmeniz, desteklemeniz ve bunun farkında olmanız ve onu çalışır durumda tutmanız gerektiğine dair ağır bir bilişsel yük var. Bunların hepsi, Atlas platformunun gerçekten elinizden aldığı ve faydalı bir şekilde çözdüğü şeylerdir.

Headless'ın gerçekten teşvik ettiğini ve gerçekten vurguladığını düşündüğüm bazı dinamiklerden bahsedelim. Buradaki ilk sütun, üç tane var. İlk sütun, geliştirici deneyimidir. İş için doğru aracı seçmemizi sağlar. Biz derken geliştiricileri kastediyorum.

İçine kod yazmak istediğimiz bir yığın seçmemize izin verir. Ve bu bizim için Haus'ta, Next.js ve React'te. Next.js, yönlendirme, performans ve uygulama mimarisi için bazı gerçekten güzel kuralların etrafındaki harika bir çerçevedir. Ayrıca sadece görsel bir tasarım sistemi değil, kodlanmış bir tasarım sistemi olan bir tasarım sistemi uygulamak istedik. Bu, uygulamamızın tutarlı, test edilmiş ve güzel olmasını sağlayan bir şeydir.

Etkileşimler tutarlıdır. İleride de bu ekosisteme yeni sayfalar ve özellikler oluşturmamıza ve bunu sürdürmemize ve bu tutarlılığı korumamıza olanak tanır. Ayrıca bildirimsel ifade kodu yazmamıza izin verir ve React bunu bir kitaplık olarak onaylar. Ancak ekip olarak bu yazı stiline de inanıyoruz. Ön uçta bizim için o yığını seçmemize izin veriyor, oysa belki geleneksel bir tema tabanlı WordPress sitesi, gerçekten aynı lükse sahip değiliz.

Ayrıca çok fazla yaratıcı kafaya ihtiyacımız var. leoburnett.com'u ziyaret ettiğinizde çok güzel sayfa geçişleri olduğunu görebilirsiniz. Şeylerin nasıl işlenmesi gerektiği konusunda geleneksel WordPress yığınına bağlı değiliz. WordPress artık ön ucu oluşturmaktan sorumlu değil.

Boşluk payımız neredeyse sınırsızdır. Animasyon kütüphanelerimizi seçebiliriz. Bileşenlerimizin birbirleriyle etkileşim kurma şeklini seçebiliriz. DX tarafında büyük bir avantaj.

Yönetici deneyimi yükseltildi ve eski aşinalıklarından asla uzaklaşmadığımız için bunu optimize ettiğimizi düşünüyorum. Arka uç geçişi yok. WordPress'ten WordPress'e geçtik. Başka bir tescilli sisteme geçmek için verileri dışa aktarmamız ve bir tür komut dosyası yazmamız gerekmedi. Yani aşinalık çok büyük. Leoburnett.com'un mevcut yöneticileri için bu tür bir akışı sürdürmek istedik.

Benimseme ve belgeleme – Web'de beş dakika geçirirseniz, muhtemelen bir WordPress arka ucuna dokunmuşsunuzdur ve bu kesinlikle abartılamaz. Leo Burnett ayrıca birçok özel içerik noktasına ve özel alana sahiptir. WordPress bunu sunar ve size bu gücü verir, ancak yönetici kullanıcı arayüzünü gerçekten samimi ve kullanılabilir hale getirmek için ayarlama konusunda gerçekten güzel bir kural olan Gelişmiş Özel Alanlar eklentisini uygulayabildik. Bu, yönetici deneyiminde bir kazançtı.

Şimdi, elbette üçüncü sütun kullanıcı deneyimidir. Gerçekten önemli olan bu. Kullanıcılar, bence Haus'taki web uygulamalarının yerel uygulamalar gibi hissetmesi gerektiğine inandığımız gibi, hiçbir düşüş olmamalıdır. Bence kullanıcılar da bunu gerçekten takdir ediyor.

Onlar sorunsuz. Duyarlı. Sadece iyi hissediyorlar. Bence Leo Burnett'in ve tüm uygulamalarımızın böyle hissetmesini istedik. Ön uçta istediğimiz yığını seçebilmek bunu yapmamızı sağlıyor.

Yerel uygulamalar doğası gereği arka uç içerik altyapılarından ayrılmıştır ve web uygulamalarımız da öyledir. Atlas'ın teşvik ettiği de budur. Genel olarak başsız mimarinin teşvik ettiği şey budur. Aynı zamanda performansı da teşvik eder. Kullanıcı arayüzümüzü evrensel olarak oluşturabiliriz. Bu, ilk yükün sunucu tarafında olduğu anlamına gelir. Ondan sonra müşteri devralır.

Burada çok fazla fayda var. Birincisi, arama motorlarını mutlu etmesi. Bunlar sunucu tarafı içeriğidir. Hızlı. Ayrıca, bir sonraki sayfayı hemen hemen anında oluşturmamıza ve bu istekleri tek seferde görünüm alanında bulunanlara göre yapmamıza olanak tanır.

Leo Burnett için kullanmayı seçtiğimiz içerik API'si açısından bir GraphQL uç noktası oluşturduk. Bu, geri gelen daha zayıf yükler olduğu anlamına gelir. Tam olarak ihtiyacımız olan içeriği açıkça tanımlıyoruz. Bu sunucu tarafı oluşturma işleminden sonra, istemci tarafı oluşturma işlemine dönüştürüldükten sonra daha az hidrasyon vardır.

Bu, kablo üzerinden daha az kod gelmesi, daha az yanıt, daha hızlı yanıt süreleri demektir. Bu kesinlikle bir kazançtır ve eğer bir Atlas iş akışına veya kafasız bir iş akışına geçecekseniz, REST API gibi bir şey yerine GraphQL API'yi kullanmaya daha yakından bakmanızı öneririm.

Ve bir kullanıcının bakış açısıyla, taze ve zamanında içerik görüyorlar. Bu, içeriği önizlemek için optimize edilmiş bir yayınlama akışıdır. Hazırlama ve önizleme tarafında hızlı içerik getirme ve ardından bunu üretime teşvik etme için optimize edilmiştir. Leo Burnett'teki yöneticiler, içeriği güncellemenin bu kadar kolay olmasından son derece memnun ve bu da kullanıcıları mutlu ediyor.

Sonuç ne? Bu sadece her şeyi yuvarlamak için bir tür. Geliştiricilere, üretken yöneticilere ve mutlu kullanıcılara ilham kaynağı oldu. Bu, tüm web geliştirme ekiplerinin gerçekten çabaladığını düşündüğüm üçlü ve umut.

Geliştiriciler ilham aldıklarında optimize edilmiş bir araç seti kullanırlar. Sadece iyi hissettiriyor. Onlar mutlular. Daha iyi kod yazarlar.

Yöneticiler, güzel bir ekosistemde içerik ürettiklerini bilirler. Hızlı. Hızlı bir şekilde gönderilir. Ve kullanıcılar bu güncellenmiş içeriği görüyorlar ve modern, güzel, iyi işleyen, optimize edilmiş bir kullanıcı arabirimi deneyimliyorlar.

Tamamlamayı düşünüyorum - aklınızda tutmanızı isteyeceğim birkaç son düşünce. Özetin kendi başına her zaman eksik bir dil olduğunu düşünüyorum. Bence çok sık sadece hey, bana güzel bir web sitesi oluştur hakkında konuşuyoruz. Bana harika bir web sitesi oluşturun. Görünmesini ve hissedilmesini istiyorum ve tüm bu incelemeleri müşterilerle birlikte yürüttük.

Ve herkes heyecanlanır ve ardından V1 gelir ve piyasaya sürülür. Ve sonra o web sitesini devralması gereken insanlar, bana bir karmaşa verdin. Bununla nasıl ilgilenirim? Bu, tasarladığınız geçici bir akış mı?

Güzel bir web sitesi oluşturmak ve bir yükü teslim etmek istemezsiniz. Haus'ta bunu yapmamaktan büyük gurur duyuyoruz. Bence bir platform olarak Atlas ve Atlas'ın harika yanı bunu çözüyor olması.

Altyapı açısından ve kod dağıtımı açısından gerçekten mantıklı olan bir ekosistemi ve bir web yayınlama sistemini gönderdiğiniz konusunda size güven verir. BT ekibine, mühendislik ekibine veya pazarlama ekibine, ne yaptığınızı bildiğinize ve onlar için oluşturduğunuz bu yeni web sitesiyle artık emin ellerde olduklarına dair belgelenmiş kanıt sağlar.

Çünkü unutmayın, biz sadece bir web sitesi yapmıyoruz. Bir içerik yayınlama sistemi kuruyoruz ve bunu ilk günden itibaren anlamak ve kabul etmek çok önemlidir. Ve yine burada Atlas devreye giriyor.

Bu yüzden umarım bu küçük bilgi, başsız yığınınızın ileriye dönük olmasını stratejik olarak tasarlamanıza yardımcı olur. Eğer almak istediğin yön buysa, Atlas'a bir göz atmanı şiddetle tavsiye ederim. Umarım seanstan keyif almışsınızdır, çok teşekkür ederim.