JAMstack Temelleri: Ne, Ne ve Nasıl

Web'de sınırları zorlamayı seviyoruz ve bu nedenle yeni bir şey denemeye karar verdik. JavaScript, API'ler ve İşaretlemeye dayalı yeni web yığını olan JAMstack'i muhtemelen duymuşsunuzdur, ancak iş akışınız için ne anlama geliyor ve projelerinizde ne zaman anlamlı oluyor?

Smashing Üyeliğimizin bir parçası olarak, her hafta bir dizi canlı web semineri olan Smashing TV düzenliyoruz. Kabartmak yok - sadece sektörden saygın uygulayıcılar tarafından yürütülen canlı Soru-Cevap içeren pratik, eyleme geçirilebilir web seminerleri. Gerçekten de, Smashing TV programı şimdiden oldukça yoğun görünüyor ve Smashing Üyeleri için kayıtlarla birlikte ücretsiz - açıkçası .

Phil Hawksworth'tan JAMStack'in gerçekte ne anlama geldiğini ve ne zaman mantıklı olduğunu ve bunun takım ve ön uç mimarisini nasıl etkilediğini açıklayan bir web semineri düzenlemesini rica ettik. Bir saatlik web semineri de artık mevcut. Phil'i yaklaşmakta olan SmashingConf Toronto'muza (25-26 Haziran) ortak sunuculuk yapması ve bu yıl da 9-10 Temmuz'da ortaklaşa düzenlediğimiz JAMStack_conf London'ı yönetmesi için ağırlamaktan daha mutlu olamazdık. Öyleyse, içeri girelim!

Phil Hawksworth: Mükemmel, tamam, o zaman konuya girelim. Çok hızlı bir merhaba olarak, demek istediğim zaten merhaba dedim, Scott bana güzel bir giriş yaptı. Ama evet, şu anda Netlify'da çalışıyorum, orada geliştirici deneyimi ekibinde çalışıyorum. Soru-Cevap için bolca zamanımız olacağını umuyoruz, ancak Scott'ın da belirttiği gibi, orada soru sorma şansınız yoksa veya sadece isterseniz, doğrudan Twitter'da bana ping atabilirsiniz, bu yüzden Twitter hesabım benim adım, Phil Hawksworth, yani her zaman bana kesinlikle JAMstack veya Twitter'daki herhangi bir şey hakkında soru sorabilirsiniz.

Phil Hawksworth: Ama bugün, bende gerçekten çok ama çok güçlü yankı uyandıran bu alıntıya biraz zamanda geriye giderek başlamak istiyorum. Bu, Creative Commons'a ve açık ağa elbette çok fazla katkıda bulunan harika Aaron Schwartz'dan bir alıntı ve bunu 2002'de blogunda yazdı ve şöyle dedi: AOL sunucusu, Postgres ve Oracle kurulumları.” AOL sunucusu, o zamanlar açık kaynaklı bir web sunucusu olduğunu kendime hatırlatmak için aramak zorunda kaldım.

Phil Hawksworth: Ama bu bana çok güçlü geliyor. Ayrıca bir blogu canlı tutmak için altyapıyı sürdürmek istemiyorum ve bahsettiği şey de buydu. Ve kendi blogundaki bu blog yazısındaydı ve başlığı “Pişir, Kızartma”. Yakın zamanda bir CMS oluşturmuş birinin kullanmaya başladığı bir terimi seçiyordu ve pişirme ile ilgili bu terimi bir nevi popüler hale getirdi (Bake, Don't Fry); orada bahsettiği şey, talep üzerine işlemek yerine ön işlemedir, bu nedenle, insanlar gelip istediğinde talep üzerine kızartmak yerine içeriği önceden pişirmek - işleri talep süresinden uzaklaştırmak ve bir tür inşa süresine dönüştürmek.

Phil Hawksworth: Ön işleme ve işleme hakkında konuştuğumuzda, bununla kastettiğimiz şey, işaretleme oluşturmaktan bahsediyoruz. Bazen bir tür sunucu oluşturma veya eş biçimli oluşturma veya bu tür moda terimlerin birçoğu hakkında konuşurken kendimi biraz bilinçli hissediyorum; Birkaç yıl önce Amsterdam'daki Frontiers Konferansı'nda sunucuda görüntü oluşturma hakkında konuşurken çağrıldım ve biri bana "HTML üretmek mi demek istiyorsun? Sadece HTML çıktısı veren bir şey mi?” Ve tabii ki, demek istediğim bu.

Phil Hawksworth: Ancak tüm bunlar, yığını basitleştirmeye yönelik uzun bir yol kat ediyor. Web sitelerine hizmet verdiğimiz yığını düşündüğümüzde; Her şeyi basitleştirmeye çalışıyorum, yığını basitleştirmeye çalışmak konusunda çok hevesliyim. Ve bu, “JAMstack” denen şeyin özünde var ve ben bunu biraz denemek ve açıklamak istiyorum. JAMstack'teki "JAM", JavaScript, API'ler ve İşaretleme anlamına gelir. Ancak bu, gerçekten ne anlama geldiğini anlamamıza yardımcı olmak için yeterli değil - bu gerçekten ne anlama geliyor?

Phil Hawksworth: Pekala, önümüzdeki yarım saat içinde denemek ve yapmak istediğim şey, bu tanımı biraz genişletmek ve JAMstack'in ne olduğuna dair daha fazla açıklama vermek. JAMstack'in etkisi ve sonuçları hakkında biraz konuşmak istiyorum ve bilirsiniz, neden seçebileceğimiz konusunda bize neler verebileceğini düşünün. Bu arada, yararlı olacak bazı araçlardan ve hizmetlerden bahsetmeye çalışacağım ve umarım, araştırmak isteyebileceğiniz bazı kaynakları tamamlayacağım ve belki de sizi elde etmek için bazı ilk adımlardan bahsedeceğim. yolda.

Phil Hawksworth: Yani, önümüzdeki yarım saat için plan bu. Ancak, yığını basitleştirme hakkındaki bu fikre geri dönmek istiyorum, çünkü umarım, buna katılan veya bu videoyu daha sonra izlemeye gelen insanlar, belki JAMstack'in ne olduğu hakkında bir fikriniz vardır veya belki de tamamen yeni bir terimdir ve siz sadece merak ediyorsunuzdur. Ama nihayetinde, zaten orada bir sürü yığın var. Bir web sitesini teslim etmenin birçok yolu vardır. LAMP yığını veya MAMP yığını veya - bilmiyorum - ORTALAMA yığını olsun, gerçekten uzun bir süredir farklı türde altyapılar inşa ediyormuşuz gibi geliyor. Burada ekranda yüzen bir grup var. Onlardan çok var.

Phil Hawksworth: Öyleyse neden başka birine ihtiyacımız olsun ki? Pekala, JAMstack, bahsettiğim gibi, JavaScript/API/Markup'tır, ancak biraz daha açıklayıcı olmaya çalışırsak, JAMstack'in JavaScript/ ile hızlı ve güvenli siteler ve dinamik uygulamalar oluşturmaya yardımcı olmak için modern bir mimari olması amaçlanmıştır. API'ler ve önceden oluşturulmuş işaretleme, web sunucuları olmadan sunulur ve işte bu son nokta, onu diğerlerinden ayıran ve belki de onu biraz daha, biraz daha ilginç ve sıradışı yapan şeydir.

Phil Hawksworth: Web sunucuları olmadan bir şeye hizmet etme fikri, kulağa büyülü ya da saçma geliyor ve umarım, yol boyunca neyin ne olduğunu anlayacağız. Ancak buna biraz ışık tutmak ve biraz daha ayrıntılı olarak açıklamak için, bazen onu geleneksel bir yığın olarak düşündüğümüz şeyle veya web'de bir şeyleri sunmanın geleneksel bir yolu ile karşılaştırmak faydalı olabilir. Öyleyse, bunu bir saniyeliğine yapalım. Belki de, geleneksel bir yığında hizmet verildiğinde bir isteğin nasıl görünebileceğini gözden geçirelim.

Phil Hawksworth: Bu senaryoda, bir web tarayıcısı açan ve bir sayfayı görmek için istekte bulunan biri var. Ve belki bu istek bir CDN'ye ulaşır, ancak muhtemelen, daha büyük olasılıkla, bu sitenin sahibi olan kişiler olarak, barındırdığımız başka bir altyapıya isabet eder. Belki de bunun çok fazla yük altında ölçekleneceğinden emin olmaya çalıştık çünkü açıkçası çok popüler ve başarılı bir manzara istiyoruz. Bu nedenle, belki de içinde biraz mantığı olan bir yük dengeleyicimiz var, bu istek, sağladığımız, yapılandırdığımız ve dağıttığımız bir dizi web sunucusundan birine hizmet edecek. Bu sunuculardan birkaçı olabilir.

Phil Hawksworth: Ve bu sunucular, "Tamam, işte şablonumuz, bunu bazı verilerle doldurmamız gerekiyor" diyerek bir mantık yürütecekler. Verilerimizi, bazı verileri aramak için bazı mantık yürütecek, bunu web sunucusuna döndürecek, ardından yük dengeleyiciden geri geçireceğimiz bir görünüm oluşturacak bir dizi veritabanı sunucusundan birinden alabiliriz. Belki de yol boyunca, CDN'yi aramak, CDN'de bazı varlıkları saklamak ve açıklığa kavuşturmalıyım, bir CDN bir İçerik Dağıtım Ağıdır, bu nedenle, istek hizmetini mümkün olduğunca yakın bir şekilde denemek ve almak için İnternet'te dağıtılan bir makine ağı. kullanıcıya ve önbelleğe alma gibi şeyler ekleyin.

Phil Hawksworth: Yani, orada bazı varlıkları saklayabiliriz ve nihayetinde tarayıcıya, daha sonra oluşturduğumuz siteyi deneyimleyen kullanıcının gözbebeklerine bir görünüm getirebiliriz. Açıkçası, bu ya aşırı basitleştirme ya da geleneksel bir yığında bir isteğe nasıl hizmet edebileceğimize dair çok genel bir bakış. Bunu, bazı şeylere biraz farklı bir şekilde hizmet veren JAMstack ile karşılaştırırsak, böyle görünebilir.

Phil Hawksworth: Yine aynı senaryo, bir web tarayıcısında başlıyoruz. Sayfanın görüntülenmesi için bir istekte bulunuyoruz ve o sayfa zaten bir CDN'de. Oradan statik olarak hizmet verir, bu yüzden kullanıcıya, tarayıcıya döndürülür ve işimiz biter. Yani, açıkçası, çok basitleştirilmiş bir görünüm, ancak hemen, buradaki farklılıkları karmaşıklık açısından görmeye başlayabilirsiniz. Kodu yönetmemiz gereken yerler açısından, derinlemesine kod, tüm bu farklı şeyler. Bu nedenle, benim için, bir JAMstack'in temel özelliklerinden biri, doğrudan bir CDN'den veya hatta statik bir dosya sunucusundan sunulabilen bir site oluşturduğunuz anlamına gelir. CDN, yükü işlemek için yerine koymak isteyebileceğimiz bir şeydir, ancak nihayetinde bu, herhangi bir statik dosya sunucusundan, bir tür statik barındırma altyapısından doğrudan sunulabilir.

Phil Hawksworth: JAMstack, karmaşıklığı azaltmak için bir çeşit fırsat sunuyor. Sadece diyagramın birkaç kez geri döneceğimiz bu iki bölümünü önümüzdeki yarım saat boyunca karşılaştırarak, bunun karmaşıklığı azaltmak ve riski azaltmak için bir fırsat olduğunu görebilirsiniz. Bu, statik varlıklar sunmanın bazı avantajlarından yararlanmaya başlayabileceğimiz anlamına geliyor ve bunların ne olduğu hakkında biraz sonra konuşacağım. Ancak buna bakıyor ve “Eh, harika, ama bu sadece statik web sitelerinin yeni adı değil mi?” Diye düşünüyor olabilirsiniz. “Her şeye statik olarak hizmet edeceğiz” derken, bu bana seviye atlamak için makul bir şey.

Phil Hawksworth: Ama buna geri dönmek istiyorum. Bunun hakkında biraz daha konuşmak istiyorum, ama her şeyden önce, bu yığın kavramı hakkında biraz konuşmak istiyorum ve her neyse, yığın nedir? Ve bir yığını, web sitenizi veya uygulamanızı sunan teknoloji katmanları olarak düşünüyorum. Ve inşa hattından veya geliştirme sürecinden bahsetmiyoruz, ancak kesinlikle sitelere hizmet etme şeklimiz, geliştirme şeklimiz ve şeyleri nasıl dağıttığımız vb. üzerinde büyük bir etkiye sahip olabilir.

Phil Hawksworth: Ama burada, aslında web sitenizi ve uygulamanızı kullanıcılara sunan teknoloji yığınından, teknoloji katmanlarından bahsediyoruz. O halde küçük bir karşılaştırma daha yapalım. Bir saniyeliğine LAMP yığınından bahsedelim.

Phil Hawksworth: LAMP yığını, hatırlarsınız, HCP yönlendirmesi ve statik varlıkların sunulması gibi şeyler yapmak için bir apache web sunucusundan oluşur. PHP, bazı ön işlemeler için, çok güzel hiper metin işleme; mantığı uygulamak, belki şablonlar için görünümler oluşturmak ve elinizde ne var. Ve benim NISQL'im sayesinde verilerinize bir miktar erişimi var ve ardından LINUX, tüm bunların altında yer alan işletim sistemidir, nefes almasını sağlar. Bunu kavramsal olarak bu web sunucusu olarak bir araya getirebiliriz. Ve bir web sitesine hizmet etmek için birlikte oturan bu sunucuların birçoğuna sahip olabiliriz.

Phil Hawksworth: Bu, LAMP yığınına bir tür geleneksel bakış ve bunu JAMstack ile karşılaştırırsak, burada kritik bir değişiklik var. Burada, işletim sistemini düşünmek ve bir web sitesi sunmak için mantığı nasıl çalıştırdığımızı düşünmek yerine aslında bir üst seviyeye çıkıyoruz. Burada, bu şeylere statik olarak hizmet edeceğimize dair bir varsayımda bulunuyoruz. Böylece, ACP yönlendirmesini ve varlıkların statik bir sunucudan sunulmasını yapıyoruz. Bu makul bir şekilde yapılabilir. Yıllar içinde statik web siteleri veya statik varlıklar sunmanın yollarını geliştirerek bu konuda çok iyi olduk.

Phil Hawksworth: Bu bir CDN olabilir ve birazdan bunun hakkında konuşacağız. Ama bizim için ilgi alanı, tarayıcıda daha çok oluyor. İşte, işaretlememizin teslim edildiği ve ayrıştırıldığı yer burasıdır. JavaScript'in yürütülebileceği yer burasıdır ve bu, tarayıcıda gerçekleşir. Tarayıcı birçok yönden modern web'in çalışma zamanı haline geldi. Sunucu altyapısında çalışma zamanına sahip olmak yerine, şimdi bunu bir seviye yukarı, kullanıcıya daha yakın ve tarayıcıya taşıdık.

Phil Hawksworth: Verilere erişim söz konusu olduğunda, bu muhtemelen harici API'ler aracılığıyla oluyor, JavaScript'ler aracılığıyla bu harici API'lere sunucu erişimi sağlamak için çağrılar yapıyor veya API'leri tarayıcı API'leri olarak düşünebiliriz, JavaScript ile etkileşim kurabiliyoruz. tam orada tarayıcınızda yeteneklerle.

Phil Hawksworth: Her iki durumda da, burada JAMstack ile ilgili anahtar şu ki, önceden oluşturulmuş şeylerden bahsediyoruz: statik olarak sunulurlar ve ardından tarayıcı API'lerini, JavaScript'leri kullanmak için tarayıcıda aşamalı olarak geliştirilebilirler. , ve sende ne var.

Phil Hawksworth: Öyleyse, burada bu küçük yan yana karşılaştırmayı yapalım. Yine, JAMstack'in tarayıcıda bir seviye yukarı çıktığını tekrarlamak istiyorum. Ve bu diyagramın iki tarafını, solda LAMP yığını ve etkin bir şekilde, JAMstack sağda olacak şekilde görürsek, LAMP yığını ile bir şeyler inşa ederken bile, hala düşünebilirsiniz. işaretleme çıktısı. Hala JavaScript çıktısı alıyoruz. Hala API'lere erişiyor olabiliriz. Bu nedenle, birçok yönden JAMstack, daha önce inşa ettiğimiz şeyin bir alt kümesi gibidir.

Phil Hawksworth: Bazen JAMstack'ten garantili yığın olarak bahsederdim, çünkü bir siteyi sunmak için ihtiyaç duyduğumuz bir dizi araç ve teknolojiyi garanti eder. Ancak, her iki durumda da, istek zamanında sunucuda mantık yürütme ve gerçekleştirme ihtiyacını ortadan kaldıran bir site sunmanın çok basitleştirilmiş bir yoludur.

Phil Hawksworth: Yani, bu pek çok şey yapabilir. Bu, dağıtımları bir nevi basitleştirebilir ve tekrar zaman zaman bu şemaya geri döneceğim. Kodumuzu ve sitemizi nasıl dağıttığımızı düşünürsek, ilk dağıtımdan tüm geliştirme yaşam döngüsü boyunca, web sitesinin ömrü boyunca her dağıtım için. Geleneksel yığında, o diyagramdaki her kutunun mantığını ve içeriğini değiştirmek zorunda kalabiliriz.

Phil Hawksworth: Oysa JAMstack'te konuşlandırma hakkında konuşurken, CDN'ye bir şeyler almaktan, statik sunucuya bir şeyler almaktan bahsediyoruz ve konuşlandırmanın gerektirdiği şey bu. Derleme, yapıyı çalıştıran türden bir mantık — her yerde çalışabilir. Bunun, web sunucusunu barındıran aynı ortamda çalışması gerekmez. Aslında, değil! JAMstack'in anahtarını başlatır. Ayrımı, bu statik varlıklara hizmet eden istek zamanında gerçekleşenler ile derleme zamanında gerçekleşenler arasında ayırıyoruz; bu, derlemek için çalıştırdığınız mantığınız olabilir ve ardından dağıtıma gelebilir.

Phil Hawksworth: Yani, bu tür bir ayrıştırma kilit bir şey ve buna daha sonra geri döneceğim. Statik dosyalar sunmakta çok iyiyiz ve bir CDN'ye bir şeyler almak veya dosya sistemine (dosya sunucusu) bir şeyler almak, son birkaç yılda büyük, bir tür ilerleme gördüğümüz bir yer. Şimdi, bunu gerçekten iyi yapmamıza yardımcı olabilecek birçok araç ve süreç var. Statik varlıklara iyi hizmet edebilecek ve yapınızı bu ortama taşımak için iş akışları sağlayabilecek birkaç hizmeti çağırmak gerekirse, bunlar Azure, AWS ve Google Cloud gibi büyük bulut altyapı sağlayıcılarını hayal edebileceğiniz olağan şüphelilerdir.

Phil Hawksworth: Ama sonra başkaları da var. Sağdaki en üstte, birkaç yıldır var olan Surge adlı bir hizmet var. Yapı ortamınızda bir komut çalıştırmanıza ve varlıklarınızı barındırma ortamlarına dağıtmanıza olanak tanır. Netlify, bir sonraki, çalıştığım yer ve hemen hemen aynı şeyi yapıyoruz ama farklı otomasyonlarımız da var. Başka bir zaman girebilirim. Ve en alttaki, Now adlı başka bir statik barındırma ortamı sitesi.

Phil Hawksworth: Yani, bunu yapmak için bir sürü farklı seçenek var ve tüm bu alanlar CDN'ye mümkün olduğunca çabuk ulaşmak için farklı araçlar sağlıyor. Sitelerinizi elimizden gelen en sorunsuz şekilde dağıtmak. Ve hepsinin bir şeyi yerel olarak yürütme ilkesine dayandırdıkları ortak bir yanı var. Sık sık statik bir site oluşturucuyu, onu çalıştırdığımızda içerik ve şablonlar gibi şeyleri ve belki de farklı hizmetlerden gelen verileri alan ve statik olarak sunulabilecek bir şey veren bir yapı içinde çalıştırabileceğimiz bir şey olarak düşünürüm.

Phil Hawksworth: Bunu yerel olarak statik sunucumuzda önizleyebiliriz. Herhangi bir yerel geliştirme ortamında yapılması biraz basit olan bir şey ve daha sonra bunu dağıtma süreci, bunu barındırma ortamına ve ideal olarak bir tür ölçek elde etmek için bir CDN'ye ulaştırıyor. Dolayısıyla, bu tür bir temel oluşturulduğunda, JAMstack siteleri söz konusu olduğunda yaygın bir yanlış anlamadan biraz bahsetmek istiyorum. Ve bunu JAMstack sitelerini JavaScript, API'ler ve İşaretleme olarak tanımlayarak açarak kendime hiçbir iyilik yapmadım. Çünkü yaygın bir yanlış anlama, her JAMstack sitesinin JavaScript ve API'ler ve İşaretleme olması gerektiğidir, ancak gözden kaçırdığımız bu tür bir şey, üçünü de kullanmak zorunda olmadığımızdır - bunların her biri, bir tür , isteğe bağlı. Bunlardan istediğimiz kadarını veya azını kullanabiliriz. Aynı şekilde, bir LAMP yığın sitesinin mutlaka bir veri tabanına ulaşması gerekmeyebilir. Şimdi, geçmişte bir Linux makinesinde bir apache sunucusu tarafından sunulan şeyler inşa ettim ve PHP kullanıyorum, ancak bir veritabanına vurmadım ve bir yığını yeniden adlandırmaya başlamazdım. bunun için mutlaka.

Phil Hawksworth: Yani, bir JAMstack sitesinin ne olduğunu düşünürsek, bir sürü farklı şey olabilir. Bu, JavaScript içermeyen, API'leri hiç etkilemeyen bir site oluşturmak için YAML dosyalarından içerik çeken Jekyll gibi statik bir site oluşturucu ile oluşturulmuş bir şey olabilir ve biz bunu GitHub Sayfaları gibi bir şey üzerinde sunarız. Veya bu bir JAMstack sitesi olurdu. Veya belki de Gatsby gibi bir statik site oluşturucu kullanıyoruz, bu daha çok Jekyll için bir Ruby ortamında, şimdi bu, React ekosisteminde yerleşik bir JavaScript statik site oluşturucudur.

Phil Hawksworth: Bu yine içerik çekiyor olabilir ve Markdown dosyalarını düzenliyor. API'lere, GraphQL'nin API'lerine yapılan çağrılarla bunu zenginleştiriyor olabilir. Tarayıcıda şablonları doldurmak için JavaScript hidrasyonu yapmak gibi şeyler yapıyor olabilir. Ve Amazon S3'te sunulabilir. Bu bir JAMStack sitesi mi? Evet kesinlikle!

Phil Hawksworth: Go ile oluşturulmuş farklı bir statik site oluşturucu olan Hugo'ya geçiyoruz! Yine, JavaScript kullanarak tarayıcıya etkileşimler ekleyerek, Markdown dosyalarındaki içeriği organize ediyor olabiliriz. Belki herhangi bir harici API çağırmamak ve belki de bunu Google Cloud'da barındırmak. JAMstack mı? Kesinlikle! Görüyorsun, burada bir tema inşa ediyorum. Artık View ekosisteminde yerleşik olan başka bir statik site oluşturucu olan Nuxt gibi bir şey kullanmak. Belki bu, farklı bitişik dosyalardan içerik çekiyordur? Yine, tarayıcıda JavaScript etkileşimlerini kullanıyor olabiliriz, belki de e-Ticaret gibi şeyler yapmak için API'leri çağırıyor, ona başka bir statik site sunuyor olabiliriz. Netlify gibi başka bir barındırma altyapısı, bir JAMstack mı? Evet öyle!

Phil Hawksworth: Ama biz de gidebiliriz, bilirsiniz, ölçeğin bu tarafına da gidebiliriz. Ve zanaatkarlıkla oluşturduğumuz, elle haddelenmiş, JavaScript'i kendimiz oluşturduğumuz, el yapımı, ilerici bir web uygulamasını düşünün. Webpack ile paketliyoruz. JavaScript web belirteçlerini kullanıyor ve kimlik doğrulaması yapmak için API'leri çağırıyor, farklı tarayıcı API'leriyle etkileşim kuruyor, Azure'da barındırıyor olabiliriz. Evet, bu da JAMstack!

Phil Hawksworth: Biliyorsunuz, tüm bunlar ve daha pek çok şey JAMstack olarak kabul edilebilir, çünkü hepsinin ortak bir özelliği vardır ve bu, hiçbirinin bir Origin sunucusuyla sunulmadığıdır. Hiçbirinin istek zamanında mantık yürüten bir sunucuya çarpması gerekmez. Bunlar statik varlıklar olarak sunulur ve daha sonra JavaScript ve API çağrıları ile zenginleştirilir.

Phil Hawksworth: Yine, bir JAMstack'in doğrudan CDN'den sunulabileceği anlamına geldiğini yinelemek istiyorum. Bu yüzden, sadece bunun bazı etkilerinden ve çıkarımlarından bahsetmek istiyorum, çünkü bunu neden yapmak isteyelim ki? İlk fikir güvenlikle ilgili ve burada saldırı için büyük ölçüde azaltılmış bir yüzey alanımız var. (Bu eski şemaya tekrar dönersek), bir saldırı ile uğraşmamız gerekebilecek yerleri düşünürsek, yük dengeleyici, web sunucuları, veritabanı sunucuları gibi şeyleri güvence altına almamız gerekir. Tüm bunların, herhangi bir saldırının ve aslında CDN'nin nüfuz edemeyeceğinden emin olmalıyız.

Phil Hawksworth: Bu yapbozdan ne kadar çok parça çıkarırsak, o kadar az saldırıya uğrayabilir ve o kadar az yeri güvence altına almamız gerekir. Saldırmak için az sayıda hareketli parçaya sahip olmak gerçekten çok değerlidir. Netlify'da, kendi CDN'lerimizi işletiyoruz, bu nedenle karşılaştığı trafiği izleyebilme lüksüne sahibiz ve Netlify'da barındırılan tüm siteler, hayal edebileceğiniz tüm JAMstack siteleri, hiçbiri tamamen ayrılmış olduğu için üzerlerinde bir WordPress yönetici sayfası var. WordPress yöneticisi yok, ancak WP Admin gibi şeyleri araştıran, giriş yollarını arayan, saldırı vektörleri arayan çok büyük bir trafik hacmi görüyoruz.

Phil Hawksworth: Kent C. Dodds'un yaptığı bazı şeyleri gerçekten çok seviyorum. React topluluğuna aşina mısınız bilmiyorum, muhtemelen geçmişte Kent C. Dodds ile karşılaşmışsınızdır. WordPress kullanmıyor, ancak yine de bu URL'yi, WPAdmin'i yönlendiriyor. Sanırım bunu YouTube'daki bir Rick Roll videosuna yönlendiriyordu. Bunu araştırmaya giden insanları kesinlikle trolliyor. Ama mesele şu ki, olayları bu şekilde ayırarak ve bir nevi, olan şeyleri hareket ettirerek, istek zamanında olanlardan zaman inşa ederek, maruz kalmamızı büyük ölçüde azaltabiliriz. İstek zamanında hareketli parçamız yok. Hareketli parçaların tümü, yapım zamanında tamamen ayrılmıştır. Potansiyel olarak, tamamen, iyi, mutlaka tamamen farklı bir altyapı üzerinde.

Phil Hawksworth: Bunun elbette performans üzerinde de etkisi var. Buradaki eski arkadaşımıza geri dönersek, bu farklı yerlerde yürütülmesi gereken mantık olduğunda, buradaki yığın boyunca performansı denemek ve geliştirmek isteyebileceğimiz yerler. Bunun geleneksel yığınlarda sıklıkla meydana gelme şekli, performansı artırmak için katmanlar eklemeye, statik katmanlar eklemeye başlamalarıdır. Yani, başka bir deyişle, statikmiş gibi davranmaya başlamanın yollarını bulmaya çalışın. İşleri hızlandırmak için yığının her seviyesinde bu mantığı uygulamak zorunda değilsiniz. Bu nedenle, tüm altyapıyı önbelleğe alma ve web sunucusunda yapabileceğimiz bariz yerleri önbelleğe alma gibi şeyleri tanıtmaya başlıyoruz, bu mantığı yerine getirmek yerine, bu mantığı gerçekleştirmeden hemen bir şeye hizmet etmek istiyoruz.

Phil Hawksworth: Yani, sözde statik olmaya doğru bir adım gibi. Aynı şekilde veritabanı sunucularında da cache-com sorgularına önbelleğe alma katmanları eklemek istiyoruz. Düşük bakiyede bile, tüm CDN'yi bir önbellek olarak düşünebilirsiniz. Ancak geleneksel yığında, bu önbelleği nasıl yöneteceğimizi bulmamız gerekiyor çünkü her şey önbelleğe alınmayacak. Yani, hakkında bir mantık olacak. Neyin önbelleğe alınabileceğine karşı dinamik olarak doldurulması gerekenler. Ve JAMstack modelinde her şey önbelleğe alınır. Dağıtımın yapıldığı andan itibaren her şey önbelleğe alınır, böylece tamamen farklı düşünebiliriz.

Phil Hawksworth: O zaman bu, bir nevi ölçeklendirmeye de işaret etmeye başlıyor. Ve ölçeğe göre, bahsettiğim şey, büyük bir trafik yüküyle nasıl başa çıkacağız? Geleneksel yığınlar, ölçeklendirmek için altyapı eklemeye başlayacak. Yani, evet, önbelleğe almak için. Geleneksel yığınımıza yerleştirmeye başlıyoruz. Bu yardımcı olacaktır - bir dereceye kadar. Genelde olan şey, büyük miktarda trafiğin üstesinden gelmek için altyapıyı genişletmeye ve bu istekleri yerine getirmek için daha fazla sunucu, daha fazla parça eklemeye başlayacağız, bu şeyleri maliyetlendiriyor ve yükü tahmin etmek büyük bir ek yük ve bu da olabilir. teknik mimari yapan herkes için baş ağrısı olabilir. Bu kesinlikle benim içindi, bu yüzden JAMstack yaklaşımını yapmaya daha fazla eğilmeye başladım, burada her şeyin varsayılan olarak ölçeği işlemek için tasarlanmış CDN'den, performansı hemen kapıdan çıkarmak için tasarlanmış olduğunu biliyorum. .

Phil Hawksworth: Ben de geliştirici deneyimine ve bunun orada yaratabileceği etkiye bir selam vermek istiyorum. Şimdi, geliştirici deneyimi hiçbir zaman kullanıcı deneyimini gölgede bırakan bir şey olarak görülmemelidir, ancak iyi bir geliştirici deneyiminin sürtünmeyi azaltabileceğine ve geliştiricilerin harika kullanıcı deneyimleri oluşturmak için çok daha iyi bir iş çıkarmasına izin verebileceğine inanıyorum!

Phil Hawksworth: Yani, geliştirici deneyiminin nerede yaşadığını ve bir geliştiricinin endişe duyduğu alanların burada nerede olduğunu düşündüğümüzde: geleneksel bir yığında, tüm bu farklı şeylerin kodunu nasıl elde edeceğimizi düşünmemiz gerekebilir. altyapının parçaları ve hepsinin birlikte nasıl oynadığı. JAMstack dünyasında, gerçekten, bahsettiğimiz şey burada, alttaki kutu. Bilirsiniz, derlemeyi ve onları nasıl çalıştırırız, ilk etapta bir şeyin sunulmasını sağlamak için bir dağıtımı nasıl otomatikleştiririz? İşin güzel yanı, JAMstack modelinde bu yapıda ne yapacağınız tamamen size kalmış.

Phil Hawksworth: Bu gerçekten iyi tanımlanmış bir problem alanı çünkü nihayetinde doğrudan bir CDN'den hizmet edebileceğiniz bir şey inşa etmeye çalışıyorsunuz. İstediğiniz araçları kullanarak bir şeyi önceden oluşturmak istiyorsunuz: Ruby veya Python veya JavaScript veya Go veya PHP'de yerleşik statik bir site oluşturucu olsun, bu seçimi yapma özgürlüğüne sahipsiniz. Ve böylece, bu çalışmanız için çok daha güzel bir ortam yaratabilir. Ayrıca, gerçek geliştirici güvenine sahip olmak için bir fırsat yaratır, çünkü JAMstack sitelerinin gerçek bir özelliği, değişmez ve atomik dağıtım olarak çok daha kolay sunulabilmeleridir.

Phil Hawksworth: Ve bunun ne anlama geldiğini açıklamak için slaytlardan bir an için uzaklaşmak istiyorum, çünkü değişmez bir dağıtım ve bir atomik dağıtım… (bu kulağa biraz pazarlama konuşması gibi gelebilir) ama ne yapacağım, tarayıcıma atlayacağım. Şimdi… aslında, bir saniyeliğine geri döneceğim. İzin ver... sadece şunu yap.

Phil Hawksworth: İşte geldik. Bu daha kolay olacak. Hemen sayfaya atlama. Şimdi Scott, bana söyleyeceksin Scott, eğer tarayıcımı göremiyorsan, umarım. Şimdi, herkesin tarayıcımı görebileceğini varsayarsak.

Scott: Her şey iyi görünüyor.

Phil Hawksworth: Mükemmel! Çok teşekkürler!

Phil Hawksworth: Yani burada yaptığım şey, hizmet örneği olarak Netlify'ı kullanmak. Ancak bu, statik olarak barındırılabilen sitelerde ortak olan bir özelliktir. Yani, değişmez bir dağıtımdan bahsettiğimizde, demek istediğimiz, her bir kod dağıtımının altyapının birçok farklı bölümüne dokunması ve birçok şeyi değiştirmesi gerektiğidir, burada sitenin durumunu değiştirmiyoruz. sunucu. Gerçekleşen her dağıtım için sitenin tamamen yeni bir örneğini oluşturuyoruz. Ve bunu yapabiliriz çünkü site bir statik varlıklar topluluğudur.

Phil Hawksworth: Burada, kendi web sitemden gerçekleşen dağıtıma bakıyorum. Sana bir ziyafet vereceğim. İşte böyle görünüyorsun. Bu sadece bir blog, özellikle dikkat çekici veya heyecan verici bir şeye benzemiyor. Bu statik olarak oluşturulmuş bir blog, ancak burada sahip olduğum şey, şimdiye kadar gerçekleşen her dağıtım, kalıcı olarak yaşıyor, çünkü bu bir CDN'den sunulan bir statik varlıklar topluluğu. Şimdi, geçmişimin beni götürebildiği kadar geriye gidebilir ve siteye tekrar bakabilirdim, eskisi gibi… bu ne zamandı? Bu, 2016 Ağustos'uydu. Ve bir dizi statik varlık olması nedeniyle, bunu sonsuza kadar yaşayan kendi URL'sinde barındırabiliyoruz ve istesem bile içeri girip yayınlamaya karar verebilirim. dağıtım.

Phil Hawksworth: Şimdi, web siteme bakan herhangi biri, buradaki web siteme geri dönersem, o sayfayı yenilersem, şimdi bu, daha önce orada olan varlıklarla birlikte doğrudan CDN'den sunuluyor. Şimdi tekrar dolaşabilirim. Burada görebilirsin. Bakın, bunun hakkında konuşuyordum, izomorfik oluşturma gibi bu korkunç terimleri kullanıyordum ve 2016'da JAMstack hakkında konuşuyordum. Yani, şimdi sitemde canlı olarak sunulan şey bu. Yine, çünkü sonsuza kadar yaşayan karşılıklı dağıtımlar var. Ben sadece kendiminkini, bir nevi gönül rahatlığımı koyacağım, gidiyorum - bu ilk sayfa mı? Evet. En son dağıtımıma geri döneceğim. Tekrar kapatıp gerçek dünyaya geri dönmem gerekecek. Bunun iyi olduğundan emin olayım.

Phil Hawksworth: Tamam! Harika! Öyleyse, şimdi bu, önceki sürümüme veya sitenin en son sürümüne hizmet etmeye geri döndü. Açılış konuşmasına geri döneceğim. Yani bu mümkün çünkü şeyler değişmez ve atomik. Bunun atomik kısmı, yine, konuşlandırmanın tamamen kapsandığı anlamına gelir. Bu nedenle, bazı varlıkların web sunucusunda mevcut olduğu noktayı asla anlayamazsınız, ancak bazıları olmayacaktır. Yalnızca her şey bağlam içinde olduğunda ve her şey orada olduğunda, eksiksiz olduğunda, sitenin sunumunu yeni sürüme geçiririz. Yine, bir şeyler doğrudan CDN'den bir grup varlık olarak hizmet veren bir JAMstack sitesi olarak inşa ediyorsanız, bu çok daha kolay yapabileceğiniz bir şeydir.

Phil Hawksworth: Açılış konuşmasından ileri geri gittikten sonra zamanlayıcımın sıfırlandığını fark ettim, bu yüzden sanırım altı ya da yedi dakikam kaldı. Söyle bana Scott, eğer...

Scott: Yani, evet, yaklaşık on dakika için hala iyiyiz.

Phil Hawksworth: On dakika mı? Tamam, harika!

Scott: Acele yok.

Phil Hawksworth: Teşekkürler, bu iyi olur!

Phil Hawksworth: Yani, biraz vites değiştirip API'ler ve hizmetlerden bahsederken (API'ler JAMstack'in bir parçası olduğundan), o zaman kullanabileceğimiz hizmet türleri çoğunlukla JAMstack'tir. Bilirsiniz, kendi bünyemizde oluşturduğumuz hizmetleri kullanıyor olabiliriz veya satın alınmış hizmetleri kullanıyor olabiliriz. Bizim için bir şeyler yapabilecek birçok farklı sağlayıcı var ve bu onların uzmanlıkları. API'ler aracılığıyla, içerik yönetim sistemlerinden bir hizmet olarak içerik çekiyor olabiliriz ve bunun için harika bir içerik yönetimi deneyimi sağlama ve ardından içeriği API aracılığıyla açığa çıkarma konusunda uzmanlaşmış bir sürü farklı sağlayıcı var, yani eskiden siz de öyleydiniz. onları içeri çekebilir.

Phil Hawksworth: Aynı şekilde, varlıkları sunmanın da farklı yolları var. Cloudary gibi kişiler, görüntü optimizasyonu yapmak, varlıkları yine API'ler aracılığıyla doğrudan sitelerinize sunmak için bu konuda harikadır. Peki ya e-Ticaret? Biliyorsunuz, Stripe veya Snipcart gibi bize API sağlayabilecek yerler var, böylece bu hizmetleri kendimiz oluşturmak zorunda kalmayalım ve bir e-Ticaret motoru oluşturmaya çalışırken ortaya çıkan çok karmaşık konulara girmeyelim. Aynı şekilde, kimlik, Oauth kullanan Auth0 gibi kişilerden. Kullanılabilir birçok hizmet vardır ve bunları, tarayıcıda veya derleme sırasında veya bazen her ikisinin bir kombinasyonunda API'ler aracılığıyla tüketebiliriz.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Hello everyone. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Doğru? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Gerçekten seviyorum, çünkü JAMstack terimi gerçekten yanıltıcı olabilir, çünkü pek çok farklı şeyi kapsamaya çalışıyor ve yapmaya çalıştığım nokta, muhtemelen o slaytta birçok kez dövdüm, her türden olabilir şeylerden. Çok geniş, ancak anahtar, sitelerin çekirdeğini statik olarak önceden oluşturmak ve barındırmaktır. Nerede bir React sitesi olması gerektiği konusunda din savaşlarına girmek bizim için çok kolay. JAMstack sitesi olmak için bir React uygulaması olmalı veya bir React uygulaması, yani JAMstack olamaz. Ancak, gerçekten, işin püf noktası, JavaScript kullansanız da kullanmasanız da, API'leri çağırsanız da aramasanız da, önceden oluşturup bir şeyleri çok performanslı olabilen statik bir ana bilgisayara alırsanız, JAMstack'in özü budur.

Vitaly: Evet, kesinlikle.

Phil Hawksworth: Tarayıcıların çok daha yetenekli hale gelmesinden dolayı çok şanslıyız ve tarayıcıların kendi içindeki API'ler de çok daha fazlasını yapmamıza izin verebilir. Yani, bu tür kapıları daha da açar, ancak bu, JAMstack sitesi olarak oluşturduğumuz her şeyin her şeyi kullanması gerektiği anlamına gelmez. Ne sunmaya çalıştığımıza bağlı olarak, bu şeyleri dağıtmak için birlikte oynadığımız araçları bu şekilde seçmeye başlamalıyız.

Vitaly: Kesinlikle. Burada Doran'ımız var. Doran, sanırım biliyorum, Doran. İçimde Doran'ı tanıdığıma dair bir his var. Şunu soruyor: "Sunucusuz yazılımın [duyulmuyor 00:44:36]'dan itibaren JAMstack ile sorunsuz entegrasyona yönelmesini bekliyor musunuz? JAM'de A olarak adlandırılan şey.

Phil Hawksworth: Bu harika bir soru, çünkü bence sunucusuz işlevler — JAMstack siteleriyle çok iyi gidiyorlar, çünkü birçok yönden, aslında, birisi bir keresinde bana JAMstack sitelerinin sunucusuz olup olmadığını sordu ve ben de kıvrandım. bu soru, çünkü sunucusuz çok yüklü bir terimdir. Ancak, birçok yönden, patlama oluyor çünkü tekrar tekrar, kaynak sunucu olmadığı hakkında konuşuyordum. Yönetebileceğiniz bir sunucu altyapısı yok. Aslında, bir keresinde “Web Sunucusuz” adlı bir blog yazısı yazmıştım çünkü dünyanın yeni bir moda terimine ihtiyacı var, değil mi?

Phil Hawksworth: Ve gerçekten, bunun bir anlamı vardı, evet, sunucular olmadan bir şeyler inşa ediyoruz. Bu sunucuları yönetmek zorunda kalmak istemiyoruz ve sunucusuz işlevler veya bir hizmet olarak işlevler, tam olarak buna uyuyor. Bu nedenle, istekte bulunmak istediğiniz bir API'ye ihtiyacınız olduğu durumlarda, bu isteği doğrudan tarayıcıdan yapmanızın gerçekten mantıklı olmadığı durumlarda. Bu nedenle, örneğin, bu istekte sırlarınız veya anahtarlarınız varsa, bu isteklerin - bu bilgilerin - istemcide ifşa edilmesini istemeyebilirsiniz. Ancak bu şeyleri kesinlikle proxy yapabiliriz ve tipik olarak, geleneksel olarak, o zaman yapmamız gereken bir sunucuyu döndürmek, etkin bir şekilde istekleri yerine getirmekten, ona güvenlik doğrulaması eklemekten ve bu istekleri iletmekten biraz daha fazlasını yapan bir altyapıya sahip olmaktır. , onları geri vekilleyerek.

Phil Hawksworth: Sunucusuz işlevler bunun için mükemmeldir. Bunun için kesinlikle idealler. Bu nedenle, bazen sunucusuz işlevleri veya bir hizmetin işlevlerini neredeyse bir kaçış kapısı gibi düşünürüm, burada yalnızca bir sunucuda biraz mantığa ihtiyaç duyarsınız, ancak tüm bir altyapı oluşturmak zorunda kalmazsınız. Ve bununla giderek daha fazlasını yapabilir ve bir hizmet olarak olgunlaşan işlevler için geliştirme iş akışları için geliştirme boru hatlarını belirleyebilirsiniz. JavaScript geliştiricilerinin bunları oluşturabilmesi için daha erişilebilir hale geliyor. Yani, evet, gerçekten bu iki şeyin çok güzel bir şekilde bir araya geldiğini düşünüyorum.

Vitaly: Pekala, bu çok kapsamlı bir cevap. Aslında, kısa süre önce Amazon'dan bir ön uç mühendisinin kullandıkları sunucusuz ve Lamda işlevleri hakkında konuştuğu bir konuşmaya katıldım - neredeyse gidiyordum. Her zaman Docker ve Kubernetes hakkında konuşuyordu ve tüm bu şeyler, Devox World, orada oturuyordum ve “Nasıl oldu da oraya geldi. Neler olduğunu anlamıyorum!” Neler olduğu hakkında hiçbir fikrim yoktu.

Phil Hawksworth: Aynen öyle, ama mesele şu ki, eskiden… Ben… O dünyadan hiçbirini anlamadığımı kabul ettim, ama bu tamamen farklı bir disiplin için olduğu için, hiç istemedim. . Ve bu disiplin hala çok önemli. Bilirsiniz, altyapı tasarlayan insanlar — bu hala çok önemli. Ama şimdi, cezbedildiğimi hissediyorum. Ön uç geliştirme geçmişine sahip biri olarak, bir JavaScript geliştiricisi olarak, o dünyada oynamak istemeye çok daha istekliyim, çünkü araçlar bir nevi bana daha yakın geliyor.

Phil Hawksworth: Eskiden alelacele yaptığım bir deneyden ziyade, bunlardan bazılarını kullanabilmem ve işleri güvenli bir şekilde teslim edebilmem çok daha olası. Bu yüzden, web geliştiricileri olarak daha güçlü hale geliyoruz, bu benim için heyecan verici.

Vitaly: Power Rangers gibi, ha?

Vitaly: Yine de sana sormak istediğim bir şey var ve bu aslında bir hafta önce tartıştığımız bir şeydi ama yine de gündeme getirmek istedim çünkü seansta bahsettiğin tek şey kavramdı. her bir dağıtımın bağımsız bir örneğine sahip olmak, ki bu gerçekten harika. Ancak soru şu ki, on binlerce sayfalık büyük bir göreviniz varsa, her seferinde her şeyi yeniden dağıtmak istemezsiniz. Yani, esasen, eğer varsa, mesela, şeylerin çoğunlukla statik tarafını kullanıyorsanız. Yani, bir süredir bu fikrimiz vardı ve bunun aslında geçen sefer gündeme getirdiğin bir şey olduğunu biliyorum. Atomik dağıtım fikri.

Vitaly: Size, kelimenin tam anlamıyla, kurulumun iki farklı anlık görüntüsünün arasında bir çeşit div hizmeti verildi. Yani, başlığı her yerde değiştirin derseniz, elbette her sayfanın yeniden konuşlandırılması gerekir. Ancak, diyelim ki atlıkarınca gibi, yalnızca 1000 sayfayı etkileyebilecek bir bileşeni değiştirirseniz, 15000 sayfayı yeniden dağıtmak mantıklı olacaktır. Ama sadece bu 1000. Peki, oraya gidebilir miyiz? Dışarıdaki sihirli bir fikir mi yoksa bu noktada oldukça somut bir şey mi?

Phil Hawksworth: Bence bu, muhtemelen, statik site oluşturucular için Kutsal Kase ve bu tür bir model çünkü kesinlikle üstesinden gelinmesi gereken en büyük engeli belirlediniz. Ya da çarptığınız en büyük tavan. Ve bu, on binlerce, yüz binlerce veya milyonlarca URL'ye sahip web siteleridir - yapının çok uzun olabileceği fikri. Bir kod değişikliğine bağlı olarak hangi URL'lerin değişeceğini tespit edebilmek zorlu bir iştir. Bu aşılmaz değil, ama büyük bir zorluk. Tüm sitenizde bağımlılık grafiğinin ne olduğunu anlamak ve ardından bunu akıllıca dağıtmak — bunu yapmak gerçekten zor.

Phil Hawksworth: Çünkü bahsettiğiniz gibi, bir bileşen değişikliğinin çok geniş kapsamlı etkileri olabilir ama siz — bunun nasıl işleyeceğini bilmek her zaman zordur. Bu nedenle, bir dizi statik site oluşturucu, bu zorluğun arkasına biraz ağırlık veren ve kısmi yenileme ve artımlı yapıları nasıl yaptıklarını anlamaya çalışan projeler var. Bunun çözülebileceği ihtimali beni çok heyecanlandırıyor, ancak şu anda kesinlikle büyük bir zorluk. Sitenizi mantıklı bir şekilde paylaşmaya çalışmak gibi şeyler yapmaya başlayabilir ve yine, taşıma sorununa benzer bir şey düşünebilirsiniz. Pekala, bildiğim bu bölüm, kullandığı bazı varlıklar veya orada yaşayan içerik türü açısından bağımsızdır, bu yüzden bunları ayrı ayrı dağıtabilirim.

Phil Hawksworth: Ama bu benim için ideal değil. Bu gerçekten mükemmel bir senaryo değil. Kavram kanıtı olarak biraz araştırdığım yaklaşımlardan biri, 404'leri akıllıca kullanmak gibi şeyleri nasıl yaptığınızı düşünmektir. Örneğin, çok büyük tabelalar için büyük bir kullanım örneği, belki haber siteleri, bir son dakika haberi olduğunda bir URL'ye ihtiyaç duyduklarında, onu oraya dağıtmak için ilk önce onlar olmalıdır. Orada bir URL almaları gerekiyor. BBC News gibi şeyler, haberin web sitesine geleceğini göreceksiniz ve daha sonra fazla mesai, kademeli olarak buna eklenecek, ancak oraya önce ulaşmak çok önemli. Yani, 10 dakika, 20 dakika süren bir yapıya sahip olmak, ne olursa olsun, bu bir sorun olabilir.

Phil Hawksworth: Ama eğer içerik soyutlanmışsa ve belki de eskiden bir API'den çağrılmışsa. Contentful veya Sanity gibi soyutlanmış içerik yönetim sistemlerinden veya bir demetinden bahsettim. İçerik API'si olan herhangi bir şey, bu içerik yapısında bir yapıyı tetikleyecek şekilde değişir ve çalıştırmayı sürdüreceğiz, ancak olabilecek diğer şey, bunun için URL'nizi yayınlarsanız ve ardından bu URL'yi yayınlarsanız. , yapı çalışmasa bile, biri bu URL'yi çalarsa, 404'ündeki ilk durak, "Anlamadık" demek yerine, aslında o API'ye doğrudan vurmaksa, diyebilirsiniz. , "Eh, derleme onu doldurmayı henüz bitirmedi, ancak bunu istemcide yapabilirim." Doğrudan API'ye gidebilir, onu alabilir, istemcide doldurabilirim.

Vitaly: Hmm, ilginç.

Phil Hawksworth: Yani, inşa devam ederken bile, bu şeyleri doldurmaya başlayabilirsiniz. Ve sonra, yapı bittiğinde, tabii ki 404'e ulaşmaz. Statik olarak çalışan o sayfaya ulaşırsınız. Yani, bununla başa çıkmak için teknikler ve stratejiler var, ama yine de, çok uzun, başıboş bir cevap, üzgünüm, ama benim sonucum, evet, bu bir meydan okuma. Parmaklar çarpıştı, daha iyi stratejiler elde edeceğiz.

Vitaly: Evet, bu harika. Merak ediyorum, bu noktada, gerçekten sadece içerik açısından performansın ne olduğunu değil, aynı zamanda performans açısından yapım hızı açısından ne olduğunu düşünmüyoruz. Bina dağıtımı gibi. Yani, bu aynı zamanda uzun zamandır aradığımız bir şey.

Vitaly: Sana sormak istediğim bir şey daha var. Yani, bu ilginç, bahsettiğiniz bu teknik gibi. Bunu nasıl öğrenirsiniz? Bu, insanların kendi bloglarında yayınlamaya meyilli olduğu bir şeydir, ya da bir tür vaka stüdyosu, JAMstack'in nasıl - şirketlerin boşaltma sırasında nasıl hareket ettiği veya taşınamadığı hakkında bir tür vaka stüdyosu alabileceğiniz merkezi bir havuz var mı? JAM yığını.

Phil Hawksworth: Yani, şu anda bu manzara biraz olgunlaşıyor. Demek istediğim, bu örneklerden bazıları, sanırım, çok şanslı bir pozisyondayım, bir yerde çalışıyorum, oyuncaklarla oynuyorum, onu kullanmanın ilginç yollarını buluyorum ve denemeye başlıyorum. onlarla. Yani, bu kavramların kanıtları, bir nevi, deneyebileceğim ve bu zorlukların üstesinden gelmeye çalıştığım şeyler. Ama daha önce de bahsettiğim gibi, New York'taki JAMstack konferansında gösterilen bir vaka çalışması ve kesinlikle bunun gibi olaylar, en iyi uygulamaların veya endüstri uygulamalarının ve endüstri yaklaşımlarının bu türden konuşulduğunu görmeye başlıyoruz. olayların. Ve kesinlikle, daha fazlasını görmek ve Smashing Magazines gibi yerlere girmek için daha fazla vaka çalışması üzerinde çalışmak istiyorum, böylece bu bilgiyi çok daha kolay paylaşabiliriz.

Phil Hawksworth: Bence, büyük şirketler ve kurumsal alan yavaş yavaş JAMstack'i farklı yerlerde, farklı şekillerde benimsiyor, ancak dünya hala oraya çıkmak için eğimli, bu yüzden düşünüyorum, bir şirket bunu benimsediği ve paylaştığı her zaman deneyim, hepimiz bundan öğreneceğiz. Ancak, özellikle bu tür zorlukların nasıl üstesinden gelindiği konusunda eğilebilmemiz için, bu vaka çalışmalarının daha fazla yayınlanmasını gerçekten istiyorum.

Vitaly: Pekala, öyleyse, belki de benden son soru, çünkü soru okumayı her zaman severim. Yani, JAMstack toprağı, eğer bir şeyi değiştirebilseydiniz, belki de konuşlandırmaların ötesinde umutsuzca görmek isteyeceğiniz bir şey vardır. Seni gerçekten çok mutlu edecek başka bir şey var mı? Bu senin günün olur mu? Bu ne olurdu? JAMstack için istek listenizde neler var?

Phil Hawksworth: Ne soru. Demek istediğim, artımlı yapılar hakkında konuşmasaydık, bu...

Vitali: Yaptık. Artık çok geç. Bu kart çoktan geçti. Başka bir şeye ihtiyacımız var.

Phil Hawksworth: Yani—

Vitaly: Demek istediğim, bir platformda olduğu gibi, arka platforma bakarsanız, çok heyecan verici şeyler oluyor. Houdini'miz var, web bileşenlerimiz geliyor ve her şey var, çünkü tüm doğru bileşenlerin tüm manzarasını değiştiriyor olabilirsiniz. Öte yandan, SS NGS ile tüm bu büyülü, süslü dünyaya sahibiz ve tabii ki, tek sayfalık uygulamalarımız da var. En çok ne için heyecanlısın?

Phil Hawksworth: Burada kafa yoracağım, çünkü olup biten çok fazla şey var, bu heyecan verici ve tarayıcıda kullanabileceğiniz pek çok yeni yetenek var. Beni gerçekten heyecanlandıran şey, insanların kendilerini kısıtlaması (gülüyor) ve dediğim gibi, sıkıcı cevaplar, ama daha geniş bir izleyici kitlesi hakkında düşünceli bir şekilde, kısıtlama ile yapılan harika infazları görmeyi seviyorum. Gerçekten çok eğlenceli ve en parlak yeni JavaScript kitaplığı veya yeni tarayıcı API'si ile derlemek, bilmiyorum, her gün umutsuzca ihtiyacımız olan tarayıcıda çizme ve koklama yetenekleri.

Phil Hawksworth: Ama pek çok yerde işe yarayacağını bildiğim şeyleri görmeyi gerçekten seviyorum. Gerçekten performans gösterecekler, var olan tarayıcılara sempati duyacaklar - sadece şık oyuncaklara sahip CEO'ların ve CTO'ların değil, aynı zamanda çok daha düşük güçlü cihazlara sahip insanların masalarında veya onlar' zorlu ağ koşulları ve bu tür şeyler var. Platforma sempati duyan ve daha geniş kitle için şefkatli bir şekilde sunulan ilginç deneyimler ve zengin deneyimler görmeyi seviyorum, çünkü web'in bizden, onun için bir şeyler inşa eden geliştiricilerden çok daha ileriye ulaştığını düşünüyorum. . Ve ilginç şeylerin daha fazla insana ulaşacak şekilde yapıldığını görünce heyecanlanıyorum.

Phil Hawksworth: Muhtemelen aradığınız cevap bu değildi—

Vitaly: Oh, bu güzel bir son. Çok teşekkür ederim. Hayır, bu mükemmel, gerçekten öyle. Pekala, her şeyin yolunda gittiğini hissettim! Bizimle olduğunuz için çok teşekkür ederiz! Scott'a dağıtıyorum!

Phil Hawksworth: Harika!

Vitaly: Ben sadece soru-cevap oynamak için buradayım. Çok teşekkür ederim, Phil! Hâlâ buradayım ama Scott, sahne artık senin! Belki Smashing TV'de sırada ne olduğunu bizimle paylaşabilirsin?

Scott: Yapacağım, ama önce Phil, karalama ve koklama API'sinin nasıl çalıştığını görmek için sabırsızlanıyorum. Kulağa çok ilginç geliyor. Ve Vitaly, JAMstackify zaten alındı.

Vitaly: (kederli) Alınmış mı?! Satın alabilir miyiz?

Scott: Hayır, var!

Vitaly: Pekala, artık çok geç. Ben her zaman gecikirim.

Phil Hawksworth: Bu kendi içinde heyecan verici.

Vitaly: Bu benim hayatımın hikayesi. Ben her zaman gecikirim.

Scott: Sırada üyeler geliyor, sanırım 13'ü Perşembe, eski babam Zach Leatherman, en iyi konuştuğu şey hakkında konuşuyor, ki bu yazı tipleri. Yani, Font Uygulamalarının Beş Y'sinden bahsediyor. Ve sonra, 19'unda yapacağımız, JavaScript ve CSS ile video düzenleme, Eva Faria ile de çok ilgileniyorum. Bu yüzden, ikisi için de bizi izlemeye devam edin.

Scott: Yani, bu yine önümüzdeki Perşembe, Zach Leatherman ile ve daha sonra 19'unda, JavaScript ve CSS'de video düzenleme hakkında konuşacak olan Eva ile. Bu notta Phil, artık seni göremiyorum, hala orada mısın?

Phil Hawksworth: Buradayım!

Scott: Bu notta, herkese çok teşekkür ederim! Ayrıca, Toronto bölgesine yakın biri var mı? Ya da Toronto'yu ziyaret etmek isteyen biri var mı? Haziran sonunda bir konferansımız var ve hala birkaç bilet kaldı. Yani, belki bazılarınızı orada görebiliriz.

Vitaly: Herkese çok teşekkür ederim!

Vitaly: Ah, bu arada, bir şey daha! Belki Phil bundan bahsetmiştir, ancak Temmuz'da Londra'da JAMstack Konferansımız da var. Yani, bu da dikkat edilmesi gereken bir şey. Ama ben çıkıyorum ve salatamı alacağım! Ne olduğundan emin değilim...

Scott: Tamam, hoşçakalın millet!

Vitaly: Pekala, herkese güle güle.

Bu Bir Sargı!

Sürekli ve nazik destekleri için Smashing Üyelerine yürekten teşekkür ediyoruz - ve gelecekte daha fazla web seminerine ev sahipliği yapmak için sabırsızlanıyoruz.

Ayrıca Phil gelecek hafta SmashingConf Toronto 2019'da ve JAMstack_conf'ta sunuculuk yapacak - sizi de orada görmek isteriz!

Lütfen bu röportaj dizisini faydalı bulursanız ve kimlerle röportaj yapmamızı istediğinizi veya hangi konuları ele almamızı istediğinizi bize bildirin, biz de hemen konuya girelim.