Anthony Campolo ile Çarpıcı Podcast 25. Bölüm: RedwoodJS Nedir?

RedwoodJS'den bahsediyoruz. Tam yığın Jamstack çerçevesi olmak tam olarak ne anlama geliyor? Bunu öğrenmek için topluluk şampiyonu Anthony Campolo ile konuştum.

Notları göster

• RedwoodJS
• Anthony Twitter'da
• Anthony'nin makale dizisi RedwoodJS'ye İlk Bakış

Haftalık güncelleme

• “Lighthouse'u Programlı Olarak Çalıştırmaya Giriş”
  Katy Bowman'ın yazdığı
• “GreenSock ile React Bileşenlerini Canlandırma”
  Blessing Krofegha tarafından yazıldı.
• “Dikkat Çekmek İçin Tasarlamak”
  Victor Yocco'nun yazdığı
• “Gatsby Web Sitelerinde Gelişmiş GraphQL Kullanımı”
  Aleem Isiaka tarafından yazıldı.
• "Next.js'de Şekillendirme Yöntemlerini Karşılaştırma"
  Adebiyi Adedotun tarafından yazılmıştır.

Transcript

Drew McLellan: O bir Lambda Okulu öğrencisi, tam yığın web geliştirme eğitimi alıyor ve RedwoodJS'e katkıda bulunuyor. Bir topluluk şampiyonu gibi, yakın zamanda, Redwood'un kökenlerini ve motivasyonlarını ve çerçevenin sunduğu birçok farklı kavramı açıklamaya yardımcı olan A First Look at RedwoodJS adlı 12 bölümlük bir makale dizisi yazdı. RedwoodJS'de uzman olduğunu biliyoruz ama hiç köpek görmediğini biliyor muydunuz? Ezici dostlarım, lütfen Anthony Campolo'ya hoş geldiniz.

Merhaba , Anthony. Nasılsınız?

Anthony Campolo: Merhaba. Parçalıyorum, bana sahip olduğun için çok teşekkür ederim.

Drew: Bugün seninle konuşmak istedim ve muhtemelen girişten RedwoodJS hakkında açıkça anlaşılıyor. RedwoodJS'i daha önce üst düzeyde duymamış olanlar için nedir?

Anthony: İnsanların nereden geldiğine bağlı olarak bunu tanımlamanın birkaç yolu olduğunu düşünüyorum, ancak kurallı tanım, Jamstack için tam yığın sunucusuz bir çerçeve olmasıdır. Bu nedenle, tam yığın web geliştirmeyi sunucusuz AWS Lambda türü şeyler ve bugünlerde büyük bir şey olan Jamstack ile birleştirir.

Drew: Yani, bir Jamstack geliştirme ekosistemi etrafında birçok fikri bir araya getirmeye çalışan tam bir yığın çerçevesi mi? Bu doğru mu?

Anthony: Evet, bir Jamstack uygulamasının ne olabileceğinin sınırlarını zorluyor, bu yüzden ona tam yığın, Jamstack diyerek, bu, sadece ön ucun ötesine geçerek aynı tür dağıtım paradigmasına sahip olmak için nasıl ilerleyeceğimiz ile ilgili. tüm kodunuz dağıtıldı. Bunu nasıl elde ederiz, aynı zamanda arka ucumuzla ve hepsi birbirine bağlı mı?

Drew: Şimdi, derinlemesine incelemeden önce, bunun oldukça deneyimli bir takımdan olduğunu duymak oldukça ilginç, değil mi? Redwood'un arkasındakiler bahar tavuğu değiller. Eski olduklarını söylemiyorum ama web geliştirme açısından her şeyi yaptılar, değil mi?

Anthony: Onlar tecrübeli. Evet, aslında çerçevenin tarihi ve ona yol açan fikirler hakkında yazmaya epey zaman harcadım ve yaratıcısı Tom Preston-Werner ve bu yüzden o aynı zamanda Jekyll'in yaratıcısı olarak da biliniyor. gerçekten etkili bir statik site oluşturucudur. Ayrıca yapılandırma dosyası dili olan TOML'yi de yaptı. Ve aslında GitHub'ın CEO'suydu. Yani, Jekyll ve GitHub sayfalarıyla yaptığı çalışma ve bence bu tür şeyler, şimdi Jamstack olarak düşündüğümüz şeye gerçekten yol açtı. Pek çok insan, “Ah, Jamstack yeni. Bunu sonsuza dek yapıyorlar.” Bu eski fikirlerin, statik site nesillerinin, ancak GraphQL ve sunucusuz ile nasıl bir uzantısı olduğundan ve uygulamanızın çalışması için tutkal kodu ve API'lerin nasıl kullanılacağına ilişkin bu fikirlerden işte bu şekilde bahsediyorduk.

Drew: Yani, bu kesinlikle o topluluğa çok bağlı olan insanlardan mı? Demek istediğim, GitHub'ın CEO'su, gerçekten bir tür açık kaynak topluluğuna bundan daha fazla dahil olmuyorsunuz. Yani, Redwood tam bir yığın çerçevesidir ve sanırım bu, ön uçta ve arka uçta çalışan Redwood kodunuz olduğu anlamına gelir. Bu doğru mu?

Anthony: Evet, insanlara bir Redwood projesini gösterirken bunu açıklamayı sevdiğim ilk şey, bunun bir monorepo olduğu. Yani, aynı depoda ön ucunuz ve arka ucunuz var ve sonra bunların her biri kendi klasörlerinde yaşıyor. Ön ucunuz olan bir web klasörünüz var ve bu, Create React uygulamasından alacağınıza oldukça benzer. Ardından, arka ucunuz olan API klasörünüz var ve bu, tüm işlevlerinizin esas olarak Netlify aracılığıyla AWS Lambda'ya dağıtılan büyük bir GraphQL işleyicisine aktarıldığı yerdir.

Drew: Pekala, yani önden başlayarak, bahsettiğiniz gibi, React'e dayanıyor. Bu React artı bir grup Redwood kodu mu, yoksa sadece basit React mi? Oradaki denge nedir?

Anthony: Pek çok şey var. Çok fazla devlet yönetimi kütüphanesi getirmemeniz anlamında kesinlikle sadece React, aslında bir yönlendirici bile getirmiyorsunuz. Yazdıkları kendi yönlendiricileri var ve birçok GraphQL malzemesi kullanıyorlar. Bu nedenle, insanlar React ve GraphQL ve arkadaşlar hakkında konuştuğunda, burada olan biraz budur, React'in GraphQL'inizle konuşmasını sağlamak için size birçok varsayılan entegrasyon sağlamasıdır. Çünkü artık React'in nasıl kullanılacağına dair birçok kuralımız var, ancak veri getirme hala büyük bir güçlük.

Drew: Yani, bu belirli görev stilini yapmak için size işleyen bir ekosistem sağlamak için React ile iyi çalışan bir dizi başka araçla yapılandırılmış React. Bu adil bir tanım mı?

Anthony: Evet, hayır, evet, bunu söylemenin harika bir yolu. Tom'un söylediği gibi, türünün en iyisi çözümler var ve kullanabileceğimiz gerçekten karmaşık araçlar ve teknolojiler var, ancak bunlardan yararlanmak gerçekten zor çünkü çok büyük bir başlangıç ​​maliyetiniz var ve bunları öğrenmek zorundasınız. , onları nasıl entegre edeceğini bulmak zorunda. Bu nedenle, sloganı "Sizin için web paketi yapılandırmanızı yapıyoruz" olarak koydular.

Drew: Sanırım, istemci tarafı JavaScript uygulamaları ve web paketini, tüm farklı şeyleri, yapı süreçlerini, adımlar oluşturun. Her şeyi birbirine bağlayıp çalışır hale getirmek tam bir mayın tarlası olabilir, değil mi? Ve “Merhaba, Dünya!”ya ulaşmanız çok uzun bir yol. Yani, Redwood bize tüm bunları önceden yapılandırılmış olarak mı veriyor?

Anthony: Evet, konfigürasyon tipi fikri üzerinde çok fazla bir gelenek, çünkü sizde… Tom, GitHub'ı Ruby on Rails ve Rob ile birlikte inşa etti, diğer ana katkıda bulunanlardan biri, sonsuza kadar bir Rails geliştiricisi oldu. Felsefi olarak Rails açısından uyumlu oldukları birçok fikirleri var, ancak konfigürasyon fikirleri, tam yığın çerçeve fikirleri konusundaki bu konvansiyonu almak ve bunu şu anda sahip olduğumuz tüm modern teknolojiyle uygulamak istiyorlar.

Drew: Yani, Redwood'un size bir yönlendirici veya yönlendirici verdiğini söylediniz, havuzun bu tarafında söylediğimiz gibi, React'te varsayılan bileşenler ve bu tür şeyler gibi şeylerle mi geliyor yoksa tam o sırada mı? tüm bunları kendin uygulamak için?

Anthony: Evet, yönlendirici çok karmaşık. Sadece React yönlendiricisinden alacağınız şeylerin çoğunu yapar, bunların nasıl uygulanması gerektiği konusunda sadece biraz farklı fikirleri vardır, çünkü Next'in de kendi yönlendiricileri vardır ve hala tam olarak nasıl çözdüğümüzü çözmüş değil. tek sayfa uygulama yönlendirmemizin işe yaramasını istiyorum. Gerilim nedeniyle, zaman uyumsuz şeylerin nereden geleceğine dair bu tür birçok sorunuz var? Redwood'da bu hücre fikrine sahibiz ve verilerinizin sizin için gerçekten getirdiği şey de bu.

Drew: Yani, belki buna biraz girebiliriz? Redwood açısından hücre nedir?

Anthony: Evet, yani bir hücre bir GraphQL sorgusu yazmanın varsayılan bir yoludur ve ardından sayfanızın temel olarak verileri geri alıp almadığınızı, bir hata alıp almadığınızı, yükleme durumunda olup olmadığınızı söylemesini sağlayın. ya da… Bir hal daha var, unuttum. Ama evet, bu yüzden size verilerinizi alıp almadığınıza bağlı olarak temelde içinde olabileceğiniz farklı durumları verir. Kapakların altında Apollo ile kurulur. Yani, Redwood kullanıyorsanız, GraphQL istemciniz olarak Apollo'yu kullanıyorsunuzdur, ancak bunun hakkında asla düşünmeniz gerekmez. Hiçbir zaman Apollo yazmanıza, hatta bunun hakkında düşünmenize bile gerek kalmaz, her şey hazırdır. Sadece GraphQL sorguları yazmanıza izin verir, insanların GraphQL'yi neden istediğinin hayali buydu, ön uç geliştiricilerin bu gerçekten basit sorgu dili olmasıydı. kullanabilirdi. Ama sonra, bir GraphQL sunucusunu nasıl kuracağınızı bulmanız gerekiyordu, diğer tüm şeyleri çözmeniz gerekiyordu ve bunların hepsini nasıl bağlayacaksınız. Böylece, tüm GraphQL entegrasyonunu sizin için yapar, böylece sadece GraphQL yazabilirsiniz, GraphQL'i nasıl uygulayacağımı düşünmenize bile gerek kalmaz.

Drew: Yani, sanırım bir çerçevenin klasik işlerinden biri, kendi yazabileceğiniz tüm kazan plakası kodunu alıp sizin için uygulamak ve perde arkasını düzenlemek, böylece o kazan plakasına asla bakmak zorunda kalmamak. ve durumunuza özel kodu yazabilirsiniz. Sanırım bir hücrede olan şey bu, değil mi? Burada devrim niteliğinde bir şey yok, tüm bu farklı durumlara sahip olmak için bir React bileşeni kurabileceğiniz ve Apollo'ya bağlanabileceğiniz ve tüm bunları kendiniz yapabileceğiniz bir şey, ancak bu aslında oldukça fazla iş ve ortak bir kalıp. Böylece Redwood, üzerinde düşünmenize gerek kalmadan kullanmaya başlayabileceğiniz güzel, yeniden kullanılabilir bir desen oluşturdu. Bu iyi bir tanım mı?

Anthony: Evet, ismi buldular ama bunun sıklıkla gördükleri bir uygulama olduğunu ve birçok insanın sadece kendilerinin kodladığını gördüklerini kesinlikle kabul ediyorlar ve veri getirmenizi yapmak için bildirimsel bir yol istediklerine karar verdiler. İşte bu yüzden bu kuruluma sahipsiniz, çünkü sadece farklı durumlarınıza sahip olmanıza izin veriyor ve anlamak için if/then mantığı yapmanıza gerek yok, bu olursa bunu yapmanız gerekir. Yani, siz yüklerken verilerinizin içinde olabileceği tüm farklı durumları bildirmenin tek bir yoluna sahip olmakla ilgilidir.

Drew: React'in özelliklerinden biri, değil mi? Bunun elbette artıları ve eksileri var. Ancak, Redwood bu yapının bir kısmını sizin için dayatıyor gibi görünüyor, böylece düşünmek zorunda kalmazsınız ve tesisatı sizin için yerleştirebilir ve React'in size verme açısından bıraktığı yerden devam edebilir. bu tür bir yapı.

Anthony: Evet, ve bence bu soruna bu çözümde birden fazla farklı girişim görmemiz gerçekten ilginç, çünkü demek istediğim, bunu sonsuza kadar söyleyen insanlar oldu, “Neden bir Rails yok? JavaScript mi ​​yoksa React için Rails mi?" Michael Chan ve Adam Wathan arasında React is Not a Rails yarışmacısı adlı harika bir Full Stack Radio röportajı var. Bu, farklı çerçevelerden biridir.

Anthony: Diğerleri, makul miktarda ses getiren BlitzJS ve ardından Bison, yeni ve gelecek olan bir tür. Hepsinin benzer bir yığını var, ancak farklı parçalar kullanıyorlar. Apollo yerine React sorgunuz olacak veya Tailwind yerine Çakranız olacak. Tüm bu parçaları yığınlarına koyan insanlar, tüm bu yığınlar bir nevi, savaşıyorlar, hepsi çok dostane bir rekabet. Aslında bu gerçekten takdir ettiğim bir şey, aslında hepimizin çerçeveler arasında da işbirliği yapıyor olmamız. Orada düşmanlık yok.

Drew: Apollo ve GraphQL'den bahsetmiştik, Redwood, GraphQL'i çerçevenin temel parçalarından biri olarak oldukça yoğun bir şekilde kullanıyor, değil mi? Muhtemelen tüm podcast bölümünü yalnızca GraphQL'e adayabiliriz, ancak aşina olmayanlar için, GraphQL burada hangi parçayı yapıyor, bu bağlamda hangi sorunu çözüyor?

Anthony: Evet, bu harika bir soru. İnsanlara Redwood ile iyi bir başlangıç ​​yapmak için ne bilmeleri gerektiğini söylerken, bir Create React uygulaması yaptıysanız ve onu Netlify'a dağıttıysanız, Create React uygulamasını kullanmanız gerektiğini söylerdim. Vercel, bu sana iyi bir başlangıç ​​yapacak. O zaman, çok merkezi olduğu için en azından biraz GraphQL öğrenin. Yani GraphQL, ön ucunuzun arka ucunuzla nasıl konuşacağıdır. Bunun API'ler için bir sorgu dili olduğunu söylüyorlar, fikir RESTful API yöntemlerine bir alternatif olması gerektiği ve bu RESTful şeyi yapmak yerine, tam olarak geri almak istediğiniz hiyerarşik veri yapısını belirten sorgular gönderdiğinizdir. veritabanı. Bu nedenle, GraphQL sunucunuzun iki parçayla konuşmasını sağlamak için biraz daha fazla başlatma süresi gerekir. Ardından, bir kez oraya sahip olduğunuzda, ön uç geliştiriciler verileri çok daha esnek bir şekilde alma yeteneğine sahip olurlar. Arka uç adamlarınızın yapmaya devam etmesi gereken tüm bu farklı API uç noktalarına ihtiyacınız yok.

Drew: Yani, ön uçta gereksinimlerde değişiklikler varsa, muhtemelen GraphQL sorgunuzda ince ayar yapabilirsiniz ve bu değişikliği sizin için yapmak için arka uçta çalışan birinin yardımına ihtiyacınız yok mu?

Anthony: Demek istediğim, gerçek hayal şu ​​ki, bir mobil istemciye atabilirsiniz, sonuçta o kadar esnek olur ki, birden fazla istemciniz tek bir API'niz ile konuşabilir. GraphQL API'niz gerçek kaynağınız olur, tüm mantığınızın merkezileştiği yer burasıdır. Ardından, tüm bu farklı görünüm katmanlarını üstte oluşturabilirsiniz.

Drew: Yani, GraphQL'ye sahibiz ve bize bir tür arka uç sorgulama yeteneği veriyor. Redwood'da arka uç nedir?

Anthony: Evet. Arka uçunuzu oluşturmanın birkaç farklı yolu vardır. Heroku'da konuşlandırılmış Postgres veritabanını kullandığınız öğretici ile kutudan çıkmanın bir yolu var, süper kolay, süper basit. Ardından, Redwood uygulamanız onunla Prisma ile konuşur. Prisma hakkında bilginiz var mı bilmiyorum ama O/RM gibi. Özellikle bunun bir O/RM olmadığını, biraz daha düşük seviyeli bir sorgu oluşturucu olduğunu söylüyorlar. Ancak, sırf insanlara açıklamak uğruna, Prisma veritabanınızla konuşmanıza izin veren şeydir. Geçişlerinizi yapar ve tablolarınızı kurar. Tüm SQL işlerini yapar, böylece SQL yazmak zorunda kalmazsınız. Bana göre, bu bir O/RM gibi geliyor. Redwood kullanmak için Prisma kullanmanıza gerek yok.

Anthony: Aslında bunun yerine FaunaDB'yi kullandığımız bir konsept kanıtı uygulaması oluşturdum. FaunaDB, kendi GraphQL API'lerine sahipler, böylece GraphQL API'sini doğrudan Fauna'ya gönderebilir ve ardından veritabanı mutasyonlarınızı bu şekilde yapabilirsiniz. Prisma'nın CLI'sinin pek çok işlevselliğini kaybedersiniz, ancak Prisma gerçekten ilişkisel veritabanınızla gerçekten kolayca çalışmak için bir kolaylık faktörüdür. Ama gerçekten, aklınıza gelebilecek her şeyi, Redwood ile nasıl bağlayacağınızı anlayabilirsiniz, çünkü GraphQL etrafında inşa edilmiş ve tüm mesele tüm bu farklı parçalarla konuşabilmek.

Drew: Yani, Prisma esasen kodunuz ile kullandığınız veri deposu arasında muhtemelen Prisma'nın desteklediği herhangi bir veri deposu arasında bir tür soyutlama katmanıdır, öyle mi… yoksa bundan daha akıllı şeyler mi yapıyor?

Anthony: Evet, yani bir şema yazıyorsunuz, böylece bir schema.Prisma dosyası oluşturuyorsunuz ve bu model gönderisine sahip olacak ve ardından tarih ve saatte oluşturulan başlık dizesi, gövde dizesi gibi id ve tamsayı ve otomatik artışa sahip olacaktı. . Böylece, temel olarak türlerle veritabanınızda olmak istediğiniz şeyi yaratırsınız ve sonra veritabanıyla ilgili şeyleri sizin için yapar, böylece veritabanıyla etkileşime girmenize gerek kalmaz.

Drew: Yani, ne tür bir veritabanından veya ne tür bir veri deposundan bahsettiğinizi tahmin etmek için Prisma'yı kullanıyorsunuz. Ardından, bu tabiri kullanmak için farklı mvc modellerinizi orada düzenlersiniz. Öyleyse, uygulamanız veri depolarıyla konuşurken, bir tür Prisma istemcisinin örneğini kullanıyor, öyle değil mi? Olan bu mu?

Anthony: Evet. Evet, tam olarak bu. Bu nedenle, arka uçunuzun API klasöründe, db.js içeren bir lib klasörünüz vardır ve bu klasör yalnızca varsayılan olarak Prisma istemcinizin kurulumuna sahiptir. Yani kutudan çıkanlar bu kadar ve dediğin gibi Prisma farklı veritabanlarıyla çalışabilir. Geliştirme için SQLite ile üretim için Postgres arasında geçiş yapabilir, bu tür şeyler. Şu anda çoğunlukla ilişkisel ama yol haritasında Mongo ve Fauna gibi şeyler var.

Drew: Öyleyse, SQLite'ı yerel geliştirme ortamınızda kurup çalıştırırken kullanabiliyor ve ardından MySQL gibi bir şeyle üretime geçebiliyorsanız, bu oldukça kullanışlıdır.

Anthony: Öğretici tam olarak bu şekilde kurulur, size gösterdiği iş akışı budur.

Drew: Bir çerçeveye çok modern bir yaklaşım gördükten sonra MySQL gibi bu daha geleneksel veritabanlarından bazılarına geri dönmek oldukça ilginç, değil mi? MySQL'e çok aşinayım. Kararlılığı için seviyorum ve veri depolamanın ilişkisel yolunu seviyorum. Bence pek çok şey için çok iyi çalışıyor. Yeni veri deposu türleri söz konusu olduğunda genellikle banyo suyu olan bebeğin dışarı atıldığını görürsünüz, bu nedenle Redwood'un varsayılan olarak bu iyi, eski ilişkisel veritabanlarını desteklediğini görmek oldukça ilginçtir.

Anthony: Evet, hayır, bu çok iyi bir nokta, çünkü Redwood'un bir araya getirdiği tüm yeni şeyler için, aslında eski, denenmiş ve doğru yolun aslında en iyisi olduğunu söyleyen bazı şeyler var. Bu nedenle, ilişkisel veritabanlarında gerçekten büyükler. Bu, Tom'un Rails kullanma ve ilişkisel bir arka uca sahip olma deneyiminden gelir. Aktif Kayıt, Prisma'nın tahmin etmek istediği O/RM katmanıydı.

Drew: Sanırım, burada Redwood ile sunucusuz bir mimariden bahsediyoruz ve Chris Coyier ile sanırım iki veya üç bölüm önce, sunucusuz API'lerin kullanımı ve bulut işlevi ve diğer şeyler hakkında konuştuk. Yani, bir adım geri atarak, sunucu tabanlı bir çerçeve açısından düşünürseniz, Ruby on Rails veya PHP dünyasında Laravel gibi bir şeyden bahsettiğimiz gibi. Bir React ön ucunda bile, API isteğiniz Rails kodu veya Laravel kodu artı kullanıcı kodunuz ve yapılandırmanız olan kodu çalıştırıyor olacaktır. Redwood'da da durum aynı mı? Çalışan gerçek bir Redwood sunucu kodu var mı, yoksa kendinizinkini uygulamanızı sağlayan daha fazla araç, yapı ve yapıştırıcı mı?

Anthony: Evet, yani arka uçta, özellikle SDL'nizi almanın bir yolu olan bir dosya var, bu yüzden şema tanımlama diliniz var ve sonra hizmetleriniz var, bunlar sizinle konuşma yöntemleriniz gibi. arka uç. Ardından, tüm bunlar tek bir Lambda işlevine dağıtılan bir GraphQL işleyicisinde birleştirilir. Bu nedenle, özellikle Lambda için optimize edilmiştir. Aslında yakın zamanda birisine sunucusuz çerçeve ile yaptırdık ve Azure ve Google Cloud üzerinde çalışan bazı kişiler var. Bu Google Cloud işlevi değil, bunun üzerine kurulmuş olanıdır. Ama evet, yani şu anda arka uçunuzu bir AWS Lambda'da bir GraphQL işlevi olarak dağıtmak için temel olarak optimize edilmiştir. Anlamadığım kodda sihir olan şeyler bunlar, ama bu üst düzey açıklama.

Drew: Yani, orada yazdığınız tüm kodu alan, hepsini bir araya getirerek bulutta çalıştırılabilen ve AWS'ye yerleştiren bir tür sihirli kod topu haline getiren dağıtım araçları var. hala bu süreci kendiniz yönetmek zorunda mısınız?

Anthony: Evet, yani öğreticiyi takip ederseniz her şey Netlify üzerinden yapılır. Herhangi bir tür sunucusuz işlevle gerçekten uğraşmanıza gerek yok. AWS Lambda'ya sokmak için arka ucunuzu birbirine bağlayan şeyler, hepsi halledilir, bu kodlardan hiçbirine dokunmanız gerekmez. Bunların hepsi, yapılandırmalarınız üzerindeki kurallarınız olarak kutudan çıkarıldığından, onu sunucusuz hale getirme konusunda çok fazla düşünmeniz gerekmez. Varsayılan olarak sunucusuzdur. Kafanı sarmak gerçekten zor bir şey. Kafamı etrafına sarmam biraz zaman aldı.

Drew: Evet, çünkü bu önemli bir nokta çünkü şu anda burada takip ettiğimiz birkaç farklı alan var. Sanırım üç farklı alanımız var. Tarayıcıda çalışan ön uç React uygulamamız var ve ardından GraphQL tabanlı, bulut işlevi olarak çalışan ve sorgularımıza yanıt veren, ancak daha sonra bir veri deposuyla etkileşime giren bir API'miz var. hangi Prisma kullanır. Ve bu veri deposu bunun neresinde ve ne durumda, çünkü Netlify'da MySQL sunucusu çalıştıramazsınız, değil mi?

Anthony: Evet, işte burada Heroku devreye giriyor. Yani, öğreticinin en son bölümünde, ön ucunuzu Netlify'a dağıtıyorsunuz ve ardından arka ucunuzu Heroku Postgres'e dağıtıyorsunuz ve sadece Heroku'dan yapılandırma değişkenlerinizi alıp takıyorsunuz. Netlify'a girin. Netlify kullanıcı arabiriminizin Postgres arka ucunuzla konuşmasını sağlamak gerçekten çok basit bir şeydir. Herkesin harekete geçmesi en kolay olacak şeyle gitmek istediler, ancak yine de sağlam, savaşta test edilmiş bir teknolojiye sahipler. Sonunda, sadece talimatları izleyerek kutudan çıkardığınız şey gerçekten inanılmaz.

Drew: Jamstack meraklıları, API olarak veri deposu sağlayan FaunaDB, AWS'nin DynamoDB'si, Google'ın Cloud SQL'i vb. gibi hizmetlere aşina olacaktır. Yani, Redwood'un entegrasyona baktığından bahsettiniz, yoksa Prisma, bu tür hizmetlerle daha da ilerideki entegrasyona bakan bileşen mi?

Anthony: Evet, bu iyi bir soru. Bu aslında Prisma'dan Ryan Chenkie ile bir tür yardım hakkında konuştuğum bir şey, Redwood için Prisma ile çalışmayan şeyler için ne tür bir veritabanı hikayesi var? Redwood'u Fauna'da yaptığım gibi doğrudan onunla çalıştırmanın bir yolunu bulmak daha mı iyi yoksa Prisma için bir sürücü uygulamak daha mı mantıklı? Yani, ona yaklaşmanın farklı yolları var. Belli ki artık herkesin kullanmak istediği milyonlarca farklı veritabanı var, bu yüzden veri deponuzu buna almak için ne kadar motive oluyorsunuz. Orada bir sürü topluluk katkısı var.

Drew: Prisma modelinizi anladığı ve onları nasıl sorgulayacağını bildiği için, bu veritabanını kurmanıza yardımcı olacak bir tür geçişler veya bunun gibi şeyler üretebilir mi?

Anthony: Prisma'yı çıkarıp verilerinizi almanız gerektiğinde kaybettiğiniz şey tam olarak bu, tüm taşıma işlevlerini kaybetmeniz. Sizin için tonlarca şey yapan gerçekten gelişmiş bir CLI'ye sahiptir, böylece tüm Redwood eğitimini gözden geçirebilir ve Prisma komutlarını girebilirsiniz ve ne yaptığı hakkında hiçbir fikriniz olması gerekmez, sadece çalışır. Doğru yaptığınızdan emin olmak istediğiniz ve doğru yapıldığından emin olmak istediğiniz tüm bu tür veritabanı türü şeyleri yapmak için gerçekten harika bir araçtır.

Drew: Çerçeveler etrafında gerçekten iyi bir araç gereç kullanmak oldukça modern bir trend gibi görünüyor, değil mi? Sadece "Bu çerçevenin yapabileceği her şey burada, ama belki de sizin için bunların çoğunu yapacak bazı CLI araçları" demekle yetinmeyin. Redwood'un CLI oluşturucular gibi araçlara ve sizi hızlı bir şekilde çalıştırıp çalıştırmanıza yardımcı olacak araçları var mı?

Anthony: Bu muhtemelen Redwood'dan aldığınız en önemli özellik, bir dizi çok karmaşık jeneratöre sahip olmanız. DHH'nin verdiği orijinal Ruby on Rails demosunu gören herkes için, 15 dakika gibi bir sürede bir blog oluşturuyor ve hepsini Rails ile yapıyor ve insanlar “Vay canına, bu harika” diyor. Redwood'un sahip olduğu etki bu. Sayfalar oluşturabilmeniz, düzenler oluşturabilmeniz, bahsettiğim hücrelerinizi oluşturabilmeniz için her şeyi gerçekten hızlı bir şekilde döndürebilmenizi istiyorlar ve tüm yapınızı oluşturacak bir iskele komutu yapabilirsiniz. CRUD arayüzü. Bütün bir bölümüm var, blog serisinin dördüncü kısmı, sadece iskelenin size verdiği tüm kodları açıklıyor. Size çok fazla kod veriyor. Kapalı bir jeneratör var, hatta arka rüzgarınızı sizin için yapılandıran bir Tailwind jeneratörü bile var.

Drew: Bu harika. DHH'nin Rails demosunu gördüğümü hatırlıyorum. Yani, muhtemelen, 15 yıl önce o iskeleyi ilk yaptığında ve size gösterdiğinde ve yeni öğeler oluşturmanıza, düzenlemenize, silmenize vb. . Bu, bir projede paha biçilmez olabilir, özellikle bir tür dinamik ortamda çalışırken, tamam, belki gelecekte bu içeriği düzenlemek için daha iyi araçlar uygulayacaksınız, ancak bu, bir şeyi hızlı bir şekilde döndürebilmek anlamına gelir. verileri test edin, hatta bunu, ön uçta çalışırken çalışmaya başlayabilecek bir içerik ekibine bile verebilirsiniz, bu gerçekten yararlıdır.

Drew: Sadece bunu dağıtmak ve üretimde olmasını istiyorsanız, muhtemelen onu ön uç kodunuzla birlikte dağıtabilirsiniz, ancak bu yönü, uygulamanızdaki kökleri güvenceye almak için bir yola ihtiyacınız olacaktır.

Anthony: Evet, kimlik doğrulama için birkaç farklı seçenek var. Netlify kimliğini kullanabilirsiniz. Öğreticiye girerseniz varsayılan budur ve ardından Auth0'ı da kullanabilirsiniz ve ardından Magic.Link adında aşina olmadığım bir tane kullanabilirsiniz ve muhtemelen gelecekte birkaç tane daha eklenecektir. Ama evet, zaten orada bir çift yerleşik çözüm var ve bu yaptığınız en son şey, bu yüzden bu 12 bölümlük blog serimin en son bölümü Auth olan. Redwood'u kullanmadan önce Auth'u çözebileceğimi sanmıyorum. Zor ve kesinlikle onunla iyi bir iş çıkardılar.

Drew: Bu, bir rota düzeyinde mi yoksa bir rota düzeyinde mi entegre oluyor, pardon, işleri nasıl güvence altına alıyorsunuz?

Anthony: Evet, kendi yönlendiricilerine sahip olmalarının bir parçası, aynı zamanda... Özel rotalar yapabilirsiniz, böylece onların özel bir rota bileşeni olur. O zaman, asıl oturum açma formunuz, Netlify kimliğinden elde ettiğiniz budur, yani aslında bir form oluşturmanız ve bununla eyalet yönetiminizi yapmanız gerekmez, işte burada birçok sorun devreye girer. Gerçekten önemli parçaları alıp, ardından rol tabanlı erişimi uygulayabilirsiniz. David T gibi son birkaç hafta içinde yapılmış olan rol tabanlı erişim kontrolü eklentimiz var. Yani, bunu yapmanın başka yollarını yaratmak için çok fazla çalışma var, ama şimdi sahip oldukları şey zaten… çalışıyor, bu' seni işlevsel hale getirecek.

Drew: İnsanlar her zaman güvenlik algoritması hashing kriptografi hakkında söylerler, asla kendinizinkini yazmamalısınız çünkü asla orada olan şeyler kadar iyi olmayacak. Giderek, bunun daha yüksek düzeyde kimlik doğrulama için de geçerli olduğunu düşünüyorum; Bu kimlik doğrulama bugünlerde o kadar karmaşık bir alandır ki, insanlar yalnızca benzersiz kimlik bilgileriyle sitenize giriş yapmak istemiyor, aynı zamanda Google'ı kullanarak kimlik doğrulaması yapmak isteyebilir veya bir Apple cihazı kullanarak kimlik doğrulamak isteyebilir veya iki faktörlü kimlik doğrulama isteyebilir. veya bir kuruluştan kullandıkları tek bir oturum açma hizmetiyle entegre etmek isteyebilirler. Tüm bunlar, kendiniz denerseniz ve uygularsanız, bir baş ağrısı ve yanlış bir şeyler yapmak ve uygulamanızdaki güvenlik açıklarını açığa çıkarmak için o kadar çok fırsattır ki, bir kimlik doğrulama hizmeti kullanmak bu noktada neredeyse hiç akıllıca görünmüyor. Bu nedenle, yalnızca birkaç satır kodla bir şey bırakabilmek ve çalışır durumda olmak, çalışmak ve işleri güvende tutmak için gerçekten verimli bir yol gibi geliyor.

Drew: Görünüşe göre hem ön uç hem de sunucu yönlerini dağıtmak, sunucusuz işlev şeyleri, Netlify'a dağıtmak için doğal olarak uygun. Redwood ile buna mı bağlısın? Yani Tom Preston-Werner'ın bu çerçevenin ana savunucularından biri olduğundan bahsetmiştik, kendisi de Netlify'ın yönetim kurulunda. Bir projenin temeli olarak Redwood'u seçerseniz, orada çok sıkı bir bağlantı olma potansiyeli olduğunu düşünüyor musunuz?

Anthony: Evet, bu Tom'un kesinlikle bilincinde olduğu bir şey. Ortalıkta dolaşan birçok şirkete yatırım yaptı. Prisma ve Fauna'ya yatırım yaptı. Sadece kullanmak istediği araçları yapmak istiyor. Bu, Netlify'ın inşa ettiği şeyin en iyi seçenek olduğunu düşündüğü kadar, sizi bu şeye kilitlemek istememizle ilgili değil, bu yüzden bunun etrafında inşa ettiler. Ancak, herhangi bir dağıtım hedefine kilitlenmesini istemiyorlar ve bu yüzden sunucusuz çerçeve gibi şeyler üzerinde çalışıyoruz ve bazı insanlar Begin hakkında konuştu. Pragmatik olmak istiyoruz, birinin kullanım durumu ne olursa olsun işe yaramasını istiyoruz. Böylece, size yolun %90'ını sağlıyoruz ve ardından, seçtiğiniz sunucular ne olursa olsun, çalışmasını sağlamak için son birkaç şeyi bağlamanız gerekiyor.

Drew: Sanırım Netlify bile sunucu işlevleri için AWS Lambda kullanıyor, bu yüzden Redwood tarafından halledilen dağıtım kısmı gerçekten bu ve aslında bunu Lambda'ya kendiniz dağıtabilirsiniz. Kullanıcı arabiriminizi göndermek yalnızca dosyalardır, değil mi, geri kalanı CDN'ye dayalı mı? Yani, çok fazla bağlanmadan oldukça fazla esneklik var.

Anthony: Evet, aslında Tom'un Redwood'un arkasındaki temel felsefi fikir olarak bahsettiği bir terim var, o da evrensel bir dağıtım makinesine ulaşmak istediğimizdir. Bu pek iyi bir fikir değil, sadece bir şeyleri dağıtabilirsiniz ve bunun hakkında hiç düşünmenize gerek yok. Yıllardır bu fikir hakkında konuşuyor ve Jekyll'in o zamanlar hakkında konuştuğu şey de buydu. Bunu şimdi duyduğunuzda, “Ah, Netlify gibi mi demek istiyorsunuz?” diyorsunuz. Netlify, ön uçta çalışan çoğu insan için temel olarak budur. Artık konuşlandırmayı düşünmüyorlar bile, bu bir düşünce bile değil.

Drew: İşte bir Git Repo'daki uygulamam, bu dizin ön uç, bu dizin arka uç, işte benim veritabanım ve bu, onu almak ve inşa etmek için hangi hizmet olursa olsun, belki de ihtiyaç duyacağınız kadar konfigürasyon. ve barındırın.

Anthony: Evet, ayrıca belirtmem gereken bir şey var, yakın zamanda Vercel Redwood varsayılan dağıtım kurulumunu yaptık, bu nedenle bir sunucu tarafı uygulamasına dağıtım yaparken “Ah, Gatsby uygulamam var” diyebilirsiniz ve Bir NextApp'e karşı bir Gatsby uygulamasının nasıl oluşturulacağını tam olarak bilir. Şimdi bunu Vercel için aldık. Yani, eğer buna daha çok ilgi duyuyorsanız, gerçekten, gerçekten iyi Netlify dışı seçenekler de var.

Drew: Yani, bir uygulama geliştirip bu hafta üretime geçirmek istersem, Redwood buna hazır mı? olgun mu

Anthony: Evet, şu anda üretimde olan yaklaşık yarım düzine uygulamamız var. İlki Mart ayında ortaya çıkan Predict COVID olarak adlandırıldı ve gerçek zamanlı bir veri görselleştirme uygulaması gibi. Ardından, Rob tarafından yapılan tekrarlayıcı.dev'imiz var, bu Jamstack için cron işi gibi bir şey. Sonra Tape.sh var, Duoflag bence başka bir tane. Yani, en az bir avuç var. Harika bir Redwood deposuna giderseniz, hepsinin bir listesini görebilirsiniz. Topluluk forumlarına giderseniz, bunların yazılarını da bulabilirsiniz, çünkü insanlar bunları üretime soktu ve nasıl gittiğini söyledi. Şimdiye kadar hepsi başarılı oldu ve kimse “Bunu bir daha asla kullanmayacağım” demedi.

Drew: Ama, bu çok yeni. Sanırım bundan kaçış yok ama olgunluk açısından Redwood oldukça yeni, iyi bir takipçi kitlesi alıyor.

Anthony: Eh, komik, öyle ve değil. Mart ayında açıklandı. Bu noktada, Tom ve Peter tarafından yaklaşık bir yıl boyunca üzerinde çalışılmıştı. So, they'd already put a ton of upfront work into this, so it wasn't like I'm going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn't… It's not a 1.0 now, but it's pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it's not ready. So, we say it's not ready for production even though it's in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they'll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they're then left with a big project to update everything onto the new version of the framework. Is that something that's likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it's structured, do you think that's a big danger or a little danger?

Anthony: Yeah, it's a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there's a version bump, you just do a command and it bumps you up the version. I've been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it's like 0.17 or something now. So, I've been slowly iterating on it as it's gone but nothing breaks. It's all, you get slowly things, or like “Oh, this is kind of a nice little touch you've got here,” but it's pretty much set in stone architecturally. Redwood as it's structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That's why they built it, so they could get something that's structured like this thing.

Drew: I guess with modern web development, there is a certain point where you're just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That's exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it's called that, is that you can just make a site and deploy it and it's not going to break, it's just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that's huge. Being built by people who tried to scale Rails apps, I imagine they've thought a lot about that. But in terms of the going away part, that's always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don't think you even need to worry about that because Tom's a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that's going on, so I wouldn't worry about that too much-

Duru: Elbette.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it's very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There's few people with more open source cred than Tom, so he's done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I'm a boot camp student, I'm learning all this stuff as I go. I'm not pushing code to the repo, I'm making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there's really a lot of things about how they approach community building that I have a lot of respect for, and that is why I've been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. For example. The Python framework, Django came out of online news publishing, and so it's a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It's made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you're starting with a web front end but you're pretty sure you're going to end up with a mobile client as well, then it's a really good fit for that because it starts you off in a way that you're going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I'd say that'd probably be the first thing that I would say is its sweet spot. But, it's meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it's going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we're working on, things we think we're kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That's one of the things we're really great about is showing here are the things that still need to be worked on. They're aiming for 1.0 by the end of the year. We'll see where we get with that, but that's the trajectory we're currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it's this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I'm in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We're essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it's all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it's much more modular than you would think based on… You talk about it, and like you said, it sounds like it's a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it's made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn't mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it's going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven't talked about?

Anthony: No. I mean, I would say if you're interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that's why it's a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They've really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you're interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I've been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I've been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you've been around the block, you know a lot of CMSs. Obviously, you know you've got your WordPress's, your Drupal, but what's really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it's just such a natural fit. So, I'm trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I'm not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I've not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you've got to join the club, dude.

Drew: Yeah, no, I'm definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it's certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn't really know GraphQL, and I'd say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You'll learn a lot and you'll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it's interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we'll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. Ayrılık sözleriniz var mı?

Anthony: Sadece bu şeylerden herhangi biriyle ilgileniyorsanız, ulaşmaktan çekinmeyin. DM'lerim her zaman açıktır. Topluluk genel olarak çok açıktır. Açıklamaktan, adım adım ilerlemek veya ilerlemek için bilmeniz gereken her şeyi size hazırlamaktan memnuniyet duyarım.