Transcript
00:00:00Halo, terima kasih banyak telah bergabung dengan kami hari ini.
00:00:02Saya Praneet dari tim workflow di Vercel.
00:00:05Hai, saya Nate, juga dari tim workflow.
00:00:08Nate, Anda dan saya telah berada di tim workflow sejak awal,
00:00:12dan dari semua hal yang telah kita rilis dalam enam bulan terakhir,
00:00:15menurut saya hook dan webhook adalah salah satu fitur favorit saya,
00:00:18dan itulah tepatnya yang akan Anda bicarakan hari ini.
00:00:21Hook dan webhook juga merupakan fitur favorit saya.
00:00:23Keduanya sangat hebat, dan saya akan menunjukkan beberapa demo untuk menjelaskan alasannya.
00:00:28Jadi, demo pertama adalah sesuatu yang mungkin sudah kita kenal semua, Magic Links.
00:00:33Magic Link adalah formulir login. Anda mengetikkan email, menerima email di kotak masuk,
00:00:40dan saat mengeklik tautan tersebut, Anda masuk ke layanan tersebut.
00:00:44Ya, dan jika saya tidak salah ingat, dengan Vercel, bahkan sebelum namanya Vercel,
00:00:48Anda butuh basis data untuk melacak status, dan itu akan menjadi berantakan dengan cepat.
00:00:52dan kami membangun seluruh sistem ini sendiri pada waktu itu.
00:00:56Benar sekali, dan saya masih mengalami trauma (ETSD).
00:01:01Karena tanpa workflow, mengimplementasikan sistem seperti itu jauh lebih rumit daripada kelihatannya.
00:01:08Logikanya akhirnya tersebar di banyak file.
00:01:12Anda perlu melibatkan database untuk melacak status, dan itu menjadi berantakan dengan cepat.
00:01:19Ya, saya sudah memikirkan bagaimana cara menyusun ini dan database apa yang akan saya gunakan,
00:01:24karena ini terasa seperti masalah umum yang pernah saya buat sebelumnya.
00:01:28Jadi ya, saya ingin melihat seperti apa tampilannya.
00:01:30Ya, jadi hanya untuk mendemonstrasikan apa yang saya maksud, titik-titik kesulitan yang saya bicarakan,
00:01:38saya mulai dengan mengimplementasikan versi "tradisional" tanpa workflow dari login Magic Link.
00:01:43Jadi ada tiga endpoint yang terlibat.
00:01:47Yang pertama adalah saat formulir login dikirimkan,
00:01:50dan perlu menghasilkan sesi serta menyimpan sesi tersebut dalam database, seperti Redis.
00:01:57Anda perlu menerapkan TTL, dan Anda tidak bisa membiarkan data menggantung selamanya, Anda harus menghapusnya.
00:02:06Lalu kirim emailnya, hal ini bisa gagal, lalu login Anda tidak berfungsi, dan itu pengalaman yang menjengkelkan.
00:02:14Benar, lalu Anda harus kembali dan menjalankan cron job atau meminta anak magang membersihkan database Anda.
00:02:19Mungkin saya adalah anak magang saat itu.
00:02:22Tapi kemudian ada endpoint kedua, ini yang terjadi saat pengguna mengeklik tautan di email mereka.
00:02:28Dan ini pada dasarnya perlu menanyakan database, memulihkan status yang dibangun di endpoint pertama.
00:02:36Dan kita sudah sampai pada kode yang sangat semrawut.
00:02:38Saat saya mencoba membayangkan seperti apa tampilannya, kode ini terlihat sangat familiar dan begitulah cara saya menyusunnya juga.
00:02:48Kita melihat bahwa ini menjadi rumit dengan cepat meskipun ini hal yang sangat sederhana, konsep yang sangat sederhana.
00:02:54Jadi mari kita lihat bagaimana Anda akan mengimplementasikan fitur ini di Workflow.
00:02:59Implementasi magic link menggunakan Workflow SDK terlihat seperti ini.
00:03:05Bisa kita lihat kita memiliki fungsi kita, ia memiliki arahan useWorkflow, yang berarti ini adalah fungsi Workflow kita.
00:03:11Dan hal pertama yang kita lakukan adalah memanggil fungsi createWebhook, yang berasal dari paket Workflow.
00:03:18Dan kita juga menggunakan opsi respondWithManual dalam hal ini, yang berarti fungsi Workflow kita akan bertanggung jawab untuk menulis atau mengirim respons terhadap permintaan HTTP yang memicu Webhook ini.
00:03:36Dan ini agar Anda bisa melakukan pengalihan atau semacamnya setelah mereka masuk?
00:03:40Ya, jadi jika ada beberapa informasi dalam fungsi Workflow kita yang kita butuhkan untuk mengetahui jenis respons apa yang harus dikirim.
00:03:51Mirip dengan endpoint pertama, kita mengirim email login. Ini adalah fungsi useStep.
00:03:57Jadi jika sesuatu seperti ini gagal, Workflow SDK memiliki percobaan ulang otomatis.
00:04:03Aspek daya tahan sudah memberikan beberapa manfaat dibandingkan pendekatan tradisional di sini.
00:04:10Jadi sendLoginEmails adalah sebuah langkah, dan jika ia melakukan satu hal dan jika email itu gagal, Anda mencoba lagi pengiriman email dengan URL yang sama yang telah Anda buat untuk Webhook.
00:04:21Dan jika kita lihat di sini, ini adalah pola yang sangat menarik.
00:04:26Kita menggunakan promise race dengan jeda (sleep) lima menit.
00:04:30Ini dimungkinkan karena objek Webhook ini mengimplementasikan sebuah promise.
00:04:35Jadi untuk menunggu permintaan dari Webhook ini, Anda cukup menggunakan await Webhook.
00:04:40Atau dalam hal ini, Anda melakukannya dengan race. Dan ini keren karena saya tadinya mengira fitur Webhook ini akan memiliki timeout atau semacam opsi sebagai argumen lain.
00:04:50Tapi saya suka karena sekarang jauh lebih bersih sehingga untuk melakukan timeout, Anda cukup memodelkannya sebagai melakukan race antara Webhook dan sleep.
00:04:58Ini terasa seperti saya bisa melakukan lebih banyak hal dengannya. Saya mungkin bisa mengadu dua Webhook yang berbeda satu sama lain.
00:05:02Tidak banyak yang bisa Anda lakukan ketika Anda hanya memiliki beberapa argumen dalam sebuah fungsi.
00:05:06Tapi fakta bahwa itu hanyalah sebuah promise dan saya bisa melakukan promise.race terhadap sleep, mungkin mendapatkan langkah lain.
00:05:12Saya suka pola ini. Sepertinya pikiran saya langsung terbayang pada semua hal yang bisa saya bangun dengannya.
00:05:16Benar, dan itulah hal yang indah tentang primitif yang ditawarkan Workflow SDK.
00:05:21Semuanya diekspos sebagai promise.
00:05:23Jadi pola standar JavaScript seperti await promise.race bisa langsung berfungsi.
00:05:28Dan satu hal lagi yang perlu diperhatikan di sini adalah tidak ada Redis di sini. Tidak ada database.
00:05:33Dalam contoh tradisional, kita menggunakan Redis TTL untuk mengimplementasikan timeout ini.
00:05:41Dan dalam hal ini, kita menggunakan primitif Workflow sleep.
00:05:44Dan juga tidak ada anak magang yang harus membersihkan database yang berantakan setelahnya.
00:05:50Itu bagian terbaiknya.
00:05:51Dan Anda bisa melihat bahwa Workflow merespons permintaan publik dengan mengalihkan ke halaman sukses login.
00:05:59Dan kemudian mengambil informasi tentang pengguna Anda untuk dikembalikan ke klien yang memulai halaman login.
00:06:07Dan itulah seluruh Workflow kita. Implementasi MagicLink kita hanya 50 baris kode.
00:06:12Luar biasa sekali melihat ini. Bisakah kita melihat aksinya?
00:06:17Jadi ini demo MagicLink kita. Saya akan masukkan email saya.
00:06:24Dan Workflow kita sudah dimulai di sana dan mengirim email. Dan ada webhook yang menunggu.
00:06:31Dan faktanya, Workflow kita sedang ditangguhkan saat ini. Jadi nol komputasi yang dikonsumsi saat menunggu manusia mengeklik tautan di email.
00:06:41Oh, dan seperti apa tampilannya di Vercel? Bisakah saya melihat proses yang sedang berjalan?
00:06:47Oke, jadi kita sudah mendapatkan emailnya. Dan sebelum saya mengekliknya, mari kita lihat observabilitasnya.
00:06:52Saya tahu saya hanya melompat-lompat, tapi saya senang kita melihat ini.
00:06:57Oke, jadi kita bisa melihat proses kita ada di sini dan dimulai 40 detik yang lalu.
00:07:02Jika kita lihat, kita memiliki fitur observabilitas standar yang disediakan Workflow.
00:07:08Kita bisa melihat input untuk proses Workflow kita. Anda bisa melihat alamat email saya yang saya ketikkan ke formulir login.
00:07:13Dan yang menarik, kita bisa melihat hook kita di sini hanya sedang menunggu.
00:07:17Dan Anda bilang tidak ada komputasi yang berjalan sekarang. Ini adalah observabilitasnya, tapi sebenarnya tidak ada yang menunggu saya mengeklik hook itu.
00:07:25Benar sekali. Jadi hook-nya sedang menunggu, dan sleep-nya sedang tidur, dan kedua hal itu sebenarnya tidak melibatkan komputasi apa pun.
00:07:39Tapi kita bisa melihat hook kita, dan jika Anda ingat, keduanya sedang berlomba dalam promise.race.
00:07:46Jadi salah satunya harus selesai lebih dulu agar Workflow berlanjut.
00:07:50Jadi jika saya mengeklik tautan itu, oke, kita bisa melihat bahwa saya dialihkan ke halaman sukses login, yang merupakan salah satu langkah dalam logika Workflow kita.
00:07:59Dan jika saya kembali ke formulir login...
00:08:01Benar, dan kemudian kembali di dasbor, itu seharusnya sudah selesai juga.
00:08:05Benar sekali. Jadi Workflow kita memang sudah selesai.
00:08:08Dan Anda bisa melihat penghitung waktunya juga berhenti setelah hook-nya menang.
00:08:11Ya, jadi kita bisa mengimplementasikan magic link dengan sekitar 50 baris kode.
00:08:17Itu sangat rapi. Sangat keren melihat bagaimana, Anda tahu, jika kita harus menggambar diagram papan tulis tentang cara kerja magic link dan menjelaskannya kepada seseorang.
00:08:27Langkah-langkah yang Anda miliki dalam kode persis seperti yang Anda petakan, tapi sekarang itulah kode akhirnya juga.
00:08:34Tidak ada database tambahan di antaranya. Tidak ada beberapa rute API. Hanya kode yang Anda tunjukkan yang terbaca sangat bersih.
00:08:41Dan saya pikir itulah aspek yang paling kuat dari Workflow SDK, cara ia memungkinkan Anda untuk menyusun logika aplikasi agar mengalir secara logis alih-alih memaksanya agar sesuai dengan infrastruktur.
00:08:59Benar. Selain itu, saya suka ide dengan webhook di sini, menamainya webhook karena itu memberi saya cara berpikir yang sama sekali berbeda tentang webhook.
00:09:07Itu hanyalah URL fana yang bisa saya buat dan tunda (suspend).
00:09:10Sebenarnya, ini adalah pengantar yang bagus karena saya memikirkan, Anda tahu, kami membangun banyak agen ini di Vercel.
00:09:16Kami membangun banyak agen Slack dan agen GitHub, dan kami sering berlangganan webhook dari GitHub atau Slack, kan?
00:09:23Setiap kali ada komentar baru di PR dan kita ingin memulai agen Vercel, kita ingin melakukan ini berdasarkan peristiwa yang dikirimkan GitHub melalui webhook ini, kan?
00:09:31Bisakah kita menggunakan Workflow webhook untuk benar-benar berlangganan peristiwa dari GitHub, misalnya?
00:09:36Oke, jadi untuk sesuatu seperti webhook yang dikirimkan dari Slack atau GitHub, biasanya Anda harus masuk ke dasbor secara manual dan mengonfigurasi URL callback statis.
00:09:49Benar. Anda tidak bisa membuatnya satu per satu, saya tidak bisa memberinya URL sekali pakai dengan cara yang sama seperti yang saya lakukan dengan email di sini.
00:09:54Benar, benar. Jadi fitur pembuat webhook sedikit lebih tinggi dalam artian ia menyediakan URL webhook unik yang dihasilkan secara acak.
00:10:04Yang memetakan kembali ke satu proses Workflow tertentu.
00:10:07Dalam kasus rute webhook GitHub atau Slack kita, itu mungkin memetakan ke sejumlah proses Workflow.
00:10:14Benar. Anda harus mengonfigurasi sesuatu sebelumnya, tapi Anda memiliki banyak pull request, namun semuanya menuju ke endpoint yang sama.
00:10:20Jadi untuk mengimplementasikannya dengan Workflow SDK, kita akan turun satu tingkat, kita akan menggunakan primitif hook yang lebih rendah.
00:10:28Dan saya punya demo untuk menunjukkannya kepada Anda.
00:10:31Mari kita lihat.
00:10:32Oke. Jadi ini adalah storytime bot.
00:10:35Ini adalah aplikasi pertama yang saya tulis dengan Workflow SDK sedikit lebih dari setahun yang lalu.
00:10:40Dan cara kerjanya adalah Anda cukup mengetikkan perintah storytime/ dan kita akan melihat utas ini dibuat.
00:10:47Setiap utas diwakili oleh masing-masing proses Workflow.
00:10:52Jadi saat kita memperluas utasnya, kita melihat bahwa sebuah LLM memulai cerita ini untuk kita dan Anda atau saya atau siapa pun yang ada di saluran ini dapat melanjutkan ceritanya.
00:11:05Dan LLM akan membantu kita membawanya ke kesimpulan akhir.
00:11:09Oke. Jadi Luna memiliki benih ajaib dan apa yang terjadi selanjutnya? Dia menanam benih itu.
00:11:13Oke. Dan kita melihat beberapa aktivitas terjadi di sini.
00:11:17Apa yang terjadi selanjutnya? Sesuatu yang ajaib.
00:11:20Cerita kita selesai dan kita memiliki cerita akhir dan akan ada gambar kecil yang dihasilkan juga.
00:11:26Tapi kita akan melompat ke sana, kembali ke situ.
00:11:28Saya sebenarnya sudah penasaran karena saya perhatikan bahwa saya mengharapkan satu permintaan webhook tetapi sebenarnya ada dua, setidaknya dua permintaan di sana karena Anda memiliki dua pesan.
00:11:35Jadi saya sangat penasaran ingin melihat seperti apa tampilannya di kode.
00:11:38Oke. Jadi ini adalah fungsi Workflow untuk storytime bot kita.
00:11:44Jadi bisa kita lihat ia mengambil ID saluran, yaitu saluran storytime bot.
00:11:50Ia memiliki beberapa opsi konfigurasi yang bisa Anda berikan.
00:11:53Tapi yang menarik, kita bisa melihat adanya array pesan ini, yang jika Anda familiar dengan AISDK, ini adalah format data tempat Anda menyimpan percakapan AI Anda.
00:12:04Dan dalam aplikasi bot Slack biasa seperti yang kita buat di sini, Anda biasanya akan menyimpan hal semacam ini dalam database dan pada setiap iterasi atau setiap peristiwa webhook, setiap pesan diketikkan ke dalam utas, Anda akan memulihkan status Anda, Anda akan mencari percakapan dari database.
00:12:23Dan bukan itu yang terjadi di sini. Ini hanyalah sebuah array dalam fungsi Anda.
00:12:27Ya. Sebenarnya tidak apa-apa karena saya terkekeh tadi karena saya melihat intro dan Anda punya komentar yang berbunyi, "Lihat bu, tanpa antrean atau KB."
00:12:34Dan tidak ada impor database di sini. Anda hanya mengimpor Workflow.
00:12:40Dan kembali ke hal pesan terakhir tadi, ini hampir terlewatkan, tapi Anda sebenarnya hanya memiliki variabel di sini yang disebut final story yang sepertinya seiring berjalannya waktu, kita akan memasukkan pesan ke array ini, saya bayangkan,
00:12:55dan cerita akhirnya akan muncul sebagai string di sini, tapi tidak ada database yang harus dituju. Jadi seolah-olah let adalah database Anda di sini.
00:13:04Ya, let adalah database Anda adalah istilah bagus yang harus kita, kita akan menciptakan istilah itu.
00:13:10Mungkin saya mencurinya dari Anda, tapi.
00:13:14Hal yang menarik di sini, dan hal yang kita bicarakan di sini adalah fitur hook yang bisa kita lihat bahwa kita sedang membuat hook di sini. Dan yang membedakannya dari contoh webhook yang kita lihat dengan magic link adalah dalam hal ini, kita memberikan token,
00:13:28yaitu sebuah string yang menyertakan informasi pengenal yang unik untuk proses Workflow ini.
00:13:35TS adalah ID utas. Jadi string ini adalah token yang secara unik mengidentifikasi proses Workflow ini.
00:13:44Jadi saat kita melihat kode untuk rute webhook, kita akan melihat bahwa payload peristiwa yang dikirimkan Slack berisi semua informasi yang kita butuhkan untuk membuat ulang pengenal ini secara deterministik.
00:13:58Dan itulah keajaiban bagaimana webhook memetakan kembali ke masing-masing proses Workflow.
00:14:04Ya, saya penasaran saat melihat webhook karena Anda membuat URL baru untuk contoh magic link, tapi karena kita pernah membangun bot Slack ini sebelumnya, Anda tidak bisa begitu saja memberikan URL baru di setiap utasnya.
00:14:17Jadi cara memahami cara Anda melakukannya di sini adalah Anda memiliki API dan menerapkannya sudah terhubung ke Slack, tetapi setiap kali Anda mendapatkan pesan di sana, Anda pada dasarnya menghitung token yang sama di sisi dimulainya kembali (resumption).
00:14:29Jadi Workflow Anda pada dasarnya bisa menunggu token ini dan Anda bisa menyusun token yang sama dari payload pesan untuk melanjutkan proses Workflow ini.
00:14:37Tepat sekali. Ya. Jadi bot Slack dikonfigurasi sekali dengan cara klik-klik manual di dasbor Slack, dan Anda perlu menentukan URL callback webhook secara statis.
00:14:50Itulah mengapa primitif hook tingkat rendah bekerja lebih baik dalam hal ini, karena kita bisa membuat ulang tokennya secara dinamis.
00:14:59Jadi hanya untuk melihat sekilas, ini adalah rute webhook, dan sebenarnya tidak banyak yang terjadi di sini.
00:15:07Hal utamanya adalah bagaimana kita membuat ulang token dari data yang diteruskan oleh Slack.
00:15:13Dan kemudian kita memanggil fungsi resume dan ini melanjutkan proses Workflow yang unik untuk itu.
00:15:20Jadi saya sebenarnya membayangkan, itu sangat keren. Dan saya rasa saya sebenarnya membayangkan bahwa dengan webhook, apa yang Anda lakukan kurang lebih sama.
00:15:28Apakah webhook pada dasarnya hanya melakukan token acak dan kemudian Anda memiliki endpoint HTTP yang hanya menyelesaikan token acak yang sama?
00:15:35Ya, yah, jadi perbedaannya dengan fitur webhook adalah Anda tidak perlu mendefinisikan rute API itu di kode Anda.
00:15:44Workflow SDK sebenarnya mengimplementasikan rute default untuk fitur webhook untuk Anda.
00:15:50Tapi ya, selain itu, itu adalah token yang dihasilkan secara acak yang unik untuk satu proses Workflow tertentu.
00:15:55Tapi dalam hal ini, kita memiliki hook kita dengan token dan kembali ke sesuatu yang Anda sebutkan beberapa saat yang lalu, hook ini bisa menerima data berkali-kali.
00:16:06Ini berbeda dari contoh Magic Link, yang hanya perlu dipicu satu kali.
00:16:11Dalam hal ini, kita ingin hook-nya menyala untuk setiap pesan unik yang diketikkan seseorang ke dalam utas Slack.
00:16:17Jadi untuk melakukannya, Anda menggunakan sintaks for-await di JavaScript, yang umum digunakan dengan async iterator.
00:16:25Tapi dalam hal ini, kita menerima beberapa payload peristiwa dari webhook Slack menggunakan hook kita.
00:16:33Ini sangat keren. Saya tidak pernah menemukan kasus penggunaan yang bagus untuk... Saya suka async iterator dan saya suka generator dan saya bahkan pernah memberikan presentasi tentang ini dulu sekali.
00:16:42Tapi mereka selalu bagus untuk demo dan saya belum bisa menemukan cara yang baik untuk menggunakannya.
00:16:46Di sini bagi saya terbaca seperti Anda hanya memiliki sebuah loop.
00:16:50Tetapi alih-alih melakukan loop pada sekumpulan item yang tetap atau loop pada timestamp karena Anda menggunakan for-await dan kemudian melakukannya pada hook, di sini ada loop yang memetakan secara tepat.
00:17:01Segala sesuatu di dalam loop memetakan ke satu pesan pengguna.
00:17:05Dan itu cara yang bagus untuk memikirkan hal ini dengan pesan pengguna baru akan menyebabkan iterasi lain dari loop ini dan ia hanya mengantre dan terus berjalan.
00:17:12Bagian yang indah tentang ini adalah bahwa untuk setiap iterasi loop ini, selagi kita menunggu pengguna mengetik pesan berikutnya, sama sekali tidak ada komputasi yang dikonsumsi.
00:17:22Workflow benar-benar ditangguhkan dan pesan berikutnya dalam utas bisa tiba dalam hitungan menit atau hari atau mungkin bahkan tidak pernah sampai dan itu tidak masalah.
00:17:33Jadi mungkin ada utas Slack di saluran yang sama dengan Slackbot di mana saya bisa kembali sekarang dan masih ada proses yang sedang duduk dan menunggu selama beberapa minggu jika tidak ada yang merespons.
00:17:42Itu sangat keren.
00:17:43Dan untuk menyinggung kembali array pesan yang kita sebutkan tadi, sekarang kita memodifikasi array-nya.
00:17:48Kita memasukkan pesan pengguna baru dan itulah modifikasi database kita karena array pesan kita hanyalah variabel lokal.
00:17:57Sangat keren. Dan kemudian saya bisa melihat Anda melakukan lebih banyak promise.all untuk memparalelkan lebih banyak langkah di antaranya.
00:18:03Ini terbaca sangat bersih untuk setiap loop, setiap pesan di Slack.
00:18:08Saya suka bagaimana ini persis seperti yang saya modelkan jika Anda mencoba membangun ini dalam sebuah hackathon atau semacamnya.
00:18:12Ini seperti begini cara saya menuliskan apa yang terjadi di setiap pesan tunggal.
00:18:16Ya, jadi model promise.all itu, ini hanyalah fungsi useStep biasa dan idenya adalah menjalankannya secara paralel.
00:18:23Dan sesuatu seperti menambahkan reaksi ke pesan Slack hanyalah untuk memberikan umpan balik yang lebih cepat kepada pengguna bahwa sesuatu sedang terjadi.
00:18:32Tetapi pada saat yang sama, kita ingin memulai LLM untuk membantu menggerakkan proses pembuatan cerita.
00:18:39Saya sebenarnya sangat tertarik kapan pun untuk melihat seperti apa observabilitasnya juga saat kita sempat melakukannya, karena saya bisa membayangkan rentang (span) tersebut dimulai pada saat yang sama dan membuatnya sangat jelas.
00:18:49Jadi kita punya observabilitas untuk story time kita.
00:18:52Ini sudah selesai, jadi kita harus kembali dan memeriksa gambarnya.
00:18:56Jadi kita bisa melihat hook kita.
00:18:58Dan yang menarik di sini adalah dalam hal ini, kita memiliki dua peristiwa hook diterima.
00:19:05Jadi itu memetakan ke dua pesan yang saya ketikkan ke dalam utas Slack kita.
00:19:10Dan observabilitas memungkinkan kita untuk melihat data individual yang diberikan ke hook.
00:19:14Oh, itu sangat keren.
00:19:16Jadi itu pada dasarnya payload Slack. Dan Anda tidak perlu mencatat ini secara tambahan. Payload Slack muncul begitu saja sebagai peristiwa yang bisa saya buka kembali dan periksa di dasbor.
00:19:25Benar. Dan kemudian kita bisa melihat bahwa setiap kali payload hook diterima, itu melanjutkan eksekusi workflow kita dan langkah-langkah kita berlanjut.
00:19:34Dan kemudian kita akhirnya mendapatkan hasil dari pembuatan gambar storyboard kita, yang terlihat seperti di sana.
00:19:40Jadi itulah story time bot.
00:19:42Itu sangat keren.
00:19:43Saya rasa melihat webhook yang dihasilkan dari magic link dan sekarang melihat Anda menggunakan primitif tingkat rendah dengan hook dan juga melakukannya dalam loop sehingga Anda benar-benar bisa melakukan banyak peristiwa.
00:19:54Itu sangat keren.
00:19:55Saya merasa modelnya benar-benar cocok untuk cara saya melakukan operasi manusia dengan webhook.
00:20:02Apakah ada hal lain yang bisa Anda gunakan untuk hook?
00:20:05Ya, tentu saja.
00:20:06Demo terakhir yang saya rencanakan untuk Anda di sini adalah pola yang sangat mirip dengan menanggapi webhook Slack.
00:20:17Tetapi dalam hal ini, kita akan menggunakan webhook sebagai cara untuk menyerahkan eksekusi kode aplikasi kita dan kemudian menunggu beberapa komputasi selesai di tempat lain selagi workflow kita ditangguhkan dan menunggu.
00:20:32Dan kemudian menggunakan URL webhook tersebut untuk memanggil kembali ke webhook kita dan kemudian kita bisa menyelesaikan apa pun yang perlu kita lakukan dengan logika aplikasi kita.
00:20:41Untuk contoh ini, kita akan menggunakan Vercel Sandbox dan kita akan melakukan beberapa operasi komputasi yang berjalan lama seperti menggunakan FFmpeg untuk melakukan konversi file.
00:20:51Jadi ini adalah workflow konversi FFmpeg kita.
00:20:56Salah satu hal pertama yang terjadi adalah kita membuat Vercel Sandbox.
00:21:00Yang menarik dari hal ini sebenarnya adalah bahwa paket NPM Sandbox mengekspos fungsi yang di balik layarnya menggunakan useStep di dalamnya.
00:21:09Jadi sebenarnya operasi ini adalah sebuah Step.
00:21:12Jadi Anda bisa merilis paket NPM.
00:21:15Sandbox pada dasarnya hanya merilis paket NPM yang memiliki direktif use Step di dalam fungsi ini.
00:21:21Sehingga saat Anda mengimpor dan menggunakannya dalam alur kerja, otomatis Sandbox menjadi Step tanpa perlu menulis kode apa pun.
00:21:29Bukan berarti Anda tidak bisa menggunakan Sandbox untuk membuat sesuatu di luar alur kerja.
00:21:32Apa yang terjadi jika Anda memanggil ini tanpa alur kerja?
00:21:35Jika Anda menyadari, direktif tersebut hanyalah sebuah string dan jika Anda mengeksekusinya tanpa kompiler alur kerja,
00:21:47string tersebut tidak melakukan apa-apa. Jadi ini tetap berfungsi.
00:21:49Menambahkan use Step di paket NPM Anda berfungsi dengan baik tanpa SDK alur kerja.
00:21:55Dan begitu Anda menggunakan fungsi itu di dalam SDK alur kerja, Anda mendapatkan manfaat durabilitas secara langsung.
00:22:03Oke, jadi Sandbox hanya melakukan hal-hal biasa.
00:22:07Ia menginstal FFmpeg karena itu tidak tersedia secara default.
00:22:11Ia mengunduh URL file yang akan kita tentukan.
00:22:14Dan setiap eksekusi ini hanyalah sebuah Step juga untuk saat ini?
00:22:17Ya, jadi ini menjalankan perintah individual di Sandbox dan itu adalah Step. Kita bisa melihatnya di observabilitas.
00:22:29Lalu kita kembali memanggil create-webhook, yang mungkin Anda ingat dari demo Magic Link.
00:22:36Namun dalam kasus ini, kita hanya meneruskan URL webhook tersebut ke dalam skrip Bash yang akan kita jalankan di Sandbox.
00:22:43Yang terjadi di sini adalah kita akan menjalankan FFmpeg dan mengonversi file ke format yang kita minta di UI.
00:22:53Dan setelah selesai, skrip Bash akan menjalankan cURL terhadap URL callback kita dari webhook.
00:22:59Dan saat permintaan cURL itu terjadi, logika alur kerja kita akan berlanjut.
00:23:04Oke, paham. Itu keren. Saya sudah melihat sedikit ke depan, dan saya perhatikan ada tanda AND pada eksekusi ini.
00:23:11Jadi Anda sebenarnya menulis skrip yang berjalan di latar belakang karena Step FFmpeg seperti ini bisa memakan waktu jauh lebih lama.
00:23:17Anda tentu tidak ingin ada Step yang hanya diam dan menunggu proses itu selesai.
00:23:20Benar sekali. Jadi baris ini memulai skrip versi FFmpeg kita di latar belakang.
00:23:28Kemudian fungsi alur kerja kita ditangguhkan dan kita menunggu webhook dilanjutkan kembali.
00:23:34Dan saya melihat promise race lagi dengan waktu tunggu satu jam. Itu pola yang sangat keren.
00:23:40Benar, dan kali ini, proses konversi FFmpeg kita mungkin memakan waktu lama.
00:23:46Bisa jadi file medianya sangat besar. Jadi kita menetapkan batas waktu satu jam untuk kasus ini.
00:23:51Dan itu tidak masalah. Dalam alur kerja, Anda bisa menunggu untuk waktu yang hampir tidak terbatas.
00:23:56Dan sekali lagi, nol komputasi yang berjalan saat kita menunggu webhook ini dilanjutkan.
00:24:01Dan bisakah kita melihat ini? Bisakah kita melihatnya berjalan? Apakah ada demonya?
00:24:04Ada.
00:24:05Ini contoh yang agak sedikit konyol.
00:24:07Ya, saya langsung mengenali contoh kelinci besar itu. Itu dari Blender.
00:24:12Ya, saya ingat menonton video-video ini saat belajar Blender dahulu kala.
00:24:16Wah, saya iri.
00:24:19Jadi kita sudah menempelkan URL file medianya. Dalam hal ini, kita hanya akan mengekstrak lapisan audionya saja.
00:24:26Setelah kita mengeklik tombolnya, itu akan memulai alur kerja dan kita bisa melihat bagian observabilitas.
00:24:33Oh, itu dia. Ya, kita bisa melihat pembuatan sandbox kita.
00:24:37Dan itu mengembalikan instans sandbox kita. Keren sekali.
00:24:42Dan ini karena sandbox, segala sesuatu dalam alur kerja harus bisa diserialisasi.
00:24:46Namun seperti yang Anda katakan, sandbox mengimplementasikan serialisasi. Jadi mereka sebenarnya bisa diserialisasi juga dalam alur kerja.
00:24:53Benar. Jadi paket NPM Vercel sandbox memiliki kelas sandbox dan kelas itu mengimplementasikan fungsi serialisasi alur kerja.
00:25:03Sehingga itu langsung berfungsi di observabilitas kita.
00:25:06Jadi paket apa pun bisa melakukan ini, kan? Bukan cuma sandbox. Tidak ada yang spesial dari sandbox karena kelas apa pun bisa menerapkannya.
00:25:17Ya, itu benar. Kita bisa melihat bahwa hook kita akhirnya dipanggil kembali dalam 20 detik kali ini.
00:25:25Konversinya sedikit lebih cepat karena filenya cukup kecil, tapi itu bisa memakan waktu berapa lama pun.
00:25:31Kita lihat setelah sandbox dibuat dan diinisialisasi, hook dibuat dan kita teruskan ke sandbox untuk memulai perintah FFmpeg.
00:25:43Dan setelah selesai, kita menerima payload dari sandbox kita.
00:25:48Dan ini adalah curl yang terjadi di dalam skrip bash tadi. Jadi ia menulis perintah lalu menggunakan curl di sandbox untuk menyelesaikan webhook.
00:25:57Benar. Jadi sandbox kita telah menyelesaikan pekerjaannya. Ia mengembalikan kendali ke alur kerja kita.
00:26:04Cara saya memikirkannya sekarang adalah dengan Step dalam alur kerja, Anda menjalankan sebuah Step, kode berjalan di latar belakang, lalu berlanjut.
00:26:13Tetapi hook dan webhook keduanya terasa seperti berada di level yang lebih rendah. Saya bisa membuat token atau URL dan menunggu apa pun.
00:26:21Bisa berupa magic link manusia, email, sandbox, atau komputasi apa pun yang harus terjadi.
00:26:27Dan alur kerja saya akan terjeda dengan seluruh statusnya sampai kejadian itu terjadi. Rasanya hampir lebih rendah levelnya daripada Step itu sendiri.
00:26:34Ya. Cara saya memikirkannya adalah webhook dan hook adalah cara untuk memasukkan payload eksternal ke dalam alur kerja Anda.
00:26:42Menurut saya Step adalah cara alur kerja menangguhkan diri dan menunggu komputasi selesai sebelum melanjutkan.
00:26:50Tapi hook dan webhook terasa lebih rendah levelnya karena Anda hanya membuat token atau URL yang bisa dikirim ke mana saja.
00:27:01Bisa ke manusia, email, atau alur kerja lainnya, misalnya.
00:27:05Dan kapan pun itu selesai, alur kerja induk Anda pada dasarnya akan terbangun dan berlanjut tepat di tempat terakhir ia berhenti.
00:27:12Jadi ini entah bagaimana lebih rendah levelnya dari Step. Ini cara untuk menangguhkan alur kerja Anda untuk tindakan eksternal apa pun.
00:27:19Ya. Saya suka memikirkannya bahwa hook adalah cara menangguhkan alur kerja Anda dan menunggu payload eksternal dikirim kembali.
00:27:31Ini sangat keren. Saya tahu waktu kita sudah habis hari ini, tapi dengan demo itu Anda memvalidasi lagi mengapa hook adalah fitur favorit saya.
00:27:42Luar biasa. Ya, saya senang Anda menikmatinya.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video