Smashing Podcast Episode 29 Dengan Leslie Cohn-Wein: Bagaimana Netlify Dogfood The Jamstack?

Dalam episode ini, kami menanyakan seperti apa dogfood Jamstack di Netlify. Bisakah Anda menerapkan seluruh aplikasi ke CDN? Drew McLellan berbicara dengan Insinyur Staf Netlify Leslie Cohn-Wein untuk mencari tahu.

Tampilkan Catatan

• Situs pribadi Leslie
• Leslie di Twitter
• Netlify

Update mingguan

• Menyelami React Dan Three.js Menggunakan react-three-fiber
  ditulis oleh Fortune Ikechi
• Praktik Terbaik Untuk Desain UI E-Commerce
  ditulis oleh Suzanne Scacca
• Mengautentikasi Aplikasi React Dengan Auth0
  ditulis oleh Nefe Emadamerho-Atori
• Dari Para Ahli: Perkembangan Aksesibilitas Digital Global Selama COVID-19
  ditulis oleh Robin Christopherson
• Apa yang Baru di Vue 3?
  ditulis oleh Timi Omoyeni

Salinan

Drew McLellan: Dia adalah spesialis frontend pemenang penghargaan yang berasal dari Austin, tetapi sekarang tinggal di Dallas, Texas, melalui tugas di kota New York. Selama waktu itu bekerja untuk agensi, dia membangun situs untuk klien, seperti Nintendo, WorldPride, dan Jerry Seinfeld. Dia sekarang menjadi staf frontend engineer di Netlify, di mana antara lain, dia bekerja membangun aplikasi yang digunakan pelanggan untuk mengelola layanan dan penerapan mereka. Jadi, kita tahu dia seorang insinyur frontend yang ulung, tapi tahukah Anda, ketika tinggal di kota New York, dia menjabat sebagai asisten hakim juru masak cabai tiga tahun berturut-turut. Dan yang satu itu memang benar. Teman-temanku yang hebat, tolong sambut Leslie Cohn-Wein. Hai, Leslie. Apa kabar?

Leslie Cohn-Wein: Saya hebat.

Drew: Saya ingin berbicara dengan Anda hari ini tentang bagaimana Netlify memakan makanan anjingnya sendiri, menggunakan ekspresi menawan itu, ketika harus membangun Jamstack. Saya harus menempatkan ini dalam konteks sedikit dengan mengatakan bahwa sampai beberapa bulan yang lalu, kami bekerja bersama di tim yang sama di Netlify. Dan sesampainya di sana, proses pengembangannya sebenarnya sangat asing bagi saya, bahkan setelah 20 tahun menjadi developer. Saya pikir itu benar-benar menarik dan layak dijelajahi sedikit, dengan audiens yang lebih luas. Saya mungkin harus menunjukkan bahwa kita sedang membicarakan hal ini karena ini membuat studi kasus yang benar-benar menarik dan ini bukan iklan besar yang disponsori untuk Netlify. Setiap orang harus memeriksa Vercel. Tapi saya pikir ada banyak hal berharga yang bisa dipelajari dari membahasnya, terutama dari sudut pandang Jamstack. Karena Netlify adalah pendukung besar pendekatan Jamstack dan layanan semacam itu ditawarkan kepada pelanggan dan dibangun di sekitar gagasan membangun proyek Jamstack. Tetapi layanan ini juga dibangun dengan menggunakan prinsip-prinsip itu sendiri. bukan?

Leslie: Itu, ya. Banyak orang menganggap arsitektur Jamstack itu sebagai situs statis, tetapi kami benar-benar memikirkan apa artinya membangun aplikasi Jamstack dengan frontend Netlify. Karena ini adalah aplikasi React yang merupakan aplikasi Jamstack lengkap yang kami gunakan Netlify di Netlify jadi… Ya, kami benar-benar mencobanya dan mendorong batas dari apa yang mungkin.

Drew: Saya pikir terkadang ada gagasan bahwa Jamstack bagus untuk situs statis saja, seperti yang Anda katakan, dan aspek API masuk jika Anda ingin mengirim formulir ke alamat email dan Anda bisa melakukan sesuatu yang mudah seperti itu, tetapi Anda mungkin dapat membangun seluruh aplikasi web seperti itu. Tapi, Anda melakukan itu bukan?

Leslie: Ya, tentu saja. Aplikasi kami, berbicara secara khusus tentang apa yang Anda lihat jika Anda login di app.netlify.com, didukung oleh… kami memiliki REST API internal, tetapi frontend, seperti yang saya katakan, adalah Jamstack murni. Jadi, kami memiliki langkah pembuatan sendiri, kami melihat aplikasi saat dibuat di aplikasi, dan kami menerapkan di sistem kami sendiri.

Drew: Jadi, ketika ada proses backend yang terlibat, dan akan selalu ada semacam tingkat proses backend, Anda tahu, data yang bertahan atau, dalam kasus Netlify, memulai dengan penerapan atau apa pun itu, backend itu saja jenis akan dibangun sebagai serangkaian API yang kemudian dapat dikonsumsi oleh frontend?

Leslie: Ya, jadi ada beberapa model berbeda tentang bagaimana Anda bisa membuat ini berhasil. Dalam kebanyakan kasus, di aplikasi kami, kami menggunakan pengambilan sisi klien dengan React, bukan? Jadi, kami menyajikan semacam shell statis aplikasi dan kemudian kami mengambil informasi pengguna dari REST API internal kami pada waktu permintaan. Jamstack menarik karena ada beberapa hal yang dapat Anda buat sebelumnya, dan kami mencoba dan mengandalkannya saat kami bisa. Dan kemudian ketika kita berbicara tentang beberapa data yang lebih dinamis, kita akan menggunakan pengambilan sisi klien untuk memastikan bahwa kita menarik data terbaru.

Drew: Saya pikir itu mengejutkan saya, ketika saya mulai mengerjakan aplikasi, seberapa banyak yang dicapai di frontend, terutama dalam hal berinteraksi dengan API eksternal dan hal-hal lainnya. Saya tahu bahwa ketika Netlify berinteraksi dengan penyedia Git Anda, sehingga ia masuk ke GitHub dan mendapatkan daftar daftar repo, itu semua terjadi antara browser Anda dan GitHub. Dan terlepas dari mungkin ... melalui fungsi tanpa server yang menempatkan beberapa rahasia pada permintaan atau sesuatu yang ringan seperti itu, sebagian besar hanya terjadi dengan cara Jamstack-y. Ini tidak melalui infrastruktur backend inti Netlify. Jadi, itu cukup menarik. Itu benar-benar jauh lebih dari sekadar situs statis dengan beberapa panggilan API untuk melakukan hal-hal kecil. Itulah fungsi inti yang sebenarnya, bukan, yang diimplementasikan di browser?

Leslie: Tentu saja. Menurut saya, itu benar-benar mendorong konsep tentang apa itu frontend developer engineer, bukan? Dan itu adalah sesuatu yang mendorong saya, sebagai seorang insinyur frontend untuk menjadi lebih baik dan untuk berpikir lebih banyak tentang ... lapisan API, yang bukan sesuatu yang secara tradisional dekat dengan saya. Saya lebih banyak bekerja di UI dan warna dan sistem desain, dan itu benar-benar… Saya benar-benar menemukan bahwa bekerja pada aplikasi Jamstack dalam skala besar, telah mendorong saya untuk menjadi pengembang yang lebih baik.

Drew: Menjadi pengembang frontend tidak mengetahui CSS dari belakang ke depan, meskipun itu bagian darinya. Itu tidak mengetahui HTML dari belakang ke depan, tetapi itu adalah bagian darinya. Itu juga menyimpang ke wilayah ini yang secara tradisional dilindungi oleh seorang insinyur backend, yang cukup menarik. Apakah Netlify menggunakan rendering sisi server baru untuk-

Leslie: Bukannya aku sadar.

Drew: Jadi, semuanya benar-benar selesai, seperti yang Anda katakan, Anda melayani shell, dan kemudian diisi dengan permintaan kembali ke titik akhir API yang berbeda untuk mengisi semuanya.

Leslie: Tepat sekali.

Drew: Dan Anda bilang itu aplikasi React?

Leslie: Ya. Ya. Reaksi. Kami menggunakan React Redux sekarang, dan sekarang kami adalah PostCSS, tetapi kami juga bereksperimen dengan arsitektur CSS kami.

Drew: Bukankah kita semua? Jadi, Anda membangun aplikasi di React dan kemudian Anda menyebarkannya di Netlify?

Leslie: Ya. Mungkin bagian favorit saya dari keseluruhan proses itu adalah keajaiban Deploy Previews, yang kami dapatkan melalui Netlify. Jadi, yang terjadi adalah, Anda akan… Anda bekerja di GitHub, Anda meningkatkan PR Anda. Jadi, Anda membuka PR Anda di GitHub, dan itu akan secara otomatis membuat build dari Deploy Preview aplikasi Anda. Jadi, kami benar-benar menggunakan Pratinjau Deploy aplikasi itu sendiri untuk menguji, untuk memastikan semuanya berfungsi sebagaimana mestinya. Kami menjalankan pengujian kami. Itulah yang kami gunakan untuk memverifikasi secara manual selama peninjauan kode. Jadi, kami memiliki semacam semua penerapan berkelanjutan yang disiapkan langsung dari GitHub.

Leslie: Dan kemudian salah satu hal keren lainnya yang telah kami siapkan adalah bahwa kami sebenarnya memiliki beberapa situs Netlify berbeda yang menarik dari repositori yang sama tempat aplikasi kami berada. Jadi, kami memiliki kedua aplikasi kami, kami memiliki instance dari Storybook yang memiliki semacam komponen UI kami untuk aplikasi tersebut. Jadi, kami memiliki kedua aplikasi itu sendiri, kami memiliki komponen UI Buku Cerita, dan pada dasarnya kami memiliki situs Netlify yang menunjukkan UI Buku Cerita kami. Dan kemudian kami juga memiliki situs ketiga yang menjalankan penganalisis bundel webpack. Jadi, ini adalah UI visual yang memberi Anda peta pohon, visualisasi semua bundel aplikasi, dan kami dapat mengurutkan ukuran mereka, dan ini hanya pengingat bagi kami untuk memeriksa ulang. Karena setiap penerapan aplikasi padam, kami dapat memeriksa dan memastikan kami tidak melakukan sesuatu yang aneh dengan ukuran bundel kami di sana. Jadi, ketiga situs tersebut dihasilkan dalam satu Permintaan Tarik aplikasi. Jadi, Anda akan mendapatkan tautan ke pratinjau, Pratinjau Deploy Anda pada dasarnya, dari Buku Cerita aplikasi dan ke profil aplikasi itu untuk kami periksa.

Drew: Dan dengan Pratinjau Deploy, yang pada dasarnya semacam itu menjadi lingkungan pementasan Anda, bukan?

Leslie: Tepat sekali. Kami tidak benar-benar menjalankan lingkungan staging tradisional, karena kami benar-benar percaya bahwa Pratinjau Deploy kami pada dasarnya adalah apa yang akan ditayangkan saat kami menekan tombol gabung dan memulai pembangunan resmi cabang utama kami di aplikasi utama kami. Jadi, saya senang kita dapat mengandalkan Pratinjau Deploy sebagai lingkungan pementasan. Kami benar-benar percaya bahwa itu akan cocok dengan produksi. Kami sedang membangunnya dengan semua variabel produksi, semua yang… variabel lingkungan, semua itu dibangun di Pratinjau Deploy. Jadi, ini seperti situasi yang tidak perlu dikhawatirkan. Selama Pratinjau Deploy Anda berfungsi, Anda tahu bahwa aplikasi juga akan berfungsi.

Drew: Dan saya kira, sebagai sebuah organisasi, jika Pratinjau Deploy Anda tidak cocok dengan apa yang ditayangkan, maka itu adalah masalah layanan yang ingin diselesaikan Netlify. Jadi, itu benar-benar bekerja dengan cukup baik dari sudut pandang itu. Jadi, Anda telah meninjau Pratinjau Deploy, semuanya tampak hebat, PR digabungkan. Apa yang terjadi kemudian?

Leslie: Jadi, karena Netlify menjalankan semua penerapan berkelanjutan kami, pada dasarnya kami telah menghubungkan semuanya sehingga setiap penggabungan ke cabang utama kami akan secara otomatis memulai penyebaran produksi resmi dengan aplikasi. Jadi, biasanya jika Anda adalah pengembang yang telah menggabungkan PR Anda sendiri, Anda akan masuk ke ... Anda harus memastikan, periksa kembali tab Anda, karena jika Anda memiliki Pratinjau Deploy dari aplikasi yang terbuka dan aplikasi, Anda harus memastikan… Anda biasanya ingin mengikuti di aplikasi sebenarnya. Jadi, Anda harus memeriksa tab Anda. Tapi, ya, di aplikasi, Anda biasanya masuk, Anda dapat melihat log build untuk penggabungan yang baru saja Anda mulai, jadi semuanya otomatis. Dan kemudian segera setelah log pembangunan itu selesai, dan situsnya aktif, yang harus Anda lakukan adalah menyegarkan jendela browser Anda dan Anda akan melihat apa pun yang baru saja Anda terapkan, harus diperbarui di aplikasi.

Drew: Dan katakanlah Anda menangkap masalah setelah ditayangkan, lalu apa yang Anda lakukan?

Leslie: Itu pertanyaan yang sangat bagus. Dan mungkin salah satu hal favorit saya tentang menggunakan Netlify bahkan sebelum saya bekerja di Netlify, ini seperti sedikit keajaiban bagi saya, karena Netlify memiliki semacam pemanggangan, yang kami sebut, rollback. Jadi, pada dasarnya setiap penerapan di Netlify… karena kami menggunakan arsitektur Jamstack ini, setiap penerapan bersifat atomik. Jadi, artinya Anda memiliki riwayat lengkap dari setiap jenis penerapan yang pernah Anda buat di sebuah situs, dan Anda dapat langsung memutar kembali ke salah satu dari itu. Jadi, jika kami secara tidak sengaja menyebarkan bug atau ada yang rusak, hal pertama yang biasanya kami lakukan adalah menghentikan integrasi berkelanjutan itu. Jadi, kita akan masuk dan hanya satu tombol di UI Netlify yang Anda katakan, "Hentikan penerbitan otomatis," dan apa yang akan dilakukan adalah menghentikan koneksi dengan GitHub. Jadi, jika rekan tim saya tiba-tiba juga menggabungkan PR mereka, kami tidak akan memperkenalkan kembali bug, hal seperti itu tidak akan terjadi.

Leslie: Jadi, kami menghentikan semua penerapan otomatis itu. Dan kemudian yang harus saya lakukan adalah kembali ke daftar penerapan saya dan menemukan penerapan terakhir yang berfungsi, tekan satu tombol lagi yang mengatakan, "Publikasikan yang ini," dan itu ditayangkan. Jadi, apa artinya, apakah dibutuhkan tekanan itu untuk bisa benar-benar kembali, lihat kodenya, cari tahu apa yang sebenarnya terjadi. Terkadang itu berarti melakukan pengembalian Git di cabang utama Anda dan mengembalikan cabang utama ke tempat yang seharusnya. Dan terkadang ini adalah hot fix atau Anda pergi ke cabang dan Anda memperbaikinya dan Anda bahkan tidak perlu khawatir tentang mengembalikan di Git. Dan kemudian, ketika Anda siap untuk kembali, Anda memastikan semuanya berfungsi di Pratinjau Deploy aplikasi Anda, dan Anda dapat mengatur ulang semua itu kembali. Jadi, segera setelah Anda memulai penerapan otomatis tersebut, pada dasarnya Anda kembali berbisnis.

Drew: Jadi, saya menemukan masalah di sini.

Leslie: ah.

Drew: Anda menggunakan Netlify untuk menerapkan perubahan ke aplikasi Netlify. Bagaimana jika bug yang Anda terapkan menghentikan Anda untuk memutar kembali? Apa yang Anda lakukan?

Leslie: Aku mimpi buruk. Tidak. Sebenarnya, kami memiliki beberapa cara untuk mengatasinya. Jadi, jika kami menghapus aplikasi dan kami tidak dapat menggunakan UI untuk melalui proses ini, Pratinjau Deploy kami sebenarnya berjalan melawan API produksi kami. Jadi, artinya, meskipun aplikasi tidak berfungsi, kita masih memiliki penerapan atom tersebut. Jadi, jika Anda memiliki tautan dari GitHub, mungkin dari PR lama atau baru-baru ini, dan Anda memiliki URL Pratinjau Deploy, Anda sebenarnya dapat mengakses Pratinjau Deploy aplikasi dan membuat perubahan apa pun yang Anda perlukan, kembali dan publikasikan penerapan yang lebih lama dari Pratinjau Deploy. Dan itu masih mengenai API produksi kami, sehingga masih akan memengaruhi aplikasi, dan kemudian itu akan menghidupkan kembali aplikasi. Ini seperti emoji otak yang meledak di sana, tapi itu salah satu cara untuk melakukannya. Kami juga dapat memublikasikan penerapan lama dari beberapa sistem backend kami. Kami dapat meminta teknisi backend kami untuk memublikasikannya untuk kami. Atau Anda selalu dapat menggunakan Git untuk mengembalikan dan mencoba dan mendorongnya, tetapi ini sedikit menakutkan karena Anda tidak dapat melihat apa yang Anda lakukan.

Drew: Saya kira Anda hanya perlu pikiran yang sangat jernih untuk mengelola situasi itu.

Leslie: Ya.

Drew: Tapi itu benar-benar dapat dipulihkan, kedengarannya seperti itu.

Leslie: Ya. Nah, dan setelah Anda memublikasikan penerapan kerja Anda, semua tekanan akan hilang. Itu benar-benar bagian terbaik. Dan saya menemukan ini bekerja di agensi juga. Mampu melakukan roll back benar-benar merupakan penyelamat bagi… Ini juga membuat Anda tidak terlalu khawatir untuk memublikasikan perubahan baru. Jika Anda memecahkan sesuatu, perlu waktu sedetik untuk menggulungnya kembali, yang sangat cocok dengan jenis gerakan cepat dan mengeluarkan model.

Drew: Pasti. Saya pikir biasanya seluruh alur kerja semacam ini bekerja paling baik ketika Anda berurusan dengan perubahan yang sangat kecil. Maksud saya, idealnya Anda ingin membuat cabang, menerapkan perubahan kecil, meningkatkan PR, dan kemudian menggabungkannya kembali secepat mungkin. Yang jelas berfungsi dengan baik untuk tweak dan perbaikan bug dan hal-hal kecil, tetapi itu tidak berfungsi dengan baik untuk pekerjaan fitur utama ketika fitur itu mungkin memakan waktu berminggu-minggu atau bahkan berbulan-bulan sejak mulai siap untuk digunakan. Bagaimana Anda mengelola proses semacam itu?

Leslie: Ya, itu pertanyaan yang bagus. Jadi, kami baru-baru ini mulai menggunakan tanda fitur sedikit lebih banyak. Sebelum saya berbicara lebih banyak tentang bagaimana kami melakukannya, saya akan berbicara tentang apa yang biasa kami lakukan. Jadi, sebelum kami menggunakan flag fitur, saya pikir semua orang sudah familiar dengan ide cabang fitur yang sudah berjalan lama. Kita semua membenci mereka, kan? Tapi kami akan mengerjakan PR kami yang lebih kecil. Kami akan menggabungkan masing-masing secara individual, setelah tinjauan kode, ke dalam cabang fitur yang berjalan lebih lama ini. Jadi, pada dasarnya Anda hanya memiliki semua fitur baru di satu tempat, Anda dapat memiliki satu Pratinjau Deploy yang dapat Anda gunakan untuk menguji fitur baru tersebut. Terkadang model ini membutuhkan penerapan terkoordinasi di seluruh tim lain. Jadi, ketika kami siap untuk mengatakan, "Oke, cabang fitur ini, kami siap untuk menggabungkannya dan mengaktifkannya," kadang-kadang itu berarti, "Oke, Anda harus memastikan backend sudah menerapkan perubahan mereka," jadi apa pun Pekerjaan API yang kami lakukan di fitur kami siap digunakan. Jika ada dokumen di situs dokumen kami yang perlu ditayangkan bersamaan dengan fitur tersebut, Anda harus mengoordinasikan dan menekan tombol secara bersamaan.

Leslie: Model ini… berhasil untuk kami, tapi Anda benar, bahwa itu mungkin bukan yang paling mulus. Ini sebenarnya agak lucu, salah satu pendiri dan CEO kami di Netlify, Matt Biilmann, sebenarnya meluncurkan fitur analitik kami menggunakan proses ini di atas panggung di Jamstack Conf London tahun lalu. Jadi, dia menggunakan fitur penyebaran kunci kami untuk pada dasarnya mengambil Pratinjau Deploy dari fitur analitik baru dan mempublikasikannya langsung di atas panggung. Jadi, itu sangat keren.

Leslie: Tapi, seperti yang Anda katakan, itu... Anda kurang percaya diri. Semuanya masih tersembunyi di Pull Request ini. Ini menjadi sedikit berat. Seseorang harus menyetujui Pull Request akhir yang biasanya cukup besar. Itu sedikit berlebihan. Jadi, saat ini kami lebih banyak menggunakan flag fitur. Kami menggunakan layanan yang disebut LaunchDarkly, yang pada dasarnya memungkinkan kami membungkus UI fitur baru kami dengan flag-flag ini, sehingga kami dapat terus menggabungkan kode, bahkan jika UI bukanlah sesuatu yang kami ingin pelanggan lihat. Jadi, Anda cukup memastikan di lingkungan produksi bahwa tanda fitur Anda dimatikan, kami dapat menerapkan kode, menggabungkannya, dan tidak seorang pun… dengan asumsi bahwa Anda adalah pengguna umum, Anda tidak akan melihat UI baru itu.

Drew: Jadi, tanda fitur pada dasarnya seperti sakelar dalam kode yang mengatakan, "Jika fitur ini diaktifkan, gunakan kode baru ini, jika tidak gunakan kode lama ini."

Leslie: Tepat sekali.

Drew: Apakah itu berarti Anda mendapatkan semacam basis kode yang berantakan dengan semua garpu ini di tempatnya? Bagaimana Anda menghadapinya?

Leslie: Ya, saya pikir itu... siapa pun yang menggunakan flag fitur mungkin sudah terbiasa dengan pertempuran semacam ini. Kapan Anda membersihkan flag fitur? Berapa lama Anda meninggalkan mereka di sana? Kami telah mendarat sekitar dua minggu setelah fitur utama dirilis, apakah kami memiliki pengingat. Untungnya, LaunchDarkly sebenarnya baru-baru ini menyiapkan fitur yang akan memberi tahu Slack. Jadi, Anda dapat menghubungkannya dengan Slack, dan itu hanya akan memberi tahu Anda, “Hei, tanda fitur Anda telah… Anda telah melakukan produksi secara langsung selama dua minggu. Sudah waktunya untuk memastikan Anda membersihkan bendera Anda dalam kode. ”

Leslie: Jadi, kami mencoba dan, dan membersihkannya cukup cepat, tetapi, di antara waktu itu, senang mengetahui bahwa bendera itu masih ada di sana. Bahkan jika Anda telah merilis fitur, itu berarti bahwa sekali lagi, dengan satu klik, Anda dapat masuk dan mematikan bendera itu kembali ada bug, jika ada sesuatu yang muncul. Jadi, kami ingin membiarkannya sebentar, sementara fitur benar-benar matang, sementara orang mulai terbiasa, untuk memastikan tidak ada masalah besar. Tapi kemudian kami mencoba dan kembali ke kode dan itu adalah sedikit pembersihan, jadi ini bukan proses yang ideal, tetapi biasanya menghapus bendera tidak memakan waktu lama, Anda hanya menghapus beberapa baris kode.

Drew: Jadi, saya kira pendekatan paling sederhana untuk mengimplementasikan tanda fitur bisa saja menjadi ... seperti variabel konfigurasi di aplikasi Anda yang mengatakan, "Fitur ini aktif atau tidak aktif," tetapi kemudian Anda, Anda perlu beberapa cara untuk memastikan bahwa itu aktif untuk orang yang tepat dan mati untuk orang yang tepat. Dan saya rasa di situlah layanan seperti LaunchDarkly masuk, karena dibutuhkan… Maksud saya, pada dasarnya dibutuhkan apa yang menghidupkan dan mematikan variabel ke tingkat yang ekstrim, bukan?

Leslie: Ya. Ya. Itu saja. Jadi, ada beberapa cara yang bisa kita lakukan, bahkan tanpa LaunchDarkly, pada dasarnya menyiapkan variabel konfigurasi sendiri yang kita kelola sendiri. Salah satu hal yang saya sukai dari LaunchDarkly adalah adanya lingkungan yang berbeda. Jadi, yang dapat kami lakukan pada dasarnya adalah mengaktifkan tanda fitur untuk Pratinjau Deploy kami. Jadi, siapa pun yang melihat secara internal di Netlify, Pratinjau Deploy aplikasi dapat memiliki akses ke fitur baru, dapat mengujinya, tetapi sekali lagi, segera setelah ditayangkan dalam produksi, tanda itu mati. Jadi, hanya ada sedikit… sekali lagi, Anda harus memeriksa tab Anda dan memastikan bahwa Anda mengetahui segmen apa yang Anda masuki, karena Anda tidak ingin mengejutkan diri sendiri dan berpikir bahwa Anda telah meluncurkan sesuatu yang Anda tidak, Anda harus sedikit berhati-hati di sana. Namun, secara umum, ini bekerja dengan cukup baik, dan LaunchDarkly memungkinkan Anda juga melakukan peluncuran selektif ini. Jadi, Anda dapat meluncurkan fitur ke beberapa persentase basis kode Anda atau ke segmen pengguna tertentu, orang dengan jenis paket tertentu, atau jenis pengguna tertentu. Jadi, ini memungkinkan Anda lebih banyak mengontrol kepada siapa Anda akan melepaskan.

Drew: Ya. Itu bisa sangat kuat, saya kira, terutama dengan fitur atau fitur baru yang mungkin Anda harapkan untuk menyelesaikan masalah. Mungkin Anda meningkatkan fitur agar lebih mudah dipahami, Anda mungkin dapat mencobanya dengan 10% pengguna dan melihat apakah mereka mengalami masalah yang sama dan…

Leslie: Tepat sekali. Ini cara yang bagus untuk mendapatkan umpan balik juga, ya.

Drew: Saya kira menggunakan LaunchDarkly dengan cara ini, daripada menggulirkan solusi Anda sendiri, merupakan aspek lain dari pendekatan Jamstack, bukan? Hanya menggunakan API yang memberi Anda fungsionalitas ini tanpa harus khawatir tentang bagaimana Anda mengimplementasikannya sendiri dan bagaimana mengembangkannya serta bagaimana memelihara dan menyimpannya sehingga Anda dapat mengalihdayakannya, katakan, “Benar, kami akan menggunakan API ini dan yang lainnya akan diurus.”

Leslie: Ya. Ya, persis.

Drew: Jadi, pendekatan ini memungkinkan Anda untuk melakukan sedikit fitur baru ke produksi pada dasarnya, tetapi mereka hanya tersembunyi di balik bendera. Dan kemudian ketika semuanya sudah siap, Anda cukup membalik bendera dan Anda dapat dengan cepat menggantinya kembali jika terjadi kesalahan.

Leslie: Ya, persis. Itu membuat peluncuran kami sedikit kurang menarik. Dulu Anda menekan tombol besar ini dan ada semua kode ini yang digabungkan dan Anda melihat log build Anda dan inilah momen antisipasinya. Dan sekarang Anda melakukan panggilan Zoom, Anda mengklik satu tombol, dan itu langsung.

Drew: Ya. Saya pikir peluncuran fitur terakhir, saya bekerja di Netlify, kami menggunakan pendekatan ini. Dan sudah berminggu-minggu kerja untuk seluruh tim, dan kami mendapat panggilan Zoom untuk mengoordinasikan rilis, dan semua orang mengonfirmasi bahwa bagian mereka sudah siap. Dan kemudian saya membalik tanda fitur dan menyalakannya untuk semua pengguna, dan hanya itu.

Leslie: Selesai.

Drew: Dan itu berakhir dalam beberapa menit dan itu benar-benar antiklimaks.

Leslie: Ya, agak menyedihkan.

Drew: Tidak ada telapak tangan yang berkeringat, tidak ada apa-apa, yang tentu saja persis seperti yang Anda inginkan, bukan? Begitulah cara Anda mengetahui bahwa Anda memiliki proses yang kuat, jika mengaktifkan sesuatu untuk semua orang bukanlah masalah besar.

Leslie: Tepat sekali. Dan jika Anda harus memutarnya kembali, sekali lagi, sesederhana itu, hanya dengan satu klik. Ini mengurangi sebagian dari tekanan itu, kecemasan.

Drew: Jadi, mungkin maksud saya, tidak semua perubahan akan menjadi perubahan frontend saja. Terkadang akan ada perubahan backend, dan mungkin mereka memiliki flag fitur mereka sendiri juga di sebagian besar sistem backend. Jadi, Anda juga menyebutkan dokumen. Apakah ada cara untuk mengoordinasikan semua ini bersama-sama? Apakah semua orang hanya mengibarkan bendera mereka pada saat yang bersamaan? Atau bagaimana cara kerjanya?

Leslie: Ya. Jadi, ini adalah area yang sedang kami kerjakan secara aktif di seluruh tim saat ini di Netlify, sedang bekerja menuju solusi yang memungkinkan kami untuk mungkin mengikat semuanya ke satu bendera tunggal di LaunchDarkly, yang digunakan semua sistem kami , semua basis kode kami menggunakan. Jadi, di dunia yang ideal, kita dapat membalik bendera dan berkata, “Oke, ini beralih pada titik akhir API baru yang juga digunakan di frontend dengan UI baru ini yang dibungkus dengan fitur bendera, serta bagian dari situs dokumen ini, yang memiliki informasi baru tentang fitur baru ini.” Dan Anda membalik satu bendera di dalamnya memengaruhi semua repositori itu. Kami belum cukup sampai di sana. Kami sedang mengerjakannya, tapi saya senang melihat apakah kami bisa mendapatkan semua itu terkoordinasi dan bekerja.

Drew: Netlify, sebagai layanan sangat disesuaikan untuk membangun situs dengan cara ini. Apakah pekerjaan yang Anda dan tim Anda lakukan menggunakan produk, benar-benar memengaruhi pengembangan produk?

Leslie: Saya akan mengatakan bahwa itu pasti. Semua orang selalu mengatakan Anda bukan pengguna Anda, yang menurut saya benar hampir sepanjang waktu, kecuali kadang-kadang ketika Anda adalah pengguna Anda. Yang lucu di Netlify karena saya pikir sebagian besar orang di tim frontend khususnya, adalah orang-orang yang pernah menggunakan Netlify sebelumnya sebagai produk. Dan tentu saja karena kami menggunakan Netlify untuk menyebarkan Netlify, kami menghadapi tantangan yang sama seperti yang saya pikir dilakukan oleh beberapa pengguna kami. Jadi, dalam beberapa hal, jika kami mengalami masalah, kami akan mencoba dan membawanya ke seluruh perusahaan. Kami akan menyebutkannya dalam panggilan teknik atau kami akan menarik CTO kami dan berkata, “Hei, ini adalah sesuatu yang sedang kami perjuangkan. Apakah ada sesuatu yang dapat kami bangun ke dalam produk yang akan membuat ini lebih mudah bagi kami dan semua pengguna kami yang menerapkan hal serupa seperti kami?” Jadi, ini adalah posisi yang unik, tetapi menyenangkan untuk melihat bagaimana peta jalan produk dikembangkan.

Drew: Saya kira mungkin ada beberapa orang di luar sana yang menggunakan Netlify secara intensif seperti Netlify sendiri.

Leslie: Ya. Ya. Saya pikir itu tentang benar. Saya menatap Netlify baik saat saya membuatnya maupun saat saya menerapkannya, jadi saya cukup familiar dengannya.

Drew: Dan kemudian pada akhir pekan Anda mengerjakan proyek sampingan dan Anda menemukan diri Anda kembali di Netlify lagi.

Leslie: Ya. Itu sebenarnya sangat benar. Ya. Ya. ya memang.

Drew: Apakah Anda memiliki contoh seperti bagaimana arah produk telah dipengaruhi sama sekali oleh pekerjaan yang dilakukan tim?

Leslie: Ya. Jadi, kami baru saja meluncurkan jenis baru dasbor pendaratan untuk aplikasi yang kami sebut Tinjauan Tim. Jadi, dulu ketika Anda login ke Netlify Anda akan mendarat di halaman situs, yang pada dasarnya hanya akan menjadi daftar panjang situs Anda. Dan kami ingin memberi orang sedikit lebih banyak area kendali misi di mana mereka dapat melihat banyak informasi penting secara sekilas, mendapatkan akses ke hal-hal yang paling berguna bagi mereka. Jadi, itu adalah fitur baru yang kami buat. Pada iterasi awal, kami mencoba mengeluarkannya dengan cepat, kami memiliki kartu kecil di UI itu yang tertaut ke build terbaru Anda. Ini menunjukkan kepada Anda setiap bangunan di seluruh tim Anda, harus muncul di kartu itu.

Leslie: Dan pada awalnya, kami sebenarnya tidak menautkannya ke build… tampilan log itu sendiri. Jadi, itu hanya daftar di mana Anda bisa memeriksanya. Anda dapat mengklik halaman build untuk mendapatkan tampilan serupa. Tapi saya benar-benar mengerjakan sesuatu selama akhir pekan, situs pribadi, dan saya mengaktifkan tinjauan tim ini dan saya kesal karena saya menyadari bahwa saya masuk ke Netlify dan saya ingin memeriksa bangunan ini yang sedang terjadi di proyek saya, dan saya tidak bisa begitu saja mengkliknya dan langsung melakukannya. Saya harus mengklik halaman build dan kemudian mengklik lagi. Jadi, keesokan harinya di tempat kerja, saya masuk dan menambahkan perubahan itu dan menghubungkan bangunan itu karena itu mengganggu saya. Jadi, itu adalah salah satu contoh dari kesadaran dengan menggunakan produk, bahwa ada peluang yang sangat kecil untuk memperbaikinya. Dan kami mengambil itu.

Leslie: Tapi kami juga punya beberapa contoh lain. Mungkin sedikit lebih berdampak. Salah satunya adalah kami menambahkan fitur deteksi formulir ini. Jadi, sedikit latar belakang, jika Anda tidak terbiasa, formulir Netlify adalah fitur di Netlify yang memungkinkan Anda membuat formulir frontend. Dan Netlify melakukan semua pekerjaan backend dalam mengelola kiriman. Ini seperti database Anda untuk formulir yang Anda buat di frontend Anda. Ini berarti Anda tidak perlu menulis kode sisi server atau banyak JavaScript tambahan untuk mengelola pengiriman formulir. Benar-benar situs apa pun yang Anda terapkan ke Netlify, saat build Anda sedang berlangsung, bot build kami mem-parsing HTML situs Anda pada waktu penerapan untuk mendeteksi jika Anda memiliki formulir Netlify yang perlu diperhatikan dan dikelola oleh Netlify. Dan deteksi formulir ini, yang dicari oleh bot build, diaktifkan secara default.

Leslie: Tapi itu artinya, seperti yang bisa Anda bayangkan, itu memakan sedikit waktu pembuatan Anda karena bot harus pergi dan mencari langkah ekstra ini. Jadi, aplikasi Netlify itu sendiri, sebenarnya, kami tidak menggunakan, kami tidak memiliki formulir Netlify di aplikasi saat ini. Jadi, ini adalah langkah yang pada dasarnya menambahkan sedikit waktu pembuatan kita, tetapi itu tidak perlu terjadi. Jadi, Netlify sebenarnya membangun fitur baru yang memungkinkan setiap pengguna untuk menonaktifkan deteksi formulir itu. Artinya adalah Anda dapat mematikan pengaturan itu di pengaturan situs Anda, bot build menyadari bahwa tidak ada yang perlu mereka cari, jadi Anda menghemat sedikit waktu pemrosesan ekstra di build.

Drew: Saya rasa itu bagus dalam hal produktivitas, karena semuanya selesai sedikit lebih cepat.

Leslie: Tepat sekali.

Drew: Tetapi juga, sebagai layanan terukur, memungkinkan Anda mendapatkan lebih banyak dari jenis tunjangan yang Anda dapatkan.

Leslie: Ya. Tepat. Jadi, ini adalah sesuatu yang juga kami dengar dari beberapa pengguna dan pelanggan kami, dan itu adalah sesuatu yang kami perhatikan juga. Itu adalah, “Kami tidak membutuhkan langkah ekstra ini dalam produk kami sendiri. Jadi, adakah cara, sesuatu yang bisa kami berikan kepada semua pengguna kami untuk membuat hidup semua orang sedikit lebih mudah, membuat semua orang membangun sedikit lebih cepat jika mereka tidak menggunakan fitur ini?”

Drew: Apakah ada bahaya… Maksud saya, Anda mengatakan bahwa Anda bukan pengguna Anda, tetapi dengan Netlify Anda sering menjadi pengguna Anda. Apakah ada bahaya bahwa, dengan intensitas Anda menggunakan produk, Anda mungkin mengabaikan jenis pengguna yang hanya menggunakannya dengan sangat ringan dan semuanya mungkin menjadi terlalu rumit dan terlalu maju, dan menjadi sangat sulit untuk mendapatkannya? dimulai dengan?

Leslie: Itu pertanyaan yang bagus. Kami juga telah benar-benar membangun fungsi penelitian pengguna kami di Netlify dan fungsi ilmu data kami, dan saya pikir, secara keseluruhan kami lebih mempercayai mereka daripada pengalaman anekdot saya menggunakan dan menerapkan aplikasi. Tapi saya pikir semua jenis data itu datang bersama untuk memungkinkan kita mendapatkan gambaran yang lebih baik tentang siapa yang menggunakan Netlify, tipe pengguna apa yang kita ajak bicara? Ada orang dengan berbagai jenis kebutuhan. Kami memiliki orang-orang di tim pemula kami yang mengelola blog dan situs pribadi, dan kami juga memiliki perusahaan besar, yang meluncurkan kampanye pemasaran besar dan aplikasi web besar, tidak jauh berbeda dari Netlify itu sendiri. Jadi, sangat menarik untuk melihat basis pengguna tumbuh dan memikirkan semua kasus penggunaan ini dan untuk mencari tahu bagaimana kami dapat melayani semua pengguna tersebut. Dan tentunya menggunakan lebih banyak fungsi penelitian kami untuk bersandar pada pemahaman siapa pengguna tersebut, bukan hanya pengalaman internal kami.

Drew: Beri tahu saya, Leslie, tentang layanan tangkapan layar yang dimiliki Netlify? Karena menurut saya itu sangat menarik.

Leslie: Ya. Di UI kami memiliki… ketika Anda menerapkan situs di Netlify, di UI, kami memiliki sedikit tangkapan layar yang biasanya menunjukkan kepada Anda seperti apa tampilan beranda situs yang Anda rasa. Sebenarnya lucu kami membahas ini, karena saya mendengarkan Chris Coyier episodenya di Serverless belum lama ini, dan dia berbicara tentang bagaimana mereka melakukan tangkapan layar di CodePen juga, yang sebenarnya tidak jauh berbeda dengan bagaimana Netlify melakukannya. Tetapi pada dasarnya kami menjalankan Puppeteer untuk menangkap tangkapan layar situs pengguna itu, dan cara menjalankannya adalah dengan mengaturnya dengan fungsi Netlify. Jadi, ini sekali lagi, contoh kami melakukan dogfood pada produk kami sendiri. Jadi, pada dasarnya kami menggunakan titik akhir ini yaitu fungsi Netlify di dalam aplikasi kami sendiri untuk mengembalikan URL gambar tangkapan layar itu, yang kemudian kami dapat menyajikannya di aplikasi.

Drew: Jadi fungsi Netlify adalah implementasi Netlify dari fungsi Tanpa Server, bukan? Di mana pada dasarnya Anda hanya meletakkan file JavaScript ke folder yang ditentukan sebagai bagian dari sumber Anda, dan kemudian tersedia untuk dieksekusi sebagai fungsi cloud.

Leslie: Ya, persis.

Drew: Sangat pintar, bukan?

Leslie: Ya. Itu brilian. This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. Ya.

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?