Smashing Podcast Episode 22 Dengan Chris Coyier: Apa Itu Tanpa Server?

Hari ini, kita berbicara tentang arsitektur Tanpa Server. Apa artinya itu, dan apa bedanya dengan cara kami membangun situs saat ini? Saya berbicara dengan Chris Coyier untuk mencari tahu.

Tampilkan Catatan

• Situs mikro Chris Kekuatan Tanpa Server untuk Pengembang Front-end
• Chris di Twitter
• Podcast Pertunjukan Talk Talk

Update mingguan

• “Menyiapkan Redux Untuk Digunakan Dalam Aplikasi Dunia Nyata,”
  oleh Jerry Navi
• “Bisakah Anda Mendesain Situs Web Untuk Panca Indera?,”
  oleh Suzanne Scacca
• “Membuat Blog Statis Dengan Sapper Dan Strapi”
  oleh Daniel Madalitso Phiri
• “Panduan Praktis Untuk Tur Produk Di Aplikasi React,”
  oleh Berkat Krofegha
• “Cara Membuat Porsche 911 Dengan Sketsa,”
  oleh Nikola Lazarevic

Salinan

Drew McLellan: Dia adalah perancang dan pengembang web yang mungkin Anda kenal dari CSS-Tricks, situs web yang ia mulai lebih dari 10 tahun yang lalu dan tetap menjadi sumber belajar yang fantastis bagi mereka yang membangun situs web. Dia adalah salah satu pendiri CodePen, taman bermain dan komunitas pengkodean berbasis browser yang digunakan oleh front-ender di seluruh dunia untuk berbagi apa yang mereka buat dan menemukan inspirasi dari orang-orang yang mereka ikuti. Di samping Dave Rupert adalah co-host ShopTalk Show, podcast tentang pembuatan situs web. Jadi kita tahu dia tahu banyak tentang pengembangan web, tapi tahukah Anda dia pernah memenangkan kompetisi makan hot dog hanya dengan menggunakan pesonanya? Teman-temanku yang hebat, tolong sambut Chris Coyier. Halo Kris, apa kabar?

Chris Coyier: Hei, aku hebat.

Drew: Saya ingin berbicara dengan Anda hari ini bukan tentang CodePen, dan saya tidak ingin berbicara dengan Anda tentang Trik-CSS, yang merupakan salah satu sumber daya luar biasa yang saya yakin semua orang tahu muncul tepat di bagian atas Google Hasil pencarian saat mencari jawaban tentang pertanyaan pengembang web apa pun. Muncul wajah Anda dan ada posting blog berguna yang ditulis oleh Anda atau salah satu kontributor tamu Anda.

Chris: Oh, saya dulu benar-benar melakukan itu. Ada ... Saya tidak tahu, itu mungkin pada saat Google memiliki jejaring sosial yang aneh itu. Apa itu tadi? GooglePlus?

Drew: Oh, Plus, ya.

Chris: Ya, di mana mereka akan mengaitkan situs web dengan akun Plus, dan akun Plus saya memiliki avatar, dan avatar itu adalah saya, jadi itu akan muncul di hasil pencarian. Saya pikir hari-hari itu sudah berlalu. Saya pikir jika Anda…

Drew: Saya pikir begitu, ya-

Kris: Ya.

Drew: Tapi saya agak ingin berbicara dengan Anda tentang sesuatu yang sedikit lebih menarik bagi Anda, dan itulah konsep arsitektur tanpa server.

Chris: Mm (mengiyakan).

Drew: Ini adalah sesuatu yang telah Anda pelajari lebih banyak untuk sementara waktu. Apakah itu benar?

Kris: Ya, ya. Saya hanya seorang penggemar. Sepertinya cocok dengan evolusi pengembangan front-end, di mana saya merasa memiliki, setidaknya, beberapa keahlian. Saya menganggap diri saya jauh lebih ... jauh lebih berguna di front-end daripada back-end, bukan karena saya ... saya melakukannya selama ini. Saya sudah ada cukup lama sehingga saya tidak takut melihat sedikit kode Ruby, itu sudah pasti. Tapi saya lebih suka front-end. Saya telah mempelajarinya lebih lanjut. Saya telah berpartisipasi dalam proyek lebih banyak pada tingkat itu, dan kemudian muncullah semacam paradigma baru yang mengatakan, "Anda dapat menggunakan keterampilan JavaScript Anda di server," dan itu menarik. Kamu tahu? Begitulah cara saya memikirkannya. Ada lebih banyak dari itu, tapi itulah mengapa saya peduli, karena saya merasa seperti pengembang front-end telah menggali begitu dalam ke JavaScript. Dan sekarang kita bisa menggunakan keahlian yang sama di tempat lain. Mm, cukup keren.

Drew: Sepertinya dunia yang sama sekali baru telah terbuka, sedangkan jika Anda hanya seorang pembuat kode front-end… Saya katakan, hanya seorang pembuat kode front-end, saya seharusnya tidak melakukannya. Jika Anda seorang pembuat kode front-end, dan Anda terbiasa bekerja dengan rekan kerja atau teman untuk membantu Anda dengan implementasi back-end, tiba-tiba itu terbuka. Dan itu adalah sesuatu yang Anda dapat mengelola lebih dari seluruh tumpukan sendiri.

Kris: Ya, ya. Itu dia.

Drew: Mengatasi gajah di dalam ruangan, tepat di atas. Kita berbicara tentang tanpa server, dan tentu saja, memberi nama sesuatu itu sulit. Kita semua tahu itu. Arsitektur tanpa server bukan berarti tidak ada server, bukan?

Chris: Saya pikir itu wajib, seperti jika ini adalah podcast pertama yang Anda dengar, atau yang pertama… Anda hanya mendengar kata “tanpa server” dalam belasan kali pertama Anda mendengarnya, wajib bagi Anda memiliki reaksi mendalam dan memiliki semacam ini, "Oh, tapi masih ada server." Tidak apa-apa. Jika itu terjadi pada Anda sekarang, ketahuilah itu, itu adalah langkah yang diperlukan dalam hal ini. Ini seperti hal lain dalam hidup. Ada tahapan untuk memahami. Pertama kali Anda mendengar sesuatu, Anda diharuskan untuk menolaknya sedikit, dan kemudian hanya setelah belasan kali atau lebih, atau setelah terbukti nilainya sedikit bagi Anda, apakah Anda bisa memasuki tahap selanjutnya pemahaman di sini. Tapi kata telah menang, jadi jika Anda masih berjuang melawan kata "serverless", saya benci untuk memberitahu Anda, bahwa kereta telah meninggalkan stasiun di sana. Kata sudah berhasil. Anda tidak akan memenangkan yang satu ini. Sangat menyesal.

Chris: Tapi saya pikir itu menarik bahwa… mulai menjadi seperti, mungkin sebenarnya tidak ada server yang terlibat kadang-kadang. Saya akan berpikir salah satu hal yang mengunci serverless sebagai sebuah konsep adalah AWS Lambda. Mereka adalah jenis yang pertama di tempat kejadian. Lambda seperti fungsi yang Anda berikan ke AWS dan meletakkannya di langit ajaib dan kemudian... ia memiliki URL, dan Anda dapat menekannya dan itu akan menjalankan fungsi itu dan mengembalikan sesuatu jika Anda menginginkannya. Kamu tahu? Itu hanya HTTP atau apa pun. Begitulah cara kerjanya, yang… pertama kali Anda mendengarnya, Anda seperti, “Mengapa? Aku tidak peduli.” Tapi kemudian, ada beberapa hal yang jelas untuk itu. Itu bisa mengetahui kunci API saya yang tidak dapat diakses orang lain. Itulah mengapa Anda menjalankan back-end untuk memulai, karena ia mengetahui hal-hal rahasia yang tidak harus ada di JavaScript di sisi klien. Jadi jika perlu berbicara dengan database, itu bisa dilakukan. Itu dapat melakukannya dengan aman tanpa harus mengekspos kunci API di tempat lain. Atau bahkan di mana data itu berada atau bagaimana cara mendapatkannya, itu…

Chris: Jadi itu cukup keren. Saya bisa menulis fungsi yang berbicara ke database, mendapatkan beberapa data, mengembalikannya. Dingin. Jadi, Lambda adalah itu, tetapi AWS berfungsi. Anda harus memilih wilayah. Anda seperti, “Saya tidak tahu. Di mana seharusnya, Virginia? Oregon? Haruskah saya memilih yang Australia? Saya tidak tahu." Mereka memiliki 20, 30. Saya bahkan tidak tahu berapa banyak yang mereka miliki hari ini, tetapi bahkan lambda memiliki wilayah. Mereka, saya pikir, hari ini memiliki Lambda@Edge, yang berarti semua wilayahnya keren. Tapi mereka dulu, dan sekarang semua orang punya sesuatu seperti Lambda. Semua layanan cloud. Mereka menginginkan suatu jenis pelayanan di dunia ini. Salah satunya adalah CloudFlare. CloudFlare memiliki pekerja. Mereka memiliki lebih banyak lokasi daripada yang dimiliki AWS, tetapi mereka mengeksekusinya pada waktu yang berbeda juga… seperti halnya seorang pekerja CloudFlare… mirip dengan lambda di mana Anda dapat menjalankan Node.js. Anda dapat menjalankan JavaScript. Anda dapat menjalankan sejumlah bahasa lain juga, tapi… Saya memikirkan hal ini sebagian besar, bahasa yang paling menarik adalah JavaScript, hanya karena prevalensinya.

Chris: Itu terjadi hanya pada level CDN, yang saya kira adalah server, tetapi saya cenderung tidak menganggap CDN sebagai server. Tidak sejelas sesuatu yang lain. Akhir-akhir ini mulai terasa lebih tanpa server. Apakah CDN adalah server? Maksud saya, saya kira itu adalah komputer di suatu tempat, tetapi rasanya seperti server-y yang lebih sedikit.

Drew: Rasanya seperti, ya, CDN mungkin sebuah server, tapi itu adalah versi server yang paling minimal. Ini seperti server tipis, jika Anda suka.

Kris: Ya. Tentu.

Drew: Baiklah. Saya pernah mendengarnya berkata… Sayangnya, saya tidak dapat mengingat sumber kreditnya, tetapi saya pernah mendengar tanpa server digambarkan sebagai “seperti menggunakan layanan berbagi tumpangan seperti Uber atau Lyft” atau apa pun. Anda bisa tanpa mobil dan tidak memiliki mobil, tetapi bukan berarti Anda tidak pernah menggunakan mobil.

Chris: Ya, bukan berarti mobil tidak ada. Mm, itu bagus.

Drew: Anda hanya memanggil satu saat Anda membutuhkannya, tetapi pada saat yang sama, Anda tidak membayar biaya pembelian mobil di muka. Anda tidak membayar perawatan atau bahan bakar atau-

Chris: Benar, dan harganya juga masuk akal, bukan? Itu bagus. Itu analogi yang bagus, saya pikir. Dan kemudian, karena itu pada level CDN juga, itu hanya memotong permintaan HTTP yang sudah terjadi, yang berarti Anda tidak memintanya… Anda tidak mengirim permintaan ke sana dan itu mengirim permintaan kembali. Itu hanya terjadi selama permintaan secara alami, yang juga membuatnya terasa kurang server-y. Saya tidak tahu, itu menarik. Ini menarik pasti. Jadi itu masalah besar, meskipun, Anda mengangkat masalah harga. Bahwa Anda hanya membayar untuk apa yang Anda gunakan. Itu juga penting, karena… katakanlah, Anda adalah pengembang back-end, yang terbiasa menjalankan server sepanjang hidup mereka. Dan mereka menanggung biayanya, “Saya membutuhkan server seperti ini dengan memori seperti ini dan CPU seperti ini dan spesifikasi seperti ini. Dan ini berapa biayanya.” Tanpa server datang dan memotong kepala dari harga itu.

Chris: Jadi, bahkan jika Anda seorang pengembang back-end yang tidak terlalu menyukai ini, bahwa mereka tidak menyukainya, seperti keahlian Anda selama bertahun-tahun, Anda membandingkan harganya dan Anda seperti, “Apa? Saya bisa membayar 1% dari apa yang saya bayarkan sebelumnya?” Anda tidak diperbolehkan untuk tidak peduli tentang itu, kan? Jika Anda adalah pengembang back-end ini yang membayar seratus kali lebih banyak untuk layanan mereka daripada yang harus mereka bayar, Anda agak buruk dalam pekerjaan Anda saat itu. Maaf untuk mengatakan. Ini telah datang dan ini telah menghancurkan harga dalam banyak cara. Anda harus peduli tentang itu. Dan itu agak keren bahwa orang lain ... Ini tidak seperti Anda tidak perlu khawatir tentang keamanan sama sekali, tapi itu bukan server Anda. Anda tidak memiliki... lambda atau fungsi cloud Anda, atau pekerja Anda, atau apa pun, tidak duduk di server yang tepat di sebelah beberapa data yang sangat sensitif di jaringan Anda sendiri. Itu tidak tepat di sebelah database Anda.

Chris: Jika seseorang menulis kode yang entah bagaimana mencoba untuk mengeluarkan dirinya dari pekerja atau lambda, atau apa pun, dan mencoba untuk mendapatkan akses ke hal-hal lain dengan cara mereka, tidak ada yang bisa didapat. Jadi keamanan juga merupakan masalah besar, jadi sekali lagi, jika itu tugas Anda sebagai admin server, adalah menangani keamanan hal ini. Menjalankannya, menjalankan hal-hal tertentu di Lambda, Anda hanya mendapatkan keamanan alami darinya, yang sangat bagus. Jadi, itu jauh lebih murah. Ini jauh lebih aman. Ini mendorong arsitektur modular kecil ini, yang bisa menjadi ide bagus. Tampaknya domino demi domino ide bagus di sini. Itu sebabnya itu penting. Kamu tahu?

Drew: Ya, maksud saya, secara tradisional dengan arsitektur berbasis server yang telah kami jalankan selama beberapa dekade di web, Anda memiliki server web yang Anda jalankan sendiri. Ini menyimpan kode front-end Anda, kode back-end Anda, database Anda dan semuanya. Kemudian Anda perlu mempertahankannya dan membuatnya tetap berjalan dan membayar tagihan, dan bahkan jika tidak digunakan, itu ada di sana untuk mencatat tagihan. Pengguna akan membuat permintaan dan itu akan membangun semua permintaan HTML dari database, mengirimkan semuanya ke browser. Proses itu berhasil. Begitulah cara banyak hal dibangun. Ini mungkin sebagian besar cara web dibangun. Begitulah cara kerja WordPress. Apakah ini benar-benar masalah yang perlu kita selesaikan? Maksud saya, kita sudah membicarakan sedikit tentang biaya. Apa jenis masalah lain dengan itu, yang kami… yang perlu kami atasi, dan tanpa server yang mungkin membantu kami?

Chris: Ya, masalah dengan pendekatan sekolah lama. Ya, saya tidak tahu, mungkin tidak ada. Maksud saya, saya tidak mengatakan bahwa seluruh web perlu mengubah keseluruhannya… semuanya dalam semalam. Saya tidak tahu. Mungkin tidak benar-benar, tapi saya pikir itu membuka pintu. Sepertinya, ketika ide bagus datang seperti ini, mereka perlahan-lahan mengubah cara kerja web sama sekali. Jadi, jika ada beberapa CMS yang dibangun dengan cara tertentu yang mengharapkan database ada di sana, itu berarti mungkin host di masa depan akan mulai memanfaatkan ini dengan cara yang menarik. Mungkin bagi Anda rasanya masih seperti server tradisional, tetapi tuan rumah sendiri telah mengembangkannya, cara mereka beroperasi, hingga arsitektur tanpa server. Jadi Anda bahkan tidak benar-benar tahu bahwa itu terjadi, tetapi mereka telah menemukan cara untuk memangkas biaya mereka dengan meng-hosting barang-barang yang Anda butuhkan dengan cara tanpa server. Mungkin ya bahkan tidak perlu peduli sebagai pengembang, tetapi pada level meta, itulah yang terjadi. Mungkin. Saya tidak tahu.

Chris: Ini juga tidak berarti bahwa… Database masih ada. Jika ternyata secara arsitektur memiliki database relasional adalah cara yang benar untuk menyimpan data itu, bagus. Saya menyebutkan itu karena dunia Tanpa Server ini tumbuh pada saat yang sama dengan JAMstack. Dan JAMstack adalah arsitektur ini, "Anda harus melayani situs web Anda dari host statis, yang tidak menjalankan apa pun kecuali untuk..." Mereka seperti CDN kecil. Mereka seperti, “Saya tidak bisa melakukan apa-apa. Saya tidak menjalankan PHP. Saya tidak menjalankan Ruby. Saya tidak menjalankan apa-apa. Saya menjalankan server web kecil kecil yang hanya dirancang untuk melayani file statis saja.”

Chris: “Dan kemudian, jika Anda perlu melakukan lebih dari itu, jika Anda perlu menarik data dari database relasional, maka lakukanlah di lain waktu, bukan di waktu server. Anda dapat melakukannya dalam proses build sebelumnya, dan menariknya keluar dari database, membuat file statis terlebih dahulu dan saya akan menyajikannya, atau melakukannya saat runtime.” Artinya Anda mendapatkan cangkang dokumen ini, dan kemudian membuat permintaan JavaScript untuk mendapatkan beberapa data dan mengisinya terlebih dahulu. Jadi Anda melakukannya sebelumnya atau setelah waktu, tetapi itu tidak berarti, "Jangan gunakan database relasional." Itu hanya berarti, "Tidak ada server yang membuatnya pada saat permintaan dokumen," yang merupakan... Saya tidak tahu, ini sedikit perubahan paradigma.

Chris: Ini bukan hanya JAMstack. Kita juga hidup di masa kerangka kerja JavaScript. Kita hidup di masa di mana itu mulai sedikit lebih diharapkan bahwa cara aplikasi JavaScript boot, adalah bahwa ia memasang beberapa komponen, dan ketika komponen itu dipasang, ia meminta data yang dibutuhkannya. Jadi, ini bisa menjadi semacam kecocokan alami untuk sesuatu seperti situs web React seperti, “Yah, saya akan menekan fungsi tanpa server untuk mengumpulkan data yang dibutuhkannya. Ini mengenai beberapa API JSON pada dasarnya. Saya mendapatkan data JSON yang saya butuhkan dan saya membangun sendiri dari data itu, dan kemudian saya merender ke halaman.” Sekarang, apakah itu baik atau buruk untuk web, itu seperti, “Saya tidak tahu. Sayang sekali. Kapal telah berlayar. Begitulah cara banyak orang membangun situs.” Itu hanya sesuatu yang diberikan klien. Jadi, jenis JavaScript tanpa server dan modern berjalan seiring.

Drew: Saya kira Anda tidak perlu grosir… melihat satu arsitektur atau yang lain. Ada area di tengah di mana bagian infrastruktur mungkin lebih tradisional dan bagian bisa tanpa server, saya kira?

Kris: Ya. Yah, mereka tetap mencoba memberitahumu itu. Siapa pun yang ingin menjual bagian arsitektur mereka kepada Anda seperti, “Anda tidak harus membeli semuanya sekarang. Lakukan sedikit saja.” Karena tentu saja, mereka ingin Anda mencelupkan kaki Anda ke dalam apa pun yang mereka jual, karena begitu Anda mencelupkan jari kaki, kemungkinan Anda menceburkan diri ke dalam kolam jauh lebih tinggi. Jadi, saya pikir ... itu bukan kebohongan, tentu saja, meskipun saya merasa sedikit kurang beruntung di ... Saya tidak ingin tumpukan saya menjadi sedikit dari segalanya. Saya pikir ada beberapa kematian teknis di sana yang tidak selalu ingin saya telan.

Drew: Mm (mengiyakan).

Chris: Tapi itu mungkin untuk dilakukan. Saya pikir yang paling banyak dikutip adalah… misalkan saya memiliki situs yang memiliki elemen eCommerce, yang artinya… dan katakanlah eCommerce skala besar, jadi 10.000 produk atau sesuatu, yang arsitektur JAMstack ini belum mencapai titik di mana itu selalu sangat efisien untuk membangunnya kembali secara statis. Jadi, pemikirannya berbunyi, "Kalau begitu jangan." Biarkan bagian itu terhidrasi secara alami dengan ... tekan fungsi tanpa server dan dapatkan data yang dibutuhkan, dan lakukan semua itu. Tapi bagian situs lainnya, yang tidak… tidak banyak halaman, tidak banyak data, Anda bisa melakukan pra-render atau apa pun. Jadi sedikit dari keduanya.

Drew: Tentu saja, banyak orang berurusan dengan sistem warisan yang… beberapa database lama yang dibangun pada tahun 2000-an sehingga mereka mungkin dapat menempelkan semacam lapisan API JSON di atas…

Kris: Ya.

Drew: … dan membangun sesuatu yang lebih modern, dan mungkin tanpa server, dan kemudian masih berinteraksi dengan sistem warisan tersebut dengan cara menempelkannya secara bersamaan.

Kris: Ya. Aku suka itu, bukan? Bukankah… kebanyakan website sudah ada. Berapa banyak dari kita yang benar-benar situs web ramah lingkungan? Sebagian besar dari kita mengerjakan beberapa omong kosong yang sudah ada yang perlu diseret ke masa depan untuk beberapa alasan, karena saya tidak tahu, pengembang ingin bekerja lebih cepat, atau Anda tidak dapat mempekerjakan siapa pun di COBOL lagi, atau apa pun ceritanya adalah. Kamu tahu?

Drew: Jadi dari segi terminologi, kita berbicara tentang JAMstack yang merupakan metodologi menjalankan kode cukup banyak di browser, menyajikannya dari CDN. Jadi, tidak memiliki sesuatu yang dinamis di server. Dan kemudian ketika kita berbicara tentang tanpa server, kita berbicara tentang fungsionalitas kecil yang berjalan di server mereka di tempat lain. Apakah itu benar? Bahwa kita berbicara tentang fungsi cloud semacam ini-

Chris: Ya, maksud saya, keduanya merupakan ide yang menarik saat ini. Jadi agak mudah untuk membicarakan yang satu dan membicarakan yang lain. Tapi mereka tidak harus bersama. Anda dapat menjalankan situs JAMstack yang tidak ada hubungannya dengan apa pun tanpa server. Anda hanya melakukannya, Anda hanya membangun situs dan menjalankannya, dan Anda dapat menggunakan tanpa server tanpa harus peduli dengan JAMstack. Faktanya, CodePen tidak melakukan JAMstack sama sekali. Bukan berarti kami ingin membicarakan CodePen, tetapi ini adalah aplikasi Ruby on Rails. Ini berjalan pada sejumlah besar instans AWS EC2 dan berbagai arsitektur lain untuk mewujudkannya. Tapi kami menggunakan barang tanpa server kapan pun kami bisa untuk apa pun yang kami bisa, karena murah dan aman, dan cara yang bagus untuk bekerja. Jadi, tidak ada JAMstack yang digunakan sama sekali kecuali tanpa server di semua tempat.

Drew: Itu cukup menarik. Jenis tugas apa yang Anda lakukan tanpa server di CodePen?

Chris: Yah, ada banyak hal. Salah satunya, menurut saya, semoga cukup jelas, saya perlu… maksud dari CodePen adalah Anda menulis setiap HTML, CSS, dan JavaScript di browser dan menampilkannya di depan Anda, bukan? Tetapi Anda juga dapat memilih bahasa pra-prosesor. Katakanlah Anda menyukai Sass. Anda mengaktifkan Sass di CSS, dan Anda menulis Sass. Nah, sesuatu harus memproses Sass. Hari-hari ini, Sass ditulis dalam Dart atau semacamnya.

Chris: Secara teoritis, Anda bisa melakukannya di klien. Tetapi perpustakaan yang melakukan pra-pemrosesan ini cukup besar. Saya tidak berpikir saya ingin mengirimkan seluruh perpustakaan Sass kepada Anda, hanya untuk menjalankan hal itu. Saya tidak mau… hanya saja tidak, itu bukan arsitektur yang tepat untuk ini. Mungkin di ujung jalan, maksud saya, kita bisa berbicara tentang omong kosong offline, yada, yada, Pekerja Web. Ada sejuta hal arsitektur yang bisa kita lakukan. Tapi begini cara kerjanya sekarang, apakah ada lambda. Ini memproses Sass. Ia memiliki satu pekerjaan kecil, kecil, kecil, kecil.

Chris: Anda mengirimkannya gumpalan Sass ini dan itu mengirimi Anda barang-barang kembali, yang merupakan CSS yang diproses, mungkin peta situs, apa pun. Ini memiliki satu pekerjaan kecil kecil dan kami mungkin membayar untuk lambda itu, seperti empat sen atau sesuatu. Karena lambda sangat murah dan Anda juga bisa memalunya. Anda tidak perlu khawatir tentang skala. Anda baru saja menekan benda itu sebanyak yang Anda inginkan dan tagihan Anda akan sangat murah. Ada saat-saat di mana tanpa server mulai melewati batas menjadi terlalu mahal. Saya tidak tahu apa itu, saya bukan ahli hal-hal seperti itu. Tetapi secara umum, setiap hal tanpa server yang kami lakukan, pada dasarnya… semuanya hampir dianggap gratis, karena itu murah. Tapi ada satu untuk Sass. Ada satu untuk Kurang. Ada satu untuk Babbel. Ada satu untuk TypeScript. Ada satu untuk… Semua itu adalah lambda individual yang kami jalankan. Berikut beberapa kode, berikan ke lambda, ia kembali, dan kami melakukan apa pun yang akan kami lakukan dengannya. Tapi kami menggunakannya untuk lebih dari itu, bahkan baru-baru ini.

Kris: Ini contohnya. Setiap Pena di CodePen memiliki tangkapan layar. Itu agak keren, kan? Jadi, orang-orang membuat sesuatu dan kemudian kami membutuhkan PNG atau JPEG, atau semacamnya, sehingga kami dapat… dengan cara itu ketika Anda men-tweet, Anda mendapatkan sedikit pratinjaunya. Jika Anda membagikannya di Slack, Anda mendapatkan sedikit pratinjaunya. Kami menggunakannya di situs web itu sendiri untuk merender… alih-alih iframe, jika kami dapat mendeteksi bahwa Pena tidak dianimasikan, karena gambar iframe jauh lebih ringan, jadi mengapa tidak menggunakan gambar? Lagipula itu bukan animasi. Hanya peningkatan kinerja seperti itu. Jadi masing-masing tangkapan layar itu memiliki URL untuk itu, tentu saja. Dan kami telah merancangnya sehingga URL tersebut sebenarnya adalah fungsi tanpa server. Ini adalah pekerja. Jadi, jika URL itu terkena, kami dapat dengan cepat memeriksa apakah kami telah mengambil tangkapan layar itu atau belum.

Chris: Itu sebenarnya diaktifkan oleh Pekerja CloudFlare, karena Pekerja CloudFlare bukan hanya fungsi tanpa server, tetapi mereka juga memiliki penyimpanan data. Mereka memiliki hal yang disebut penyimpanan nilai kunci, jadi ID-nya, kita dapat memeriksanya dengan sangat cepat dan itu akan menjadi, "Benar atau salah, apakah Anda memilikinya atau tidak?" Jika sudah mendapatkannya, ia menyajikannya. Dan itu menyajikannya melalui CloudFlare, yang sangat cepat untuk memulai. Dan kemudian memberi Anda semua kemampuan ini juga. Karena ini adalah CDN gambar, Anda dapat mengatakan, “Nah, sajikan dalam format yang optimal. Sajikan sebagai dimensi ini.” Saya tidak perlu membuat gambar dalam dimensi tersebut. Anda cukup memasukkan dimensi di URL dan ukurannya kembali seperti itu, secara ajaib. Jadi itu sangat bagus. Jika tidak memilikinya, ia meminta fungsi tanpa server lain untuk membuatnya sangat cepat. Jadi itu akan membuatnya dan kemudian akan memasukkannya ke dalam ember di suatu tempat… karena Anda harus memiliki asal untuk gambar tersebut, bukan? Anda harus benar-benar meng-host-nya di suatu tempat biasanya. Jadi kami memasukkannya ke dalam ember S3 dengan sangat cepat dan kemudian menyajikannya.

Chris: Jadi tidak ada server antrian, tidak ada apa-apa. Ini seperti fungsi tanpa server yang mengelola pembuatan, penyimpanan, dan penyajian gambar-gambar ini. Dan ada seperti 50 juta atau 80 juta dari mereka atau sesuatu. Itu banyak, jadi ini menanganinya sebagai skala dengan cukup baik. Kami bahkan tidak menyentuhnya. Itu hanya terjadi. Semuanya terjadi super cepat. Sangat baik.

Drew: Saya rasa itu… yah, fungsi tanpa server idealnya cocok untuk tugas yang membutuhkan sedikit pengetahuan tentang keadaan. Maksud saya, Anda menyebutkan kemampuan CloudFlare untuk menyimpan pasangan nilai kunci untuk melihat apakah Anda sudah memiliki sesuatu yang di-cache atau belum.

Kris: Ya. Itulah yang mereka coba selesaikan, dengan itu. Pasangan nilai-kunci itu, adalah bahwa... Saya pikir secara tradisional itu benar. Mereka seperti, "Hindari keadaan dalam benda itu," karena Anda tidak bisa mengandalkannya. Dan Pekerja CloudFlare seperti, "Ya, sebenarnya, Anda dapat menangani keadaan, sampai tingkat tertentu." Ini tidak semewah... Saya tidak tahu, ini adalah nilai kunci, jadi ini adalah kunci dalam sebuah nilai. Ini tidak seperti hal mewah relasional yang bersarang. Jadi mungkin ada beberapa batasan untuk itu. Tapi ini adalah hari bayi untuk ini. Saya pikir hal-hal itu akan berkembang menjadi lebih kuat, jadi Anda memang memiliki beberapa kemampuan untuk melakukan beberapa hal seperti keadaan.

Drew: Dan terkadang keterbatasan, kemampuan terbatas semacam itu untuk mempertahankan status, atau fakta bahwa Anda tidak memiliki… Anda tidak ingin mempertahankan status sama sekali, mendorong Anda ke dalam arsitektur yang memberi Anda semacam ini… Nah, ketika kita berbicara tentang filosofi perangkat lunak "Potongan-potongan Kecil yang Digabungkan Secara Lepas", bukan?

Chris: Mm (mengiyakan).

Drew: Di mana setiap komponen kecil melakukan satu hal dan melakukannya dengan baik. Dan tidak benar-benar tahu tentang sisa ekosistem di sekitarnya. Dan sepertinya itu benar-benar berlaku untuk konsep fungsi tanpa server ini. Apa kamu setuju?

Kris: Ya. Saya pikir Anda bisa melakukan debat filosofis apakah itu ide yang bagus atau tidak. Kamu tahu? Saya pikir beberapa orang menyukai monolit. Saya pikir ada kemungkinan ... ada cara untuk melakukan ini secara berlebihan dan membuat terlalu banyak bagian kecil yang terlalu sulit untuk diuji sama sekali. Sangat menyenangkan memiliki tes seperti, “Oh, saya ingin tahu apakah fungsi Sass saya berfungsi. Baiklah, mari kita tulis tes kecil untuk itu dan pastikan itu benar. ” Tapi katakanlah, yang penting bagi pengguna adalah beberapa rangkaian dari tujuh di antaranya. Bagaimana Anda menguji ketujuh dari mereka bersama-sama? Saya pikir cerita itu menjadi sedikit lebih rumit. Saya tidak tahu bagaimana berbicara dengan sangat cerdas untuk semua hal itu, tetapi saya tahu bahwa itu belum tentu, jika Anda menggunakan semua fungsi tanpa server yang secara otomatis merupakan arsitektur yang lebih baik daripada arsitektur lainnya. Saya suka itu. Itu beralasan bagi saya dengan baik, tetapi saya tidak tahu bahwa itu adalah akhir dari semua arsitektur. Kamu tahu?

Drew: Bagi saya, ini terasa sangat seperti web, karena… ini persisnya bagaimana HTML bekerja, bukan? Anda mengirimkan beberapa HTML dan browser kemudian akan pergi dan mengambil gambar Anda dan mengambil JavaScript Anda dan mengambil CSS Anda. Sepertinya ini adalah perluasan dari itu -

Kris: Itu bagus.

Drew: … semacam ide. Namun, satu hal yang kami ketahui tentang web, adalah web dirancang agar tangguh karena jaringannya rapuh.

Chris: Mm (mengiyakan).

Drew: Seberapa kuat jenis pendekatan tanpa server? Apa yang terjadi jika sesuatu... jika salah satu bagian kecil itu hilang?

Chris: Itu akan sangat buruk. Kamu tahu? Ini akan menjadi bencana. Situs Anda akan down sama seperti server lain, jika kebetulan turun, saya kira.

Drew: Apakah ada cara untuk mengurangi itu, khususnya -

Kris: Saya tidak tahu.

Drew: … cocok dengan pendekatan semacam ini, yang pernah Anda temui?

Kris: Mungkin. Maksud saya, seperti yang saya katakan, hal kuat yang sangat mewah mungkin seperti... katakanlah Anda mengunjungi CodePen dan katakanlah ada implementasi JavaScript dari Sass dan kami melihat bahwa Anda berada di jaringan yang cukup cepat dan Anda sedang menganggur sekarang. Mungkin kita akan mengambil JavaScript itu dan memasukkannya ke dalam service worker. Kemudian, jika kami mendeteksi bahwa lambda gagal, atau sesuatu, atau Anda sudah menginstalnya, maka kami akan menekan pekerja layanan alih-alih lambda, dan pekerja layanan dapat bekerja secara offline. Jadi, itu agak bagus juga. Itu menarik. Maksudku, mereka adalah bahasa yang sama. Service worker adalah JavaScript dan banyak fungsi Cloud adalah JavaScript, jadi ada beberapa… Saya pikir itu kemungkinan, meskipun… hanya saja, itu beberapa teknis serius yang… Saya takut memiliki potongan JavaScript yang telah Anda kirimkan ke berapa ribu pengguna, yang Anda belum tentu tahu apa yang mereka miliki, dan versi apa yang mereka miliki. Eww, tapi itu hanya ketakutanku sendiri. Saya yakin beberapa orang telah melakukan pekerjaan yang baik dengan hal semacam itu.

Chris: Saya sebenarnya tidak tahu. Mungkin Anda tahu beberapa strategi yang saya tidak tahu, tentang ketahanan tanpa server.

Drew: Saya kira ada mode kegagalan, gaya kegagalan, yang bisa terjadi dengan fungsi tanpa server, di mana Anda menjalankan fungsi sekali dan gagal, dan Anda dapat menjalankannya untuk kedua kalinya segera setelah itu dan itu akan berhasil, karena mungkin berhasil server yang sama sekali berbeda. Atau apa pun masalahnya, saat proses itu mungkin tidak ada pada permintaan kedua. Masalah seluruh host yang down adalah satu hal, tapi mungkin ada... Anda memiliki masalah individu dengan mesin. Anda memiliki server tertentu di mana memorinya rusak, dan itu menimbulkan banyak kesalahan, dan pertama kali Anda menekannya, itu akan gagal. Kedua kalinya, masalah itu mungkin telah berakar.

Chris: Perusahaan yang cenderung menawarkan teknologi ini, Anda harus mempercayai mereka, tetapi mereka juga merupakan jenis perusahaan yang… ini adalah kebanggaan mereka. Inilah alasan mengapa orang menggunakannya karena mereka dapat diandalkan. Saya yakin orang dapat menunjukkan beberapa pemadaman AWS di masa lalu, tetapi mereka cenderung agak jarang, dan tidak terlalu umum. Jika Anda menghosting omong kosong Anda sendiri, saya yakin mereka membuat Anda kalah dari tingkat persentase SLA. Kamu tahu? Jadi ini tidak seperti, "Jangan membangun dengan cara yang tangguh," tetapi umumnya jenis perusahaan yang menawarkan hal-hal ini sangat dapat diandalkan. Kemungkinan Anda turun karena Anda mengacaukan fungsi itu jauh lebih tinggi daripada karena arsitekturnya gagal.

Drew: Saya kira, maksud saya, sama seperti apa pun di mana Anda menggunakan API atau sesuatu yang bisa gagal, hanya memastikan Anda menyusun kode Anda untuk mengatasi mode kegagalan itu, dan untuk mengetahui apa yang terjadi selanjutnya, daripada hanya membuang kesalahan untuk pengguna, atau hanya sekarat, atau apa yang Anda miliki. Itu menyadari hal itu dan meminta pengguna untuk mencoba lagi. Atau mencoba lagi sendiri, atau sesuatu.

Chris: Ya, saya suka ide mencoba lebih dari sekali, daripada hanya berkata, “Oh tidak. Gagal. Menggugurkan." “Entahlah, kenapa tidak coba lagi kesana sobat?”

Drew: Jadi maksud saya, dalam hal pengujian dan pengembangan fungsi tanpa server, semacam fungsi cloud, apakah itu sesuatu yang dapat dilakukan secara lokal? Apakah harus dilakukan di cloud? Apakah ada cara untuk mengelolanya?

Chris: Saya pikir ada beberapa cara. Saya tidak tahu apakah ceritanya sehebat itu. Ini masih konsep yang relatif baru, jadi saya pikir itu menjadi lebih baik dan lebih baik. Tapi dari yang saya tahu, untuk satu hal, Anda sedang menulis fungsi Node yang cukup normal. Dengan asumsi Anda menggunakan JavaScript untuk melakukan ini, dan saya tahu bahwa di Lambda secara khusus, mereka mendukung semua jenis hal. Anda dapat menulis PHP Cloud Function. Anda dapat menulis Ruby Cloud Function. Jadi, saya tahu saya secara khusus berbicara tentang JavaScript, karena saya merasa bahwa sebagian besar dari hal-hal ini adalah JavaScript. Bahkan tidak peduli bahasa apa itu, maksud saya, Anda dapat pergi ke baris perintah Anda secara lokal dan menjalankannya. Beberapa dari pengujian itu adalah… Anda hanya mengujinya seperti yang Anda lakukan pada kode lainnya. Anda cukup memanggil fungsi tersebut secara lokal dan melihat apakah itu berfungsi.

Chris: Ini cerita yang sedikit berbeda ketika Anda berbicara tentang permintaan HTTP untuk itu, itulah hal yang Anda coba uji. Apakah itu menanggapi permintaan dengan benar? Dan apakah itu mengembalikan barang dengan benar? Saya tidak tahu. Jaringan mungkin terlibat di sana. Jadi, Anda mungkin ingin menulis tes pada level itu. Tidak apa-apa. Saya tidak tahu. Apa cerita normal di sana? Anda memutar semacam server lokal atau sesuatu yang melayaninya. Gunakan tukang pos, saya tidak tahu. Tapi ada… Kerangka mencoba membantu juga. Saya tahu bahwa ".com" tanpa server, yang sangat membingungkan, tetapi sebenarnya ada perusahaan bernama Tanpa Server dan mereka membuat kerangka kerja untuk menulis fungsi tanpa server yang membantu Anda menerapkannya.

Chris: Jadi jika Anda suka menginstal NPM tanpa server, Anda mendapatkan kerangka kerja mereka. Dan secara luas dianggap sangat bagus, karena sangat membantu, tetapi mereka tidak memiliki cloud sendiri atau apa pun. Anda menulis ini dan kemudian membantu Anda membawanya ke lambda nyata. Atau mungkin bekerja dengan beberapa penyedia cloud. Saya bahkan tidak tahu hari ini, tetapi tujuan keberadaan mereka adalah untuk membuat cerita penyebaran lebih mudah. Saya tidak tahu apa… AWS tidak terkenal karena kesederhanaannya. Kamu tahu? Ada banyak alat untuk membantu Anda menggunakan AWS dan mereka salah satunya.

Chris: Mereka memiliki semacam produk berbayar. Saya bahkan tidak tahu persisnya apa. Saya pikir salah satu hal yang mereka lakukan adalah ... tujuan menggunakannya adalah untuk pengujian, adalah untuk memiliki lingkungan dev untuk menguji fungsi tanpa server Anda.

Drew: Ya, karena saya kira, itu adalah bagian besar dari alur kerja, bukan? Jika Anda telah menulis fungsi JavaScript Anda, Anda telah mengujinya secara lokal, Anda tahu itu akan berhasil. Bagaimana Anda benar-benar memilih penyedia mana yang akan dituju dan bagaimana Anda memasukkannya ke layanan itu? Nah, maksud saya, itu ladang ranjau, bukan?

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

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

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

Drew: Absolutely.

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

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

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

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

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

Drew: Yeah, that sounds smart. Ya.

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

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

Chris: Easily.

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

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

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

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

Chris: They all do, you know?

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

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

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

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

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

Kris: Ya, ya. Saya pikir begitu, saya pikir itu… karena ada saat-saat seperti… Anda tidak harus sangat ahli untuk mengetahui apa yang pantas dan apa yang tidak untuk sebuah situs web. Seperti, saya melakukan sedikit tutorial minggu lalu, di mana ada kesalahan ini menggunakan ini ... ketika Anda menyimpan kesalahan, mereka memberi Anda siput untuk barang yang Anda buat, yaitu, “Whiskey, tango, foxtrot. 1.000.” Ini seperti hal kecil yang pintar. Peluangnya untuk menjadi unik sangat tinggi, karena saya pikir mereka bahkan menambahkan nomor atau sesuatu juga. Tapi mereka akhirnya menjadi hal-hal kecil yang menyenangkan ini. Mereka membuka perpustakaan mereka yang memiliki semua kata di dalamnya, tapi itu seperti seratus, ribuan kata. Filenya sangat besar. Kamu tahu? Ini megabyte besar hanya kamus kata-kata. Anda mungkin belajar di tahun pertama pengembangan Anda, "Jangan mengirimkan file JavaScript yang berukuran megabita kamus." Itu bukan hal yang baik untuk dikirim. Kamu tahu? Tapi Node tidak peduli. Anda dapat mengirimkan ratusan dari mereka. Ini tidak relevan dengan kecepatan di server.

Drew: Ya.

Chris: Tidak masalah di server. Jadi, saya bisa seperti, "Hmm, baiklah, saya akan melakukannya di Node kalau begitu." Saya akan memiliki pernyataan yang mengatakan, "Kata-kata yang sama membutuhkan kata-kata," atau apa pun, dan sebuah catatan di atas, "Mintalah untuk mengacak sebuah angka. Tarik keluar dari array dan kembalikan.” Jadi fungsi tanpa server adalah delapan baris kode dengan paket@JSON yang menarik pustaka sumber terbuka ini. Dan kemudian kode front-end saya, ada URL ke fungsi tanpa server. Itu menyentuh URL itu. URL mengembalikan satu kata atau sekelompok kata atau apa pun. Anda membangun API kecil Anda sendiri untuk itu. Dan sekarang, saya memiliki sesuatu yang sangat bagus dan efisien. Apa yang menyenangkan tentang itu adalah, itu sangat sederhana. Saya tidak khawatir tentang keamanannya. Aku tidak… kau tahu?

Chris: Ini hanya… pengembang JavaScript yang sangat rata-rata atau pemula, saya pikir, dapat melakukannya, dan itu keren. Itu adalah hal yang memungkinkan yang tidak mereka miliki sebelumnya. Sebelumnya, mereka seperti, "Nah, ini adalah susunan kata 2MB." "Oh, saya tidak bisa mengirimkan itu ke klien." “Oh, kalau begitu kamu tutup saja.” Anda mungkin menabrak dinding ini yang seperti, “Saya tidak bisa melakukan bagian itu kalau begitu. Saya perlu meminta orang lain untuk membantu saya dengan itu atau tidak melakukannya atau memilih siput yang lebih membosankan atau semacamnya…” Hanya saja, Anda harus pergi ke jalan lain yang merupakan tembok bagi Anda, karena Anda tidak bisa melakukannya. Dan sekarang, Anda, "Oh, baiklah, saya akan ..." Alih-alih memilikinya di skrip slash saya, atau di folder skrip slash sumber saya, saya akan meletakkannya di folder fungsi saya sebagai gantinya.

Chris: Anda seperti memindahkan skrip dari satu folder ke folder lain. Dan yang itu kebetulan digunakan sebagai fungsi tanpa server sebagai gantinya. Betapa kerennya itu? Kamu tahu? Anda menggunakan keahlian yang sama persis, hampir. Masih ada beberapa tepi kasar untuk itu, tapi itu cukup dekat.

Drew: Ini sangat keren. Anda telah mengumpulkan semacam situs mikro kecil tentang ide-ide ini, bukan?

Kris: Ya. Saya sedikit lebih awal untuk permainan. Saya baru saja mengerjakannya hari ini, karena… itu mendapat permintaan tarik. Idenya… yah, ada di serverless.css-tricks.com dan… ada tanda hubung di CSS-Tricks. Jadi ini adalah subdomain dari CSS-Tricks, dan saya juga membuatnya tanpa server, jadi ini… CSS-Tricks seperti situs WordPress, tetapi ini adalah situs generator situs statis. Semua kontennya ada di repo GitHub, yang merupakan sumber terbuka. Jadi jika Anda ingin mengubah konten situs, Anda bisa mengirimkan permintaan polling, yang bagus karena sudah ada sekitar seratus dari waktu ke waktu. Tapi saya membangun semua konten asli.

Drew: Ini adalah tempat yang sangat berguna, karena mencantumkan… Jika Anda berpikir, “Benar, saya ingin memulai dengan fungsi tanpa server,” ini mencantumkan semua penyedia yang dapat Anda coba dan…

Chris: Itu saja, cukup banyak, adalah daftar teknologi. Ya.

Drew: Bagus sekali, karena jika tidak, Anda hanya mencari di Googling dan tidak tahu apa yang Anda temukan. Ya, ini adalah daftar penyedia API yang membantu Anda melakukan hal-hal semacam ini.

Chris: Formulir adalah salah satu contohnya, karena… jadi begitu Anda memilih untuk… katakanlah, Anda akan menggunakan JAMstack, yang saya tahu bukan itu intinya, tetapi Anda lihat betapa bergandengan tangan mereka . Tiba-tiba, Anda tidak memiliki file PHP atau apa pun untuk memproses formulir itu. Bagaimana Anda membuat formulir di situs JAMstack? Nah, ada sejumlah cara untuk melakukannya. Semua orang dan saudara perempuan mereka ingin membantu Anda memecahkan masalah itu, rupanya. Jadi saya pikir jika saya adalah penemu kata JAMstack, jadi mereka mencoba membantu Anda secara alami, tetapi Anda tidak harus menggunakannya.

Chris: Sebenarnya, saya sangat terkejut menempatkan situs ini bersama-sama. Ayo lihat. Ada enam, sembilan, dua belas, lima belas, delapan belas, dua puluh satu, dua puluh dua layanan di luar sana, yang ingin membantu Anda memproses formulir tanpa server di situs ini sekarang. Jika Anda ingin menjadi yang ke-23, silakan saja, tetapi Anda memiliki beberapa kompetisi di luar sana. Jadi ide di balik ini adalah Anda menulis formulir dalam HTML, seperti elemen formulir secara harfiah. Dan kemudian atribut tindakan dari formulir, itu tidak bisa menunjuk ke mana pun secara internal, karena tidak ada yang bisa ditunjukkan. Anda tidak dapat memproses, jadi ini menunjuk ke luar. Ini menunjuk ke apa pun yang mereka ingin Anda tunjukkan. Mereka akan memproses formulir dan kemudian mereka cenderung melakukan hal-hal yang Anda harapkan, seperti mengirim pemberitahuan email. Atau kirim barang Slack. Atau kemudian kirimkan ke Zapier dan Zapier akan mengirimkannya ke tempat lain. Mereka semua memiliki set fitur dan harga dan hal-hal yang sedikit berbeda, tetapi mereka semua mencoba memecahkan masalah itu untuk Anda, seperti, “Anda tidak ingin memproses formulir Anda sendiri? Tidak masalah. Kami akan memprosesnya untuk Anda.”

Drew: Ya, ini adalah sumber yang sangat berguna. Saya benar-benar akan merekomendasikan semua orang untuk memeriksanya. Ini tanpa server.css-tricks.com. Jadi, saya telah mempelajari semua tentang tanpa server. Apa yang telah kamu pelajari akhir-akhir ini, Chris?

Chris: Yah, saya masih sangat banyak di dunia ini dan belajar tentang hal-hal tanpa server. Saya punya ide untuk… Saya dulu pernah memainkan game role playing online ini. Saya baru-baru ini menemukan bahwa itu masih hidup. Ini adalah jenis permainan fantasi abad pertengahan berbasis teks. Saya memainkannya ketika AOL adalah suatu hal, karena AOL ingin memiliki permainan ini sehingga Anda harus masuk untuk memainkannya, karena mereka ingin Anda menghabiskan berjam-jam di AOL, sehingga mereka dapat mengirimi Anda tagihan besar ini, yaitu , Saya yakin, mengapa mereka melakukannya dengan sangat baik di beberapa titik.

Drew: Jadi penagihan per detik. Ya.

Kris: Ya. Jadi permainan itu besar bagi mereka. Jika mereka bisa membuat Anda bermain game dengan orang lain di sana. Jadi game ini semacam... tidak debut di sana, tapi pindah ke AOL, karena saya yakin mereka mendapat kesepakatan yang menarik untuk itu, tapi memang begitu... Maksudku, hanya saja, tidak mungkin lebih nerdier. Anda adalah penyihir kurcaci dan Anda mendapatkan tongkat rune dari sarung kulit Anda. Dan Anda mengetik perintah ke dalamnya seperti terminal. Kemudian game merespons Anda. Saya memainkan permainan itu untuk waktu yang sangat lama. Saya sangat menyukainya. Saya masuk ke komunitas itu dan semangatnya. Itu semacam ... itu seperti saya sendirian di depan komputer saya, tetapi saya melihat kembali waktu itu dalam hidup saya, dan menjadi seperti, "Itu adalah waktu yang indah dalam hidup saya." Saya benar-benar... Saya hanya menyukai orang-orangnya dan permainannya dan semua itu. Tapi kemudian saya tumbuh dan berhenti memainkannya, karena hidup terjadi pada Anda.

Chris: Saya baru mengetahuinya baru-baru ini, karena seseorang mulai membuat podcast tentangnya lagi… Saya tidak tahu bagaimana saya menemukannya, tetapi saya baru saja melakukannya. Saya seperti, “Permainan ini hidup dan sehat di dunia sekarang ini, apakah Anda bercanda? Hal berbasis teks ini. ” Dan saya sangat senang untuk mengaktifkan kembali dan mendapatkan kembali karakter lama saya dan memainkannya. Tetapi hanya untuk mengetahui bahwa klien yang mereka unduh untuk game ini, belum berkembang sama sekali. Mereka mengerikan. Mereka hampir berasumsi bahwa Anda menggunakan Windows. Hanya ada rendering buruk yang sangat cheesy ini ... dan itu berbasis teks, Anda pikir itu setidaknya memiliki tipografi yang bagus. Tidak. Jadi saya seperti, “Saya bisa terlibat. Saya bisa menulis klien untuk game ini. Letakkan tipografi yang indah di dalamnya.” Modernkan saja, dan saya pikir para pemain game akan menghargainya, tetapi itu terasa luar biasa bagi saya. “Bagaimana saya bisa melakukannya?” Tapi saya menemukan beberapa proyek open source. Salah satunya adalah seperti... Anda dapat memainkan game melalui jendela terminal yang sebenarnya, dan menggunakan beberapa lib sumber terbuka untuk membuat GUI dari jendela terminal.

Drew: Benarkah?

Kris: Saya tidak tahu. Jadi itu agak keren. Saya seperti, “Jika mereka menulis itu, pasti ada kode di sana untuk menghubungkan ke game dan menjalankan semuanya dan sebagainya. Jadi setidaknya saya punya beberapa kode starter. ” Saya mencoba mengikuti aplikasi, "Mungkin saya akan melakukannya di Flutter atau semacamnya," sehingga aplikasi produk akhir akan berfungsi di ponsel dan, "Saya benar-benar dapat memodernisasi hal ini." Tapi kemudian saya kewalahan. Saya seperti, “Ah, ini terlalu besar… saya tidak bisa. Saya sibuk." Tetapi saya menemukan orang lain yang memiliki ide yang sama dan mereka jauh lebih jauh dengan itu, jadi saya hanya bisa berkontribusi pada tingkat desain. Dan itu sangat menyenangkan untuk dikerjakan, tetapi saya juga belajar banyak, karena jarang bagi saya untuk terjun ke proyek yang merupakan bayi orang lain, dan saya hanya berkontribusi sedikit, dan itu benar-benar berbeda pilihan teknologi daripada yang pernah saya pilih.

Chris: Ini adalah aplikasi Electron. Mereka memilih itu, yang juga merupakan cara yang keren untuk dilakukan, karena ini adalah keterampilan web saya… jadi saya tidak mempelajari sesuatu yang terlalu aneh, dan ini lintas platform, yang sangat bagus. Jadi, saya telah belajar banyak tentang Electron. Saya pikir itu menyenangkan.

Drew: Itu menarik. Itu selalu menakjubkan bagaimana proyek sampingan kecil dan hal-hal yang kita lakukan untuk bersenang-senang, akhirnya menjadi tempat di mana kita kadang-kadang belajar paling banyak. Dan pelajari keterampilan yang kemudian dapat digunakan kembali dalam pekerjaan sehari-hari kita.

Chris: Itulah satu-satunya cara saya mempelajari sesuatu. Saya terseret ke dalam sesuatu yang… Saya seperti, “Mereka tidak…” Itu diterjemahkan dengan pustaka JavaScript bernama Mithril, yang… Saya tidak tahu apakah Anda pernah mendengarnya, tapi ini aneh. Bukan… hampir seperti menulis React tanpa JSX. Anda harus "membuat elemen" dan melakukan semua ini... tapi itu seharusnya menjadi tolok ukur yang jauh lebih baik dari itu... Dan itu sebenarnya penting karena dalam game berbasis teks ini, teksnya terbang begitu saja. Ada banyak manipulasi data, seperti… Anda akan mengira game berbasis teks ini akan sangat mudah dijalankan oleh jendela browser, tetapi sebenarnya tidak. Ada begitu banyak manipulasi data yang terjadi, sehingga Anda harus benar-benar… kita harus berhati-hati dengan kecepatan rendering. Kamu tahu?

Drew: Itu menarik-

Kris: Cukup keren.

Drew: Ya. Jika Anda, pendengar terkasih, ingin mendengar lebih banyak dari Chris, Anda dapat menemukannya di Twitter, di mana dia @chriscoyier. Tentu saja, CSS-Tricks dapat ditemukan di css-tricks.com dan CodePen di codepen.io. Tapi yang terpenting, saya sarankan Anda berlangganan podcast ShopTalk Show jika Anda belum melakukannya, di shoptalkshow.com. Terima kasih telah bergabung dengan kami hari ini, Chris. Apakah Anda memiliki kata-kata perpisahan?

Chris: Smashingpodcast.com. Saya harap itu adalah URL yang sebenarnya.