Smashing Podcast Episode 25 Dengan Anthony Campolo: Apa Itu RedwoodJS?

Kita berbicara tentang RedwoodJS. Apa sebenarnya yang dimaksud dengan kerangka kerja Jamstack full-stack? Saya berbicara dengan juara komunitas Anthony Campolo untuk mencari tahu.

Tampilkan Catatan

• RedwoodJS
• Anthony di Twitter
• Seri artikel Anthony Pandangan Pertama di RedwoodJS

Update mingguan

• “Pengantar Menjalankan Lighthouse Secara Terprogram”
  ditulis oleh Katy Bowman
• “Menganimasikan Komponen React Dengan GreenSock”
  ditulis oleh Blessing Krofegha
• “Merancang Untuk Perhatian”
  ditulis oleh Victor Yocco
• “Penggunaan GraphQL Tingkat Lanjut Di Situs Web Gatsby”
  ditulis oleh Aleem Isiaka
• “Membandingkan Metode Styling Di Next.js”
  ditulis oleh Adebiyi Adedotun

Salinan

Drew McLellan: Dia adalah siswa Sekolah Lambda, mempelajari pengembangan web tumpukan penuh, serta menjadi kontributor untuk RedwoodJS. Sebagai seorang juara komunitas, dia baru-baru ini menulis rangkaian artikel 12 bagian berjudul A First Look at RedwoodJS yang membantu menjelaskan asal usul dan motivasi Redwood, bersama dengan banyak konsep berbeda yang diperkenalkan oleh framework. Jadi, kita tahu dia ahli di RedwoodJS, tapi tahukah Anda bahwa dia tidak pernah melihat anjing? Teman-temanku yang hebat, tolong sambut Anthony Campolo.

Drew: Hai, Anton. Apa kabar?

Anthony Campolo: Halo. Saya menghancurkan, terima kasih banyak telah memiliki saya.

Drew: Saya ingin berbicara dengan Anda hari ini, dan mungkin sudah jelas dari pendahuluan, tentang RedwoodJS. Bagi mereka yang belum pernah mendengar tentang RedwoodJS sebelumnya, apa itu?

Anthony: Saya pikir ada beberapa cara Anda dapat menggambarkannya tergantung dari mana orang berasal, tetapi definisi kanoniknya adalah kerangka kerja tanpa server tumpukan penuh untuk Jamstack. Jadi, ini menggabungkan pengembangan web tumpukan penuh dengan hal-hal jenis AWS Lambda tanpa server dan Jamstack, yang merupakan hal besar akhir-akhir ini.

Drew: Jadi, ini adalah kerangka kerja tumpukan penuh yang mencoba mengumpulkan banyak ide seputar ekosistem pengembangan Jamstack? Apakah itu benar?

Anthony: Ya, ini mendorong batas-batas aplikasi Jamstack, jadi dengan menyebutnya tumpukan penuh, Jamstack, ini tentang bagaimana kita melampaui hanya front end untuk memiliki paradigma penerapan yang sama, hanya didorong, mendapatkan seluruh kode Anda dikerahkan. Bagaimana kita mendapatkannya tetapi juga dengan back end kita, dan semuanya terhubung?

Drew: Sekarang, sebelum kita mempelajarinya terlalu dalam, saya pikir cukup menarik untuk mendengar bahwa itu dari tim yang cukup berpengalaman, bukan? Orang-orang di belakang Redwood, mereka bukan ayam musim semi. Bukan untuk mengatakan mereka sudah tua, tetapi mereka sudah sekitar blok, bukan, dalam hal pengembangan web?

Anthony: Mereka sudah berpengalaman. Ya, saya sebenarnya telah meluangkan banyak waktu untuk menulis tentang sejarah kerangka kerja dan ide-ide yang mengarah ke sana, dan Tom Preston-Werner adalah penciptanya, jadi dia juga dikenal sebagai pencipta Jekyll, yang adalah generator situs statis yang sangat berpengaruh. Dia juga melakukan TOML, bahasa file konfigurasi. Dan dia adalah CEO GitHub awalnya. Jadi, karyanya dengan halaman Jekyll dan GitHub dan hal semacam itu menurut saya benar-benar mengarah pada apa yang sekarang kita anggap sebagai Jamstack. Banyak orang akan berkata, “Oh, Jamstack baru. Mereka telah melakukan ini selamanya.” Begitulah cara kami berbicara tentang bagaimana ini merupakan perpanjangan dari ide-ide lama ini, generasi situs statis, tetapi dengan GraphQL dan tanpa server dan ide-ide tentang bagaimana menggunakan kode glue dan API untuk membuat aplikasi Anda bekerja.

Drew: Jadi, ini pasti dari orang-orang yang sangat melekat di komunitas itu? Maksud saya, CEO GitHub, Anda benar-benar tidak bisa lebih tertanam dalam komunitas open source semacam itu daripada itu. Jadi, Redwood adalah kerangka kerja tumpukan penuh dan saya rasa itu berarti Anda menjalankan kode Redwood di ujung depan dan di ujung belakang. Apakah itu benar?

Anthony: Ya, ini adalah hal pertama yang ingin saya jelaskan kepada orang-orang ketika saya menunjukkan proyek Redwood kepada mereka, adalah bahwa itu adalah monorepo. Jadi, Anda memiliki front end dan backend Anda di repo yang sama, dan kemudian masing-masing dari mereka tinggal di folder mereka sendiri. Anda memiliki folder web, yang merupakan ujung depan Anda, dan itu cukup mirip dengan apa yang Anda dapatkan dari aplikasi Create React. Kemudian, Anda memiliki folder API, yang merupakan bagian belakang Anda, dan di sinilah semua fungsi Anda pada dasarnya didorong ke dalam satu pengendali GraphQL besar yang disebarkan ke AWS Lambda melalui Netlify.

Drew: Oke, jadi mulai dari depan, seperti yang Anda sebutkan, ini didasarkan pada React. Apakah itu React plus sekumpulan kode Redwood, atau hanya React biasa? Apa saldo di sana?

Anthony: Banyak hal. Ini pasti hanya Bereaksi dalam arti Anda tidak membawa banyak perpustakaan manajemen negara, Anda bahkan tidak membawa router sebenarnya. Mereka memiliki router sendiri yang mereka tulis, dan mereka menggunakan banyak barang GraphQL. Jadi, ketika orang berbicara tentang React dan GraphQL dan teman-teman, itu sedikit dari apa yang terjadi di sini, adalah memberi Anda banyak integrasi default untuk membuat React berbicara dengan GraphQL Anda. Karena kami memiliki banyak konvensi sekarang tentang cara menggunakan React, tetapi pengambilan data masih sangat merepotkan.

Drew: Jadi, React dikonfigurasikan dengan sekumpulan alat lain yang bekerja dengan baik dengan React untuk memberi Anda ekosistem yang berfungsi untuk melakukan gaya tugas khusus ini. Apakah itu deskripsi yang adil?

Anthony: Ya, tidak, ya, itu cara yang bagus untuk mengatakannya. Cara Tom mengatakan bahwa ada semua solusi breed terbaik yang ada, dan alat dan teknologi yang sangat canggih yang dapat kita gunakan, tetapi sangat sulit untuk benar-benar memanfaatkannya karena Anda memiliki biaya awal yang sangat besar, dan harus mempelajarinya , harus mencari cara untuk mengintegrasikannya. Jadi, mereka menempatkan tagline sebagai, "Kami melakukan konfigurasi webpack untuk Anda."

Drew: Saya pikir ini adalah masalah umum yang Anda dengar dari banyak orang ketika mereka mencoba untuk memulai kerangka kerja pengembangan modern dengan aplikasi JavaScript sisi klien dan mengonfigurasi paket web, mengonfigurasi semua hal yang berbeda, proses pembuatan, membangun langkah. Ini bisa menjadi ladang ranjau, bukan, untuk membuat semuanya terhubung dan bekerja? Dan itu jauh sebelum Anda sampai ke "Halo, Dunia!". Jadi, Redwood memberi kita semua yang sudah dikonfigurasi sebelumnya?

Anthony: Ya, itu adalah konvensi tentang ide jenis konfigurasi, karena Anda telah… Tom, seperti dia membangun GitHub dengan Ruby on Rails dan Rob, salah satu kontributor inti lainnya, dia telah menjadi pengembang Rails selamanya. Mereka memiliki banyak ide yang secara filosofis mereka selaraskan dengan Rails, tetapi mereka ingin mengambil konvensi tersebut daripada ide konfigurasi, ide kerangka tumpukan penuh, dan menerapkannya dengan semua teknologi modern yang kita miliki sekarang.

Drew: Jadi, Anda menyebutkan bahwa Redwood memberi Anda router atau router, seperti yang kami katakan di sisi kolam ini, apakah itu datang dengan hal-hal seperti komponen default dan hal-hal semacam itu di React, atau apakah Anda baru saja untuk menerapkan semua itu sendiri?

Anthony: Ya, routernya sangat canggih. Itu melakukan sebagian besar hal yang akan Anda dapatkan hanya dari router React, itu hanya memiliki ide yang berbeda dalam hal bagaimana ini harus diterapkan, karena Next mereka juga memiliki router mereka sendiri, dan masih belum sepenuhnya memahami bagaimana kami ingin membuat perutean aplikasi satu halaman kami berfungsi. Karena Ketegangan, Anda memiliki banyak pertanyaan semacam ini tentang di mana hal-hal asinkron akan masuk? Kami memiliki dengan Redwood, gagasan tentang sel ini, dan inilah yang sebenarnya diambil oleh data Anda untuk Anda.

Drew: Jadi, mungkin kita bisa membahasnya sedikit? Apa yang dimaksud dengan sel dalam istilah Redwood?

Anthony: Ya, jadi sel adalah cara default untuk menulis kueri GraphQL dan kemudian membuat halaman Anda pada dasarnya memberi tahu apakah Anda mendapatkan data kembali, apakah Anda mendapatkan kesalahan kembali, apakah Anda sedang dalam keadaan memuat, atau apakah… Ada satu keadaan lagi, saya lupa. Tapi ya, jadi ini memberi Anda status berbeda yang pada dasarnya Anda dapat berdasarkan apakah Anda mendapatkan data atau tidak. Ini setup dengan Apollo di bawah selimut. Jadi, jika Anda menggunakan Redwood, Anda menggunakan Apollo sebagai klien GraphQL Anda, tetapi Anda tidak perlu memikirkannya. Anda tidak perlu menulis Apollo apa pun atau bahkan memikirkannya, semuanya sudah matang. Ini memungkinkan Anda hanya menulis kueri GraphQL, yang benar-benar merupakan impian mengapa orang menginginkan GraphQL, adalah bahwa bahasa kueri yang sangat sederhana inilah yang dikembangkan oleh front end devs dapat menggunakan. Tapi kemudian, Anda harus memikirkan cara menyiapkan server GraphQL, Anda harus memikirkan semua hal lain ini, dan bagaimana Anda memasang semuanya. Jadi, ia melakukan semua integrasi GraphQL untuk Anda sehingga Anda cukup menulis GraphQL, Anda tidak perlu memikirkan bagaimana cara mengimplementasikan GraphQL.

Drew: Jadi, saya kira salah satu pekerjaan klasik dari sebuah kerangka kerja adalah mengambil semua kode pelat ketel yang dapat Anda tulis sendiri dan menerapkannya untuk Anda, dan merapikan cara di belakang layar sehingga Anda tidak perlu melihat pelat ketel itu lagi, dan Anda bisa menulis kode yang unik untuk keadaan Anda. Saya kira itu yang terjadi dengan sel bukan? Tidak ada yang revolusioner di sini, ini adalah sesuatu yang Anda dapat mengatur komponen React untuk memiliki semua status yang berbeda ini dan Anda dapat menghubungkan Apollo dan Anda dapat melakukan semua ini sendiri, tetapi itu sebenarnya cukup banyak pekerjaan dan itu adalah pola yang umum. Jadi, Redwood telah merapikan menjadi pola yang bagus dan dapat digunakan kembali yang dapat Anda gunakan tanpa harus memikirkannya. Apakah itu deskripsi yang bagus?

Anthony: Ya, mereka datang dengan nama itu tetapi mereka pasti mengakui bahwa ini adalah praktik yang sering mereka lihat dan bahwa mereka melihat banyak orang hanya mengkodekannya sendiri, dan mereka memutuskan bahwa mereka menginginkan cara deklaratif untuk melakukan pengambilan data Anda. Jadi, itulah mengapa Anda memiliki pengaturan ini, karena ini memungkinkan Anda memiliki status yang berbeda dan Anda tidak perlu melakukan logika if/then untuk mencari tahu, perlu melakukan ini jika ini terjadi. Jadi, ini tentang hanya memiliki satu cara untuk mendeklarasikan semua status berbeda yang mungkin dimiliki data Anda saat Anda memuatnya.

Drew: Itu salah satu karakteristik React, kan, React tidak mencoba dan memberi Anda arsitektur untuk proyek Anda, ini memungkinkan Anda memutuskan bagaimana Anda akan menyusun sesuatu. Hal itu tentu saja menimbulkan pro dan kontra. Tapi, sepertinya Redwood memaksakan beberapa struktur itu untuk Anda sehingga Anda tidak perlu memikirkannya dan agar itu bisa membantu Anda dan semacam melanjutkan di mana React tinggalkan dalam hal memberi Anda struktur semacam itu.

Anthony: Ya, dan saya pikir sangat menarik bahwa kita telah melihat beberapa upaya yang berbeda dalam solusi untuk masalah ini, karena maksud saya Anda memiliki orang-orang yang telah mengatakannya selamanya, “Mengapa tidak ada Rails untuk JavaScript atau Rails for React?” Ada wawancara Full Stack Radio yang hebat antara Michael Chan dan Adam Wathan yang disebut React is Not a Rails pesaing. Ini adalah salah satu kerangka kerja yang berbeda.

Anthony: Yang lainnya adalah BlitzJS yang mendapat banyak buzz, dan kemudian Bison adalah jenis yang baru dan akan datang. Mereka semua memiliki tumpukan yang sama, tetapi mereka menggunakan bagian yang berbeda. Anda akan memiliki kueri React alih-alih Apollo, atau Anda akan memiliki Chakra alih-alih Tailwind. Orang-orang yang mengumpulkan semua bagian ini ke dalam tumpukan mereka, semua tumpukan ini adalah sejenis, mereka bertarung habis-habisan, semuanya adalah kompetisi yang sangat bersahabat. Sebenarnya, satu hal yang sangat saya hargai, adalah kita semua sebenarnya juga berkolaborasi antar framework. Tidak ada permusuhan di sana.

Drew: Jadi, kami telah menyebutkan Apollo dan GraphQL, Redwood menggunakan GraphQL cukup banyak sebagai salah satu bagian inti, bukan, dari kerangka kerja? Kami mungkin dapat mendedikasikan seluruh episode podcast hanya untuk GraphQL, tetapi bagi mereka yang tidak terbiasa, bagian apa yang dilakukan GraphQL di sini, masalah apa yang dipecahkannya dalam konteks ini?

Anthony: Ya, ini pertanyaan yang bagus. Ketika saya memberi tahu orang-orang apa yang harus mereka ketahui untuk memulai dengan Redwood, saya akan mengatakan bahwa Anda seharusnya menggunakan aplikasi Create React, hanya jika Anda telah membuat aplikasi Create React, dan Anda telah menerapkannya ke Netlify atau Vercel, itu akan membantu Anda memulai. Kemudian, tahu setidaknya sedikit GraphQL karena sangat sentral. Jadi, GraphQL adalah bagaimana ujung depan Anda akan berbicara dengan ujung belakang Anda. Mereka mengatakan itu adalah bahasa kueri untuk API, gagasannya adalah bahwa itu dimaksudkan sebagai alternatif untuk metode RESTful API, dan alih-alih melakukan hal yang RESTful, Anda mengirim kueri yang menentukan dengan tepat struktur data hierarkis yang ingin Anda terima kembali dari data. Jadi, dibutuhkan sedikit lebih banyak waktu untuk memulai agar server GraphQL Anda dapat berbicara dengan dua bagian. Kemudian, setelah Anda memilikinya di sana, pengembang front end memiliki kemampuan untuk mendapatkan data dengan cara yang jauh lebih fleksibel. Anda tidak memerlukan semua titik akhir API berbeda yang harus terus dibuat oleh orang-orang di belakang Anda.

Drew: Jadi, jika ada perubahan persyaratan di bagian depan, mungkin Anda dapat mengubah kueri GraphQL Anda dan Anda tidak memerlukan bantuan seseorang yang bekerja di bagian belakang untuk membuat perubahan itu untuk Anda?

Anthony: Maksud saya, mimpi sebenarnya adalah Anda dapat menggunakan klien seluler untuk itu, yang pada akhirnya akan menjadi fleksibel, Anda dapat memiliki banyak klien yang semuanya berbicara dengan satu API Anda. GraphQL API Anda menjadi sumber kebenaran Anda, di situlah semua logika Anda terpusat. Kemudian, Anda dapat membangun semua lapisan tampilan yang berbeda ini di atas.

Drew: Jadi, kami memiliki GraphQL yang memberi kami kemampuan untuk menanyakan semacam back end. Di Redwood, apa bagian belakangnya?

Antonius: Ya. Ada beberapa cara berbeda untuk membuat bagian belakang Anda. Ada cara Anda akan keluar dari kotak dengan tutorial, yaitu Anda menggunakan database Postgres yang digunakan di Heroku, super mudah, super sederhana. Kemudian, aplikasi Redwood Anda berbicara dengan Prisma. Saya tidak tahu apakah Anda akrab sama sekali dengan Prisma, tetapi itu seperti O/RM. Mereka secara khusus mengatakan itu bukan O/RM, ini adalah pembuat kueri, yang levelnya sedikit lebih rendah. Tapi, hanya untuk menjelaskannya kepada orang-orang, Prisma adalah hal yang memungkinkan Anda berbicara dengan database Anda. Itu melakukan migrasi Anda dan mengatur tabel Anda. Itu melakukan semua hal SQL sehingga Anda tidak perlu menulis SQL. Bagi saya, itu terdengar seperti O/RM. Anda tidak perlu menggunakan Prisma meskipun untuk menggunakan Redwood.

Anthony: Saya benar-benar membuat aplikasi konsep bukti di mana kami menggunakan FaunaDB sebagai gantinya. FaunaDB, mereka memiliki GraphQL API sendiri, jadi Anda cukup mengirim GraphQL API langsung ke Fauna, dan kemudian melakukan mutasi database Anda seperti itu. Anda kehilangan banyak fungsi CLI Prisma, tetapi Prisma benar-benar merupakan faktor kenyamanan untuk bekerja dengan sangat mudah dengan database relasional Anda. Tapi sungguh, apa pun yang Anda pikirkan, Anda bisa mencari cara untuk menghubungkannya dengan Redwood adalah apa yang saya temukan hanya karena itu dibangun di sekitar GraphQL dan intinya adalah untuk dapat berbicara dengan semua bagian yang berbeda ini.

Drew: Jadi, Prisma pada dasarnya adalah semacam lapisan abstraksi antara kode Anda dan penyimpanan data apa pun yang Anda gunakan yang mungkin didukung oleh Prisma, apakah itu… atau apakah itu melakukan hal-hal yang lebih cerdas dari itu?

Anthony: Ya, jadi Anda menulis skema, jadi Anda membuat file skema.Prisma, dan itu akan memiliki pos model, dan kemudian akan memiliki id dan bilangan bulat dan kenaikan otomatis, seperti sengatan judul, string tubuh, dibuat pada tanggal, waktu . Jadi, pada dasarnya Anda akan membuat apa yang Anda inginkan dalam database Anda dengan tipenya, dan kemudian melakukan hal-hal database untuk Anda sehingga Anda tidak perlu berinteraksi dengan database.

Drew: Jadi, Anda menggunakan Prisma untuk menentukan, saya kira database macam apa atau penyimpanan data macam apa yang Anda ajak bicara. Kemudian, di sana Anda meletakkan model mvc Anda yang berbeda untuk menggunakan bahasa itu. Jadi, ketika aplikasi Anda berbicara dengan penyimpanan data, itu seperti menggunakan instance dari klien Prisma, bukan? Apakah itu yang terjadi?

Antonius: Ya. Ya, itulah tepatnya. Jadi, di folder API bagian belakang Anda, Anda memiliki folder lib dengan db.js, dan secara default klien Prisma Anda sudah diatur. Jadi, hanya itu yang Anda dapatkan, dan seperti yang Anda katakan, Prisma dapat bekerja dengan database yang berbeda. Itu dapat beralih antara SQLite untuk pengembangan dan kemudian Postgres untuk produksi, hal semacam itu. Ini sebagian besar relasional sekarang, tetapi peta jalan memiliki hal-hal seperti Mongo dan Fauna di atasnya.

Drew: Jadi, itu cukup berguna jika Anda dapat mengatur dan menggunakan SQLite di lingkungan pengembangan lokal Anda saat Anda menyiapkan dan menjalankannya, dan kemudian masuk ke produksi dengan sesuatu seperti MySQL.

Anthony: Begitulah cara tutorial diatur, itulah alur kerja yang ditunjukkannya kepada Anda.

Drew: Sangat menarik, bukan, untuk melihat pendekatan yang sangat modern untuk sebuah kerangka kerja kemudian menggunakan beberapa database yang lebih tradisional seperti MySQL. Saya sangat akrab dengan MySQL. Saya menyukainya karena stabilitasnya dan saya menyukai cara relasional dalam menyimpan data. Saya pikir itu bekerja sangat baik untuk banyak hal. Seringkali Anda melihat bayi dibuang yang merupakan air mandi ketika datang ke jenis penyimpanan data yang lebih baru, jadi cukup menarik untuk melihat Redwood secara default mendukung database relasional lama yang bagus ini.

Anthony: Ya, tidak, itu poin yang bagus, karena saya mengatakan bahwa untuk semua hal baru yang digabungkan oleh Redwood, ada beberapa hal yang sebenarnya mengatakan cara lama, yang dicoba dan yang benar sebenarnya yang terbaik. Jadi, mereka sangat besar dalam database relasional. Itu berasal dari pengalaman Tom menggunakan Rails dan memiliki back end relasional. Rekaman Aktif adalah lapisan O/RM yang dimaksudkan untuk didekati oleh Prisma.

Drew: Saya kira, kita berbicara tentang arsitektur tanpa server di sini dengan Redwood, dan kami berbicara dengan Chris Coyier Saya pikir dua atau tiga episode lalu, semua tentang tanpa server menggunakan API dan fungsi cloud dan hal-hal lainnya. Jadi, mundur selangkah, jika Anda berpikir dalam kerangka kerja berbasis server, seperti yang kami sebutkan Ruby on Rails atau sesuatu seperti Laravel di dunia PHP. Bahkan dengan front end React, permintaan API Anda akan menjalankan kode yaitu kode Rails atau kode Laravel plus kode pengguna dan konfigurasi Anda. Apakah itu sama dengan Redwood? Apakah ada kode server Redwood aktual yang berjalan, atau hanya lebih banyak alat dan struktur dan lem yang memungkinkan Anda untuk mengimplementasikan kode Anda sendiri?

Anthony: Ya, jadi di bagian belakang, ada file khusus yang merupakan cara untuk mengambil SDL Anda, jadi Anda memiliki bahasa definisi skema Anda, dan kemudian Anda memiliki apa yang disebut layanan Anda, yang seperti metode Anda untuk berbicara dengan Anda ujung belakang. Kemudian, semua ini digabungkan menjadi handler GraphQL yang diterapkan ke satu fungsi Lambda. Jadi, ini dioptimalkan untuk Lambda secara khusus. Kami sebenarnya baru-baru ini meminta seseorang melakukannya dengan kerangka kerja tanpa server, dan kami memiliki beberapa orang yang mengerjakan sesuatu di Azure dan Google Cloud. Ini bukan fungsi Google Cloud, itu yang dibangun di atas itu. Tapi ya, jadi sekarang pada dasarnya dioptimalkan untuk menerapkan back end Anda sebagai fungsi GraphQL di AWS Lambda. Ini adalah hal-hal ajaib yang terjadi dalam kode yang saya tidak mengerti, tapi itulah penjelasan tingkat tinggi.

Drew: Jadi, ada alat penerapan di sana, yang mengambil semua kode yang telah Anda tulis, menyatukan semuanya menjadi semacam bola ajaib kode yang dapat dieksekusi di cloud dan memasangnya ke AWS atau Anda masih harus mengelola proses itu sendiri?

Anthony: Ya, jadi semuanya dilakukan melalui Netlify jika Anda mengikuti tutorialnya. Anda tidak perlu mengotak-atik sendiri segala jenis fungsi tanpa server. Hal-hal yang menghubungkan ujung belakang Anda untuk memasukkannya ke dalam AWS Lambda, itu saja yang ditangani, Anda tidak perlu menyentuh kode itu. Itu semua dihasilkan di luar kotak sebagai konvensi Anda atas konfigurasi Anda sehingga Anda tidak perlu terlalu memikirkan cara membuatnya tanpa server. Ini tanpa server secara default. Ini benar-benar hal yang sulit untuk membungkus kepala Anda. Butuh beberapa saat bagi saya untuk membungkus kepala saya di sekitarnya.

Drew: Ya, karena itu poin penting bukan karena sekarang ada beberapa area berbeda yang kami pantau di sini. Kami punya saya pikir tiga bidang yang berbeda. Kami memiliki aplikasi React ujung depan kami, yang berjalan di browser, dan kemudian kami memiliki API yang berbasis GraphQL, berjalan sebagai fungsi cloud, dan yang menanggapi pertanyaan kami, tetapi kemudian berinteraksi dengan penyimpanan data yang menggunakan Prisma. Dan penyimpanan data itu adalah apa dan di mana dalam hal ini, karena Anda tidak dapat menjalankan server MySQL di Netlify, bukan?

Anthony: Ya, di situlah Heroku masuk. Jadi, di bagian terakhir dari tutorial, Anda menyebarkan ujung depan Anda ke Netlify dan kemudian Anda menyebarkan ujung belakang Anda ke Heroku Postgres dan Anda hanya mengambil variabel konfigurasi Anda dari Heroku, pasang ke Netlify. Membuat ujung depan Netlify Anda berbicara dengan ujung belakang Postgres Anda adalah hal yang sangat, sangat sederhana. Mereka ingin pergi dengan hal yang akan menjadi yang paling mudah bagi siapa saja untuk mendapatkan berputar, tetapi masih memiliki stabil yang baik, teknologi pertempuran diuji. Pada akhirnya, apa yang Anda dapatkan hanya dengan mengikuti petunjuknya, sungguh luar biasa.

Drew: Penggemar Jamstack akan terbiasa dengan layanan seperti FaunaDB yang Anda sebutkan yang menyediakan penyimpanan data sebagai API, AWS memiliki DynamoDB, Google memiliki Cloud SQL, dan sebagainya. Jadi, Anda menyebutkan bahwa Redwood sedang mempertimbangkan integrasi, atau saya kira Prisma adalah komponen di sini yang ingin mengintegrasikan dengan layanan semacam itu di masa mendatang?

Anthony: Ya, ini pertanyaan yang bagus. Ini adalah sesuatu yang sebenarnya saya bicarakan dengan Ryan Chenkie di Prisma tentang jenis bantuan, apakah jenis cerita database untuk Redwood untuk hal-hal yang tidak selalu bekerja dengan Prisma? Apakah lebih baik mencari cara untuk membuat Redwood bekerja dengannya secara langsung seperti yang saya lakukan dengan Fauna atau apakah lebih masuk akal untuk menerapkan driver untuk Prisma? Jadi, ada berbagai cara untuk mendekatinya. Jelas ada sejuta database berbeda sekarang yang ingin digunakan semua orang, jadi seberapa termotivasi Anda untuk memasukkan penyimpanan data Anda ke dalamnya. Ada banyak kontribusi komunitas yang masuk ke sana.

Drew: Jadi, karena Prisma memahami model Anda dan tahu cara menanyakannya, apakah Prisma dapat menghasilkan semacam migrasi atau hal-hal seperti itu untuk membantu Anda menyiapkan basis data itu?

Anthony: Itulah hal yang Anda kehilangan ketika Anda harus mengambil Prisma dan mengambil data Anda, adalah bahwa Anda kehilangan semua fungsi migrasi. Ini memiliki CLI yang sangat canggih yang melakukan banyak hal untuk Anda, sehingga Anda dapat membaca seluruh tutorial Redwood dan memasukkan perintah Prisma dan Anda tidak perlu tahu apa yang dilakukannya, itu hanya berfungsi. Ini adalah alat yang sangat hebat untuk melakukan semua jenis jenis database yang Anda ingin pastikan Anda melakukannya dengan benar dan Anda ingin memastikannya dilakukan dengan benar.

Drew: Sepertinya memiliki alat yang sangat bagus di seputar kerangka kerja adalah tren yang cukup modern, bukan? Untuk tidak hanya mengatakan, “Inilah semua hal yang dapat dilakukan oleh kerangka kerja ini, tetapi mungkin inilah beberapa alat CLI yang akan melakukan banyak hal untuk Anda.” Apakah Redwood memiliki alat untuk hal-hal seperti generator CLI dan hal-hal lain untuk membuat Anda bangun dan berjalan dengan cepat?

Anthony: Ini mungkin fitur utama terbesar yang Anda dapatkan dari Redwood, adalah Anda mendapatkan seluruh rangkaian generator yang sangat canggih. Bagi siapa saja yang pernah melihat demo Ruby on Rails asli, yang diberikan DHH, dia membangun blog dalam waktu 15 menit dan dia melakukan semuanya dengan Rails, dan orang-orang seperti, “Wah, ini luar biasa.” Itulah efek yang dilakukan Redwood. Mereka ingin Anda dapat menyelesaikan semuanya dengan sangat cepat sehingga Anda dapat membuat halaman, Anda dapat membuat tata letak, Anda dapat menghasilkan sel Anda, yang saya bicarakan, dan Anda dapat melakukan perintah scaffold yang akan membuat seluruh antarmuka CRUD. Saya memiliki seluruh bagian, bagian empat dari seri blog, hanya menjelaskan semua kode yang diberikan scaffold kepada Anda. Ini memberi Anda begitu banyak kode. Ada generator mati, bahkan ada generator Tailwind yang mengonfigurasi tailwind untuk Anda.

Drew: Itu luar biasa. Saya ingat melihat demo DHH tentang Rails. Maksud saya, itu mungkin, apa, 15 tahun yang lalu sekarang ketika dia pertama kali melakukan perancah itu dan menunjukkannya kepada Anda, dan Anda mendapatkan panel kontrol yang cukup sederhana tetapi berfungsi pada dasarnya untuk memungkinkan Anda membuat item baru, mengeditnya, menghapusnya, dan lain-lain. . Itu bisa sangat berharga dalam sebuah proyek, terutama bekerja di semacam lingkungan dinamis di mana, oke mungkin Anda akan menerapkan alat yang lebih baik di masa depan untuk mengedit konten itu, tetapi itu berarti dapat memutar sesuatu dengan cepat, Anda bisa mendapatkannya menguji data, atau Anda bahkan dapat menyerahkannya kepada tim konten yang dapat mulai bekerja saat Anda bekerja di bagian depan, jadi itu sangat berguna.

Drew: Jika Anda hanya ingin menerapkan itu dan memilikinya dalam produksi, mungkin Anda bisa menerapkannya bersama dengan kode ujung depan Anda, tetapi Anda memerlukan beberapa cara untuk mengamankan aspek itu, akar-akar itu di aplikasi Anda.

Anthony: Ya, ada beberapa opsi berbeda untuk otentikasi. Anda dapat menggunakan identitas Netlify. Itu default jika Anda masuk ke tutorial, dan kemudian Anda juga dapat menggunakan Auth0, dan kemudian yang saya tidak kenal bernama Magic.Link, dan mungkin akan ada beberapa tambahan yang ditambahkan di masa mendatang. Tapi ya, jadi sudah ada beberapa solusi bawaan di sana, dan itulah hal terakhir yang Anda lakukan sehingga bagian terakhir dari keseluruhan rangkaian blog 12 bagian saya adalah yang Auth. Saya tidak berpikir saya pernah menemukan Auth sebelum saya menggunakan Redwood. Sulit dan mereka pasti telah melakukan pekerjaan dengan baik dengan itu.

Drew: Apakah itu terintegrasi pada tingkat rute, atau tingkat rute, maaf, bagaimana Anda mengamankan sesuatu?

Anthony: Ya, jadi bagian dari bagaimana mereka memiliki router sendiri, mereka juga memiliki… Anda dapat melakukan rute pribadi, jadi mereka memiliki komponen rute pribadi. Kemudian, formulir login Anda yang sebenarnya, itulah yang Anda dapatkan dari identitas Netlify sehingga Anda tidak perlu benar-benar membuat formulir dan melakukan manajemen negara Anda dengan itu, di situlah banyak masalah ikut bermain. Mengambil bagian yang benar-benar penting dan kemudian Anda bisa mengimplementasikan akses berbasis peran. Kami memiliki kontrol akses berbasis peran tambahan yang telah dilakukan selama beberapa minggu terakhir menjadi David T. Jadi, ada banyak pekerjaan yang terjadi untuk menciptakan cara lain untuk melakukannya, tapi apa yang mereka dapatkan sekarang sudah… berhasil, itu' akan membuat Anda fungsional.

Drew: Orang-orang selalu mengatakan tentang kriptografi hashing algoritma keamanan, bahwa Anda tidak boleh menulis sendiri karena tidak akan pernah sebagus hal-hal yang ada di luar sana. Semakin, saya pikir itu juga berlaku untuk otentikasi di tingkat yang lebih tinggi; bahwa autentikasi adalah area yang sangat kompleks akhir-akhir ini sehingga orang tidak hanya ingin masuk ke situs Anda dengan kredensial unik, tetapi mereka mungkin ingin mengautentikasi menggunakan Google, atau mereka mungkin ingin mengautentikasi menggunakan perangkat Apple, atau mereka mungkin menginginkan autentikasi dua faktor , atau mereka mungkin ingin mengintegrasikannya dengan layanan masuk tunggal yang mereka gunakan dari perusahaan. Semua hal ini sangat memusingkan jika Anda mencoba dan mengimplementasikannya sendiri dan begitu banyak kesempatan untuk mendapatkan sesuatu yang salah dan mengekspos lubang keamanan di aplikasi Anda, yang menggunakan layanan otentikasi tampaknya hampir seperti tidak punya otak pada saat ini bagi saya. Jadi, hanya dapat memasukkan sesuatu pada dasarnya dengan beberapa baris kode dan menjalankannya terdengar seperti cara yang sangat produktif untuk bekerja dan menjaga semuanya tetap aman.

Drew: Sepertinya penerapan aspek front end dan server, fungsi tanpa server, secara alami cocok untuk diterapkan ke Netlify. Apakah Anda terikat dengan Redwood? Maksud saya, kami menyebutkan bahwa Tom Preston-Werner adalah salah satu pendukung utama kerangka kerja ini, dia juga anggota di Netlify. Apakah menurut Anda ada potensi sambungan yang terlalu ketat jika Anda memilih Redwood sebagai dasar untuk sebuah proyek?

Anthony: Ya, ini adalah sesuatu yang sangat disadari oleh Tom. Dia berinvestasi di banyak perusahaan yang mengambang. Dia berinvestasi di Prisma dan Fauna. Dia hanya ingin membuat alat yang ingin dia gunakan. Ini bukan tentang kami ingin mengunci Anda ke dalam hal ini seperti apa yang Netlify telah buat yang menurutnya adalah pilihan terbaik, jadi itu sebabnya mereka membangun di sekitarnya. Namun, mereka tidak ingin itu dikunci ke salah satu target penerapan, dan itulah sebabnya kami sedang mengerjakan hal-hal seperti kerangka kerja tanpa server dan beberapa orang telah membicarakan tentang Begin. Kami ingin menjadi pragmatis, kami ingin itu berfungsi untuk apa pun kasus penggunaan seseorang. Jadi, kami mendapatkan Anda 90% dari jalan dan kemudian Anda hanya perlu memasang beberapa hal terakhir untuk membuatnya bekerja dengan apa pun server pilihan Anda.

Drew: Saya kira bahkan Netlify menggunakan AWS Lambda untuk fungsi server jadi itu benar-benar bagian penerapan yang ditangani oleh Redwood di sana, dan sebenarnya Anda bisa menerapkannya sendiri ke Lambda. Memposting front end Anda hanyalah file, bukan, sisanya berbasis CDN? Jadi, ada cukup banyak fleksibilitas di sana tanpa terlalu terikat.

Anthony: Ya, sebenarnya ada istilah yang dibicarakan Tom sebagai ide filosofis inti di balik Redwood, yaitu bahwa kami ingin menggunakan mesin penerapan universal. Itu semacam ide, adalah bahwa Anda hanya dapat menyebarkan sesuatu dan Anda tidak perlu memikirkannya sama sekali. Dia telah berbicara tentang ide ini selama bertahun-tahun, dan ini adalah tentang Jekyll di masa lalu. Ketika Anda mendengarnya sekarang, Anda seperti, "Oh, maksud Anda seperti Netlify?" Pada dasarnya itulah Netlify bagi kebanyakan orang yang bekerja di front end. Mereka bahkan tidak berpikir tentang penggelaran lagi, itu bahkan bukan pikiran.

Drew: Ini aplikasi saya di Git Repo, direktori ini adalah ujung depan, direktori ini adalah ujung belakang, inilah database saya, dan itu tentang konfigurasi sebanyak mungkin yang Anda perlukan untuk layanan apa pun untuk mengambilnya dan membangunnya dan tuan rumah itu.

Anthony: Ya, dan satu hal yang juga harus saya tunjukkan, kami baru-baru ini menyiapkan penyebaran default Vercel Redwood, jadi ketika Anda menerapkan pada aplikasi sisi server, Anda dapat mengatakan, "Oh, saya punya aplikasi Gatsby," dan ia tahu persis bagaimana membangun aplikasi Gatsby versus NextApp. Kami memiliki itu untuk Vercel sekarang. Jadi, ada opsi non-Netlify yang sangat bagus juga, jika Anda lebih menyukainya.

Drew: Jadi, jika saya ingin memulai dan membangun aplikasi dan membawanya ke produksi minggu ini, apakah Redwood siap untuk itu? Apakah itu dewasa?

Anthony: Ya, kami memiliki sekitar setengah lusin aplikasi yang sedang diproduksi saat ini. Yang pertama disebut Predict COVID, yang keluar pada bulan Maret, dan itu seperti aplikasi visualisasi data waktu nyata. Kemudian, kita punya repeater.dev yang dilakukan oleh Rob, itu seperti pekerjaan cron untuk Jamstack. Lalu, ada Tape.sh, Duoflag menurut saya adalah satu lagi. Jadi, setidaknya ada segelintir. Jika Anda menggunakan repo Redwood yang luar biasa, Anda dapat melihat daftar semuanya. Jika Anda pergi ke forum komunitas, Anda juga dapat menemukan tulisan tentang ini, karena orang-orang telah memasukkan ini ke dalam produksi dan mengatakan bagaimana hasilnya. Sejauh ini, mereka semua telah berhasil dan tidak ada yang berkata, "Saya tidak akan pernah menggunakan ini lagi."

Drew: Tapi, ini sangat baru. Saya kira tidak ada jalan keluar dari itu, tetapi dalam hal kedewasaan, Redwood cukup baru, mendapatkan pengikut yang baik.

Anthony: Yah, itu lucu, benar dan tidak. Itu diumumkan pada bulan Maret. Pada saat itu, itu telah dikerjakan selama sekitar satu tahun oleh Tom dan Peter. 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-

Drew: Tentu saja.

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. Sebagai contoh. 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. Apakah Anda memiliki kata-kata perpisahan?

Anthony: Jika Anda tertarik dengan salah satu hal ini, silakan hubungi kami. DM saya selalu terbuka. Masyarakat pada umumnya sangat terbuka. Saya akan dengan senang hati menjelaskan atau memandu Anda atau menyiapkan apa pun yang perlu Anda ketahui untuk memulai.