Ngobrolin WebSocket
Ringkasan Episode
Bantu KoreksiEpisode ini membahas teknologi real-time communication di web, dengan fokus utama pada WebSocket. Host menjelaskan perbedaan antara HTTP request-response konvensional dengan WebSocket yang memungkinkan koneksi terus-menerus (persistent connection) antara klien dan server. Episode ini mengupas sejarah singkat munculnya WebSocket sebagai solusi atas keterbatasan HTTP untuk komunikasi dua arah secara real-time, serta membahas alternatif seperti polling, long polling, dan COMET yang pernah digunakan sebelum WebSocket menjadi standar. Selain WebSocket, episode ini juga membahas Server-Sent Events (SSE) sebagai alternatif yang lebih sederhana untuk use case satu arah (server-to-client) serta WebTransport sebagai teknologi terbaru yang menjanjikan. Diskusi juga menyentuh implementasi WebSocket di berbagai framework seperti Ruby on Rails (Action Cable, Hotwire) dan Laravel (Laravel Echo, Livewire), tantangan scaling koneksi WebSocket untuk jumlah pengguna besar, serta perbedaan WebSocket dengan teknologi lain seperti WebRTC yang bersifat peer-to-peer.
Poin-poin Utama
- •WebSocket memungkinkan komunikasi bidireksional dengan latency rendah - Koneksi tetap terbuka (persistent connection) antara klien dan server, memungkinkan data dikirim dua arah secara real-time tanpa perlu request-response berulang seperti HTTP biasa.
- •Server-Sent Events (SSE) sebagai alternatif yang lebih sederhana - SSE hanya mengizinkan server mengirim event ke klien (satu arah), lebih mudah diimplementasikan, dan kompatibel dengan infrastruktur yang tidak mendukung WebSocket seperti di belakang CDN.
- •gRPC menggunakan HTTP/2 untuk komunikasi antar microservice - Framework dari Google yang mengirim data dalam format binary (protobuf) dengan performa tinggi, awalnya dirancang untuk komunikasi server-to-server, bukan browser-to-server.
- •WebTransport adalah teknologi baru yang masih dalam pengembangan - Menawarkan API yang lebih user-friendly, mendukung UDP (datagram) dan TCP (stream), namun belum didukung oleh semua browser dan masih berstatus limited availability.
- •Masalah utama WebSocket adalah skalabilitas dan kompatibilitas server - Setiap klien membutuhkan koneksi persistent yang terus terbuka, membuat scaling lebih sulit, dan tidak semua hosting/CDN mendukung WebSocket.
- •Socket.io menyediakan abstraksi dengan fallback mechanism - Library yang secara otomatis memilih teknologi terbaik yang tersedia (WebSocket, HTTP long polling, atau lainnya) dan menangani reconnection otomatis ketika koneksi terputus.
- •Hotwire dan Livewire merender di server, mengirim HTML melalui WebSocket - Pendekatan HTML over the wire di mana hanya bagian yang berubah yang dikirimkan melalui WebSocket, memungkinkan server-side rendering dengan pengalaman real-time.
Berhati-hati, selamat malam.
Selamat malam, para pemirsa.
Hari ini selasa malam, kalau selasa malam kita gak main.
Kita ngobrolin apa? Salah gitu promptnya.
Ngobrolin apa ya? Halo-halo teman-teman semua, apa kabarnya?
Ketemu lagi kita di selasa malam ini.
Cara kesayangan kita sih.
Cara kesayangan kita bersama.
Berpacu dalam web. Bukan ya?
Malam ini sengaja kita gak taruh judul ya, biar penasaran kita mau bahas apa.
Karena dari sampai sore kita masih bingung bahas apa sebenarnya, tapi udah ada ya topiknya ya. Tenang aja tenang.
Dan ternyata topik yang seperti minggu lalu ternyata banyak yang suka juga ya.
Ada beberapa komen yang masuk juga katanya, "Eh seru nih bahas impromtu kayak kita gak tau ada update apa."
Terus kita bahas sebarang-barang kayaknya banyak yang suka juga dengan format itu.
Agak-agak kaget juga kita ya.
Nah, jadi malam hari ini kita mau bahas apa?
Kita bahas komunikasi.
Hari Senin harganya diselesai waktu nya.
Ngobrolin web.
Ngobrolin web. Nah itu dulu.
Nggak mau ngomong, tadi ada yang nonton live gak sih?
Ucap sepi nih.
Ucap sepi ya.
Mana yang live nya?
Iya, kan lagi bola. Nonton bola.
Kan lagi Indonesia.
Oh iya.
Kalo gitu kita nonton bola bareng-bareng aja sekarang.
Nonton bola.
Ada yang cek akunnya gak sini dong.
Lihat transkrip lengkap (836 segmen lagi)
Bahkan gak tau ditayangin dimana sih.
Nah ini bisa disambungin ya kalo misalnya nonton bola.
Kalo streaming itu.
Kalo protocol apa ya?
Nah kalo website nayangin hal-hal yang real kan gimana tuh caranya kan?
Harus ada data yang masuk terus.
Streaming.
Atau apa pun itu.
Event stream ya.
Kalo protocol event stream itu kalo di web biasanya pake apa?
Contohnya kayak kita pake apa nih?
Pake stream nya.
RTC.
Atau temen-temen pada pake YouTube live chat.
Ya ini web RTC.
Ya live chat.
Pernah kebayang gak bagaimana protocol nya si...
Sapa lagi ya?
Si Zoom.
Youtube.
Youtube.
Terus kemudian Google Doc.
Google Doc.
Google Doc.
Office 360.
Office 360. Atau siapa yang kuliahnya pernah bikin chat application?
Saya.
Nah pake protocol apa tuh?
Soccer.
Yey.
Kenapa ini kenapa?
Kenapa ini kenapa?
Kenapa yang sifatnya real time atau soft real time seperti chat gitu ya.
Terus mungkin video atau yang lainnya itu.
Kenapa butuh protocol baru gak di HTTP aja?
Karena kan HTTP itu kan dia sifatnya satu stateless.
Request response.
Request response.
Jadi kalo kita tidak merequest apa-apa server nganggur.
Dan ribet kan kita harus request.
Kita ngirim header.
Sama server diterima dikonfirmasi.
Server ngirim balik.
Kita harus klien, maksudnya browser.
Mesti konfirmasi lagi.
Nerima dulu.
Terus minta data lagi. Request lagi.
Ribet kan?
Terus apa lagi tadi?
Apa ya?
Jadi kalo misalkan.
Kan sifatnya itu kalo misalkan ada request.
Request ini baik itu get, post, ngisi form dan lain-lain ya.
Kita ketik misalkan ngobrolinweb.com gitu kan.
Nah itu dia servernya baru bekerja.
Terus dia kirimin balik.
Abis itu udah selesai.
Jadi itu adalah satu proses lengkap.
Sampai...
Life cycle.
Ya life cycle-nya selesai.
Sampai si user mendapatkan halaman web yang dia inginkan.
Nah, sebelum kita ke Websocket.
Sempet dulu ada solusi.
Kalo Ivan bilang akal-akal nontir.
Dalam setiap beberapa detik di-polling, di-refresh manual.
Polling itu berarti istilah kan ya.
Cuma istilah buat kita minta aja secara berkala gitu ya.
Ini ada update gak sih?
Itu tekniknya namanya heartbeat.
Dan sampe sekarang masih dipakai kok.
Heartbeat untuk sesuatu yang gak butuh stream.
Karena gak semua hosting itu bisa stream.
Ya jadi perlu diketahui temen-temen gak semua hosting bisa stream.
Apalagi CloudFront, CDN lah ya.
Semuanya di depan CDN.
By default tanpa perlu setting-setting, gak bisa stream.
-Belum bisa. -Ya.
-Tapi kalo... -By nature.
Apakah cuma pake...
Apa itu pake HTTP biasa kan?
Request-response HTTP biasa.
Atau ada teknik apa khusus gitu?
-Oh biasa. -Yap.
Jadi kalo di HTTP ada beberapa teknik.
Jadi kita bahas dulu deh sedikit mengenai apa socket itu, kenapa ada socket kali ya.
-Iya. -Asik.
Tapi saya gak nemu ini sih, gak nemu web page-nya yang...
Mungkin buka socket.io aja kali ya mas Tiza, ada socket.io.
-Boleh, boleh. -Ya.
Kita present entire screen di sebelah kan.
Be directional, low latency communication for every platform.
-Zoom in. -Ya, Sir.
Jadi ada introduction kali ya, itu di documentation.
Langsung pencet documentation itu loh.
Documentation button gede.
-Hmm, ini dia. -What is socket?
Jadi socket itu by B or B directional.
B directional dan event aja.
-Dua arah ya. -B directional ya, jadi dua arah.
Dimana koneksi yang terjadi itu tidak terputus.
Jadi dia tetap secara low level, saya gak bisa ngasih tahu bagaimana,
saya juga gak mengerti 100%, tetapi secara low level,
koneksi yang terjadi di dalam network antara si client dan si server itu
selalu terbuka, ada session-nya.
Nah, ini tuh sulit dibayangin ya, buat orang yang masih awam soal infra,
soal HTTP, kalau yang mulai belajarnya beneran dari web, ngerti web doang,
konsep ini nih agak, apa ya, gue dulu agak sudah pahamin terbuka terus,
karena kan belajarnya cuma HTTP, request-response,
kan biasanya kalau kita ngirim request, udah dibalikin dikasih response,
baik itu oke ataupun error atau redirect atau apapun,
ya udah selesai kan, nah ini tuh kayak mental, kayak perspective shift,
bahwa bisa sekali kita initiate koneksi terbuka, ini belum selesai,
walaupun maksudnya kirim data, udah dapet datanya,
tapi koneksinya masih terbuka, jadi ini kayak harus biasain dengan mindset ini.
Betul, jadi bayangkan sekarang saya waktu kuliah, di salah satu jurus,
mata kuliahnya, kalau gak salah jarinan, itu salah satu tugasnya membuat aplikasi chat,
dimana kita menggunakan socket dan murni socket, karena waktu itu pakainya C#,
jadi benar-benar socket, dimana kita buka aplikasi Windows,
akan membuka port, dan di server akan membuka port,
jadi saya sambungin, oke IP-nya sekian, yang dibuka port sekian,
nanti si server akan terima, oke handshake, dan terjadi koneksi.
Nah, lalu di klien yang lain juga melakukan hal yang sama,
dia ke server, IP server, dan port yang sama, terus kemudian si,
setelah handshake, dan terjadi koneksinya secara sudah confirm, nanti bisa saya lihat,
di klien A, di komputer 1, kelihatan tuh komputer 2 is online,
jadi komputer 2, komputer 1 is online, gitu ya, bisa dibikin.
Nah, lalu saya chat dong, saya chat, hello, nanti data itu dikirimkan ke server,
nanti dikasih ke klien 2, atau bisa juga yang namanya broadcast,
jadi kalau misalnya ada 10 klien yang terkoneksi secara bersama,
dia kirim satu, nanti dia ke broadcast semua, ke semuanya klien.
Bayangkan jaman MIRC, group chat jaman dulu, dan Yahoo Messenger yang one-on-one chat,
kayak gitu lah konsepnya socket.
Aplikasi penggunaan socket nggak cuma untuk chatting,
banyak ya, banyak, karena dia low latency, karena tidak melewati yang namanya
HTTP TCP/IP yang ada 6 layer, 7 layer, ya TCP ada 7 layer, dan ada Acheca segala,
dia nggak ada itu.
Pokoknya sudah handshake, terjadi koneksi, semuanya event-based,
dia akan dengerin, dan siap terima data, dan kirim data.
Dari sisi aplikasinya, banyak, salah satu tugas akhir dari mata kuliah itu
saya disuruh bikin sejenis, apa tuh namanya, Trojan.
Jadi, iya Trojan, jadi kalau misalnya, beneran dosennya suruh bikin Trojan,
jadi si aplikasinya bisa ditanam, diinstall di target komputer,
maka target komputer, jadi socket server.
Jadi kita dari jaringan yang sama, bisa tahu, oh itu server yang sudah target,
sudah ada terinstall aplikasi kita, jadi saya bisa kirim komen,
oke, open, jadi yang dikirimkan datanya, komen itu open notepad,
open ini, nanti dikirim, karena sudah aplikasi sudah diinstall,
dikirim secara komen dari menganggil Win32 API,
jadi tinggal panggil, buka aplikasi notepad, buka ini, buka itu,
itu bisa shutdown juga, segala macam, itu dari si aplikasi, dari kliennya kita.
Banyak, kalian kalau penggemar game, penggemar game, mau main Warcraft,
mau main Starcraft, mau main apa sih game anak jaman sekarang,
MOBA, MABBA, itu semuanya koneksinya socket.
Jadi, nah itu dari sisi socket. Nah, kembali ke Websocket.
- Websocket. - Websocket itu berarti protokol atau pattern apa, pola...
- Protokol. Dia ada protokolnya sendiri, dia ada protokolnya sendiri.
Ya, dia ada protokol. Lalu, kalau Websocket...
- Bukan protokol HTTP ya berarti ya? - Bukan, dia WS kan.
- Nggak ngelewati HTTP layer sama sekali kan? - Tidak, dia nggak pakai HTTP.
- Tetapi handshake-nya butuh HTTP. - Oh iya handshake.
Oh iya buat buka...
Nanti coba buka Websocket di ini deh, di Wikipedia kalau nggak salah,
Websocket yang di Wikipedia itu ada jelas ini.
Ada HTTP response yang dikirimkan saat handshake.
- Iya handshake. - Yes, handshake-nya itu pakai HTTP dulu.
Sebelum terjadi koneksi.
Ternyata Websocket itu adalah implementasi socket di atas...
- TCP juga. - Apa?
- Di paket TCP tetapi nggak pakai HTTP. - Bukan HTTP, iya.
- Dan ini standar web ya? - Yes.
Websocketnya yang standar web. Jadi socket kan itu umum, infrastruktur umum,
tapi Websocketnya itu standar web yang memungkinkan dari web ngebuka koneksi gitu kan?
Membuat koneksi, melakukan koneksi socket.
- Turun sedikit.
Ada ininya kan Websocket API pakai WS tuh, yang nggak secure itu WS.
Itu protokolnya. Protokol kan WS.
Kalau misalnya kita web biasa kan HTTP.
Kalau yang Websocket yang secure WSS.
- Jadi HTTPS, WSS. - Oke, HTTPS, HTTPS, nice.
Nah, ini menarik juga nih historinya ya.
Jadi cerita dari 2008.
Terus result in the first version of protocol known as Websocket.
- Zoom in, zoom in. - Nah, mantap.
- Comet channel itu apa? - Nggak tahu.
Before Websocket, port 80 full duplex communication was attainable using Comet channel.
- Di sini ada nih. Comet is web application model. - Web application model.
Ya pokoknya teknologi lama yang udah punah ya.
Ya sepertinya kalau dari dasar long held HTTPS dikurs, artinya
keep alive-nya sampai dibikin 60 second, 120 second.
Paragraf terakhir tuh.
Jadi karena ada Websocket dan server send events, maka cometnya jadi obsolete.
- Alex Russell lagi. - Alex Russell lagi.
Slightly late.
Oh dia bikin, bukan dia yang bikin cometnya, tapi bikin istilahnya.
- Istilahnya. - Bikin kata-kata comet.
Dia bikin istilah, dia itu ya spesialis copywriter teknologi.
- KWA juga dia yang itu kan. - Iya, PWA dia.
- Jadi dia sama istrinya. - Oh, comet itu sebenarnya ajak spus,
reverse ajar, PWA web, HTTPS 3D, HTTPS 4D.
- Jadi itu bukan satu, bukan satu label. - Berarti kayak PWA juga ya.
Server send event, server send event gitu juga konsepnya sebenarnya.
Nanti kita bahas akan event ya, SSA.
Nah, turun sedikit, nanti ada HTTPS response-nya.
Turun, turun sedikit.
- Ya, server example. - Server example.
- Ini contohnya apa nih? - Iya kan.
- Pakai Python. - Itu apa sih JavaScript?
- Python, Python, Python. - Ya, Python.
Nanti itu format response-nya.
Oke, pertama dia kirimkan HTTPS, requestnya HTTPS.
Terus kemudian dia upgrade, "Hey, ini sebenarnya websocket, websocket connection loh."
- Baru lagi buka. - Koneksi upgrade.
Betul. Baru si browser menjawab, "Oke, kita connect ya.
Saya buka port nih, menuju port-nya lu."
Inilah salah satu apa tuh yang dibikin sama DNH untuk, sorry bukan DNH.
Accent cable. Hotwire.
- Hotwire. - Hotwire ya.
Itu kan dia pakai websocket.
Makanya websocket itu bagus untuk low latency bi-directional.
Tetapi karena dia butuh koneksi yang selalu dibuka, sehingga scaling-nya menuju banyak channel.
Scaling itu scaling.
Misalnya yang scaling online itu bisa anggap aja webnya diakses 1 juta user saat yang bersamaan.
Maka ada 1 juta koneksi yang di-open ke server.
Dan itu 1 channel, 1 session. Makanya scaling-nya susah.
Beda dengan yang hanya pakai request-response, yaitu CDN-nya static, udah, ga usah pusing.
- Iya. Kalau Ruby owners itu awalnya mereka punya namanya, sebentar, namanya itu accent cable.
Itu adalah wrapper untuk pakai websocket di Ruby on Rails.
Mempermudahkan antara server-nya sama klien-nya.
Kemudian muncul lagi yang namanya hotwire. Hotwire itu HTML over the wire.
Jadi HTML page-nya dikirim lewat websocket.
- Oke. - Lumayan overkill ya.
- Iya. Kalau dulu kan request-response. Memang response-nya HTML, CSS JavaScript dikirimkan lewat HTTP, kan?
Terus abis itu muncul yang SPA. SPA itu datanya doang yang dikirim dari server, kan?
- Ya, kayak even websocket ini juga datanya, kan?
- Iya. Dirender di sisi klien, ya kan?
Kemudian muncul di tengah-tengah yang ada hotwire, ada live view, ada di Laravel itu ada namanya live wire.
Itu mereka render-nya di server. Karena kan ngerender di server kan cepat, kan?
Ini ide-nya, ide dasarnya. Ngerender di server itu proses yang cepat dibandingkan ngerender di klien, kan?
Jadi render-nya cepat, abis itu hasilnya mungkin div-nya aja perbedaan antara halaman 1 dengan halaman 1, versi 1,
karena udah ada update, misalkan update harga, gitu ya. Nah itu div-nya dikirimin lewat websocket.
Jadi nggak semua HTML-nya dikirim, nggak seluruhnya, hanya bagian yang berubah saja yang dikirimkan.
- Jadi sebenarnya ini tuh kayak hydration, tapi mustahil hydration-nya di server semua ya?
- Di server, betul. - Jadi kayak dikirim lewat protocol socket ini.
- Iya. Yang jadi masalah di Ruby on Rails adalah memang masalah yang si Ruby-nya, Ruby-nya scaling-nya kan rumit ya.
Karena mereka bukan fungsional programming, kalau mau pakai banyak CPU dan lain-lain,
parallel programming itu sulit, makanya kena dia di situ scaling-nya.
Tapi kalau bahasa-bahasa yang sudah cukup kuat seperti Go atau Elixir yang konkurensinya bagus,
menggunakan websocket itu harusnya tidak separah yang digunakan oleh Ruby on Rails.
- Oke. - Ini lagi lama ya di Twitter ya.
- Sudah mau apa lagi? - Hey Calendar, Hey Calendar itu dibuat pakai
holding wire. - Oh holding wire. Terus jadi berat?
- Terus banyak yang complain kalau itu berat. Habis itu si DHA-nya komen pas lihat videonya,
"Nah, lu itu apa, network-nya di throttle ke 3G, dia nggak mau, slow 3G nggak mau.
Harus yang itu dong, harus full." Karena kalau Google Calendar dibuka di slow 3G juga jelek katanya gitu.
Jadi dia merasa, ya merasa diserang lah ya, kan itu produknya dia kan.
Mungkin agak-agak emosi juga. - Iya sulit. Itu risiko bikin produknya pakai orang banyak.
- Iya. Udah produknya punya dia, framework-nya juga punya dia. Jadi dua-duanya diserang.
Diserangnya gitu dia bilang, "Ruby on Rails deserve better," katanya gitu.
Maksudnya harusnya dipakai dengan cara yang benar gitu. Kan diserang dua-duanya.
Udah produknya diserang, framework-nya diserang, gimana nggak marah kan?
Ya begitulah. - Nah.
- Valeri. Cuma Valeri doang. Yang lain mungkin sambil parah.
Yang lain nonton Indonesia Finlay Pin. Udah sepenuh cuy. - Udah sepenuh.
- LiveScore-nya boleh ya. Pake WebSocket ya. Update ya. Kita nggak bisa nonton.
Kalau Laravel, pakai Laravel Reverb. - Reverb.
- Reverb. - Seru ini.
- Iya di-Googling aja. Oh, Reverb. - Bukan LiveWire ya, bukan?
- Beda. - Ih bagus sekali. Ini khas banget Laravel ya. Produknya Laravel.
First party WebSocket server for Laravel application.
- Dia bikin web printer. - Oh, dia bikin web printer.
- Seperti socket. - Oh.
- Ratchet PHP.
- Oke.
- Ini seperti socket I/O sebenarnya. Socket I/O kan library.
- Oh iya, iya. Rapper, iya betul. - Iya.
- Nah, cuma ini buat orang yang baru belajar WebSocket,
kalau, ya sebenarnya mungkin agak mirip ya, kalau misalnya belum menguasain fundamental,
apalah HTML, JavaScript, terus langsung pakai Next.js,
itu jadi kayak bingung nggak menguasain mana yang sinteks dan fiturnya Next.js,
mana yang fundamental web.
Nah, gue dulu pertama kali juga nyobainya socket.io,
karena iya sekitar 3-4 tahun lalu yang demo-nya paling lengkap,
yang contoh-contohnya bagus, banyak tutorial-nya itu kan socket.io.
Oke lah, ngerti, paham dikit, tapi bahkan saat itu nggak terlalu ngah
bahwa itu WebSocket, cara kerjanya gimana, teknologinya apa,
terus udah sampai lama abis itu nggak paham-paham WebSocket tuh.
Jadi maksudnya ada asikunya juga sih.
- Salah satu kegunggulan WebSocket itu kan dia event-based ya, event-based.
Dimana data yang dikirimkan itu ada-ada header-nya dan ada payload-nya.
Jadi sebagai pengganti, ya maksudnya satu-satu kapsul,
biasanya kalau dikirimkan, header-nya dan payload.
Nah, di dalam header-nya itu isinya ini komen-nya apa?
Kalau tadi kan ada event, subscribe, ada event apapun lah itu ya,
yang antara client dan server harus mengerti komen itu.
Jadi dari header itu ngapain? - Event-event-nya apa kan?
- Iya, baru ada payload-nya isinya ya data, saat event mungkin chat ping,
payload-nya ping, sorry, header-nya ping, payload-nya nama kliennya.
Jadi waktu di ping nanti bisa dikelihatan di client yang di server atau di client satu lagi,
"Oh, si X ini nge-ping." Jadi bisa ada cara kerjanya begitu.
Selama koneksi kebuka, dia kan ibaratnya ngelisening apa yang terjadi.
Dan yang dilisening itu on error, on data, on apa lagi, banyak lah itu.
- Client kan yang listen event-handler-nya?
- Bagusnya dari koneksi atau protokol WebSocket ini, kalau misalnya terjadi koneksi putus,
dia akan berusaha connect lagi. - Dengan sendirinya?
- Dengan sendirinya, dia akan berusaha menyangka. - Oh, nice. Enak ya?
- Iya. Nah, kembali sedikit kita rewind sedikit dengan tadi si comment,
bahasanya si Alex Lasal yang comment itu. Di implementasi-implementasi, maksudnya selain WebSocket itu
ada juga loh banyak yang menggunakan Ajax, seperti Ajax Push, atau berusaha HTTP streaming,
HTTP server push, atau yang saya sebutkan tadi namanya Heartbeat.
Bukan pulling, tetapi si aplikasi kita, si client kita. Misalnya anggap, bayangkan aplikasi kita sedang
upload database dan berusaha mengekstrak database di server.
Tetapi untuk mengetahui progress bar, progress apa yang terjadi di server,
kita bisa pulling. Sudah sampai mana, sudah berapa persen, sudah sampai mana, sudah sampai mana.
- Itu kita manuali bikin request kan maksudnya? - Iya.
- Manuali ngeloop request, entah gimana sekarangnya. - Ya, si simpelnya ya,
aplikasi client JavaScript kita, looping aja set timeout, set timeout mungkin setiap 2 detik nanya,
setiap 2 detik nanya, sudah sampai mana progress restoring database-nya.
Jadi kalau teman-teman lihat banyak yang kayak progress bar saat copy data, atau segala macem antar itu,
ya bisa jadi gak perlu WebSocket, tapi bisa juga pakai yang namanya, apa tadi namanya,
bisa jadi yang namanya Heartbeat itu. Bukan pulling, pulling beda lagi.
Hanya request terus, tanya, tanya, tanya, tanya apa yang terjadi setiap itu.
Kalau pulling itu berbeda, jadi kalau pulling itu, coba buka server send event, SSE.
Itu teknik namanya pulling.
- S-S-server? - Send event. - S-S-E-S-E-N-T. Server send event. - Event, ya.
Ini bagi teman-teman yang misalnya server-nya gak bisa WebSocket, ini adalah pull bed-nya.
Yang introduction-nya, klik. - Jadi teman-teman yang server-nya gak bisa WebSocket,
mungkin karena dibelakang CDN, ya bisa pakai yang namanya server send event.
- Tapi cuma bisa server ya yang kirim event, gak bi-direksional kan?
- Bisa bi-direksional, nanti ada event source namanya, event source.
Nah, dari sisi cara kerjanya itu dia pakai API yang namanya server send event namanya API-nya event source.
Event source itu ada server send event aja langsung, play using-nya. Itu di guide.
Ya, serve event source. Nah, ini udah ada API-nya.
Jadi misalnya kita buka koneksi HTTP ya ini ke satu endpoint namanya SSE demo atau API SSE demo.
Dimana SSE demo ini akan membuka koneksi selama max timeout-nya PHP.
Jadi si server tidak akan memutus sampai dia timeout.
Ngebayangin ya, kita nge-request tapi request-nya kita tuh gak ada response end of life, end of AOF-nya dari server.
Jadi dia akan menunggu terus seperti while true.
Ujung-ujungnya while true, coba lihat ada server implementation-nya.
Nah, ini dia. Selama while true dan header-nya itu yang dikirimkan text event stream dan no cache.
Dan selama while true, tentu kan si server akan membuka koneksi ini kan, gak sampai dia timeout.
Nah, selama while true ini yang dia listen to ya data-data ini apa yang dikirimkan oleh si user,
nanti dia balas pakai stream, event stream. Dan setiap stream-nya selesai dia kirimkan, dia flush.
Nanti itu artinya flush itu dia akan kirimkan, jadi chunk, chunk data aja yang dikirimkan, text.
Seperti itulah dan itu namanya pooling.
Ini ada pertanyaan yang relevan sekali, kalau user matiin app-nya tanpa lockout, apakah koneksinya tetap open atau
pas dibuka lagi aplikasinya bisa reconnect lagi?
Gak bisa reconnect karena dia akan tetap putus, dia akan berbeda session.
Lockout-nya bukan lockout seperti login dan lockout, yang menentukan lockout itu kan si cookie.
Gak ada hubungannya sama event source.
Jadi gak terjadi, tapi progress yang terjadi terputus. Misalnya data yang kalian terima itu data yang boot copy data ya rusak datanya.
Misalnya menunggu data, corrupted datanya.
Tapi kalau sekedar life score, saya pernah bikin aplikasi pakai SSI untuk life score, karena server yang dipakai tidak mendukung web socket.
Jadi saya pakenya SSI, pakai life score ini, Hockey.
Itu kan tadi sudah buka koneksi, terus kalau browser-nya ditutup, close tap, tanpa manggil event close, itu masih terbuka dong server-nya gak tahu kan?
Nanti, kan ada, ada mekanisme dari si web server kan, kalau misalnya mengetahui kalau browser itu terputus atau internet terputus deh.
Ada mekanisme dari server kan, untuk mengetahui oh itu udah terputus.
Dan dia kan ada time out selalu, pasti ada, web server itu ada time out kan.
Dari PHP-nya, bisa jadi dari PHP-nya, atau dari si web server seperti Nginx ada time out.
Nah, kerennya si event source ini, kalau misalnya sudah time out terputus, dia akan create ulang otomatis, jadi kita gak perlu buat lagi.
Ada demo-nya kan, coba aja demo-nya ada di atas.
Di atas ada demo-nya deh, dia gak kasih ya, ada.
Itu kali yang main page-nya, server send event, ada gak?
Di atas, iya iya.
Oh, sudah bisa jadi, ya udah. Harus punya server.
Ya kan demo teknologi server, Sahit.
Ya, anyway, begitulah cara kerjanya SSC. Nah, ini HTTP long pooling sebagai foldback-nya, itu langsungnya cara kerjanya.
Kalau soket I/O ya, kalau teman-teman pakai soket I/O, misalkan web soketnya tidak jalan, baik di client atau di server, dia foldback-nya ke HTTP long pooling.
Artinya, jadi refresh secara bertala dan lain-lain ya.
Tapi kalau browser itu sudah hampir 97% katanya di sini sudah mendukung web soket.
Hampir semua sih, paling 3%-nya itu IE sama Opera Mini kecuali kayaknya. Soalnya ini udah puluhan tahun kan teknologi ini.
Semuanya Chrome versi 4 sudah support web soket.
Itu Opera Mini doangnya gak support.
Nah, terus ini tadi soket I/O kan belum selesai ya, kita bahasnya.
Ini kan sebenarnya library ya, kayak satu abstraction on top of semua teknologi soket tadi.
Makanya dia bisa, kelebihannya adalah itu kan dia bisa incorporate 3 hal itu yang di situ.
Bisa pakai long pooling, web soket, web transport, mana yang paling optimal dan tersedia di client-side.
That will automatically pick the best available option. Oke ya.
Ini kalau pakai library, kalau kita mau pakai web soketnya langsung, itu juga bisa.
Artinya ya cuma web soket doang. Kalau gagal, ya kita harus foldback-nya kita bikin sendiri.
Ya kita bikin semua itu sesuai kebutuhan kita.
Yes, nah ngomong-ngomongin soal web soket manual atau Vanilla, ternyata sudah dimers di Node.js.
Oh iya lho, baru.
Oh lah, masa sih?
Ya ini kan September 2018, kali tahun ini udah.
Udah ya?
Karena gue udah pernah lihat, oh pakai Node.js udah bisa langsung pakai web soket gitu. Pernah baca dimana?
Ada contohnya nggak ya?
Contoh untuk apa?
Kita lihat ya, dokumentasinya. Sudah masuk belum ya?
Di Node.js-nya. Jadi biasanya kalau kita, eh kok download, kalau kita pakai server Node.js gitu ya.
Itu biasanya paling umum kita pakai socket I/O ya, paling umum ya.
Ada kan NPM, NPM Web Socket yang ada?
Ada, ada.
Web Socket?
Ya, belum ada di sini. Ini versi berapa?
Enggak ada versinya. 22? 22 belum ada?
Ya ini yang gue selalu pakai. NPM itu yang Web Socket, NPM ini yang selalu, paling sering gue pakai.
Oh yang ini.
Oh, NPM package, Web Socket.
Ya ada, ada.
The Turtle.
Kalau dia tiba-tiba ngamuk dan delete, banyak yang rusak.
Ya selesai.
Risikonya pakai software open source ya. Mending kalau cuma, mending kalau cuma ngamuk terus ngedelete.
Nah kalau yang dulu siapa itu? Yang apa dikasih malicious code, lebih serem lagi sih ini.
Soalnya ini kan langsung berhubungan sama data ya.
Ya selalu dikunci versinya, ya in case Liu tiba-tiba ngamuk atau apa ya.
Kita ambil tiga sirisiko.
Kok node.js webnya berubah ya?
Dokumentasinya gak bisa di-search lagi. Dulu ada tombol search-nya sekarang gak ada.
Search bar, cuman karena ke zoom in, zoom in, zoom out.
Oh iya mungkin juga, gak ada, gak ada.
Apa dinet dia, itu Web Socket itu dimana?
Cuman ya.
Web Crypto, Web Stream.
Ya begitulah.
Eh ini malah adanya di, bukan docs-nya juga sih, tapi di release announcement-nya.
Web Socket client.
Coba deh buka blog post.
Oh salah yang ini, Web Socket WS ini.
Ya dia cuma itu, "We are excited to announce release node.js 22.
Highlights include require AS module, Web Socket client, blablabla."
Web Socket client, bukan Web Socket client.
Client, justru client.
Jadi mungkin apa ya, si node.js-nya itu buka koneksi ke ya suatu server lainnya.
Server lain, jadi proxy.
Iya, jadi proxy ya.
Kayaknya.
Coba, mana dia?
Coba aja buka Web Socket.
Web Socket default, semfer, enable Web Socket by default.
Oh udah ada nih.
Kan tadi sebelumnya experimental tuh ya, September 2023.
Nah yang Januari 2024 ini, enable by default, berarti udah nggak usah pakai flag.
Cuma itu sebagai apa dan gimana pakainya masih misterius.
Masih belum, ya masih misterius.
Mana sih Web Socket-nya?
Enable Web Socket by default.
Ada lagi nggak Web Socket lain?
Nggak ada, oh ini.
Loh, dia lagi.
Oh ini total semuanya ya.
Major commit another.
Ini yang ini.
Wah ini codenya, ada doc-nya, CLI.
Oh CLI buat ini ya, experimental itu tadi ya.
Yang ini.
Nggak ada doc-nya.
Global?
Global apa?
Oh.
Nggak ada.
Ini nih, coba deh.
Oh iya.
Coba buka docs-nya tuh.
History.
Iya betul, buka historinya deh, kan cocok.
Itu sebelumnya edit di versi 2.1.
Terus di 2.2 udah stabil, maksudnya nggak hidden.
Cuma nggak ada link-nya.
Kalau yang atas-atasnya kan ada link-nya tuh, ada link ke docs.
Nah ini belum ditulis.
Jadi mungkin temen-temen yang pengen avatar GitHub-nya masuk ke dokumentasi Node.js,
coba bikin pull request.
Tapi nggak ada.
Bikin dokumentasi.
Untuk apa gitu cara pemakaiannya ya?
Harus bikin, harus dibikin dulu kan.
Biasanya sih begini ya, coba.
Saya salah, tadi bukan yang NPMJS itu bukan itu saya pakai, saya pakai yang WS.
Iya.
Ini yang betul.
Nah, cara pakenya ya, menurut saya,
kalau seadanya ada sih, bakal begini juga ya.
Kurang lebih ya, iya sih.
Ini server-nya.
Tutup, tutup, tutup.
WSS port-nya.
Kalau ini kan Websocket, bukan, apa ya, Websocket yang,
kalau socket I/O salah satunya ini doang kan.
Kalau socket I/O itu kan sebenarnya ini lebih baik.
Iya, salah satu lagi.
Dia rapper.
Dia hampir kayak framework sih, maksudnya kalau mindset front-end ya,
hampir bisa dibilang kayak framework itu dia bikin keputusan arsitektur,
dan termasuk konfigur fallback-fallback-nya,
dan sintaksnya juga dipermudah lah.
Ini kan buat initiate server-nya aja,
config object-nya ribet.
Kalau socket.io cuma masukin port-nya doang.
Oke.
Nah, pertanyaan selanjutnya adalah,
kan HTTP/2 itu sudah bisa push data kan ya?
Iya.
Apakah dengan HTTP/2 Websocket jadi akan punah?
Atau bahkan HTTP/3?
HTTP/2 is primarily focus on optimizing delivery of web content and improving performance of web application.
Feature like multiplexing header compression prioritization help reduce latency and speed up page rendering.
Terus, kalau Websocket apa?
Serve different purpose and as distinct advantages.
They are not necessarily better or worse than each other.
Jadi, peruntukannya beda.
Kalau HTTP/2 itu bisa dia ngirimin static file ya.
Peruntukannya untuk ngirimin static file kan yang di sini ya.
Yang pernyataan ini kan ya. Mana dia?
Delivering web content.
Ya nggak harus static, tapi punya sekali antar ya udah.
Emang kayak kita terima paket aja, paket titerli di dunia nyata kan ya udah kita minta sesuatu,
kita memesan sesuatu, barang itu datang ya udah itu cukup buat kebutuhan kita ya udah.
Itu kan berarti analoginya HTTP itu kayak gitu.
Sementara kalau Websocket itu kan ya itu tadi harus bi-direktional ya dua arah.
Harus terbuka terus menerus, harus kita tinggal bikin semacam event handler atau listener.
Nah, tapi GRPC itu pake HTTP/2 buat komunikasi bi-direktionalnya.
- Oh, baru tahu? - Dan dia ngirimin binary formatnya.
- GRPC gimana secara perjalanannya? Pernah pasti nggak pernah ngedalami GRPC.
- GRPC itu kan remote procedural call. - Ya, kalau RPC gue tahu tuh caranya.
Coba apa bedanya dengan G-nya itu apa sih?
- G-nya itu adalah Google punya. - Oh.
- FourKey. - Ya, dari internal Google, kayak Kubernetes lah.
- Framework. - Framework yang bisa dijalankan...
- Zoom in coba lagi. - Zoom in, oke.
- Bisa jalan dimana aja. - Jadi sebenarnya dia itu bisa equivalent sama Websocket juga.
Kita harus bikin servernya, kemudian bisa berbagai client, baik itu mobile ataupun browser itu bisa konekt ke servernya GRPC.
Nah, tapi bedanya kalau Websocket itu yang data yang dikirim itu umumnya kan string ya.
- Benar nggak? - Oh, text.
Text, string, kalau pun kita mau ngirim JSON kita stringify dulu kan.
Nah, kalau GRPC itu kirimnya binary data.
Binary data yang konon kabarnya membuat si GRPC ini performanya lebih bagus.
Tapi cara kirimnya ribet, karena harus pakai protobuf, sintaksnya protobuf.
- Buffered. - Protobufnya Google punya.
Itu kayak sintaks GraphQL lah.
Iya, kirimannya pakai ini. - Coba lihat contohnya.
Jangan-jangan mereka bikin ini buat Youtube ya? Nggak? Atau buat apa sih?
Bisa kan kalau yang bikin kayak Google, Meta, ya buat in-house produk mereka kan.
- Calendar. - Ini contohnya kalau kita mau ngirimin apa, kita harus bikin objeknya dulu,
terus struktur datanya seperti apa, nanti kliennya juga punya file proto yang sama,
bisa memaping si binary yang dikirimin oleh server ke klien, begitu juga sebaliknya.
Tapi ini tuh apa sih? Library, protokol, kayak teknologi proprietary-nya mereka?
Ini library, framework, RPC framework. Protokolnya mereka menggunakan HTTP 2 dan Sun akan menggunakan HTTP 3.
Jadi ya sebetulnya kayak misalnya tadi socket.io kan dia bikin produk, bikin library,
abstraksi, dibawahnya ada macam-macam tuh ada web socket, ada apa.
Nah kalau ini dia bikin, di dalamnya tuh HTTP 2 biasa ya?
- Mungkin ya mereka mungkin menemukan masalah di web socket sehingga mereka tidak menggunakan web socket,
jadi akhirnya mereka bikin di atas HTTP 2. - Ya mungkin untuk optimum kompatibilitas kali ya.
- Betul. Mungkin tadinya HTTP 2 hanya dioptimise untuk delivery content atau static file,
akhirnya mereka bikin untuk binary. - Web socket perjuangan lah gitu ya.
- Web socket perjuangan. Comet perjuangan. Comet, ini berarti apa? Penerusnya Comet ya?
- Penerusnya Comet, nggak tahu. - Beda sih. Ini bisa di web ya? Bisa?
- Bisa. - RPC bisa di web?
- Bisa, bisa. Ada ini nggak contohnya ya? Google C++.
- Work across languages and platforms. - Nggak ada JavaScript.
- Bisa di PHP, bisa di Node. - Server ke server kan, server ke server.
- Iya makanya. - Maksudnya bukan ke browser.
- Iya. Server to server. - Server to server.
Supported platform. Ini ada web? - Coba. Quick start.
Gitclone, Docker Compose. Antarservice. Ini sebenarnya benar-benar.
Saya baru ingat nih, benar sekali. Jadi, gRPC itu dipakai untuk web services,
komunikasi antarservice di web services. Itu peruntukannya. Peruntukan utamanya.
- Jadi bukan ke client ya? - Bukan untuk client dan server.
Tapi antarservice. Iya. Benar-benar. - Nah, terus berarti dari client,
dari browser, nge-request biasa juga ya, tetap ujung-ujungnya?
- Biasa. - Atau...
Iya kan? Kita harus minta terus ya? Nggak bisa buka koneksi.
- Iya. Bisa jadi... - Kabarnya bakal ada.
- Kabarnya bakal ada. - Apa tadi yang kabarnya bakal ada?
- Yang web browser. GRPC diakses dari browser. Library-nya ya.
- Basic tutorial apa tuh? - Basic tutorial.
- GRPC. - Ada tadi? Coba diklik.
- Itu di kiri. - What's next?
- GRPC web. Itu ada GRPC web. - Oh, ada pasangannya gitu.
- Ini back-end server. Configure Envoy Proxy. - Oke, fine.
Saya cuma pengen tahu di web itu gimana sih?
Itu tadi ada event handler-nya, ada pullback-nya.
- Ini kan, yang atas ini kan? - Atas. Nah, itu ada...
- Eh, ini server kan? - Oh.
- Server. - Ini server, echo.
- Echo server. - Iya.
- Nah, kita mau lihat client sekarang. - Iya.
- Udah ada berarti. - Oh, oke.
Hampir sama seperti Websocket kan, model bentukannya kan ya?
- Betul, betul. - Ya, jadi kayak...
- Kayak ngebuat event source sendiri aja gitu. - Iya.
Kayak bikin event source, betul. Kayak bikin event source.
- Terus request... - Http kan? Http kan?
Jadi membuat event source yang lebih terstruktur.
Karena data yang kita panggil, terus data yang kita panggil, remote code prosedur ya.
Data yang... salah, remote prosedur call.
Prosedur yang kita panggil, prosedurnya apa, data structure-nya apa,
sudah kita kirimkan, nanti kita terima data server seperti apa.
Iya. Jadi si file protobuf ini yang tadi ada bentuknya kayak gini,
itu kan, ini ada struktur datanya. Ada echo request, echo response.
Ada message-nya isinya satu. Terus di sini, ini adalah prosedurnya.
Ini adalah fungsinya. Fungsi yang dibuka oleh server dan bisa dieksekusi oleh klien.
Ini file.proto ini nanti dikompile seperti ini, terus bisa di-output ke JS.
- Jadi kode... - Oh, yang diimport tadi ini ya?
Yang ada di server, kemudian dikompile pakai protokompiler, jadilah file JS
yang isinya sudah auto-generated. - Output-nya JS.
Nah, terus tadi tuh, nah ini nih yang di-require, yang di-import, itu tadi hasil output-nya.
- Iya, echo request, echo response. Dan kemudian echo request-nya bisa kita eksekusi di sini,
di sisi klien. - Kayak web assembly, kayak ngebungkus dengan web assembly.
- Ini kan prosedur call di sini kan sebenarnya kan? - Iya, itu prosedurnya.
- Prosedur call-nya ini kan, set message ini kan. Jadi kita set message seolah-olah di lokal,
padahal sebenarnya request-nya ini ada di server. - Iya, jalan di server.
Jadi yang data yang dikirimkan via, pakainya binary tadi kan. Tapi kirimkan via binary.
- Iya, HTTP2. Dia pakai HTTP2. - Makanya saya bilang, seperti jampur-campur
antara web assembly dan event source, kan web assembly binary juga.
- Di client doang? - Iya sih.
- Tidak ke server? - Susah. Benar-benar RPC sendiri.
- Manggil prosedur yang ada di server tapi dari client, gitu ya. - Iya, betul. Itulah konsepnya seperti itu.
- Serasa, berarti ini khusus untuk orang server tapi dipaksa pengen bikin aplikasi yang di client.
Ya udahlah, tetap seperti nulis logic yang di server, tetapi jalannya di client.
Tapi sebenarnya prosesnya jalan di server. - Enggak. Sebenarnya awalnya ya,
peruntukannya awalnya adalah untuk berkomunikasi antar server, awalnya.
Tapi ternyata banyak yang minta, eh, yang web dibikin dong. - Iya, sekalian.
- client ke web, gitu kan. Ya udah, gitu. Awalnya buat antar server, microservice.
- Nah, berarti sebenarnya itu head-to-head-nya yang tadi masuk baru di Node.js 22, kan.
Mau dibikin kayak gitu juga kan, websocketnya.
Si node server-nya itu sebagai client, makanya tadi kan websocket client.
- Hmm, oke, oke. Tapi pakai WS, instead of HTTPS. - Iya, head-to-head-nya.
- Head-to-head-nya. Oke, oke. Nanti lagi mau kita bahas.
- Nah, terakhir itu ada yang baru, yang baru tentang websocket, web transport.
Ada tuh yang dari Google tuh. - Developer Chrome.
- Ini masih ini ya, masih... - Chrome only.
- Ini bukan? - Iya, limited... Apa itu kalo ininya baseline-nya kuning?
- Availability. Safari Bloom. Safari Bloom Support.
Nah, tapi apa ini saya nggak tau. Kita baca sama-sama aja.
- Baca bareng aja. Nah, MDN itu bukan resource yang bagus kalo kita belum tau.
Tapi bagus kalo kita udah tau. Nah, ini aja yang lebih user-friendly.
API, Offering Low Latency, Bidirectional Client Server.
- Apa? Kayak websocket. Tapi apa bedanya itu yang pertama tau?
- Oh, pakai HTTPS. - Oh, dia ngeliat itu ya kali ya.
Ngeliat DRPC kali ya. - Berarti nggak pakai websocket protocol lagi.
Oh, ini. Oke, lanjut. - Lanjut.
- Nah, kalo non-secure, pakai datagram. Kalo secure, pakai stream. Atau gimana? Gak tau.
Unreliable itu maksudnya apa, coba? - Gak reliable.
- Bebas. Datagram. Oh, do not need strong delivery guarantee.
Kalo stream, oh, urutannya harus sama ya.
Kalo nggak masalah, siapa yang sampe duluan, pakai datagram.
Kalo yang harus urut, pakai stream. Mungkin kalo datagram tuh kayak apa sih?
FTP. File Uploader kali ya. Kan maksudnya yang penting keupload.
Kan pasti ada hashnya atau apanya nanti diurus, di gabungin sendiri di server.
Tapi kalo misalnya kayak video atau chat kan harus urut. Jadi pakai stream API.
Oh, kalo websocket itu di atas TCP kan. Kalo TCP itu sifatnya kita kirimin data.
Terus kalo datanya udah nyampe up problem, kita tau statusnya kan.
Dikirimin balik. Data received gitu kan. Ada atikannya kan.
Kalo ini, di atas UDP. - Makanya lebih cepet.
- Fire and Foreman. Kirim ya udah. Mau nyampe, mau nggak, terserah.
- Dia pakai Quick. - Dia pakai Quick.
- Urutannya kayak gimana? Terserah tadi yang kalo datagram.
Kalo stream, bakal urutkan tuh, one or more streams of ordered data.
- Ini kayaknya contekan banget sama GRPC. Karena GRPC juga bakal menggunakan HTTP 3,
menggunakan UDP, dan pakai Quick protocol juga. Mirip-mirip ya.
- Saling mencontek. - Receiving media stream push.
Receiving notification push.
- Menarik. Bisa bikin push notification nih. Coba gimana secara pakainya?
- Current status. Oh, udah hampir komplit semua.
- Wah, ini masih proposal kan soalnya. - Masih proposal?
- Iya. Eh, nggak tau. Tadi udah launch di Chrome sih.
- Wah, udah ada website ini, webtransport.de. Apa ini?
- Community maintain. - Connect.
- Kan community maintain tadi katanya. Ya kali servernya udah dimatiin.
- Ini ya, localhost. Localhost emang bisa, kan nggak ada jalan.
Localhost harus bikin. - Iya, iya.
- Basic JavaScript client to try. Oh, kita harus bikin servernya.
- Oh, pantasan ke localhost. Maksudnya kita jalanin. Kita bikin dulu di local atau di mana.
Abis itu kalau kita mau nyoba, bisa. Kayaknya maksudnya gitu.
- Code sandbox nih, ada code sandboxnya.
- Nah, mending lihat kodenya.
- Wah, langsung webtransport, wah. - Zoom in, BTW.
- Text send the data 10 times. - Coba buka log.
- Initiating connection. - Kalau network, network isinya apa?
- Server lognya ada nggak sih? - Nggak ada.
- Development servernya, kayak misalnya kalau terminalnya.
- Ada tuh. - Ada.
- Nah, npm relastart. - Sudah itu udah jalan biasanya.
- Udah jalan, tapi servernya aja. - Coba kita lihat ke mana sih dia perginya.
- Component log, input. - Wah, jadi kayak mau buka juga.
- Send data kan? - Be-directional stream isinya apa tuh?
- Oh, di transport, di metode. Apa metodenya transport?
- Sebetulnya, sebentar, sebentar. Saya jadi bingung. Ini kan input dan output.
- Inputnya itu... - Bawah.
- Send data. - Send data, send data.
- Iya, itu tadi kan create by directional. - Oh, nggak ada replay?
- Pasalnya dia harus nge-replay lognya itu, dia harus ne-kirim di browser juga itu lognya.
- Ptw, demo-nya mana sih ini? - Makanya bingung kan?
- Demo-nya dari sini itu ada try it out, serverless write your own. - Oh, try it out.
- Open bidirectional stream. Gak bisa ya. - Mati.
- Anyway, namanya coba-coba using the API. Udah ya, habis ya. Oh, ini ya, bukan?
- Itu, itu cara kerjanya. Oh, berarti web transport API itu sudah ada tuh, itu kan?
- Iya, ini ada. URL-nya masukin. Terus... - Itu URL server-nya kan ya maksudnya?
Yang kita mau buka koneksi. - Once ready, fulfill, the connection can be used.
- Wait, transport, ready. - Turun, turun.
- Nah, ini kan open connection. - Nah, kita kan bisa milih tadi,
pake datagram atau pake stream. Kalo datagram caranya, haa, bingung juga, pake vector ya.
- Binary berarti ya, dikirimin ya? - Binary?
- Iya. - Binary.
- Dan UDP itu data yang bisa dikirimkan, dikit loh. Gak bisa banyak.
- Kecil ya, kecil ya? - Kalo gak salah sih, berapa? UDP itu maksimal data-nya berapa sih?
- Stream API. Ini contoh stream-nya, create bidirectional stream.
- UDP itu maksimal 65 kilobyte. - Ya, harus dipecah-pecah.
- Dipecah-pecah kan makanya, misalnya kalo video yang di front-end masters atau apa yang kursus berbayar gitu,
video berbayar kan pakenya kayak gini ya kayaknya. - Betul, betul.
- Gak tau sih, exactly pake datagram atau bentuk lainnya, selalu ngirim.
Jadi ngirimnya bukan media, bukan file media, tapi dipecah jadi chunk yang kayak gitu.
- Iya, pengen download ya? - Iya, pengen nyolong.
- Kecil-kecil. - Gak bisa dicolong. Gak ada yang bukan media file.
- Ketauan, sama saya juga melakukannya jadi tau.
Maksudnya mau didownload dulu kan sebelum ditonton gitu kan, kalo nontonnya gitu kadang-kadang suka nge-like kan.
Liat lah. Oh, ga ada ternyata yang fullnya, ada yang kecil-kecil.
- Kecil-kecil pas dibuka di preview isinya kagak jelas bahasa alien.
- Iya, berarti dia modelnya kayak gini. Polyfill. Oh, udah ada polyfill.
- Gak kelihatan. - Oke, tadi gak kelihatan di networknya.
- Coba kita baca ini dulu tadi.
- Berarti, tapi udah didukung banyak, apa, beberapa, tadi mana dia?
- Eh, Jeff Postic loh, tuh yang bikin ininya, postnya.
- Pak Jeff ini dimana sekarang? - Nuh, udah gak di Google ya?
- Epo dikit. - Kan dulu dia yang bikin workbox ya, kalo gak salah.
Dan ngejawabin semua. - Iya, yang review saya jadi GDI nih, Pak Jeff Postic.
- Dan dia tuh rajin banget dulu pas masih Googler ya, di Stack Overflow,
semua pertanyaan yang tagging workbox selalu dijawab dengan apa, kayak detail, ada linknya, wah, itu banget.
Rajin banget ngejawabin. Pindah ke mana gitu. Sekarang mungkin pindah ke Ternak Ayam Petunjuk.
- Ternak Lele. - Ternak Lele Dumbo. Jadi tadi ada apa aja, pertama tadi yang website.
- Hmm, 2sigma apaan? E-commerce, oh, 2sigma, scientist financial service. Beda banget ya?
- Jauh-jauh. - Shopify atau semacamnya, kirain teknologi.
- Sopify lagi, semua perangnya bonong deh, saya kan Sopify. - Kalo gak, ke itu, ke Edge, Microsoft Edge,
ikutan Pak Alex Russell. - Alex Russell udah di Edge sekarang?
- Iya. - Oh, gak jauh-jauh.
- Iya, emang spesialisasinya di situ. - Browser engineer yang asal Indonesia itu kak Rakina,
dia kan sempet ngomong, kalo browser engineer itu pindahnya tuh gak jauh-jauh, muter-muter aja.
Mozilla, Safari, Chrome, sekarang Edge. - Karena skillnya niche.
- Iya, karena ekspertisnya kemosnya itu udah spesifik banget dan dia optimalnya kalo ya di antara 4 perusahaan itu.
- Iya, makanya. Jadi ya, muter-muter aja itu. - By the way, Edge sekarang sudah resmi berdiri sendiri ya.
Bukan Chromium-based browser lagi. - Really? Engine-nya apa?
- Iya, maksudnya dalam major browser, Edge itu bukan lagi begini. Kayak Opera kan gak di bawah Chrome.
- Iya, kalau sebelumnya kan jadi satu antara Chrome sama Edge. - Jadi dulu kan Chrome, Safari, Firefox, sekarang ada Edge.
Contohnya kan gak ada kan, ada Brave, Opera, Arc, jadi kan semua di bawah Chrome.
Sedangkan Edge berdiri sendiri, dia udah bener-bener kayak udah working, meskipun engine-nya mungkin masih tetap ada Chromium-nya,
versi sekian, tetapi dia udah punya banyak layer untuk yang membuat dia differentiasi.
- Betul. Kan memang tujuannya buat dioptimise ke OS-nya dia kan.
- Tapi maksudnya berarti dia gak direct fork-nya Chromium ya. Dia kayak semacam, apalah, dia forking ke tempatnya sendiri,
tapi kalau dia ngubah itu, dia gak merge ke upstream-nya Chromium berarti. Maksudnya dia bisa mengatakan sesuka dia kan,
mau diapain ya terserah, tapi gak merge upstream. - Mungkin dia akan merge khusus spesifik untuk yang Windows doang.
Untuk yang Linux mungkin dia gak optimise kan. Linux dan Mac OS mungkin dia tidak dioptimise kesana. Mungkin, gak tahu kita.
- Alright. Ada lagi yang mau dibahas? - Ya yang tadi aja, Websocket nih,
ada pertanyaan karena penasaran apa, yang baru-baru ini terutama sih kayak tadi Websocket, server scene event, web transport,
pertimbangan performance-nya gimana ya? Baik dari browser, berarti kan ada event handler yang jalan terus.
Tapi kalau event handler sih sebenarnya gak terlalu masalah ya. Tapi server-nya kan berarti harus ngebuka terus tuh.
Itu kayak pertimbangan performance-nya, seberapa signifikan, maksudnya seberapa banyak yang harus dipikir dan dihitung,
terutama kalau dikaitin sama ya resource dan cost, misalnya berarti hampir tanda putip gak boleh,
atau tabu kalau misalnya kita pakai cloud service gitu kan. Gitu aja. Masa berarti tiap ada yang buka koneksi itu jalan terus gitu.
Pertimbangannya kayak gimana ya itu? - Tapi kan Websocket ini, mungkin ya, koreksi kalau salah.
Websocket ini dia ngirimnya kan teks dalam jumlah kecil kan, apalagi kalau kayak tadi web transport itu kan UDP-UDP lebih kecil lagi.
Jadi dia ngirimnya gak bermega-mega, kirimnya per kilo aja. Kecil tapi sering gitu.
- Tapi sekali koneksi terbuka dia jalan terus kan? - Iya. Dan nanti bisa dibaca yang content type event stream.
Content type event stream itu. Websocket tuh kirim datanya, content type-nya stream.
Jadi content type-nya ada text HTML, ada apa lagi? Gak lupa. Apa aja sih content type?
- Application JSON. - Application JSON.
- Oh iya. - Text HTML, MP4, something-something gitu ya.
Multi-part, ada multi-part form data. Nah kalau Websocket itu event stream. Content type-nya.
Ya meskipun si Websocket ini bilang ya kalau udah sekali terkoneksi abis itu gak putus-putus ya tetep bisa diputus.
Kalau on-close ya server yang close atau client yang close bisa. Eh kita udahannya. Putus deh.
Tapi kalau request-response kan begitu dikirimin udah otomatis putus gitu kan.
Selama belum ada pernyataan putus ya dia tetep nyambung terus.
- Nah iya berarti kalau pakai websocket bahaya juga kan? - No no no. Websocket tuh ada.
Iya gak bisa. Kalau Websocket itu ada ping-nya juga. Ada ping-pong. Ada ping-pong ya dia si server akan nge-ping juga.
Dia nge-ping kalau gak dibalas dia tutup. Ping-pong.
- Nah ini bener nih. Anak dia mana udah dimaja sama Firebase kenapa harus set-up gitu.
Masalahnya Firebase kan itu sama database. Kalau saya gak mau pakai database-nya Firebase gimana?
Tetep mau real-time tapi gak mau pakai database Firebase. Atau service Firebase yang mungkin harganya mahal.
- Bisa. Kayaknya FCM Firebase Cloud Messaging tuh bisa dipakai buat diintegrasiin sama kode apapun tanpa harus pakai database-nya.
Pernah pakai soalnya di kerjaan.
- Iya. Kalau dulu kan semudah kita bikin table di Firebase, abis itu semua klien konek ke Firebase.
Ketika datanya berubah semuanya ikut berubah kan. Itu magic-nya si Firebase kan. Orang banyak yang suka gara-gara itu salah satunya kan.
Ketika ada data berubah semua ke klien semua di broadcast jadi berubah gitu.
Tapi ya masalahnya itu lagi. Firebase itu kan satu tipe database. Kalau misalkan kita udah punya database atau kita gak mau pakai dokumen database seperti Firebase,
kita mau pakai yang lebih structure kayak relational database, ya mungkin bisa pakai FCM dan lain-lain.
FCM itu mirip message broker. Saya gak tahu. - Belum pernah pakai message broker sayangnya.
Kalau FCM itu Firebase Cloud Messaging. Ya itu messaging service sih. Itu spesifik banget.
Kayak cuma buat ngirim push, push notif, push message. Itu optimize-nya buat itu.
Kalau mau dipakai buat hal lain ya bisa-bisa aja. Cuma emang dia optimize-nya buat kirim push notif.
Kalau gak salah, Posgill gak bisa loh sebenarnya. - Posgill dibikin apa? - Push data ke klien.
- Gak tahu. - Gak tahu ya. - Jadi kayak ada hook-nya gitu.
Kalau misalkan kita subscribe, kita kasih tahu ke Posgill, saya mau subscribe ke table ini ketika ada perubahan di table itu.
- Kalau ada row baru atau apapun itu, kirim event. Dia manggil suatu webhook URL atau apa gitu?
- Iya, protokolnya sendiri URL lewat itu. Event trigger ya. Itu kayaknya pembahasannya di luar konteks ya, agak jauh ya.
Kalau server send event, nemu satu artikel yang enak sih nih. Kayak pembahasannya ringan banget.
- Ini terkenal memang bagus dia bikin-bikin. - Kalau bikin posting infographic atau semacamnya, bagus.
- Zoom in. Nah, streaming events from a server. Terus server send event itu ternyata spesifikasi tersendiri.
Itu kalau link-nya diklik masuk ke HTML speknya. Bukan, HTML spek. Kalau iseng pengen lihat speknya. Nah, terus itu penjelasannya.
Kalau kita simpler alternative to websocket, kalau cuma pengen server-nya aja yang kirim event. Jadi sebenarnya ini single direction ya kayaknya.
- Maksudnya tujuan atau keunggulan utamanya streaming updates from a server. Tapi dia nggak mau polling ceritanya.
I didn't want to be doing polling. Mau stream updates. Nah, terus itu ada contoh-contohnya.
Ya itu contohnya semi-sudo code sih. Cuma cukup illustratif, enak. Maksudnya kalau belum paham, baca itu jadi oh gitu.
- Nah, begini isinya. Betul. Itu tadi saya bilang event-nya, header-nya apa, payload-nya apa.
- Oh ini. Terus connection-nya keep alive ya. - Long live connection. Nah itu tuh yang nomor 3, event stream.
- Benar. Content-type-nya event stream. - Ini SSI ya. - Nah, terus udah lanjut scroll ke bawah. Nanti ada contoh yang buat client-side-nya, JavaScript-nya ya kayak gitu doang.
Nama event-nya sesuai yang dikirim dari server tadi. Tapi client cannot send updates in the middle.
So itunya unlike web sockets, jadi perbedaannya sama web sockets tuh yang ga bisa back and forth di tengah-tengah. Jadi pas dia lagi terima, sepanjang keep alive itu,
ga bisa bolak-balik. Ga bi-directional. - Tidak bi-directional sebenarnya kan ya. - The client makes one request at the beginning, abis itu server-nya yang kirim response.
Kayak request-response, tapi keep alive. Bener ga sih? - Iya. Kayak request di awal, abis itu sepanjang connection-nya masih alive, server bisa kirim kapanpun dan berapapun data.
Ini tadi yang udah kita bahas selanjutnya sih, kalau connection-nya putus, dia otomatis restart. - Oh ada bug, dia ketemu bug. Gak bisa di-power or send event.
Event were being buffered. - Bisa difix dengan settingan proxy.
Stack overflow is amazing. Apa ini? - Oh salah, dia salah pakai HTTP 1. - Oh harusnya HTTP 2 ya?
- Mungkin. Atau itu settingan attack-nya ya, gitu masalah dia. Cuma tadi yang di atas itu kayak simple banget penjelasannya, cuma langsung jadi kebayang, oh flow-nya kayak gitu.
- Websocket bisa digunakan untuk WebRTC ga sih? Bisa aja, tapi WebRTC setau saya ada protokol untuk kirim datanya kan ya, protokol tersendiri kan.
- Websocket itu client server, kalau WebRTC itu peer-to-peer, beda. - Oh iya bener, beda peruntukan ya.
- Peer-to-peer dan bahkan ga perlu server optional kalau ga perlu pakai server.
- Ini harus ada ini-nya, apa bahasanya, eye-server, turn, yang handshake mereka yang ngasih tau, oh si ini di IP ini, si ini di IP sini, yaudah kalian ketemu ya.
Register-nya gitu, macongblangnya, harus ada macongblangnya. Register-nya aja sih sebenernya. Buku tamu, harus ada buku tamu, harus ada buku tamunya.
- Buku absent. - Sip, kalau gitu, berarti sudah cukup, jangan lupa saran-sarannya. - Bener, bola berapa hasilnya, coba hasil bola.
- Ih 2-0, Cuy menang kita, asik. - Menang, jangan lupa ya, temen-temen bisa kesana.in/ngobrolinweb untuk nanya-nanya, atau saran topik, atau pemateri, ga ada sumber.
Jadi, terus dimatikan dulu, nanti mungkin kita akan ada episode khusus untuk membahas beberapa yang belum. Websocket adalah salah satu materi yang lumayan banyak.
- Udah lama nyangkut di discussions-nya. - Discussions, ya. PHP sekarang bisa websocket, apa saya dong yang baru karena... - PHP, socket sudah lama, sudah bisa.
- Laravel 11 itu bikin rapper-nya memudahkan. - Rapper-nya, ya. - Revert ya, tadi yang di-post sama di-comment di atas. - Iya, tadi ada pertanyaan ini, apa hubungannya Laravel Echo dan Pusher? Kenapa API-nya mirip?
- Temen-temen yang pengguna Laravel mungkin bisa kasih masukan, Laravel Echo dan Pusher. - Ga pake itu sih soalnya, ga pake Echo. Laravel itu produknya banyak banget ya, itu offisial integration-nya.
- Ada terakhir pertanyaan itu, konkurensi, websocket bisa di-thread atau process? - Bisa di-thread atau process? - Kan dia event handler ya? - Ga tau. Kenapa? - Oh, kalau di server mah ga ngerti.
- Saya ga ngerti server, kalau di client ya event handler harus di main thread kan. Atau ditaro web worker juga bisa sih. Server-nya bikin. - Kalau thread itu biasa kalau seperti Java, itu kan kalau kita mau konkurensi kan harus pake thread.
- Kemudian kalau process itu biasanya istilahnya mirip seperti thread, tapi lebih ringan kalau di Erlang, Elixir dan mungkin Go Routine ya.
- Itu kan konsepnya supaya bisa multi-threading kan, maksudnya biar bisa parallel kan, makanya namanya multi-threading. Kalau Java itu kan agak berat, makanya sekarang bahasa-bahasa yang modern itu sebutnya process, itu lebih ringan katanya gitu.
Cuman bagusnya websocket jalan di thread atau di process ya tergantung bahasa pemogramannya. Kalau di Java mungkin ga bisa pake process kan. Harus bikin thread kan. Ga tau juga sih.
- Ga tau. Belum pernah sampai sedalam itu. - Kita hanya pengguna, menggunakan.
- Cuma jadi kepikiran sih kalau di browser, bisa juga ditaro di service worker atau web worker atau semacamnya ya. Enak juga kan biar yang lungguin, maksudnya ibaratnya ngurangin kerjaan browser.
- Selama proses yang dilakukan itu ga perlu ngubah dong ya, saya terserah. Jadi cuma kayak nge-update index DB atau local storage bisa-bisa aja.
- Ya kan dari service worker bisa post message. Jadi maksudnya misalnya perlu ada yang di-update, ya kirim post message. Ya itu tergantung apa yang dibikin sih.
Cuma yang jelas kalau kebutuhannya adalah biar ga lambat, ga lagging, core web vitals, INP atau semacamnya. Berarti kan itu semua event handlernya bisa dipindahin ke service worker ya.
- Coba aja. Belum pernah coba sih. Kayaknya sih bisa. - Belum pernah coba juga. Ini juga asal. - Kalau SSI ga bisa di service worker.
- Oh iya. Berarti problem utamanya di Websocket adalah tidak semua server mendukung ya. Kalau temen-temen deploy server sendiri, mungkin pakai PM, install, itu mungkin bisa.
Tapi kalau yang hosted, ya itu harus dicek apakah Websocketnya mendukung. Kalau ga mendukung, mungkin bisa fallback ke SSI, server send event. Kalau server send event itu kompatibilitasnya lebih tinggi ya.
- Karena dia pakai HTTP. - Iya. Karena itu sebenarnya. - Tapi lebih lambat ya. - Tapi lebih lambat. Ya karena dia kayak polling kan. Request response tapi keep alive.
- Berarti web transport salah satunya solusi untuk ini ya. Karena mungkin ada server yang ga mendukung, nginx-nya juga harus ditwik supaya lebih kencang dan lebih mendukung si Websocket. Akhirnya ada web transport yang pakai HTTP tapi mungkin kecepatannya menyamai Websocket atau mungkin hampir menyamai gitu ya.
Kita coba aja. Temen-temen bisa komen. Saya belum coba, baru belajar hari ini web transport. - Iya. Mungkin nanti beberapa bulan ke depan web transport muncul, kita bisa coba, mungkin lebih bagus atau gimana reviewnya nanti kita lihat lagi.
- Shoutout Mas Johan tadi yang nyaranin materi web transport. Tadi kita cuma pengen bahas Websocket doang tapi disarankan coba deh web transport sama tadi server event.
- Karena Mas Johan lagi main-main kesana kan. Web artisi, Websocket buat chatting-nya mungkin. Oh ada yang balapan. We are. Sama web transport mungkin ya itu ya.
Ada hubungannya lah. Masih bikin aplikasi yang real-time kan. - Video call. - Video call.
Oke untuk malam ini segitu aja. Terima kasih banyak buat semuanya yang hadir. Kita ketemu lagi minggu depan dengan topik yang berbeda. Selamat malam, selamat istirahat, bye bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
2 Okt 2024
Ngobrolin Drama Trademark & Open Source
Episode ini membahas drama perseteruan antara Matt Mullenweg (co-founder WordPress) dengan WP Engine, sebuah perusahaan ...
5 Jun 2024
Ngobrolin NextJS
Episode Ngobrolin kali ini membahas update terbaru dari Next.js 14 beserta berbagai kontroversi dan perubahan signifikan...
13 Nov 2024
Ngobrolin Slide
Episode ini membahas tentang berbagai tools dan platform untuk membuat presentasi slide, mulai dari konvensional seperti...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .