Chris Coyier ile Çarpıcı Podcast Bölüm 22: Sunucusuz Nedir?

Bugün Sunucusuz mimarilerden bahsediyoruz. Bu ne anlama geliyor ve şu anda site oluşturma şeklimizden ne farkı var? Öğrenmek için Chris Coyier ile konuştum.

Notları göster

• Chris'in mikro sitesi Ön Uç Geliştiriciler için Sunucusuz Gücün Gücü
• Twitter'da Chris
• ShopTalk Gösterisi podcast'i

Haftalık güncelleme

• “Gerçek Dünya Uygulamasında Kullanım İçin Redux Ayarlama”
  Jerry Navi tarafından
• “Beş Duyu İçin Bir Web Sitesi Tasarlayabilir misiniz?”
  Suzanne Scacca tarafından
• “Sapper ve Strapi ile Statik Bir Blog Oluşturma”
  tarafından Daniel Madalitso Phiri
• “React Uygulamalarında Ürün Turları İçin Pratik Bir Kılavuz”
  Blessing Krofegha tarafından
• “Sketch ile Porsche 911 Nasıl Oluşturulur”
  tarafından Nikola Lazareviç

Transcript

Drew McLellan: 10 yıldan uzun bir süre önce başlattığı ve web siteleri oluşturanlar için harika bir öğrenme kaynağı olan CSS-Tricks'ten tanıyabileceğiniz bir web tasarımcısı ve geliştiricisidir. Dünyanın her yerindeki öncüler tarafından yaptıklarını paylaşmak ve takip ettikleri kişilerden ilham almak için kullanılan tarayıcı tabanlı kodlama oyun alanı ve topluluğu CodePen'in kurucu ortağıdır. Dave Rupert'in yanı sıra tamamen web siteleri yapmakla ilgili bir podcast olan ShopTalk Show'un ortak sunucusu. Web geliştirme hakkında çok şey bildiğini biliyoruz, ancak bir keresinde sadece cazibesini kullanarak bir sosisli sandviç yeme yarışmasını kazandığını biliyor muydunuz? Ezici dostlarım, lütfen Chris Coyier'e hoş geldiniz. Merhaba Chris, nasılsın?

Chris Coyier: Hey, harikayım.

Drew: Bugün sizinle CodePen hakkında değil konuşmak istedim ve sizinle ille de CSS-Tricks hakkında konuşmak istemiyorum. Herhangi bir web geliştirici sorusuna yanıt ararken arama sonuçları. Yüzünüz açılır ve sizin veya konuk katkıda bulunanlardan birinin yazdığı faydalı bir blog yazısı vardır.

Chris: Oh, aslında bunu yapardım. Bir… Bilmiyorum, muhtemelen Google'ın o tuhaf sosyal ağa sahip olduğu zamanlardaydı. Neydi o? Google artı?

Drew: Oh, Artı, evet.

Chris: Evet, burada bir web sitesini bir Plus hesabıyla ilişkilendireceklerdi ve bu yüzden Plus hesabımın bir avatarı vardı ve avatar bendim, bu yüzden arama sonuçlarında görünecekti. Bence o günler geride kaldı. Bence eğer…

Drew: Sanırım, evet-

Chris: Evet.

Drew: Ama seninle biraz daha ilginizi çeken bir şey hakkında konuşmak istedim ve bu sunucusuz mimariler konsepti.

Chris: Mm (olumlu).

Drew: Bu, bir süredir hakkında daha fazla şey öğrendiğin bir şey. Bu doğru mu?

Chris: Evet, evet. Ben sadece bir hayranım. En azından biraz uzmanlığa sahip olduğumu hissettiğim ön uç geliştirme evrimine doğal bir uyum gibi görünüyor. Ben kendimi... ön uçta arka uçtan çok daha faydalı biri olarak görüyorum, öyle değil... Bütün bu günlerde bunu yapıyorum. Küçük bir Ruby koduna bakmaktan korkmayacak kadar uzun süredir buralardayım, orası kesin. Ama ben ön tarafı tercih ederim. Onu daha çok araştırdım. Bu seviyedeki projelere daha çok katıldım ve sonra “JavaScript becerilerinizi sunucuda kullanabilirsiniz” diyen bu küçük yeni paradigma geliyor ve bu ilginç. Biliyorsun? Ben böyle düşünüyorum. Bundan çok daha fazlası var, ama bu yüzden umurumda, çünkü ön uç geliştiricilerin JavaScript'i çok derinden kazdığını hissediyorum. Ve şimdi aynı beceri setini başka bir yerde kullanabiliriz. Çok güzel.

Drew: Yepyeni bir dünya açılmış gibi görünüyor, oysa sadece bir ön uç kodlayıcı olsaydınız… Bence, sadece bir ön uç kodlayıcı, yapmamalıyım. Bir ön uç kodlayıcıysanız ve arka uç uygulamasında size yardımcı olması için bir meslektaşınız veya bir arkadaşınızla çalışmaya alışkınsanız, aniden bu açılır. Ve tüm yığının daha fazlasını kendi başınıza yönetebileceğiniz bir şey.

Chris: Evet, evet. Bu kadar.

Drew: Odadaki file sesleniyor, en üstte. Sunucusuzdan bahsediyoruz ve açıkçası bir şeyleri adlandırmak zor. Hepimiz bunu biliyoruz. Sunucusuz mimari, sunucu olmadığı anlamına gelmez, değil mi?

Chris: Sanırım bu zorunlu, sanki bu onu duyduğunuz ilk podcastse ya da ilkinde… "sunucusuz" kelimesini yalnızca ilk düzinesinde duyuyorsunuz, bu zorunlu. içgüdüsel bir tepkiye sahip olun ve bu tür bir "Oh, ama hala sunucular var" deyin. Sorun yok. Bu şu anda size oluyorsa, bunu bilin, bu, bu işte gerekli bir adım. Tıpkı hayattaki diğer her şey gibi. Anlamanın aşamaları var. Bir şeyi ilk duyduğunda, onu biraz reddetmen gerekiyor ve sonra ancak bir düzine kadar kez ya da senin için değeri biraz kanıtlandıktan sonra, sonraki aşamalara geçebiliyor musun? burada anlamaktan. Ama kelime kazandı, yani hala “sunucusuz” kelimesine karşı savaşıyorsanız, trenin oradaki istasyonu terk ettiğini söylemekten nefret ediyorum. Söz zaten başarılı. Bunu kazanamayacaksın. Çok üzgünüm.

Chris: Ama bunun ilginç olduğunu düşünüyorum... gibi olmaya başlıyor, belki de bazen işin içinde sunucular yok. Sunucusuz bir konsept olarak kilitlenen şeylerden birinin AWS Lambda olduğunu düşünürdüm. Olay yerine ilk gelenlerdi. Bir lambda, AWS'ye verdiğiniz bir işlev gibidir ve onu büyülü gökyüzüne koyar ve sonra… bir URL'si vardır ve ona vurabilirsiniz ve bu işlevi çalıştırır ve isterseniz bir şey döndürür. Biliyorsun? Bu sadece HTTP ya da her neyse. Bu böyle çalışır, ki… bunu ilk duyduğunuzda, “Neden? umurumda değil.” Ama sonra, bunun için bazı bariz şeyler var. Başka kimsenin erişemediği API anahtarlarımı bilebilir. Bu nedenle, başlamak için arka uç kullanırsınız, istemci tarafında JavaScript'te olması gerekmeyen gizli şeyleri bilir. Yani bir veritabanıyla konuşması gerekiyorsa, bunu yapabilir. API anahtarlarını başka bir yerde açığa çıkarmak zorunda kalmadan bunu güvenli bir şekilde yapabilir. Veya bu verilerin nerede olduğu veya nasıl elde edildiği bile…

Chris: Yani bu oldukça havalı. Bir veritabanıyla konuşan, biraz veri alan, onu döndüren bir işlev yazabilirim. Serin. Lambda öyle ama AWS çalışıyor. Bir bölge seçmelisiniz. Sen, "Bilmiyorum. Nerede olmalı, Virginia? Oregon? Avustralya'yı seçmeli miyim? Bilmiyorum." 20, 30 tane var. Bugünlerde kaç tane olduklarını bile bilmiyorum ama lambdaların bile bölgeleri vardı. Sanırım bu günlerde Lambda@Edge var, bu da tüm bölgelerin olduğu anlamına geliyor, ki bu biraz havalı. Ama önceydiler ve şimdi herkesin Lambda gibi bir şeyi var. Tüm bulut hizmetleri. Bu dünyada bir çeşit hizmet istiyorlar. Bunlardan biri CloudFlare. CloudFlare'in çalışanları var. AWS'den çok daha fazla lokasyona sahipler, ancak bunu farklı bir zamanda da yürüttüler… bir CloudFlare çalışanı gibi… Node.js'yi çalıştırabileceğiniz bir lambda'ya benzer. JavaScript'i çalıştırabilirsiniz. Bir dizi başka dili de çalıştırabilirsiniz, ancak… Bunu büyük ölçüde düşünüyorum, en ilginç dil JavaScript'tir, çünkü yaygınlığı nedeniyle.

Chris: Bu sadece CDN düzeyinde oluyor, ki bu sanırım bir sunucu ama ben CDN'leri sunucu olarak düşünmeme eğilimindeyim. Açıkça başka bir şey gibi değil. Son zamanlarda daha da sunucusuz hissetmeye başladı. CDN bir sunucu mu? Demek istediğim, sanırım bir yerlerde bir bilgisayar, ama daha az sunucu-y gibi geliyor.

Drew: Evet, bir CDN bir sunucu olabilir gibi geliyor, ancak bir sunucunun en minimal versiyonu. İstersen ince bir sunucu gibi.

Chris: Evet. Emin.

Duru: Peki. Dediğini duydum… Ne yazık ki, kredi kaynağı olduğunu hatırlayamıyorum, ancak sunucusuzun “Uber veya Lyft gibi bir yolculuk paylaşım hizmeti kullanmak gibi” veya her neyse olarak tanımlandığını duydum. Arabasız olabilir ve araba sahibi olamazsınız, ancak bu asla araba kullanmadığınız anlamına gelmez.

Chris: Evet, bu arabaların olmadığı anlamına gelmez. Bu güzel.

Drew: İhtiyacın olduğunda sadece bir tane çağırıyorsun, ama aynı zamanda bir arabanın peşin satın alma maliyetini de ödemiyorsun. Bakım ya da yakıt ödemiyorsun ya da...

Chris: Doğru ve fiyatlandırma da mantıklı, değil mi? Bu iyi. Güzel bir benzetme bence. Ve sonra, CDN seviyesinde de olduğu için, sadece halihazırda gerçekleşmekte olan HTTP isteklerini yakalar, bu da ona sormadığınız anlamına gelir… ona bir istek göndermezsiniz ve bir istek geri gönderir. Sadece istek sırasında doğal olarak oluyor, bu da daha az server-y hissettiriyor. Bilmiyorum, ilginç. Kesinlikle ilginç. Yine de fiyatlandırma olayını gündeme getirmen çok önemli. Sadece kullandığınız kadar ödersiniz. Bu da önemli, çünkü… diyelim ki, tüm yaşamları boyunca sunucuları döndürmeye alışmış bir arka uç geliştiricisiniz. Ve maliyetleri üstleniyorlar, “Bu tür bir belleğe, bu tür CPU'ya ve bu tür özelliklere sahip bu tür bir sunucuya ihtiyacım var. Ve maliyeti bu kadar." Sunucusuz gelir ve bu fiyatlandırmanın başını keser.

Chris: Yani, bundan pek hoşlanmayan bir arka plan geliştiricisi olsanız bile, onlar sadece bununla ilgilenmezler, sanki yetenekleriniz yıllar içinde olduğu gibi, fiyatı karşılaştırırsınız. ve sen, "Ne? Daha önce ödediğimin %1'ini ödüyor olabilir miyim?" Bunu umursamama hakkın yok, değil mi? Hizmetleri için ödemeleri gerekenden yüz kat daha fazla ödeyen bu arka uç geliştirici iseniz, işinizde biraz kötüsünüz demektir. Söylediğim için üzgünüm. Bu ortaya çıktı ve bu, fiyatlandırmayı birçok yönden paramparça etti. Bununla ilgilenmelisin. Ve başka birinin olması biraz havalı… Güvenlik konusunda hiç endişelenmenize gerek yok, ama bu sizin sunucunuz değil. Sizin… lambda veya bulut işleviniz veya çalışanınız veya her neyse, kendi ağınızdaki gerçekten hassas verilerin hemen yanında bulunan bir sunucuda oturmuyor. Veritabanınızın hemen yanında değil.

Chris: Eğer biri bir şekilde kendini işçiden veya lambdadan ya da her neyse ondan çıkarmaya çalışan ve kendi yollarıyla başka şeylere erişmeye çalışan bir kod yazarsa, elde edilecek hiçbir şey yoktur. Dolayısıyla güvenlik de çok önemli, yani yine, sunucu yöneticisi olarak işiniz buysa, bu şeyin güvenliğiyle ilgilenmek. Çalıştırmak, Lambda'da bazı şeyleri çalıştırmak, ondan sadece biraz doğal güvenlik elde edersiniz, ki bu harika. Yani çok daha ucuz. Çok daha güvenli. İyi bir fikir olabilecek bu küçük modüler mimariyi teşvik eder. Burada iyi fikirlerin dominodan sonra domino gibi görünüyor. Bu yüzden dikkate değer. Biliyorsun?

Drew: Evet, yani, geleneksel olarak, web üzerinde on yıllardır yürüttüğümüz sunucu tabanlı bir mimariyle, kendi başınıza çalıştırdığınız bir web sunucunuz var. Ön uç kodunuzu, arka uç kodunuzu, veritabanınızı ve her şeyi tutar. O zaman bunu sürdürmeniz ve çalışır durumda tutmanız ve faturaları ödemeniz gerekir ve kullanılmasa bile orada faturaları doldurur. Kullanıcı bir istekte bulunacak ve tüm bu HTML sorgularını veritabanından oluşturacak, hepsini satırdan tarayıcıya gönderecekti. O süreç işe yarıyor. Bir sürü şey böyle inşa edilir. Muhtemelen web'in nasıl kurulduğunun çoğunluğu budur. WordPress gibi şeyler böyle çalışır. Bu gerçekten çözmemiz gereken bir problem mi? Yani, biraz maliyetlerden bahsettik. Bununla ilgili ele almamız gereken ve sunucusuz yazılımın bize yardımcı olabileceği diğer sorunlar nelerdir?

Chris: Evet, eski usul yaklaşımla ilgili sorunlar. Evet, bilmiyorum, belki de yoktur. Demek istediğim, tüm ağın bütününü değiştirmesi gerektiğini söylemiyorum… her şeyi bir gecede. Bilmiyorum. Belki gerçekten değil, ama bence kapıları açıyor. Görünüşe göre, böyle iyi fikirler geldiğinde, web'in işleyişini yavaş yavaş değiştiriyorlar. Dolayısıyla, bir şekilde orada bir veritabanı olmasını bekleyen bir CMS varsa, bu, belki de geleceğin ana bilgisayarlarının bundan ilginç şekillerde yararlanmaya başlayacağı anlamına gelir. Belki size hala geleneksel bir sunucu gibi geliyor, ancak ana bilgisayarların kendileri, nasıl çalıştıklarını, sunucusuz mimarilere ayırdılar. Yani bunun olduğunu gerçekten bilmiyorsunuz bile, ancak ihtiyacınız olan şeyleri sunucusuz yollarla barındırarak maliyetlerini düşürmenin bir yolunu buldular. Belki evet, bir geliştirici olarak ilgilenmeye bile gerek yok, ancak meta düzeyde olan bu. Belki. Bilmiyorum.

Chris: Bu aynı zamanda şu anlama da gelmiyor... Veritabanları hala orada. Mimari olarak ilişkisel bir veritabanına sahip olmanın, bu verileri depolamanın doğru yolu olduğu ortaya çıkarsa, harika. Bu Sunucusuz dünyasının JAMstack ile aynı zamanda büyüdüğünden bahsediyorum. Ve JAMstack, "Web sitenize statik ana bilgisayarlardan hizmet vermelisiniz, bunun dışında hiçbir şey çalıştırmamalısınız..." mimarisidir. Bunlar küçük CDN'ler gibidir. Onlar, “Hiçbir şey yapamam. PHP çalıştırmıyorum. Ruby'yi çalıştırmıyorum. hiçbir şey çalıştırmıyorum. Yalnızca statik dosyalara hizmet etmek için tasarlanmış küçük bir web sunucusunda çalışıyorum.”

Chris: “Ve bundan daha fazlasını yapmanız gerekiyorsa, ilişkisel bir veritabanından veri çekmeniz gerekiyorsa, lütfen bunu sunucu zamanında değil başka bir zamanda yapın. Ya bunu önceden bir derleme işleminde yapabilir ve bu şeyleri veritabanından çekebilir, statik dosyaları önceden oluşturabilirsiniz ve ben bunları sunacağım ya da çalışma zamanında yapacağım." Yani bir belgenin bu kabuğunu alırsınız ve ardından bazı verileri almak için bir JavaScript isteğinde bulunur ve daha sonra onu önceden doldurur. Yani bunu vaktinden önce veya sonra yaparsınız, ancak bu "İlişkisel bir veritabanı kullanmayın" anlamına gelmez. Bu sadece, "Belgenin istendiği sırada sunucunun onu oluşturmasını sağlama" anlamına gelir, ki bu bir... Bilmiyorum, bu biraz paradigma kayması.

Chris: Sadece JAMstack da değil. Ayrıca JavaScript çerçeveleri zamanında yaşıyoruz. Bir JavaScript uygulamasının açılma şeklinin, bazı bileşenleri monte etmesi ve bu bileşenler takıldığında ihtiyaç duyduğu verileri istemesinin biraz daha beklendiği bir zamanda yaşıyoruz. Bu nedenle, bir React web sitesi gibi bir şey için doğal bir uyum olabilir, "Pekala, ihtiyacı olan verileri almak için sunucusuz bir işleve basacağım. Esasen bazı JSON API'lerine isabet ediyor. İhtiyacım olan JSON verilerini alıyorum ve kendimi bu verilerden oluşturuyorum ve ardından sayfaya aktarıyorum." Şimdi, bu web için iyi mi yoksa kötü mü, "Bilmiyorum. Çok kötü. Gemi yola çıktı. Pek çok insan bu şekilde şantiye inşa ediyor.” Sadece müşteri tarafından oluşturulan şeyler. Bu nedenle, sunucusuz ve modern JavaScript bir nevi el ele gider.

Drew: Sanırım toptan satış yapmak zorunda değilsin... şu ya da bu mimariye bakıyor olman gerek. Ortada, altyapının bölümlerinin daha geleneksel olabileceği ve bölümlerin sunucusuz olabileceği bir alan var, sanırım?

Chris: Evet. Zaten sana bunu anlatmaya çalışıyorlar. Size mimarisinin herhangi bir parçasını satmak isteyen herkes, “Hemen satın almak zorunda değilsiniz. Sadece biraz yap." Tabii ki, sattıkları her şeye ayak parmağınızı sokmanızı istiyorlar, çünkü parmağınızı bir kez daldırdığınızda, kendinizi havuza sıçratma şansınız çok daha yüksek. Yani, bence… bu bir yalan değil, ille de, biraz daha az şans bulsam da… Yığınımın her şeyden biraz olmasını istemiyorum. Sanırım orada her zaman yutmak istemediğim teknik bir ölüm var.

Drew: Mm (olumlu).

Chris: Ama yapmak mümkün. Sanırım en çok alıntı yapılanı… diyelim ki e-Ticaret öğesi olan bir sitem var, bu şu anlama geliyor… ve diyelim ki büyük ölçekli e-ticaret, yani 10.000 ürün falan, bu JAMstack mimarisi o noktaya gelmedi bu, bunu statik olarak yeniden oluşturmak için her zaman özellikle verimlidir. Yani, düşünce "O zaman yapma" olur. Bırakın bu parça, sunucusuz işlevlerle doğal olarak nemlensin ve ihtiyaç duyduğu verileri alın ve tüm bunları yapın. Ama sitenin geri kalanı, ki... o kadar çok sayfa yok, o kadar veri yok, bir tür ön-işleme ya da her neyse yapabilirsiniz. Yani ikisinden de biraz.

Drew: Elbette, pek çok insan eski sistemlerle uğraşıyor… 2000'lerde inşa edilmiş eski bir veritabanı şeyi, onların üzerine bir tür JSON API katmanı yapıştırabilecekler…

Chris: Evet.

Drew: … ve daha modern ve belki de sunucusuz bir şey inşa edin ve sonra yine de garip bir şekilde tamamen yapıştırarak bu eski sistemlerle etkileşime geçin.

Chris: Evet. Bu hoşuma gidiyor ama değil mi? Değil mi… çoğu web sitesi zaten var. Kaçımız tamamen yeşil alan web siteleriyiz? Çoğumuz zaten var olan ve bir nedenden dolayı geleceğe sürüklenmesi gereken bazı saçmalıklar üzerinde çalışıyoruz, çünkü bilmiyorum, geliştiriciler daha hızlı çalışmak istiyor veya artık COBOL'da kimseyi işe alamazsınız ya da hikaye ne olursa olsun dır-dir. Biliyorsun?

Drew: Terminoloji açısından bakıldığında, bir kodu CDN'den sunan, tarayıcıda hemen hemen çalıştıran bu metodoloji olan JAMstack'ten bahsediyoruz. Yani sunucuda dinamik bir şey olmaması. Ve sonra sunucusuz hakkında konuştuğumuzda, sunucularında başka bir yerde çalışan küçük işlevsellik parçalarından bahsediyoruz. Bu doğru mu? Bu bulut işlevi hakkında konuştuğumuz...

Chris: Evet, yani, şu anda ikisi de çok sıcak fikirler. Yani biri hakkında konuşmak ve diğeri hakkında konuşmak biraz kolay. Ama mutlaka birlikte olmaları gerekmiyor. Sunucusuz hiçbir şeyle ilgisi olmayan bir JAMstack sitesi çalıştırabilirsiniz. Sadece bunu yapıyorsunuz, siteyi önceden oluşturup çalıştırıyorsunuz ve JAMstack'i umursamadan sunucusuz kullanabilirsiniz. Aslında, CodePen hiçbir JAMstack yapmaz. Mutlaka CodePen hakkında konuşmak istemiyoruz, ancak bu bir Ruby on Rails uygulaması. Bunu gerçekleştirmek için bir sürü AWS EC2 bulut sunucusunda ve çeşitli başka mimarilerde çalışır. Ancak, ucuz ve güvenli olduğu ve çalışmanın güzel bir yolu olduğu için, elimizden geldiğince sunucusuz malzemeleri kullanıyoruz. Bu nedenle, JAMstack kullanımda değil, ancak her yerde sunucusuz.

Drew: Bu oldukça ilginç. CodePen'de sunucusuz olarak ne tür görevler alıyorsunuz?

Chris: Şey, bir sürü şey var. Bunlardan biri, sanırım, umarım oldukça açıktır, ihtiyacım var… CodePen'in amacı, her HTML, CSS ve JavaScript'i tarayıcıya yazmanız ve onu önünüzde işlemesidir, değil mi? Ancak ön işlemci dillerini de seçebilirsiniz. Diyelim ki Sass'tan hoşlanıyorsunuz. CSS'de Sass'ı açarsınız ve Sass yazarsınız. Şey, bir şeyin Sass'ı işlemesi gerekiyor. Bu günlerde, Sass Dart veya başka bir şeyle yazılıyor.

Chris: Teorik olarak bunu istemcide yapabilirsin. Ancak ön işleme yapan bu kütüphaneler oldukça büyüktür. Sırf o şeyi çalıştırmak için tüm Sass kitaplığını sana göndermek istediğimi sanmıyorum. İstemiyorum… bu sadece değil, bunun için doğru mimari bu değil. Belki yolun aşağısındadır, yani çevrimdışı saçmalıklardan, yada, yada, Web Workers hakkında konuşabiliriz. Yapabileceğimiz milyonlarca mimari şey var. Ama şimdi şu şekilde çalışıyor, bir lambda var mı? Sass'ı işler. Küçücük, küçücük, küçücük bir işi var.

Chris: Ona bu Sass bloğunu gönderiyorsun ve o sana geri gönderiyor, bu da işlenmiş CSS, belki bir site haritası, her neyse. Küçük bir işi var ve muhtemelen o lambda için dört sent falan ödüyoruz. Çünkü lambdalar inanılmaz derecede ucuzdur ve siz de çekiçleyebilirsiniz. Ölçek konusunda endişelenmenize gerek yok. O şeye istediğiniz kadar vurun ve faturanız şaşırtıcı derecede ucuz olacak. Sunucusuz yazılımın çok pahalı olma sınırını aşmaya başladığı anlar vardır. Bunun ne olduğunu bilmiyorum, böyle şeylerin ustası değilim. Ancak genel olarak, yaptığımız herhangi bir sunucusuz iş, temelde… neredeyse ücretsiz sayılırız, çünkü o kadar ucuzdur. Ama Sass için bir tane var. Less için bir tane var. Babbel için bir tane var. TypeScript için bir tane var. Bunun için bir tane var… Bunların hepsi, koştuğumuz bireysel lambdalar. İşte bir kod, onu lambda'ya verin, geri gelir ve onunla ne yapacaksak onu yaparız. Ancak son zamanlarda bile bundan çok daha fazlası için kullanıyoruz.

Chris: İşte bir örnek. CodePen'deki her bir Kalemin bir ekran görüntüsü vardır. Bu biraz havalı, değil mi? Yani, insanlar bir şey yaparlar ve sonra bir PNG veya JPEG'e ya da buna benzer bir şeye ihtiyacımız olur, böylece biz… bu şekilde tweet attığınızda, onun küçük ön izlemesini alırsınız. Slack'te paylaşırsanız, küçük bir önizlemesini alırsınız. Oluşturmak için web sitesinin kendisinde kullanıyoruz… iframe yerine, eğer Kalem'in animasyonlu olmadığını tespit edebilirsek, çünkü bir iframe'in görüntüsü çok daha hafiftir, öyleyse neden görüntüyü kullanmayalım? Nasılsa animasyonlu değil. Sadece performans böyle kazanır. Yani bu ekran görüntülerinin her birinin belli ki bir URL'si var. Ve bunu, URL'nin aslında sunucusuz bir işlev olacağı şekilde tasarladık. Bu bir işçi. Dolayısıyla, bu URL isabet alırsa, o ekran görüntüsünü alıp almadığımızı gerçekten hızlı bir şekilde kontrol edebiliriz.

Chris: Bu aslında CloudFlare Workers tarafından etkinleştirildi, çünkü CloudFlare Workers yalnızca sunucusuz bir işlev değil, aynı zamanda bir veri deposuna da sahip. Anahtar/değer deposu denen bir şeye sahipler, yani bunun kimliği, gerçekten hızlı bir şekilde kontrol edebiliriz ve "Doğru mu yanlış mı, sizde var mı, yok mu?" Eğer varsa, ona hizmet eder. Ve buna başlamak için süper hızlı olan CloudFlare üzerinden hizmet veriyor. Ve sonra size tüm bu yeteneği de verir. Bu bir görüntü CDN'si olduğu için, “Pekala, onu en uygun formatta sunun. Bu boyutlar olarak hizmet edin.” Görüntüyü bu boyutlarda yapmak zorunda değilim. Sadece boyutları URL'ye koyarsınız ve o boyut olarak sihirli bir şekilde geri gelir. Bu gerçekten güzel. Eğer sahip değilse, gerçekten hızlı hale getirmek için başka bir sunucusuz işlev ister. Yani bunu yapacak ve sonra onu bir yere bir kovaya koyacak… çünkü görüntü için bir kökene sahip olmanız gerekiyor, değil mi? Aslında genellikle bir yerde barındırmanız gerekir. Bu yüzden onu çok hızlı bir şekilde bir S3 kovasına koyduk ve sonra servis ettik.

Chris: Yani kuyruk sunucusu yok, hiçbir şey yok. Bu görüntülerin oluşturulmasını, depolanmasını ve sunulmasını sunucusuz işlevler gibi yönetir. Ve 50 milyon ya da 80 milyon falan var. Çok fazla, bu yüzden ölçek olarak oldukça iyi idare ediyor. Sadece dokunmuyoruz bile. Öyle olur bazen. Her şey süper hızlı oluyor. Süper güzel.

Drew: Sanırım... Sunucusuz bir işlev, ideal olarak, durum hakkında çok az bilgi gerektiren bir göreve uyacaktır. Demek istediğim, CloudFlare'in zaten önbelleğe alınmış bir şey olup olmadığını görmek için anahtar/değer çiftlerini saklama yeteneğinden bahsettiniz.

Chris: Evet. Yine de bunlarla çözmeye çalıştıkları şey bu. Bu anahtar/değer çiftleri, bu… Bence bu geleneksel olarak doğruydu. “Şeydeki durumdan kaçının” gibiler çünkü buna güvenemezsiniz. Ve CloudFlare Çalışanları, "Evet, aslında, bir dereceye kadar devletle başa çıkabilirsiniz." O kadar süslü değil… Bilmiyorum, bu anahtar değerler, yani bir değerin anahtarı. İç içe geçmiş, ilişkisel süslü bir şey gibi değil. Yani muhtemelen bunun bazı sınırları vardır. Ama bunun için bebek günleri. Bence bu şeyler daha güçlü olacak şekilde gelişecek, bu yüzden bazı devlet benzeri şeyler yapma yeteneğiniz var.

Drew: Ve bazen sınırlama, durumu sürdürmek için bu tür sınırlı bir yeteneğe sahip olma ya da hiçbir duruma sahip olmamanız… hiçbir durumu sürdürmek istememeniz, sizi bu tür bir mimariye itiyor… Şey, ne zaman “Small Pieces Loosely Joined” yazılım felsefesinden bahsediyoruz değil mi?

Chris: Mm (olumlu).

Drew: Her küçük bileşenin bir şeyi yaptığı ve onu iyi yaptığı yer. Ve etrafındaki ekosistemin geri kalanı hakkında gerçekten bir şey bilmiyor. Görünüşe göre bu, sunucusuz işlevler kavramı için gerçekten geçerli. Katılıyor musun?

Chris: Evet. Bence bunun iyi bir fikir olup olmadığı konusunda felsefi bir tartışma yapabilirsiniz. Biliyorsun? Sanırım bazı insanlar monoliti seviyor. Bence mümkün… Bunu aşırıya kaçmanın ve birlikte test edilmesi çok zor olan çok fazla küçük parça yapmanın yolları var. "Ah, Sass işlevimin çalışıp çalışmadığını merak ediyorum. Peki, bunun için küçük bir test yazalım ve öyle olduğundan emin olalım.” Ama diyelim ki, kullanıcı için önemli olan, bunlardan yedi tanesinden oluşan bir dizidir. Yedisini bir arada nasıl test edersiniz? Bence bu hikaye biraz daha karmaşık hale geliyor. Tüm bunlarla süper akıllıca nasıl konuşacağımı bilmiyorum, ancak tüm sunucusuz işlevlerle çalışırsanız, otomatik olarak diğer mimarilerden daha iyi bir mimari olan bunun zorunlu olmadığını biliyorum. Beğendim. Bana iyi geliyor, ama bunun tüm mimarilerin sonu olduğunu bilmiyorum. Biliyorsun?

Drew: Bana son derece web gibi geliyor, bunda… HTML tam olarak böyle çalışıyor, değil mi? Biraz HTML iletirsiniz ve tarayıcı daha sonra gidip resimlerinizi alır ve JavaScript'inizi alır ve CSS'nizi getirir. Bunun bir uzantısı gibi görünüyor -

Chris: Bu güzel.

Drew: … bir çeşit fikir. Ancak web hakkında bildiğimiz bir şey var ki, ağ kırılgan olduğu için esnek olacak şekilde tasarlanmıştır.

Chris: Mm (olumlu).

Drew: Sunucusuz yaklaşım türü ne kadar sağlam? Bir şey... o küçük parçalardan biri kaybolursa ne olur?

Chris: Bu çok kötü olurdu. Biliyorsun? Bir felaket olurdu. Siteniz çökerse, diğer sunucular gibi çökecektir, sanırım.

Drew: Bunu azaltmanın yolları var mı, özellikle -

Chris: Bilmiyorum.

Drew: … karşılaştığınız bu tür bir yaklaşıma uygun mu?

Chris: Belki. Demek istediğim, dediğim gibi, gerçekten süper süslü, sağlam bir şey şöyle olabilir… diyelim ki CodePen'i ziyaret ettiniz ve diyelim ki Sass'ın bir JavaScript uygulaması var ve oldukça hızlı bir ağda olduğunuzu ve boşta olduğunuzu fark ettik. şu anda. Belki gidip o JavaScript'i alırız ve onu bir servis görevlisine atarız. Ardından, lambdanın arızalandığını veya başka bir şey olduğunu veya bu şeyin zaten kurulu olduğunu tespit edersek, lambda yerine servis çalışanına vuracağız ve servis çalışanları çevrimdışı çalışabilir. Yani bu da çok hoş. İlginç. Demek istediğim, onlar aynı dil-ish. Hizmet çalışanları JavaScript'tir ve birçok Bulut işlevi JavaScript'tir, bu yüzden bazıları var… Bence bu bir olasılık, ancak bu… bu sadece, bu ciddi bir teknik ki… Teslim ettiğiniz bu JavaScript yığınına sahip olmak beni korkutuyor Neye sahip olduklarını ve hangi sürümüne sahip olduklarını mutlaka bilmediğiniz kaç bin kullanıcıya. Eww, ama bu sadece benim korkum. Eminim bazı insanlar bu tür şeylerle iyi bir iş çıkarmıştır.

Chris: Aslında bilmiyorum. Belki sunucusuzun esnekliği konusunda benim bilmediğim bazı stratejiler biliyorsunuzdur.

Drew: Sanırım sunucusuz işlevlerde olabilecek bir başarısızlık modu, bir başarısızlık tarzı var, burada bir işlevi bir kez çalıştırırsanız başarısız olur ve hemen ardından ikinci kez çalıştırabilirsiniz ve başarılı olur, çünkü vurabilir tamamen farklı bir sunucu. Veya sorun ne olursa olsun, bu çalıştırma ikinci bir istekte bulunmayabilir. Tüm bir ana bilgisayarın arızalı olması bir şeydir, ancak belki de… makineyle ilgili bireysel sorunlarınız var. Belleğinin bozulduğu belirli bir sunucunuz var ve bir sürü hata veriyor ve ona ilk vurduğunuzda başarısız olacak. İkinci kez, bu sorun kök salmış olabilir.

Chris: Bu teknolojiyi sunma eğiliminde olan şirketler, onlara güvenmek zorundasınız, ancak onlar aynı zamanda, onların gurur kaynağı olan şirketler türüdür. İnsanların onları kullanmalarının nedeni, güvenilir olmalarıdır. İnsanların geçmişteki bazı AWS kesintilerine işaret edebileceğinden eminim, ancak bunlar biraz nadir olma eğilimindedir ve çok yaygın değildir. Kendi saçmalıklarınıza ev sahipliği yapıyorsanız, bahse girerim sizi bir SLA yüzde seviyesinden yenmişlerdir. Biliyorsun? Yani, "Dayanıklı bir şekilde inşa etmeyin" gibi değil, ancak genellikle bu şeyleri sunan şirketler oldukça güvenilirdir. Bu işlevi bozduğunuz için düşme olasılığınız, mimarilerinin başarısız olmasından çok daha yüksek.

Drew: Sanırım, demek istediğim, tıpkı bir API kullandığınız herhangi bir şey veya başarısız olabilecek bir şey gibi, sadece kodunuzu bu başarısızlık moduyla başa çıkmak için yapılandırdığınızdan emin olmak ve sadece atmak yerine daha sonra ne olacağını bilmek. kullanıcıya bir hata, ya da sadece ölüyor ya da ne var. Bunun farkında olmak ve kullanıcıdan tekrar denemesini istemektir. Ya da kendini tekrar denemek, ya da başka bir şey.

Chris: Evet, sadece "Oh hayır. Başarısız. İptal et.” “Bilmiyorum, neden orada tekrar denemiyorsun dostum?”

Drew: Yani, sunucusuz işlevlerin, bir tür bulut işlevlerinin test edilmesi ve geliştirilmesi söz konusu olduğunda, bu yerel olarak yapılabilecek bir şey mi? Bulutta mı yapılması gerekiyor? Bunu yönetmenin yolları var mı?

Chris: Sanırım bazı yollar var. Hikaye bu kadar harika mı bilmiyorum. Bu hala nispeten yeni bir konsept, bu yüzden bunun daha iyi ve daha iyi olduğunu düşünüyorum. Ama bildiğim kadarıyla, bir şey için, oldukça normal bir Düğüm işlevi yazıyorsunuz. Bunu yapmak için JavaScript kullandığınızı varsayarsak ve özellikle Lambda'da her türlü şeyi desteklediğini biliyorum. Lanet olası bir PHP Bulut İşlevi yazabilirsiniz. Bir Ruby Bulut İşlevi yazabilirsiniz. Bu yüzden, özellikle JavaScript'ten bahsettiğimi biliyorum çünkü bunların çoğunun JavaScript olduğunu hissediyorum. Hangi dil olursa olsun, yani yerel olarak komut satırınıza gidip o şeyi çalıştırabilirsiniz. Bu testlerden bazıları… başka herhangi bir kodda yaptığınız gibi test edersiniz. Sadece işlevi yerel olarak çağırın ve çalışıp çalışmadığını görün.

Chris: Bir HTTP isteğinden bahsederken biraz farklı bir hikaye, test etmeye çalıştığınız şey bu. İsteğe uygun şekilde yanıt veriyor mu? Ve eşyaları düzgün bir şekilde iade ediyor mu? Bilmiyorum. Ağ orada devreye girebilir. Yani bu seviyede testler yazmak isteyebilirsiniz. Bu iyi. Bilmiyorum. Oradaki normal hikaye nedir? Bir tür yerel sunucuyu veya ona hizmet eden bir şeyi çalıştırıyorsunuz. Postacı kullan, bilmiyorum. Ama var… Çerçeveler de yardımcı olmaya çalışıyor. Son derece kafa karıştırıcı olan sunucusuz “.com”un olduğunu biliyorum, ancak kelimenin tam anlamıyla Sunucusuz adında bir şirket var ve bunları dağıtmanıza yardımcı olan sunucusuz işlevleri yazmak için bir çerçeve oluşturuyorlar.

Chris: Yani NPM'nin sunucusuz kurulumunu seviyorsanız, onların çerçevesini alırsınız. Ve yaygın olarak çok iyi olarak kabul edilir, çünkü bu sadece çok faydalıdır, ancak kendi bulutları veya başka bir şeye sahip değildirler. Bunları yazıyorsunuz ve bu onları gerçek bir lambdaya ulaştırmanıza yardımcı oluyor. Veya birden çok bulut sağlayıcısı ile çalışabilir. Bu günleri bile bilmiyorum ama var olma amaçları dağıtım hikayesini kolaylaştırmak. Ne olduğunu bilmiyorum… AWS basitliği ile ünlü değildir. Biliyorsun? AWS'yi kullanmanıza yardımcı olacak bir takım araçlar dünyası var ve onlar da onlardan biri.

Chris: Bir çeşit ücretli ürünleri var. Tam olarak ne olduğunu bile bilmiyorum. Bence yaptıkları şeylerden biri… bunları kullanmanın amacı test etmek, sunucusuz işlevinizi test etmek için bir geliştirme ortamına sahip olmaktır.

Drew: Evet, çünkü sanırım bu iş akışının oldukça büyük bir parçası, değil mi? JavaScript işlevinizi yazdıysanız, yerel olarak test ettiniz, işi yapacağını biliyorsunuz. How do you actually pick which provider it's going to go into and how do you get it onto that service? Now, I mean, that's a minefield, isn't it?

Chris: Evet. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. It's kind of a big deal. You don't want to screw up a worker. You know? You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. Bilmiyorum. It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. Whatever. It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. Evet.

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

Duru: Evet. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. I think so. I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

Duru: Evet. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. You know? That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

Chris: Evet, evet. Bence öyle, bence bu… çünkü şöyle anlar var… Bir web sitesi için neyin uygun olup neyin olmadığını bilmek için çok yetenekli olmanıza gerek yok. Geçen hafta küçük bir eğitim yaptım, bu aksaklığın olduğu yerde bunları kullanır… bir aksaklığı kaydettiğinizde, inşa ettiğiniz şey için size bir sümüklü böcek verirler, yani “Viski, tango, fokstrot. 1.000.” Küçük akıllı bir şey gibi. Eşsiz olma şansı çok yüksek, çünkü bence ona bir sayı falan da ekliyorlar. Ama sonunda bu eğlenceli küçük şeyler oluyorlar. İçinde tüm bu kelimelerin bulunduğu kütüphanelerini açık kaynak olarak açıyorlar, ama bu yüz, binlerce kelime gibi. Dosya çok büyük. Biliyorsun? Sadece bir kelime sözlüğünden oluşan megabayt büyüklüğünde. Muhtemelen geliştirmenizin ilk yılında, "Megabaytlarca sözlük olan bir JavaScript dosyası göndermeyin" diye öğrenmişsinizdir. Göndermek iyi bir şey değil. Biliyorsun? Ama Düğüm umursamıyor. Yüzlerce gönderebilirsiniz. Bir sunucudaki hız ile alakası yok.

Duru: Evet.

Chris: Bir sunucuda önemli değil. Yani, "Hmm, peki, o zaman sadece Düğüm'de yapacağım" gibi olabilirim. "Kelimeler eşittir kelimeler gerektirir" ya da her neyse diyen bir ifadem olacak ve en üstte "Bir sayıyı rastgele olsun. Diziden dışarı çekin ve geri verin." Yani bu sunucusuz işlev, bu açık kaynak kitaplığı çeken bir paketlenmiş@JSON içeren sekiz satırlık koddur. Ve sonra ön uç kodum, sunucusuz işlevin bir URL'si var. Bu URL'ye isabet ediyor. URL, bir kelimeyi veya bir kelime grubunu veya herhangi bir şeyi döndürür. Bunun için kendi küçük API'nizi oluşturuyorsunuz. Ve şimdi, gerçekten güzel, verimli bir şeyim var. Bunda güzel olan şey, bu kadar basit olması. Güvenliğinden endişe etmiyorum. Ben... biliyor musun?

Chris: Bu sadece… çok ortalama veya yeni başlayan bir JavaScript geliştiricisi, bence, bunu başarabilir, ki bu harika. Bu, daha önce sahip olmadıkları, olanak sağlayan bir şey. Daha önce, "İşte 2 MB'lık bir kelime dizisi" gibiydiler. "Ah, bunu müşteriye gönderemem." "Oh, o zaman kapatacaksın." Bu duvara, “O kısmı yapamam o zaman. Başka birinden bu konuda bana yardım etmesini istemeliyim ya da yapmamasını ya da daha sıkıcı sümüklü böcekleri seçmesini ya da bazılarını…” Sadece, senin için duvar olan başka bir yoldan gitmelisin, çünkü yapamazsın. Ve şimdi siz, “Ah, peki, ben sadece…” Bunu komut dosyası eğik çizgimde veya kaynak eğik çizgi komut dosyaları klasörümde kullanmak yerine, onu işlevler klasörüme koyacağım.

Chris: Senaryoyu bir klasörden diğerine taşımayı seviyorsun. Ve bu, bunun yerine sunucusuz bir işlev olarak dağıtılır. Ne kadar serin? Biliyorsun? Neredeyse aynı beceri setini kullanıyorsunuz. Hâlâ bazı pürüzlü yanları var, ama oldukça yakın.

Drew: Çok havalı. Tüm bu fikirlerle ilgili bir tür küçük mikro site oluşturdunuz, değil mi?

Chris: Evet. Oyuna biraz erken geldim. Yine de bugün üzerinde çalışıyordum çünkü... çekme istekleri alıyor. Fikir… peki, serverless.css-tricks.com'da ve… bu arada CSS-Tricks'te bir çizgi var. Bu, CSS-Tricks'in bir alt alanı ve onu da sunucusuz olarak oluşturdum, yani bu… CSS-Tricks bir WordPress sitesi gibidir, ancak bu statik bir site oluşturma sitesidir. Tüm içeriği açık kaynak kodlu GitHub deposundadır. Bu nedenle, sitenin içeriğini değiştirmek istiyorsanız, sadece bir anket isteği gönderebilirsiniz, bu güzel çünkü zaman içinde yüzlercesi oldu. Ama tüm orijinal içeriği oluşturdum.

Drew: Süper kullanışlı bir yer, çünkü listeleniyor… “Doğru, sunucusuz işlevlere başlamak istiyorum” diye düşünüyorsanız, deneyebileceğiniz tüm sağlayıcıları listeliyor ve…

Chris: Hepsi bu kadar, hemen hemen teknoloji listeleri. Evet.

Drew: Bu harika, çünkü aksi halde, her ne için Google'a gidiyorsun ve ne bulduğunu bilmiyorsun. Evet, bu tür şeyleri yapmanıza yardımcı olan API sağlayıcılarının listesidir.

Chris: Formlar buna bir örnek, çünkü… yani… seçtiğiniz anda… diyelim ki, JAMstack'e gideceksiniz, ki bunun mutlaka amacının bu olmadığını biliyorum, ancak bunların ne kadar el ele olduğunu görüyorsunuz. . Birdenbire, bir PHP dosyanız veya bu formu işlemek için herhangi bir dosyanız yok. JAMstack sitesinde formları nasıl yaparsınız? Pekala, bunu yapmanın birçok yolu var. Görünüşe göre herkes ve kız kardeşleri bu sorunu çözmenize yardım etmek istiyor. Sanırım JAMstack kelimesinin mucidi ben olsaydım, bu yüzden size doğal olarak yardım etmeye çalışırlar, ama onları kullanmak zorunda değilsiniz.

Chris: Aslında, bu siteyi bir araya getirmek beni çok şaşırttı. Bakalım. Şu anda bu sitedeki formlarınızı sunucusuz olarak işlemenize yardımcı olmak isteyen altı, dokuz, on iki, on beş, on sekiz, yirmi bir, yirmi iki hizmet var. 23'üncü olmak istiyorsan, bunu kabul edebilirsin, ama orada biraz rekabet var. Bunun arkasındaki fikir, kelimenin tam anlamıyla bir form öğesi gibi HTML'de bir form yazmanızdır. Ve sonra formun action niteliği, dahili olarak hiçbir yeri işaret edemez, çünkü işaret edecek hiçbir şey yoktur. İşlem yapamazsınız, bu nedenle dışarıdan işaret eder. Neyi göstermenizi istiyorlarsa onu işaret ediyor. Formu işlerler ve ardından e-posta bildirimi göndermek gibi onlardan beklediğiniz şeyleri yapmaya eğilimlidirler. Veya bir Slack şey gönderin. Ya da Zapier'e gönderirseniz Zapier başka bir yere gönderir. Hepsinin biraz farklı özellik kümeleri, fiyatlandırması ve diğer şeyleri var, ancak hepsi bu sorunu sizin için çözmeye çalışıyor, "Kendi formlarınızı işlemek istemiyor musunuz? Sorun yok. Sizin için işleyeceğiz.”

Drew: Evet, süper faydalı bir kaynak. Gerçekten herkesin incelemesini tavsiye ederim. Bu serverless.css-tricks.com. Yani, sunucusuz hakkında her şeyi öğreniyorum. Son zamanlarda ne öğreniyorsun, Chris?

Chris: Ben de hâlâ bu dünyadayım ve sunucusuz şeyler hakkında yeni şeyler öğreniyorum. Bir fikrim vardı… Bu çevrimiçi rol yapma oyununu çok uzun zaman önce oynardım. Son zamanlarda hala hayatta olduğunu keşfettim. Metin tabanlı bir ortaçağ fantezi oyunudur. AOL bir şeyken oynadım, çünkü AOL oynamak için oturum açmanız gereken bu oyunlara sahip olmak istedi, çünkü AOL'de saatlerce harcamanızı istediler, böylece size bu büyük faturaları gönderebildiler. , eminim, neden bir noktada bu kadar iyi yaptılar.

Drew: Yani saniyesine fatura kesiliyor. Evet.

Chris: Evet. Yani oyunlar onlar için büyüktü. Oradaki diğer insanlarla oyun oynamanı sağlayabilirlerse. Yani bu oyun bir nevi… orada piyasaya çıkmadı, ama AOL'ye taşındı, çünkü eminim ki bunun için sulu bir anlaşma yaptılar, ama öyleydi… Yani, sadece, muhtemelen daha inek olamazdı. Sen bir cüce büyücüsün ve deri kılıfından rune asası alıyorsun. Ve içine bir terminal gibi komutlar yazıyorsunuz. Sonra oyun size cevap verir. O oyunu çok uzun süre oynadım. çok ilgiliydim. Topluluğuna ve ruhuna girdim. Bu bir nevi… sanki bilgisayar başında tek başımaymışım gibi ama yine de hayatımın o zamanına bakıyorum ve “Hayatımda harika bir zamandı” diyorum. Ben gerçekten… Ben sadece insanları, oyunu ve tüm bunları sevdim. Ama sonra büyüdüm ve oynamayı bıraktım çünkü hayat senin başına geliyor.

Chris: Bunu daha yeni öğrendim, çünkü biri yine bununla ilgili bir podcast yapmaya başladı... Nasıl rastladım bilmiyorum ama buldum. Ben de, “Bu oyun bugünün dünyasında canlı ve iyi durumda, dalga mı geçiyorsun? Bu metne dayalı şey.” Ve eski karakterlerimi yeniden aktif hale getirmekten ve oynamaktan çok mutlu oldum. Ama sadece bu oyun için indirdikleri müşterilerin hiç gelişmediğini öğrenmek için. Onlar korkunç. Neredeyse Windows kullandığınızı varsayıyorlar. Sadece bu çok sevimsiz, kötü renderleme var… ve metin tabanlı, en azından güzel bir tipografiye sahip olacağını düşünüyorsunuz. Hayır. Yani, “Ben de dahil olabilirim. Bu oyun için bir müşteri yazabilirim. İçine güzel bir tipografi koyun.” Sadece şeyi modernize edin ve oyunun oyuncularının bunu takdir edeceğini düşünüyorum, ancak bana çok ezici geldi. "Nasıl yapabilirim?" Ama bazı açık kaynak projeleri buluyorum. Oyunu gerçek bir terminal penceresinden oynayabilirsiniz ve bir terminal penceresinden bir GUI yapmak için bazı açık kaynak kütüphanelerini kullanır.

Duru: Gerçekten mi?

Chris: Bilmiyorum. Yani bu biraz havalıydı. Ben, “Bunu onlar yazdıysa, oyuna nasıl bağlanılacağına ve her şeyin nasıl yürütüleceğine dair bir kod olmalı. Yani en azından biraz başlangıç ​​kodum var.” Son ürün uygulamasının cep telefonlarında çalışması için "Belki bunu Flutter'da falan yaparım" şeklinde bir uygulama üzerinde ilerlemeye çalışıyordum ve "Bu şeyi gerçekten modernize edebilirim." Ama sonra bunaldım. Ben, “Ah, bu çok büyük bir… Yapamam. Meşgulüm." Ama aynı fikre sahip başka bir kişi buldum ve onlar onunla çok daha ileri gittiler, bu yüzden sadece tasarım düzeyinde katkıda bulunabilirdim. Ve üzerinde çalışmak gerçekten eğlenceliydi, ama ben de çok şey öğreniyorum, çünkü başka birinin bebeği olan bir projeye atlamak benim için nadirdir ve ben sadece biraz katkıda bulunuyorum ve bu tamamen farklı bir şey. hiç seçemeyeceğim teknoloji seçimleri.

Chris: Bu bir Elektron uygulaması. Bunu seçtiler, bu da gitmek için harika bir yol çünkü bu benim web becerilerim… yani çok garip bir şey öğrenmiyorum ve çapraz platform, ki bu harika. Elektron hakkında çok şey öğreniyorum. Bence eğlenceli.

Drew: Bu büyüleyici. Küçük yan projelerin ve eğlence için yaptığımız şeylerin bazen en çok öğrendiğimiz yer haline gelmesi her zaman şaşırtıcıdır. Ve daha sonra günlük işlerimize geri dönebilecek becerileri öğrenin.

Chris: Bir şeyler öğrenmemin tek yolu bu. Öyle bir şeye sürüklendim ki… “Onlar değil…” dedim, Mithril adında bir JavaScript kitaplığı ile işleniyor, yani… Bunu hiç duydunuz mu bilmiyorum, ama garip. Değil… neredeyse JSX olmadan React yazmak gibi. “Element yaratmanız” ve tüm bunları yapmanız gerekiyor… ama bunun ondan çok daha iyi bir kıyaslama yapması gerekiyor… Ve aslında bir bakıma önemli çünkü bu metin tabanlı oyunda metin sadece uçuyor. Bu metin tabanlı oyunun bir tarayıcı penceresinin çalışması için çok kolay olacağını düşünürdünüz, ama aslında pek öyle değil. Gerçekleşen o kadar çok veri manipülasyonu var ki, gerçekten gerçekten olmalısınız… işlemenin hızı konusunda vicdanlı olmalıyız. Biliyorsun?

Drew: Bu büyüleyici...

Chris: Oldukça havalı.

Duru: Evet. Sevgili dinleyici, Chris'ten daha fazlasını duymak istiyorsanız, onu @chriscoyier olduğu Twitter'da bulabilirsiniz. Elbette, CSS-Tricks css-tricks.com'da ve CodePen'i codepen.io'da bulabilirsiniz. Ama hepsinden önemlisi, shoptalkshow.com adresinden ShopTalk Show podcast'ine henüz abone olmadıysanız abone olmanızı tavsiye ederim. Bugün bize katıldığın için teşekkürler, Chris. Ayrılık sözleriniz var mı?

Chris: Smashingpodcast.com. Umarım gerçek URL budur.