Dasar-dasar JAMstack: Apa, Apa, dan Bagaimana

Kami senang melampaui batas di web, jadi kami memutuskan untuk mencoba sesuatu yang baru. Anda mungkin pernah mendengar tentang JAMstack — tumpukan web baru berdasarkan JavaScript, API, dan Markup — tetapi apa artinya bagi alur kerja Anda dan kapan itu masuk akal dalam proyek Anda?

Sebagai bagian dari Keanggotaan Smashing kami, kami menjalankan Smashing TV , serangkaian webinar langsung, setiap minggu. Tanpa basa-basi — hanya webinar yang praktis dan dapat ditindaklanjuti dengan tanya jawab langsung, dijalankan oleh praktisi yang disegani dari industri ini. Memang, jadwal Smashing TV sudah terlihat cukup padat, dan gratis untuk Anggota Smashing, bersama dengan rekaman — tentu saja .

Kami dengan hormat meminta Phil Hawksworth untuk menjalankan webinar yang menjelaskan apa sebenarnya arti JAMStack dan kapan itu masuk akal, serta bagaimana hal itu memengaruhi perkakas dan arsitektur front-end. Webinar berdurasi satu jam sekarang juga tersedia. Kami sangat senang menyambut Phil untuk menjadi co-MC SmashingConf Toronto mendatang kami (25-26 Juni) dan menjalankan JAMStack_conf London, yang juga kami selenggarakan bersama pada 9-10 Juli tahun ini. Jadi, mari kita masuk ke dalamnya!

Phil Hawksworth: Bagus, oke, mari kita masuk ke dalamnya. Hanya dengan cara menyapa yang sangat cepat, maksud saya saya sudah menyapa, Scott memberi saya pengantar yang bagus. Tapi ya, saya saat ini bekerja di Netlify, saya bekerja di tim pengalaman pengembang di sana. Mudah-mudahan kami akan memiliki banyak waktu untuk Tanya Jawab, tetapi, seperti yang disebutkan Scott, jika Anda tidak mendapatkan kesempatan untuk mengajukan pertanyaan di sana, atau jika Anda lebih suka, Anda dapat melakukan ping langsung ke saya di Twitter, jadi Twitter saya menangani adalah nama saya, ini Phil Hawksworth, jadi kapan pun Anda pasti bisa bertanya kepada saya tentang JAMstack atau apa pun di Twitter.

Phil Hawksworth: Tapi saya ingin memulai hari ini hanya dengan sedikit mundur ke masa lalu ke kutipan ini yang sangat, sangat kuat dengan saya. Ini adalah kutipan dari Aaron Schwartz yang luar biasa yang, tentu saja, berkontribusi begitu banyak pada Creative Commons dan web terbuka dan dia menulis ini di blognya pada tahun 2002, dan dia berkata, “Saya peduli untuk tidak mempertahankan rewel Server AOL, Postgres, dan instalasi Oracle.” Server AOL, saya harus melihat ke atas untuk mengingatkan diri saya sendiri adalah server web open source pada saat itu.

Phil Hawksworth: Tapi ini sangat cocok dengan saya. Saya juga tidak ingin memelihara infrastruktur agar blog tetap hidup, dan itulah yang dia bicarakan. Dan itu di posting blog ini di blognya sendiri dan berjudul "Panggang, Jangan Goreng". Dia memilih istilah yang baru-baru ini mulai digunakan oleh seseorang yang baru saja membuat CMS, dan dia mempopulerkan istilah ini tentang memanggang (Panggang, Jangan Goreng); apa yang dia bicarakan di sana adalah pra-rendering daripada rendering sesuai permintaan, jadi memanggang konten terlebih dahulu, daripada menggorengnya sesuai permintaan ketika orang datang dan memintanya — mendapatkan sesuatu dari waktu permintaan dan menjadi semacam waktu pembuatan.

Phil Hawksworth: Dan ketika kita berbicara tentang pra-rendering dan rendering, yang kami maksud adalah tentang menghasilkan markup. Saya merasa sedikit sadar diri kadang-kadang berbicara tentang jenis render server atau rendering isomorfik atau banyak istilah buzzwordy semacam ini; Saya dipanggil beberapa tahun yang lalu di sebuah konferensi, Frontiers Conference di Amsterdam ketika saya berbicara tentang rendering di server dan seseorang berkata kepada saya, “Maksud Anda menghasilkan HTML? Hanya sesuatu yang menghasilkan HTML?” Dan itu, tentu saja, yang saya maksud.

Phil Hawksworth: Tapi semua ini sangat membantu menyederhanakan tumpukan. Ketika kami memikirkan tentang tumpukan situs web yang kami layani; Saya ingin mencoba menyederhanakan banyak hal, saya sangat tertarik untuk mencoba menyederhanakan tumpukan. Dan itulah inti dari hal yang disebut "JAMstack" dan saya ingin mencoba menjelaskannya sedikit. "JAM" di JAMstack adalah singkatan dari JavaScript, API, dan Markup. Tapi itu tidak cukup untuk membantu kita memahami apa artinya — apa sebenarnya artinya itu?

Phil Hawksworth: Yah, apa yang ingin saya coba dan lakukan dalam setengah jam ke depan atau lebih, adalah saya ingin memperluas definisi itu dan memberikan lebih banyak deskripsi tentang apa itu JAMstack. Saya ingin berbicara sedikit tentang dampak dan implikasi JAMstack, dan, Anda tahu, pikirkan tentang apa yang dapat memberi kita alasan mengapa kita memilihnya. Sepanjang jalan, saya akan mencoba menyebutkan beberapa alat dan layanan yang akan berguna, dan mudah-mudahan, saya akan menyelesaikan dengan beberapa sumber yang mungkin ingin Anda gali dan mungkin menyebutkan beberapa langkah pertama untuk mendapatkan Anda sedang berjalan.

Phil Hawksworth: Jadi, itulah rencana untuk setengah jam berikutnya. Tapi, saya ingin, semacam, kembali ke gagasan tentang menyederhanakan tumpukan, karena, mudah-mudahan, orang-orang yang bergabung ini atau telah datang untuk menonton video ini nanti, mungkin Anda punya gagasan tentang apa itu JAMstack, atau mungkin itu istilah yang sama sekali baru, dan Anda hanya ingin tahu. Tapi, pada akhirnya, sudah ada banyak tumpukan di luar sana. Ada banyak cara yang dapat Anda lakukan untuk mengirimkan situs web. Rasanya seperti kami telah membangun berbagai jenis infrastruktur untuk waktu yang sangat lama, apakah itu tumpukan LAMP atau tumpukan MAMP, atau — entahlah — tumpukan MEAN. Ada banyak dari mereka yang mengambang di layar di sini. Ada banyak dan banyak dari mereka.

Phil Hawksworth: Jadi, mengapa kita membutuhkan yang lain? Yah, JAMstack, seperti yang saya sebutkan, adalah JavaScript/API/Markup, tetapi jika kita mencoba dan sedikit lebih deskriptif, JAMstack dimaksudkan untuk menjadi arsitektur modern, untuk membantu membuat situs yang cepat dan aman serta aplikasi dinamis dengan JavaScript/ API dan markup pra-render, disajikan tanpa server web, dan ini adalah poin terakhir yang, semacam, sesuatu yang membedakannya dan mungkin, membuatnya sedikit lebih, menarik, dan tidak biasa.

Phil Hawksworth: Gagasan menyajikan sesuatu tanpa server web, kedengarannya ajaib atau konyol, dan mudah-mudahan, kami akan mencari tahu apa yang terjadi di sepanjang jalan. Namun untuk mencoba dan menjelaskan hal ini dan menjelaskannya dengan sedikit lebih detail, terkadang berguna untuk membandingkannya dengan apa yang mungkin kita anggap sebagai tumpukan tradisional, atau cara tradisional menyajikan sesuatu di web. Jadi, mari kita lakukan itu sebentar. Mari kita telusuri, mungkin, seperti apa tampilan permintaan saat dilayani di tumpukan tradisional.

Phil Hawksworth: Jadi, dalam skenario ini, kami meminta seseorang membuka browser web dan membuat permintaan untuk melihat halaman. Dan mungkin permintaan itu mengenai CDN, tetapi kemungkinan besar, permintaan itu mengenai infrastruktur lain yang kami hosting — sebagai pemilik situs ini. Mungkin kami mencoba memastikan bahwa ini akan diskalakan di bawah banyak beban karena kami, jelas, menginginkan pemandangan yang sangat populer dan sukses. Jadi, mungkin kami memiliki penyeimbang beban, yang memiliki beberapa logika di dalamnya, yang akan melayani permintaan itu ke salah satu dari sejumlah server web yang telah kami sediakan dan konfigurasikan dan terapkan. Mungkin ada beberapa server tersebut.

Phil Hawksworth: Dan server tersebut akan menjalankan beberapa logika untuk mengatakan, "Oke, ini template kita, kita perlu mengisinya dengan beberapa data." Kami mungkin mendapatkan data kami dari salah satu dari sejumlah server basis data yang akan melakukan beberapa logika untuk mencari beberapa data, mengembalikannya ke server web, membuat tampilan yang kemudian kami lewati kembali melalui penyeimbang beban. Mungkin, di sepanjang jalan, memanggil CDN, menyimpan beberapa aset di CDN, dan saya harus mengklarifikasi, CDN adalah Jaringan Pengiriman Konten, jadi jaringan mesin yang didistribusikan di Internet untuk mencoba dan mendapatkan layanan permintaan sedekat mungkin ke pengguna dan menambahkan hal-hal, seperti caching.

Phil Hawksworth: Jadi, kami mungkin menyimpan beberapa aset di sana, dan pada akhirnya, mengembalikan tampilan ke browser, ke bola mata pengguna, yang kemudian dapat merasakan situs yang kami buat. Jadi, jelas, itu adalah penyederhanaan yang berlebihan atau pandangan yang sangat umum tentang bagaimana kami dapat melayani permintaan dalam tumpukan tradisional. Jika kita membandingkannya dengan JAMstack, yang melayani berbagai hal dengan cara yang sedikit berbeda, beginilah tampilannya.

Phil Hawksworth: Jadi, sekali lagi, skenario yang sama, kita mulai di browser web. Kami membuat permintaan untuk melihat halaman, dan halaman itu sudah ada di CDN. Ini berfungsi secara statis dari sana, jadi dikembalikan ke pengguna, ke browser, dan selesai. Jadi, jelas, tampilan yang sangat disederhanakan, tetapi langsung, Anda dapat mulai melihat perbedaan di sini dalam hal kerumitan. Dalam hal tempat yang kita perlukan untuk mengelola kode, kode mendalam, semua hal yang berbeda itu. Jadi, bagi saya, salah satu atribut inti dari JAMstack, adalah artinya Anda sedang membangun situs yang mampu dilayani langsung dari CDN, atau bahkan dari server file statis. CDN adalah sesuatu yang mungkin ingin kami tempatkan untuk menangani beban, tetapi pada akhirnya, ini dapat dilayani langsung dari semua jenis server file statis, jenis infrastruktur hosting statis.

Phil Hawksworth: JAMstack, semacam, menawarkan kesempatan untuk mengurangi kompleksitas. Hanya dengan membandingkan dua bagian diagram yang akan kita bahas beberapa kali, selama setengah jam berikutnya, Anda dapat melihat bahwa ini adalah kesempatan untuk mengurangi kerumitan dan mengurangi risiko. Jadi, itu berarti kita dapat mulai menikmati beberapa manfaat dari melayani aset statis, dan saya akan membicarakan apa itu nanti. Tetapi Anda mungkin melihat ini dan berpikir, “Wah, bagus, tapi bukankah ini hanya nama baru untuk situs web statis?” Itu adalah hal yang masuk akal untuk saya tingkatkan ketika saya mengatakan, "Kami akan melayani hal-hal secara statis."

Phil Hawksworth: Tapi saya ingin kembali ke sana. Saya ingin membicarakannya sedikit lebih banyak, tetapi pertama-tama, saya ingin berbicara tentang pengertian tumpukan ini dan apa sih tumpukan itu? Dan saya menganggap tumpukan sebagai lapisan teknologi, yang mengantarkan situs web atau aplikasi Anda. Dan kita tidak berbicara tentang jalur pembangunan, atau proses pengembangan, tetapi tentu saja cara kami melayani situs dapat berdampak besar pada cara kami mengembangkan dan cara kami menerapkan berbagai hal, dan seterusnya.

Phil Hawksworth: Tapi di sini, kita berbicara tentang tumpukan teknologi, lapisan teknologi, yang benar-benar menghadirkan situs web dan aplikasi Anda kepada pengguna. Jadi, mari kita lakukan sedikit perbandingan lagi. Mari kita bicara tentang tumpukan LAMP sebentar.

Phil Hawksworth: Tumpukan LAMP, Anda mungkin ingat, terdiri dari server web apache, untuk melakukan hal-hal seperti perutean HCP dan penyajian aset statis. PHP, untuk beberapa pra-pemrosesan, pemrosesan hiper-teks yang sangat cantik; menerapkan logika, mungkin membangun tampilan untuk templat dan apa yang Anda miliki. Dan memiliki beberapa akses ke data Anda, dengan NISQL saya, dan kemudian LINUX adalah sistem operasi yang berada di bawah semua itu, membuat semuanya tetap bernafas. Kita dapat membungkusnya secara bersama-sama sebagai server web ini. Dan kami mungkin memiliki banyak dari server ini, semacam, duduk bersama untuk melayani sebuah situs web.

Phil Hawksworth: Itu semacam, tampilan tradisional di tumpukan LAMP, dan jika kita membandingkannya dengan JAMstack, nah, di sini, ada perubahan penting. Di sini, kami benar-benar naik level, daripada memikirkan sistem operasi dan memikirkan bagaimana kami menjalankan logika untuk menghadirkan situs web. Di sini kita membuat asumsi bahwa kita akan melayani hal-hal ini secara statis. Jadi, kami melakukan perutean ACP, dan penyajian aset dari server statis. Itu bisa dilakukan secara wajar. Kami sangat ahli dalam hal ini, selama bertahun-tahun, membangun cara untuk menghadirkan situs web statis, atau aset statis.

Phil Hawksworth: Ini mungkin CDN, dan sekali lagi, kita akan membicarakannya sebentar lagi. Tetapi area yang menarik bagi kami, lebih banyak terjadi di browser. Jadi, di sinilah markup kami dikirimkan dan diuraikan. Di sinilah JavaScript dapat dijalankan, dan ini terjadi di browser. Dalam banyak hal, browser telah menjadi runtime untuk web modern. Daripada memiliki runtime di infrastruktur server itu sendiri, sekarang kami telah memindahkannya ke tingkat yang lebih tinggi, lebih dekat ke pengguna, dan ke browser.

Phil Hawksworth: Ketika datang untuk mengakses data, itu terjadi melalui, mungkin, API eksternal, membuat panggilan melalui JavaScript ke API eksternal ini untuk mendapatkan akses server, atau kita dapat menganggap API sebagai API browser, dapat berinteraksi dengan JavaScript dengan kemampuan yang ada di browser Anda.

Phil Hawksworth: Apa pun itu, kunci di sini tentang JAMstack adalah, kita berbicara tentang hal-hal yang telah dirender sebelumnya: mereka disajikan secara statis dan kemudian, mereka mungkin ditingkatkan secara progresif di browser untuk menggunakan API browser, JavaScripts , dan apa yang Anda miliki.

Phil Hawksworth: Jadi, mari kita lakukan perbandingan kecil ini di sini. Sekali lagi, saya hanya ingin menegaskan kembali bahwa JAMstack telah naik satu tingkat ke browser. Dan jika kita melihat dua sisi diagram ini, dengan tumpukan LAMP di sebelah kiri dan secara efektif, JAMstack di sebelah kanan, Anda mungkin berpikir bahwa, bahkan ketika kita sedang membangun sesuatu dengan tumpukan LAMP, kita masih keluaran mark-up. Kami masih mengeluarkan JavaScript. Kami mungkin masih mengakses API. Jadi, dalam banyak hal, JAMstack hampir seperti bagian dari apa yang kami bangun sebelumnya.

Phil Hawksworth: Saya kadang-kadang berbicara tentang JAMstack sebagai tumpukan yang terjamin, karena ini memastikan seperangkat alat dan teknologi yang kita perlukan untuk memberikan sebuah situs. Namun, bagaimanapun juga, ini adalah cara yang jauh disederhanakan untuk memberikan situs yang, semacam, menghilangkan kebutuhan akan hal-hal untuk mengeksekusi dan menjalankan logika di server pada waktu permintaan.

Phil Hawksworth: Jadi, ini bisa melakukan banyak hal. Ini bisa, semacam, menyederhanakan penerapan dan sekali lagi, saya akan memanggil kembali diagram ini dari waktu ke waktu. Jika kita berpikir tentang bagaimana kita menerapkan kode dan situs kita, untuk setiap penerapan, dari yang pertama, melalui seluruh siklus hidup pengembangan, sepanjang masa pakai situs web. Pada tumpukan tradisional, kita mungkin harus mengubah logika dan konten untuk setiap kotak pada diagram itu.

Phil Hawksworth: Padahal, di JAMstack, ketika kita berbicara tentang penerapan, kita berbicara tentang mendapatkan sesuatu ke CDN, mengirimkan sesuatu ke server statis, dan itulah yang diperlukan dalam penerapan. Build, jenis logika yang menjalankan build — yang bisa dijalankan di mana saja. Itu tidak perlu dijalankan di lingkungan yang sama yang menghosting server web. Sebenarnya tidak! Itu memulai kunci ke JAMstack. Kami menempatkan pemisahan pada apa yang terjadi pada waktu permintaan, menyajikan aset statis ini, versus apa yang terjadi pada waktu pembuatan, yang dapat menjadi logika Anda yang Anda jalankan untuk membangun dan kemudian ke penerapan.

Phil Hawksworth: Jadi, pemisahan semacam ini adalah kuncinya, dan saya akan kembali membahasnya nanti. Kami sangat baik dalam menyajikan file statis, dan memasukkan sesuatu ke CDN atau memasukkan sesuatu ke sistem file (server file) adalah suatu tempat yang telah kami lihat kemajuan besar, semacam, selama beberapa tahun terakhir. Ada banyak alat dan proses, sekarang, yang dapat membantu kami melakukan ini dengan sangat baik. Hanya untuk menyebut beberapa layanan yang dapat melayani aset statis dengan baik dan memberikan alur kerja untuk membawa bangunan Anda ke lingkungan itu, mereka adalah tersangka yang biasa Anda bayangkan penyedia infrastruktur cloud besar, seperti Azure, AWS, dan Google Cloud.

Phil Hawksworth: Tapi kemudian, ada yang lain. Jadi, yang paling atas di sebelah kanan adalah layanan yang disebut Surge, yang telah ada selama beberapa tahun. Ini memungkinkan Anda untuk menjalankan perintah di lingkungan build Anda dan menyebarkan aset Anda ke lingkungan hosting mereka. Netlify, yang berikutnya, adalah tempat saya bekerja dan kami melakukan banyak hal yang sama tetapi kami juga memiliki otomatisasi yang berbeda. Saya bisa membahasnya lain kali. Dan yang di bawah, situs lingkungan hosting statis lainnya, bernama Now.

Phil Hawksworth: Jadi, ada banyak pilihan berbeda untuk melakukan ini, dan semua ruang ini menyediakan alat yang berbeda untuk sampai ke CDN, secepat mungkin. Menyebarkan situs Anda dengan cara yang paling mulus yang kami bisa. Dan mereka semua memiliki kesamaan di mana mereka membangun prinsip menjalankan sesuatu secara lokal. Saya sering menganggap generator situs statis sebagai sesuatu yang mungkin kita jalankan dalam sebuah build yang ketika kita menjalankannya, dibutuhkan hal-hal seperti konten dan template dan mungkin, data dari layanan yang berbeda dan menghasilkan sesuatu yang dapat disajikan secara statis.

Phil Hawksworth: Kami dapat mempratinjaunya secara lokal di server statis kami. Sesuatu yang agak mudah dilakukan di lingkungan pengembangan lokal mana pun, dan kemudian proses penerapan yang membawanya ke lingkungan hosting dan idealnya, ke CDN untuk mendapatkan, semacam, skala. Jadi, dengan dasar semacam itu, saya ingin mengatasi sedikit kesalahpahaman umum tentang situs JAMstack. Dan saya tidak membantu diri saya sendiri dengan membuka ini sebagai menggambarkan situs JAMstack sebagai JavaScript, API, dan Markup. Karena kesalahpahaman umum adalah bahwa setiap situs JAMstack harus berupa JavaScript dan API, dan Markup, tetapi hal semacam ini yang kami abaikan adalah bahwa kami tidak harus menggunakan ketiganya — masing-masing adalah, semacam , pilihan. Kita dapat menggunakan sebanyak, atau sesedikit yang kita suka. Dengan cara yang sama seperti situs tumpukan LAMP tidak perlu mengenai basis data. Sekarang, saya telah membangun hal-hal di masa lalu yang dilayani oleh server apache, pada mesin Linux, dan saya telah menggunakan PHP, tetapi saya belum mencapai database dan saya tidak akan mulai mengganti nama tumpukan tentu untuk itu.

Phil Hawksworth: Jadi, jika kita berpikir tentang apa itu situs JAMstack, maka itu bisa menjadi banyak hal yang berbeda. Ini mungkin sesuatu yang dibangun dengan generator situs statis, seperti Jekyll, menarik konten dari file YAML untuk membangun situs yang tidak memiliki JavaScript, tidak mencapai API sama sekali, dan kami menyajikannya pada sesuatu, seperti Halaman GitHub. Atau, itu akan menjadi situs JAMstack. Atau mungkin kita menggunakan generator situs statis, seperti Gatsby, yang lebih tepatnya di lingkungan Ruby untuk Jekyll, sekarang ini adalah generator situs statis JavaScript yang dibangun di ekosistem React.

Phil Hawksworth: Itu mungkin menarik konten lagi, dan itu mengatur file penurunan harga. Mungkin memperkaya itu dengan panggilan ke API, API GraphQL. Mungkin melakukan hal-hal di browser, seperti melakukan hidrasi JavaScript dari mengisi template di browser. Dan mungkin disajikan di Amazon S3. Apakah itu situs JAMStack? Ya, tentu saja!

Phil Hawksworth: Beralih ke generator situs statis yang berbeda, Hugo, yang dibuat dengan Go! Sekali lagi, kami mungkin mengatur konten dalam file penurunan harga, menambahkan interaksi di browser menggunakan JavaScript. Mungkin tidak memanggil API eksternal apa pun dan mungkin menghostingnya di Google Cloud. Apakah itu JAMstack? Sangat! Anda lihat, saya sedang membangun sebuah tema di sini. Menggunakan sesuatu seperti Nuxt, generator situs statis lainnya, sekarang dibangun di ekosistem View. Mungkin itu menarik konten dari file yang berdekatan yang berbeda? Sekali lagi, kita mungkin menggunakan interaksi JavaScript di browser, mungkin memanggil API untuk melakukan hal-hal seperti e-Commerce, menyajikannya situs statis lain. Infrastruktur hosting lain seperti Netlify, apakah itu JAMstack? Ya itu!

Phil Hawksworth: Tapi kita bahkan mungkin pergi, Anda tahu, pergi ke ujung skala ini juga. Dan pikirkan tentang aplikasi web progresif buatan tangan yang kami buat dengan tangan, JavaScript yang kami buat sendiri. Kami mengemasnya dengan webpack. Kami mungkin menggunakan token web JavaScript dan memanggil API untuk melakukan otentikasi, berinteraksi dengan API browser yang berbeda, menghostingnya di Azure. Ya, itu JAMstack juga!

Phil Hawksworth: Dan, Anda tahu, semua hal ini, dan banyak lagi, dapat dianggap sebagai JAMstack, karena semuanya memiliki satu atribut yang sama dan tidak ada yang dilayani dengan server asal. Tak satu pun dari mereka harus menekan server yang melakukan logika pada waktu permintaan. Ini disajikan sebagai aset statis, dan kemudian diperkaya dengan JavaScript dan panggilan ke API, setelahnya.

Phil Hawksworth: Jadi, sekali lagi, saya hanya ingin menegaskan kembali bahwa JAMstack berarti dapat dilayani langsung dari CDN. Jadi, saya hanya ingin menyebutkan beberapa dampak dan implikasi dari ini, karena mengapa kita ingin melakukan ini? Nah, gagasan pertama adalah tentang keamanan, dan kita memiliki area permukaan yang sangat berkurang untuk diserang, di sini. Jika kita memikirkan (kembali ke diagram lama ini lagi), tempat di mana kita mungkin harus menghadapi serangan, kita harus mengamankan hal-hal seperti penyeimbang beban, server web, server database. Semua hal ini, kita harus memastikan tidak dapat ditembus oleh segala jenis serangan dan, memang, CDN.

Phil Hawksworth: Jika semakin banyak potongan yang bisa kita ambil dari teka-teki ini, semakin sedikit tempat yang bisa diserang dan semakin sedikit tempat yang harus kita amankan. Memiliki beberapa bagian yang bergerak untuk menyerang benar-benar sangat berharga. Di Netlify, kami mengoperasikan CDN kami sendiri, jadi kami mendapatkan kemewahan untuk dapat memantau lalu lintas yang melewatinya, dan meskipun semua situs yang dihosting di Netlify, semua situs JAMstack yang mungkin Anda bayangkan, tidak satupun dari mereka memiliki halaman admin WordPress di dalamnya karena benar-benar terpisah. Tidak ada admin WordPress, tetapi kami melihat volume lalu lintas yang sangat besar, menyelidiki hal-hal seperti WP Admin, mencari jalan masuk, mencari vektor serangan.

Phil Hawksworth: Saya sangat menyukai beberapa hal yang telah dilakukan Kent C. Dodds. Saya tidak tahu apakah Anda familiar dengan komunitas React, Anda mungkin pernah bertemu Kent C. Dodds di masa lalu. Dia tidak menggunakan WordPress, tetapi dia masih merutekan URL ini, WPAdmin. Saya pikir dia biasa mengarahkannya ke video Rick Roll di YouTube. Dia pasti telah menjebak orang-orang yang telah menyelidikinya. Tapi, intinya adalah, dengan memisahkan hal-hal dengan cara itu dan, semacam, memindahkan hal-hal yang terjadi, membangun waktu dari apa yang terjadi dalam waktu permintaan, kita dapat secara drastis mengurangi eksposur kita. Kami tidak punya bagian yang bergerak pada waktu permintaan. Semua bagian yang bergerak benar-benar dipisahkan pada waktu pembuatan. Berpotensi, pada infrastruktur yang sama sekali berbeda.

Phil Hawksworth: Ini, tentu saja, juga berdampak pada kinerja. Kembali ke teman lama kita di sini, tempat-tempat yang mungkin ingin kita coba dan tingkatkan kinerjanya di seluruh tumpukan di sini, ketika ada logika yang perlu dijalankan di tempat yang berbeda ini. Cara yang sering terjadi di tumpukan tradisional adalah, mereka mulai menambahkan lapisan, menambahkan lapisan statis, untuk meningkatkan kinerja. Jadi, dengan kata lain, cobalah dan temukan cara agar kita bisa mulai berperilaku seolah-olah itu statis. Tidak harus melakukan logika itu di setiap level tumpukan untuk mempercepat. Jadi, kami mulai memperkenalkan hal-hal seperti caching di seluruh infrastruktur dan tempat yang mungkin kami temukan untuk melakukannya adalah di server web, daripada menjalankan logika itu, kami ingin menyajikan sesuatu dengan segera tanpa menjalankan logika itu.

Phil Hawksworth: Jadi, ini seperti langkah menuju, semacam, menjadi statis semu. Demikian juga di server basis data, kami ingin menambahkan lapisan caching ke kueri cache-com. Bahkan dalam saldo rendah, seluruh CDN, Anda dapat menganggapnya sebagai cache. Tetapi pada tumpukan tradisional, kita perlu mencari cara untuk mengelola cache itu, karena tidak semuanya akan di-cache. Jadi, ada akan beberapa logika tentang. Apa yang perlu diisi secara dinamis versus apa yang dapat di-cache. Dan model JAMstack, semuanya di-cache. Semuanya di-cache sejak penerapan selesai, sehingga kami dapat memikirkannya secara berbeda.

Phil Hawksworth: Ini, kemudian, mulai, semacam, mengisyaratkan penskalaan, juga. Dan berdasarkan skala, yang saya bicarakan, bagaimana kita menangani banyak lalu lintas? Tumpukan tradisional akan mulai menambahkan infrastruktur untuk skala. Jadi, ya, untuk caching. Kami mulai menempatkan di tumpukan tradisional kami. Itu akan membantu — sampai taraf tertentu. Apa yang biasanya terjadi adalah, untuk menangani banyak lalu lintas, kami akan mulai memperluas infrastruktur dan mulai menambahkan lebih banyak server, lebih banyak bagian untuk menangani permintaan ini, mengeluarkan biaya dan memperkirakan beban adalah overhead yang besar dan itu bisa menjadi sakit kepala bagi siapa pun yang melakukan arsitektur teknis. Itu pasti untuk saya, itulah sebabnya saya mulai lebih condong ke arah melakukan pendekatan JAMstack di mana saya hanya tahu bahwa semuanya dilayani dari CDN, yang dirancang secara default untuk menangani skala, untuk menangani kinerja langsung dari gerbang .

Phil Hawksworth: Jadi, saya juga ingin memberikan anggukan pada pengalaman pengembang, dan dampaknya di sana. Sekarang, pengalaman pengembang tidak boleh dilihat sebagai sesuatu yang mengalahkan pengalaman pengguna, tetapi saya percaya bahwa pengalaman pengembang yang baik dapat mengurangi gesekan, dapat memungkinkan pengembang untuk melakukan pekerjaan yang jauh lebih baik dalam membangun pengalaman pengguna yang hebat!

Phil Hawksworth: Jadi, ketika kita berpikir tentang di mana pengalaman pengembang tinggal, dan di mana area yang menjadi perhatian pengembang di sini: baik, dalam tumpukan tradisional, kita mungkin perlu memikirkan bagaimana kita mendapatkan kode untuk semua ini. bagian dari infrastruktur, dan bagaimana mereka semua bermain bersama. Di dunia JAMstack, sebenarnya, yang kita bicarakan adalah kotak ini di bagian bawah. Anda tahu, bagaimana kami menjalankan build dan mereka, bagaimana kami mengotomatiskan penerapan untuk mendapatkan sesuatu yang disajikan di tempat pertama? Dan hal yang menyenangkan adalah, dalam model JAMstack, apa yang Anda lakukan dalam build itu sepenuhnya terserah Anda.

Phil Hawksworth: Itu adalah ruang masalah yang terdefinisi dengan baik, karena pada akhirnya, Anda mencoba membangun sesuatu yang dapat Anda layani langsung dari CDN. Anda ingin melakukan pra-render sesuatu, menggunakan alat apa pun yang Anda suka: apakah itu generator situs statis yang dibangun di Ruby atau Python atau JavaScript atau Go atau PHP, Anda memiliki kebebasan untuk membuat pilihan itu. Jadi, itu dapat menciptakan lingkungan yang jauh lebih baik bagi Anda untuk bekerja. Dan juga, ini menciptakan peluang untuk memiliki kepercayaan pengembang yang nyata karena atribut nyata dari situs JAMstack adalah bahwa mereka dapat lebih mudah disajikan sebagai penyebaran atom yang tidak dapat diubah dan atom.

Phil Hawksworth: Dan saya ingin, agak, melompat dari slide sesaat, untuk menjelaskan apa artinya itu, karena penerapan yang tidak dapat diubah dan penerapan atom dapat… (itu mungkin terdengar sedikit seperti pembicaraan pemasaran) tetapi apa yang akan saya lakukan, adalah saya akan masuk ke browser saya. Sekarang ... sebenarnya, saya akan kembali sebentar. Biarkan aku ... lakukan saja ini.

Phil Hawksworth: Ini dia. Ini akan lebih mudah. Langsung masuk ke halaman. Sekarang, Scott, Anda akan memberi tahu saya, Scott, jika Anda tidak dapat melihat browser saya, saya harap. Sekarang, dengan asumsi semua orang dapat melihat browser saya.

Scott: Semuanya terlihat bagus.

Phil Hawksworth: Luar biasa! Terima kasih banyak!

Phil Hawksworth: Jadi, yang saya lakukan di sini adalah saya menggunakan Netlify sebagai contoh, sebagai contoh layanan. Tapi, ini adalah atribut yang umum untuk situs yang dapat dihosting, secara statis. Jadi, ketika kita berbicara tentang penerapan yang tidak dapat diubah, yang kami maksudkan adalah, bahwa setiap penerapan kode harus menyentuh banyak bagian infrastruktur yang berbeda, dan mengubah banyak hal, di sini kami tidak mengubah status situs di server. Kami membuat instance situs yang sama sekali baru untuk setiap penerapan yang terjadi. Dan kita bisa melakukannya karena situs adalah kumpulan aset statis.

Phil Hawksworth: Di sini, saya melihat penerapan yang telah terjadi dari situs web saya sendiri. Aku akan memberimu hadiah. Itu dia, itu yang terlihat. Ini hanya sebuah blog, tidak terlihat seperti sesuatu yang luar biasa atau menarik. Ini adalah blog yang dibuat secara statis, tetapi apa yang saya miliki di sini adalah setiap penerapan yang pernah terjadi, hidup selamanya, karena ini adalah kumpulan aset statis yang disajikan dari CDN. Sekarang, saya bisa kembali sejauh sejarah saya dapat membawa saya dan pergi dan melihat situs itu, seperti dulu… kapan ini? Ini adalah Agustus 2016. Dan karena itu menjadi satu set aset statis, kami dapat meng-host ini di URL-nya sendiri yang terus hidup dan jika saya mau, saya bisa memutuskan untuk masuk dan mempublikasikannya penyebaran.

Phil Hawksworth: Jadi, sekarang, siapa pun yang melihat situs web saya, jika saya kembali ke situs web saya di sini, jika saya menyegarkan halaman itu, sekarang itu disajikan langsung dari CDN dengan aset yang ada di sana sebelumnya. Sekarang, saya bisa bernavigasi lagi. Di sini, Anda bisa melihat. Dengar, saya membicarakan hal ini, saya menggunakan istilah-istilah mengerikan ini seperti rendering isomorfik dan berbicara tentang JAMstack pada tahun 2016. Jadi, sekarang inilah yang disajikan langsung di situs saya. Sekali lagi, karena ada penerapan bersama yang hidup selamanya. Saya hanya akan menempatkan pikiran saya sendiri, jenis, ketenangan pikiran, saya akan — apakah ini halaman pertama? Ya. Saya akan kembali ke penerapan terbaru saya. Aku harus menutup lagi, dan membawaku kembali ke dunia nyata. Biarkan aku memastikan ini baik-baik saja.

Phil Hawksworth: Oke! Besar! Jadi, sekarang, ini kembali ke versi saya sebelumnya, atau versi terbaru dari situs saya. Saya akan kembali ke keynote. Jadi, ini mungkin karena segala sesuatunya tidak dapat diubah dan bersifat atomik. Bagian atom dari itu berarti, sekali lagi, bahwa penyebaran sepenuhnya terkandung. Jadi, Anda tidak akan pernah mengerti di mana beberapa aset tersedia di server web, tetapi beberapa di antaranya tidak. Hanya ketika semuanya ada dalam konteks dan semuanya ada di sana, lengkap, barulah kami beralih penyajian situs ke versi baru. Sekali lagi, ini adalah jenis hal yang dapat Anda lakukan dengan lebih mudah jika Anda membangun sesuatu sebagai situs JAMstack yang melayani langsung dari CDN sebagai sekumpulan aset.

Phil Hawksworth: Saya perhatikan bahwa pengatur waktu saya telah diatur ulang, setelah bolak-balik dari keynote, jadi saya pikir saya punya waktu sekitar enam atau tujuh menit lagi. Katakan padaku, Scott, jika—

Scott: Jadi, ya, kami masih baik-baik saja selama sekitar sepuluh menit.

Phil Hawksworth: Sepuluh menit? Oke, luar biasa!

Scott: Tidak perlu terburu-buru.

Phil Hawksworth: Terima kasih, itu pasti bagus!

Phil Hawksworth: Jadi, hanya berpindah gigi sedikit dan berbicara tentang API dan layanan (karena API adalah bagian dari JAMstack), jenis layanan yang mungkin dapat kami gunakan sebagian besar adalah JAMstack. Anda tahu, kami mungkin menggunakan layanan yang kami buat sendiri, atau kami mungkin menggunakan layanan yang dibeli. Ada banyak penyedia berbeda yang dapat melakukan sesuatu untuk kita, dan itu karena itulah keahlian mereka. Melalui API, kami mungkin menarik konten dari sistem manajemen konten sebagai layanan, dan ada banyak penyedia berbeda untuk ini, yang mengkhususkan diri dalam memberikan pengalaman manajemen konten yang hebat dan kemudian, mengekspos konten melalui API, jadi Anda dulu mampu menarik mereka masuk.

Phil Hawksworth: Demikian juga, ada berbagai cara Anda dapat melayani aset. Orang-orang seperti Cloudary hebat dalam hal ini, untuk melakukan pengoptimalan gambar, menyajikan aset langsung ke situs Anda, sekali lagi, melalui API. Atau bagaimana dengan e-Commerce? Anda tahu, ada tempat seperti Stripe atau Snipcart yang dapat menyediakan API kepada kami, sehingga kami tidak perlu membangun layanan ini sendiri dan masuk ke masalah yang sangat kompleks yang datang dengan mencoba membangun mesin e-Commerce. Demikian juga identitas, dari orang-orang seperti Auth0 yang menggunakan Oauth. Ada banyak layanan yang tersedia dan kita dapat menggunakan hal-hal ini melalui API, baik di browser atau pada waktu pembuatan, atau terkadang, kombinasi keduanya.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. Halo semuanya. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. Benar? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: Saya sangat suka, karena istilah JAMstack bisa sangat menyesatkan, karena mencoba untuk menutupi banyak hal yang berbeda dan poin yang saya coba, saya mungkin memukulnya berkali-kali di slide itu, adalah bahwa itu bisa bermacam-macam dari hal-hal. Ini sangat luas, tetapi kuncinya adalah pra-rendering dan hosting inti dari situs secara statis. Sangat mudah bagi kita untuk terlibat dalam perang agama tentang di mana itu perlu menjadi situs React. Itu harus aplikasi React, untuk menjadi situs JAMstack, atau itu aplikasi React, jadi itu bukan JAMstack. Tapi, sungguh, intinya adalah, apakah Anda menggunakan JavaScript atau tidak, apakah Anda memanggil API atau tidak, jika Anda melakukan pra-render dan memasukkan sesuatu ke dalam host statis yang bisa sangat berkinerja, itulah inti dari JAMstack.

Vitaly: Ya, tentu saja.

Phil Hawksworth: Kami sangat beruntung bahwa browser menjadi jauh lebih mampu, dan API yang ada di dalam browser itu sendiri dapat memungkinkan kami untuk melakukan lebih banyak juga. Jadi, hal semacam itu membuka pintu lebih jauh, tetapi itu tidak berarti bahwa semua yang kami bangun sebagai situs JAMstack harus memanfaatkan semuanya. Bergantung pada apa yang kami coba berikan, begitulah cara kami harus mulai memilih alat yang kami mainkan untuk menerapkan hal-hal itu.

Vitalia: Tentu saja. Kami memiliki Doran di sini. Doran, sepertinya aku tahu, Doran. Saya merasa bahwa saya mengenal Doran. Dia bertanya, “Apakah Anda berharap tanpa server akan condong ke integrasi tanpa batas dengan JAMstack dari [tidak terdengar 00:44:36]? Apa yang disebut sebagai A di JAM.

Phil Hawksworth: Itu pertanyaan yang bagus, karena menurut saya, fungsi tanpa server adalah — mereka sangat cocok dengan situs JAMstack, karena dalam banyak hal, pada kenyataannya, saya pikir seseorang pernah bertanya kepada saya apakah situs JAMstack tidak memiliki server, jadi saya bertanya-tanya pertanyaan itu, karena tanpa server adalah istilah yang dimuat. Tapi, dalam banyak hal, itu menggemparkan karena saya berbicara, berkali-kali, tentang tidak ada server asal. Tidak ada infrastruktur server untuk Anda kelola. Bahkan, saya pernah menulis posting blog yang disebut "Web Serverless," karena dunia membutuhkan istilah buzz lain, bukan?

Phil Hawksworth: Dan sungguh, intinya adalah, ya, kami membangun sesuatu tanpa server. Kami tidak ingin harus mengelola server ini, dan fungsi tanpa server, atau fungsi sebagai layanan, sangat cocok dengan itu. Jadi, jika Anda memang memerlukan API yang ingin Anda buat permintaannya, di mana sebenarnya tidak masuk akal bagi Anda untuk membuat permintaan itu langsung dari browser. Jadi, misalnya, jika Anda memiliki rahasia, atau kunci, dalam permintaan itu, Anda mungkin tidak ingin permintaan itu — informasi itu — pernah diekspos di klien. Tapi kita pasti bisa mem-proxy hal-hal itu, dan biasanya, secara tradisional, apa yang perlu kita lakukan kemudian, adalah memutar server, memiliki beberapa infrastruktur yang secara efektif melakukan sedikit lebih banyak daripada menangani permintaan, menambahkan otentikasi keamanan ke dalamnya dan meneruskan permintaan itu. , mem-proksi mereka kembali.

Phil Hawksworth: Fungsi tanpa server sempurna untuk itu. Mereka benar-benar ideal untuk itu. Jadi, saya terkadang memikirkan fungsi tanpa server, atau fungsi layanan, hampir seperti pintu keluar, di mana Anda hanya memerlukan beberapa logika di server, tetapi Anda tidak ingin harus membuat seluruh infrastruktur. Dan Anda dapat melakukan lebih banyak dan lebih banyak lagi dengan itu, dan menetapkan jalur pengembangan untuk, alur kerja pengembangan, untuk fungsi sebagai layanan yang semakin matang. Semakin mudah bagi pengembang JavaScript untuk dapat membangun hal-hal ini. Jadi, ya, saya benar-benar berpikir dua hal itu berjalan bersama dengan sangat baik.

Vitaly: Baiklah, itu jawaban yang sangat komprehensif. Sebenarnya, saya menghadiri sebuah ceramah baru-baru ini, di mana seorang insinyur front-end dari Amazon berbicara tentang fungsi tanpa server dan Lamda yang mereka gunakan — saya hampir pergi. Dia selalu berbicara tentang Docker, dan Kubernetes, dan semua hal itu, Devox World, saya duduk di sana, berpikir, “Bagaimana dia bisa ada di sana. Aku tidak mengerti apa yang sedang terjadi!” Aku tidak tahu apa yang terjadi.

Phil Hawksworth: Tepat, tapi masalahnya, dulu… saya… Saya menerima bahwa saya tidak mengerti dunia itu, tapi saya tidak punya keinginan untuk itu, karena itu untuk disiplin ilmu yang sama sekali berbeda . Dan disiplin itu masih sangat penting. Anda tahu, orang-orang yang merancang infrastruktur — itu masih sangat penting. Tapi, rasanya, sekarang, aku tergoda. Sebagai seseorang dengan latar belakang pengembangan front-end, sebagai pengembang JavaScript, saya jauh lebih tergoda untuk ingin bermain di dunia itu, karena alatnya semakin dekat dengan saya.

Phil Hawksworth: Kemungkinan besar saya dapat menggunakan beberapa dari hal-hal ini, dan mengirimkan barang-barang dengan aman, daripada hanya sebagai eksperimen saya sendiri, di mana saya dulu melakukan dappling. Jadi, rasanya kami menjadi lebih kuat sebagai pengembang web, yang menarik bagi saya.

Vitaly: Seperti Power Rangers, ya?

Vitaly: Satu hal yang ingin saya tanyakan kepada Anda, dan ini sebenarnya adalah sesuatu yang sudah kita diskusikan, mungkin, seminggu yang lalu, tetapi saya masih ingin membicarakannya, karena satu hal yang Anda sebutkan dalam sesi itu adalah gagasan memiliki instance yang berdiri sendiri dari setiap penerapan, yang sangat keren. Namun, pertanyaannya adalah jika Anda memiliki tugas besar, dengan puluhan ribu halaman, Anda benar-benar tidak ingin menerapkan ulang setiap hal, setiap saat. Jadi, pada dasarnya, jika Anda memiliki, seperti, jika Anda sebagian besar menggunakan sisi statis. Jadi, kami memiliki ide ini untuk sementara waktu dan saya tahu ini sebenarnya adalah sesuatu yang Anda kemukakan terakhir kali. Ide penyebaran atom.

Vitaly: Di mana Anda sebenarnya, secara harfiah, disajikan semacam div antara dua versi snapshot yang berbeda dari pengaturan. Jadi, jika Anda mengatakan, ubah tajuk di mana-mana, maka, tentu saja, setiap halaman harus digunakan kembali. Tetapi jika Anda mengubah, mungkin, sebuah komponen, seperti katakanlah, carousel, yang mungkin hanya memengaruhi 1000 halaman, maka masuk akal untuk menerapkan kembali 15000 halaman. Tapi hanya 1000 ini. Jadi, bisakah kita sampai di sana? Apakah itu ide ajaib yang ada di luar sana, atau apakah itu sesuatu yang cukup nyata, pada saat ini?

Phil Hawksworth: Saya pikir itu, mungkin, Cawan Suci untuk generator situs statis dan model semacam ini karena, tentu saja, Anda mungkin telah mengidentifikasi rintangan terbesar yang harus diatasi. Atau langit-langit terbesar yang Anda temui. Dan itu adalah situs web yang memiliki banyak, puluhan ribu atau ratusan ribu, atau jutaan URL — gagasan bahwa pembuatannya bisa menjadi sangat panjang. Mampu mendeteksi URL mana yang akan berubah, berdasarkan perubahan kode, adalah sebuah tantangan. Bukan tidak bisa diatasi, tapi ini tantangan besar. Memahami grafik ketergantungan di seluruh situs Anda dan kemudian, menerapkannya dengan cerdas — itu sangat sulit dilakukan.

Phil Hawksworth: Karena seperti yang Anda sebutkan, perubahan komponen mungkin memiliki implikasi yang sangat luas tetapi Anda — sulit, selalu, untuk mengetahui cara kerjanya. Jadi, ada sejumlah generator situs statis, proyek yang memberikan bobot di balik tantangan itu, dan mencoba mencari tahu bagaimana mereka melakukan regenerasi parsial dan pembangunan inkremental. Saya sangat senang bahwa prospek itu mungkin akan terpecahkan hari ini, tetapi pada saat ini, itu jelas merupakan tantangan besar. Anda dapat mulai melakukan hal-hal seperti mencoba membagi situs Anda secara logis, dan memikirkan, sekali lagi, hal yang serupa dengan masalah migrasi. Nah, bagian ini saya tahu independen dalam hal, jenis, beberapa aset yang digunakannya, atau jenis konten yang ada di sana, jadi saya bisa menyebarkannya satu per satu.

Phil Hawksworth: Tapi itu tidak ideal bagi saya. Itu bukan skenario yang sempurna. Salah satu pendekatan yang telah saya jelajahi sedikit, hanya sebagai bukti konsep, adalah memikirkan bagaimana Anda melakukan sesuatu, seperti, memanfaatkan 404 secara cerdas. Jadi, misalnya, kasus penggunaan besar untuk tanda-tanda yang sangat besar, mungkin situs berita, ketika mereka membutuhkan URL saat berita utama terjadi, mereka harus menjadi yang pertama menyebarkannya di luar sana. Mereka perlu mendapatkan URL di sana. Hal-hal seperti BBC News, Anda akan melihat bahwa berita akan tiba di situs web, dan kemudian seiring waktu, mereka akan menambahkannya, secara bertahap, tetapi sampai di sana terlebih dahulu adalah kuncinya. Jadi, memiliki build yang membutuhkan waktu 10 menit, 20 menit, apa pun itu, itu bisa menjadi masalah.

Phil Hawksworth: Tapi, jika kontennya diabstraksikan dan mungkin dulu dipanggil dari API. Saya menyebutkan sistem manajemen konten yang diabstraksikan, seperti Contentful, atau Sanity, atau banyak dari itu. Apa pun yang memiliki API konten berubah menjadi struktur konten yang akan memicu pembuatan dan kami akan menjalankannya, tetapi hal lain yang dapat terjadi adalah, jika Anda memublikasikan URL untuk itu, lalu memublikasikan URL tersebut , bahkan jika build belum berjalan, jika seseorang melakukan hicks URL tersebut, jika pemberhentian pertama pada 404-nya adalah alih-alih mengatakan, "Kami belum mendapatkannya," sebenarnya untuk menekan API itu secara langsung, maka, Anda dapat mengatakan , "Yah, build belum selesai untuk mengisinya, tapi saya bisa melakukannya di klien." Saya bisa langsung ke API, dapatkan itu, isi di klien.

Vitaly: Hmm, menarik.

Phil Hawksworth: Jadi, bahkan saat pembangunan masih berlangsung, Anda dapat mulai mengisi hal-hal itu. Dan kemudian, setelah build selesai, tentu saja tidak akan mencapai 404. Anda akan mencapai halaman yang berjalan secara statis itu. Jadi, ada teknik dan ada strategi untuk mengatasinya, tapi tetap saja, itu jawaban yang sangat panjang, bertele-tele, maaf, tapi kesimpulan saya, ya, itu tantangan. Semoga kita bisa mendapatkan strategi yang lebih baik.

Vitaly: Ya, itu bagus. Jadi, saya bertanya-tanya, jadi, pada titik ini, kami benar-benar tidak memikirkan, bukan hanya kinerja dalam hal penyampaian konten, tetapi kinerja dalam hal kecepatan pembuatan. Seperti pembangunan gedung. Jadi, ini juga sesuatu yang telah kami cari, cukup lama sekarang juga.

Vitaly: Satu hal lagi yang ingin saya tanyakan kepada Anda. Jadi, ini menarik, seperti teknik yang Anda sebutkan ini. Bagaimana Anda belajar tentang ini? Ini hanya sesuatu yang cenderung dipublikasikan orang di blog mereka sendiri atau, apakah itu media atau ada repositori pusat di mana Anda bisa mendapatkan semacam studio kasus, tentang bagaimana JAMstack—bagaimana perusahaan bergerak saat membongkar, atau gagal pindah ke JAMstack.

Phil Hawksworth: Jadi, ini sedikit mematangkan lanskap ini, saat ini. Maksud saya, beberapa contoh ini, saya pikir, saya berada dalam posisi yang sangat beruntung, saya bekerja di suatu tempat di mana saya berada dalam peran yang saya mainkan dengan mainan, menemukan cara menarik untuk menggunakannya dan mulai bereksperimen dengan mereka. Jadi, bukti konsep ini adalah, semacam, hal yang saya dapatkan untuk bereksperimen dan mencoba mengatasi tantangan ini. Tapi, seperti yang saya sebutkan sebelumnya, sebuah studi kasus yang ditunjukkan pada konferensi JAMstack di New York, dan tentu saja, acara seperti itu, kita mulai melihat praktik terbaik atau praktik industri dan pendekatan industri dibicarakan di tempat semacam itu. dari peristiwa. Dan tentu saja, saya ingin melihat lebih banyak dan mengerjakan lebih banyak studi kasus untuk mendapatkan tempat-tempat seperti di Majalah Smashing, sehingga kami dapat membagikan informasi ini dengan lebih mudah.

Phil Hawksworth: Saya pikir, perusahaan besar dan ruang perusahaan, secara bertahap mengadopsi JAMstack, di tempat yang berbeda, dengan cara yang berbeda, tetapi dunia masih miring untuk keluar dari sana, jadi saya pikir, setiap kali sebuah perusahaan mengadopsinya dan membagikannya pengalaman, kita semua bisa belajar dari itu. Tetapi saya benar-benar ingin melihat semakin banyak studi kasus ini diterbitkan, sehingga kita dapat bersandar terutama tentang bagaimana tantangan semacam ini diatasi.

Vitaly: Baiklah, kalau begitu, mungkin itu saja pertanyaan terakhir dari saya, karena saya selalu suka membaca pertanyaan. Jadi, JAMstack mendarat, jika Anda dapat mengubah sesuatu, mungkin ada sesuatu yang sangat ingin Anda lihat, di luar penerapan. Adakah hal lain yang benar-benar membuat Anda sangat bahagia? Itu akan membuat harimu menyenangkan? Apa itu? Apa yang ada di daftar keinginan Anda, untuk JAMstack?

Phil Hawksworth: Pertanyaan yang luar biasa. Maksudku, jika kita tidak membicarakan tentang build tambahan, itu akan menjadi—

Vitaly: Kami melakukannya. Itu sudah terlambat, sekarang. Kartu ini telah berlalu, sudah. Kami membutuhkan sesuatu yang lain.

Phil Hawksworth: Jadi—

Vitaly: Maksud saya, seperti di platform, jika Anda melihat platform belakang, ada banyak hal menarik yang terjadi. Kami memiliki Houdini, kami memiliki komponen web yang akan datang, dan semuanya, karena Anda dapat mengubah seluruh lanskap dari semua komponen yang tepat. Di sisi lain, kami memiliki semua dunia ajaib dan mewah ini dengan SS NGS, dan, tentu saja, kami juga memiliki aplikasi satu halaman dan semuanya. Apa yang paling membuatmu bersemangat?

Phil Hawksworth: Saya akan tumpul di sini, karena ada begitu banyak hal yang terjadi, menarik, dan ada begitu banyak kemampuan baru yang dapat Anda manfaatkan di browser. Hal yang membuat saya sangat bersemangat adalah orang-orang menunjukkan pengekangan (tertawa) dan seperti yang saya katakan, jawaban yang membosankan, tetapi saya suka melihat eksekusi hebat yang dilakukan dengan menahan diri, secara bijaksana — tentang khalayak yang lebih luas. Ini benar-benar menyenangkan, dan memuaskan untuk membangun dengan perpustakaan JavaScript baru yang paling keren atau API browser baru yang, saya tidak tahu, mampu menggores dan mengendus di browser, yang sangat kita butuhkan, kapan saja sekarang.

Phil Hawksworth: Tapi saya sangat suka melihat hal-hal yang saya tahu akan berhasil di banyak tempat. Mereka akan benar-benar berkinerja, akan bersimpati pada browser yang ada — tidak hanya di meja CEO dan CTO yang mendapatkan mainan keren, tetapi juga orang-orang yang memiliki perangkat berdaya jauh lebih rendah, atau mereka' punya kondisi jaringan yang menantang dan hal-hal semacam itu. Saya suka melihat pengalaman yang menarik, dan pengalaman yang kaya, disampaikan dengan cara yang simpatik kepada platform, dan baik hati untuk audiens yang lebih luas, karena saya pikir web menjangkau lebih jauh dari kami, para pengembang, yang membangun sesuatu untuk itu . Dan saya bersemangat dengan melihat hal-hal menarik dilakukan, dengan cara yang menjangkau lebih banyak orang.

Phil Hawksworth: Itu mungkin bukan jawaban yang Anda butuhkan—

Vitaly: Oh, itu akhir yang bagus. Terima kasih banyak. Tidak, itu sempurna, itu benar-benar. Baiklah, saya merasa semuanya berjalan baik! Terima kasih banyak telah bersama kami! Saya bagikan ke Scott!

Phil Hawksworth: Hebat!

Vitaly: Saya di sini hanya untuk bermain tanya jawab. Jadi, terima kasih banyak, Phil! Aku masih di sini, tapi Scott, panggung adalah milikmu, sekarang! Mungkin Anda bisa berbagi dengan kami apa yang akan terjadi selanjutnya di Smashing TV?

Scott: Saya akan melakukannya, tetapi pertama-tama, Phil, saya tidak sabar untuk melihat bagaimana implementasi dari scratch-and-sniff API bekerja. Kedengarannya sangat menarik. Dan, Vitaly, JAMstackify sudah diambil.

Vitaly: (kesal) Diambil?! Bisakah kita membelinya?

Scott: Tidak, itu ada!

Vitaly: Yah, itu sudah terlambat. Aku selalu terlambat.

Phil Hawksworth: Itu menarik dengan caranya sendiri.

Vitaly: Itulah kisah hidup saya. Aku selalu terlambat.

Scott: Anggota yang akan datang, saya percaya, Kamis, tanggal 13, kami memiliki ol 'pa saya, Zach Leatherman, berbicara tentang apa yang dia bicarakan terbaik, yaitu font. Jadi, dia berbicara tentang Lima Y dari Implementasi Font. Dan kemudian, saya juga sangat tertarik dengan yang kami hadirkan pada tanggal 19, yaitu mengedit video, dengan JavaScript dan CSS, dengan Eva Faria. Jadi, pantau terus keduanya.

Scott: Jadi, itu lagi, Kamis depan, dengan Zach Leatherman, dan kemudian pada tanggal 19, dengan Eva, yang akan berbicara tentang mengedit video dalam JavaScript dan CSS. Jadi, pada catatan itu, Phil, aku tidak bisa melihatmu lagi, apakah kamu masih di sana?

Phil Hawksworth: Aku di sini!

Scott: Atas catatan itu, terima kasih banyak semuanya! Juga, apakah ada orang yang berada di dekat area Toronto? Atau siapa saja yang pernah ingin mengunjungi Toronto? Kami memiliki konferensi yang akan datang pada akhir Juni, dan masih ada beberapa tiket tersisa. Jadi, mungkin kita akan melihat beberapa dari Anda di sana.

Vitaly: Terima kasih banyak, semuanya!

Vitaly: Oh, omong-omong, hanya satu hal lagi! Mungkin Phil menyebutkannya, tetapi kami juga mengadakan Konferensi JAMstack di London, pada bulan Juli. Nah, itu juga yang harus diwaspadai. Tapi saya keluar dan akan mendapatkan salad saya! Tidak yakin apa yang Anda—

Scott: Oke, selamat tinggal, semuanya!

Vitaly: Baiklah, sampai jumpa, semuanya.

Itu Bungkus!

Kami dengan hormat berterima kasih kepada Anggota Smashing dari lubuk hati kami yang paling dalam atas dukungan mereka yang berkelanjutan dan baik hati — dan kami tidak sabar untuk menyelenggarakan lebih banyak webinar di masa mendatang.

Selain itu, Phil akan menjadi MC di SmashingConf Toronto 2019 minggu depan dan di JAMstack_conf — kami juga ingin melihat Anda di sana!

Harap beri tahu kami jika menurut Anda rangkaian wawancara ini bermanfaat, dan siapa yang Anda ingin kami wawancarai, atau topik apa yang Anda ingin kami bahas dan kami akan segera membahasnya.