Ngobrolin Storage
Ringkasan Episode
Bantu KoreksiMelanjutkan episode cookie minggu sebelumnya, pembahasan bergeser ke tempat penyimpanan lain di browser — bukan basis data di server, melainkan yang benar-benar tinggal di perangkat pengguna. localStorage dan sessionStorage bersaudara dengan API yang sama; bedanya hanya umur: sessionStorage hilang begitu tab ditutup, localStorage bertahan sampai dihapus. Keduanya menempel pada domain, jadi data yang disimpan satu situs tidak bisa dibaca situs lain. Contoh paling membumi adalah kejengkelan lama: sudah menulis panjang di kolom komentar lalu koneksi bermasalah dan semuanya hilang setelah refresh. Sekarang jarang terjadi karena aplikasi menyimpan draft ke localStorage, dan itu disebut sebagai cara tercepat menaikkan pengalaman pengguna secara tajam. Contoh lain preferensi mode gelap, yang memang tidak perlu ikut dikirim ke server di setiap request seperti cookie — dan di Svelte pun menyinkronkannya ke localStorage relatif mudah. Untuk kebutuhan lebih berat ada IndexedDB, yang berperilaku seperti basis data sungguhan: punya indeks, jauh lebih cepat, dan satu-satunya yang bisa menyimpan blob. Kapasitasnya sangat besar — di browser berbasis Chromium bisa memakai sebagian besar ruang disk — tapi berbeda tiap perangkat, jadi transaksinya tetap harus ditangani kalau gagal. Sintaksnya diakui kurang menarik, dan dari situlah PouchDB yang mengikuti gaya CouchDB, Minimongo milik Meteor, serta RxDB menawarkan lapisan yang lebih nyaman sekaligus sinkronisasi ketika koneksi kembali ada. Disinggung pula SQLite yang kini bisa berjalan di browser lewat WebAssembly.
Poin-poin Utama
- •localStorage dan sessionStorage punya API yang sama dan bedanya hanya umur: sessionStorage hilang saat tab ditutup, localStorage bertahan sampai dihapus
- •Keduanya menempel pada domain, jadi data yang ditulis satu situs tidak bisa dibaca situs lain — mirip perilaku cookie
- •Menyimpan draft tulisan ke localStorage adalah cara tercepat menaikkan pengalaman pengguna: teks panjang tidak lagi hilang saat halaman ter-refresh
- •Preferensi seperti mode gelap cocok di localStorage justru karena tidak perlu ikut menempel di setiap request seperti cookie
- •IndexedDB berperilaku seperti basis data sungguhan — punya indeks, lebih cepat, dan satu-satunya yang bisa menyimpan blob
- •Kapasitas IndexedDB sangat besar, di browser Chromium bisa sampai sebagian besar ruang disk, tapi berbeda tiap perangkat sehingga kegagalan transaksi tetap harus ditangani
- •Sintaksnya kurang nyaman, dan dari situlah PouchDB yang mengikuti gaya CouchDB, Minimongo milik Meteor, dan RxDB menawarkan lapisan yang lebih ramah plus sinkronisasi
[telepon]
Halo, halo, hallo. Selamat malam.
Selamat malam.
Gimana kabarnya semua?
Berbaik. Mas Riza gimana kabarnya?
Baik-baik. Alhamdulillah, apa, saya dan keluarga sudah sehat-sehat kembali.
Jadi mudah-mudahan ada yang kangen ya malam hari ini ya.
Karena kita skip satu minggu.
Saya juga sebenarnya kangen.
Minggu kemarin itu kayak sepil.
Gak ada kegiatan gitu ya, sepil.
Iya, iya, iya, iya.
Oke, seperti biasa, selama nggak lama waktunya ngobrol di web.
Masih bersama Ivan, masih ada Eka, dan masih ada saya Riza.
Nah, ini mungkin karena apa ya, karena kangen-kangenan jadi agak beda sedikit ya.
Sebelum kita mulai ke topik.
Saya mau nanyain satu-satu nih.
Kegiatan apa, kerjaan, kerjaan. Boleh nggak dibocongkan?
Boleh, boleh.
Terus kerjaan apa nih, Ivan?
Minum dia.
Minum juga.
Butuh melegakan, karena kalau soal kerjaan itu.
Sekarang kerja itu lagi...
Saya nggak bisa bilang saya lagi pick, atau nggak lagi pick.
Karena pick mulu, jadi sepertinya normal gitu ya.
Jadi apa nih? Maksudnya bikin website apa atau apa?
Kliennya nggak usah disebutin lah.
Iya, kalau ininya news site.
Oh, news site.
Lihat transkrip lengkap (1061 segmen lagi)
Publishing site, bukan di Indonesia, tapi masih di Asia.
Okay.
Traffic-nya lumayan.
20 jutaan sampai...
Lumayan.
Pick-nya, dia pernah pick 80 juta sebulan.
Page view sebulan.
Jadi per harinya itu lumayan lah ya.
Kayak sejuta apa dua juta gitu per page view per hari.
Terus kemudian...
Masih berkutat, saya sendiri masih berkutat soal side performance dan core web vital dan fitur-fitur tambahan lainnya.
Namun musuh terbesar saat ini, saya itu, bukan LCP, TTFB itu udah lewat masanya.
Sekarang musuh terutama itu layout shift.
Sulit banget.
Content layout shift itu celes ya.
Banyak iklan atau gimana?
Iklan gampang, iklan itu ketahuan, size-nya.
Tahu nggak apa yang paling susah?
Dynamic content, misalnya lo posting gitu.
Embed, Twitter embed, Instagram embed, TikTok.
Karena kalau YouTube masih bisa di prediksi.
Ukurannya dijelas ya.
Karena Instagram embed atau TikTok embed itu depend sama content.
Nah itu sedang saya nggak bisa menaruh minimal height-nya berapa.
Karena kalau saya bikin terlalu besar, content-nya jadi bolong-bolong.
Kalau saya bikin terlalu kecil, terjadi layout shift.
Jadi mau gimana?
Jadi sedang saya research, jadi target saya saat ini sedang mengumpulkan data sendiri.
Untuk elemen-elemen tertentu.
Jadi saya bisa tahu embed itu apa, dari mana.
Nanti saya cari rata-ratanya berapa.
Layout shift bakal terjadi, tapi saya minimal kan.
Jadi masih itu.
Selanjutnya masih ada satu sisi site WatCamp Asia tanggal 17 Februari di Bangkok.
Jadi WatCamp Asia audiensnya 1800 orang yang sudah beli dikit.
Di Bangkok tanggal 17 sampai 19 Februari.
Jadi saya organizing, jadi organizer termasuk 2020 yang dibatalkan.
Sekarang 2023 akhirnya kita jalan lagi.
- Offline lagi? - Sudah setahun ini.
- Pertama kali offline berarti ya sejak?
- Enggak, kemarin. Kampat kan?
- WatCamp Asia 2020 itu sudah mau terjadi, tetapi dibatalkan karena pandemi hit.
Jadi Februari 2020, namun Desember 2019, pandemi kan.
Akhirnya semua di cancel. Sekarang 2023.
Dan mudah-mudahan doain, teman-teman semua doain supaya lancar.
Jadi kita bisa punya WatCamp Asia pertama kali di 2023.
- Wah, nanti bisa kita review ya. - Kenapa?
- Lo doang atau wakil Indonesia-nya banyak? - Ada 3 orang.
Saya, mbak Devin, yang organizer ya.
Saya, mbak Devin, dan satu mas Haris Rustiono dari Jawa Timur.
- Ada yang jadi speaker dari Indonesia? Pasti ada dong?
- Nggak tahu. - Tahu saya nggak ada.
- Semoga tahun depan. - Udah ada, belum ada.
- Udah tutup ya GFP-nya? - Sudah rangkum semua.
- Udah rangkum lagi banyak. - Udah sayap tahun depan.
- Tahun depan harus ada. - Harus dong.
- Iya. - Nah, yang nonton, siap-siap GFP buat WatCamp Asia.
Tahun depan siapa dari sekarang?
- WatCamp Asia bagi yang nggak dapat tiket, karena tiketnya udah habis.
Jadi jangan tanya saya. Udah habis dari kapan tahun.
- Oh, nice. Berarti apa? - Ada online-nya ya.
- Ada online-nya juga. - Jadi hybrid ya?
- Iya, ini gue kasih link-nya buat siya.wotcamp.org.
- Oke, sambil menunggu. Eka, gimana? Ada update apa nih? Kerjaan-kerjaan?
- Wah, lagi seru nih kerjaan. Jadi aku kerjanya tuh di sebuah NGO.
In-house, konsultan. Jadi maksudnya ngerjain satu produk doang sebetulnya.
Produknya itu semacam, ada user-generated kontennya ada,
static kontennya ada, tanpa iklan, karena ini lebih buat
ada unsur komunitas sama konten manusia.
monthly active user-nya nggak, apa, kalau active user nggak sebanyak, Ivan.
Hanya harian, setiap hari tuh di angka ratusan aja.
Cuma mungkin challenge-nya adalah timnya kecil banget.
Tim developer-nya itu kayak cuma sekitar, kalau yang loading, 3 orang.
Sama QA, UI/UX 1 orang, QA-nya 2 orang.
Apalagi timnya kecil banget dan kerjanya harus cepet banget.
Karena sering, apa, sebenarnya untuk funding,
kan nggak pakai iklan dan nggak menjual apapun.
Terus banyak berurusan dengan funding atau sponsor atau kerja sama.
Jadi sering harus iterate feature-feature, nyoba suatu feature.
Terus sedikit-sedikit ditambahin buat demo misalnya.
Atau mungkin untuk try out dengan pihak yang propose suatu feature.
Belum tentu develop sampai selesai, jadi kayak tek-tekannya
mesti selalu vigil.
Terus yang kalau belakangan ini, yang lumayan seru adalah
baru dapet kayak hand-over produk eksternal
yang di-develop oleh pihak eksternal, pokoknya kita nggak dikasih dokumentasi.
Cuma, maksudnya, di luar itu, beyond itu, nggak bisa tanya-tanya
ya pokoknya nggak ada kontak dengan yang bikin.
Jadi kayak, ya udah, harus mengadaptasi.
Dan itu emang produknya di semacam di hand-over.
Beberapa bagiannya mau diintegrasi ke produk tempat kerja aku.
Cuma ada yang disesuaikan.
Dan pusingnya kadang kayak tiba-tiba dapet codebase
yang dokumentasinya kurang lengkap.
Atau misalnya nggak pakai TypeScript sama sekali,
terus beneran library-nya mesti nyocokin.
Oh, nggak, di auto-update ke versi terbaru.
Jadi untuk ngecek dokumentasi, cross-check dokumentasi pun
mesti ngecek versinya berapa.
Ya, itu yang paling berkesan, yang belakangan sih.
Sampai mau nangis lah udah, handle JavaScript semua,
nggak ada type system, bahkan nggak ada JSDoc-nya gitu,
nggak ada JSDoc, sama versinya nggak tahu gimana,
nggak matching semua sama dokumentasi.
Rewrite, rewrite, rewrite.
Nggak bisa berburu-buru kejar tayang.
Iya, nggak tahu apa yang rewrite.
Ada beberapa bagian yang sukses dapet sign-off
buat bikin baru, pakai Astro.
Ada bagian yang emang setelah dicek,
itu reasonable bahwa daripada maksain,
terlalu banyak yang dimodifikasi dari versi lama.
Jadi kalau bikin baru, pakai stack yang pilihan sendiri.
Karena gua satu-satunya front-end, jadi bebas milih stack juga.
Asal bisa justify ke seluruh tim,
dan misalnya anggota tim lain mau edit,
atau mau bikin modifikasi minor, harus jelas.
Asal semua udah oke, ya udah.
Jadi sebenarnya agak random, agak wild-wild quest juga,
cuma seru.
Cuma seru, oke.
Tapi setidaknya ada dokumentasi, kan?
Atau nggak ada sama sekali? Ada, kan?
Nggak, kalau yang kayak data model, data base,
yang gitu-gitunya sih ada.
Cuma kalau udah yang di function-functionnya,
ya kayak isinya lah, kayak nggak ada testing,
sama nggak pakai jesdoc ataupun TypeScript.
Dokumentasi biasanya dikode itu sendiri katanya.
Kalau mau baca dokumentasi, baca aja.
Nggak ada, nggak ada komennya juga.
Nggak ada komen, nggak ada TypeScriptnya,
atau TypeSystemnya, nggak ada jesdocnya.
Jadi nggak ada interesting-nya.
Oke.
Nah, terus versinya bukan yang terbaru.
Jadi pas nggak buka, misalnya pakai LibraryX,
ya, bisa lah.
Mesti nyocokin sendiri.
Ya, ya, ya.
Lumayan latihan mental lah.
Latihan mental.
Udah coba pakai change GPT, rewrite my code gitu.
Belum minta kredit.
Belum minta kredit.
Masih gratis kok.
Tapi suka down, sering down malah, lebih sering.
Iya, karena gratis.
Oke.
Kalau saya nggak ada update berkait dengan coding-codingan sih ya.
Jadi agak ini juga ya.
Mungkin share sedikit lagi ya.
- Dimana update-nya soal ekosistem?
- Ecosistem. - Nah, ini yang penting.
- Iya.
- Kalau saya terakhir-terakhir ini lebih sering ngerjain
ada sesi foto.
Jadi nggak ada yang sama coding.
Sesi foto, terus juga besok hari Rambu
ada
hari Kamisnya, grand launching-nya.
Jadi persiapan ke sana.
- Kita diundang nggak nih?
- Boleh, silahkan datang.
- Diundang grand launching, ada makan-makannya nggak sih?
- Ada dong.
- Cuma, maksudnya sebagai coder, programmer
biasa coding, maksudnya dulunya biasa coding.
Terus sekarang kan kayak ngurus launching, blablabla,
mesti lebih banyak urusan sama manusia ya.
Daripada biasa ya, biasa ya sama layar, sama pixel.
Sekarang sama manusia, stres nggak?
- Stres sih nggak ya.
Mungkin ada fase adem-samasanya.
Kalau misalkan udah terlalu lama ketemu sama orang
bersosialisasi, mungkin ada stres juga,
paling cepat-cepat pulang, penginin diri, gitu kan.
Tapi di sisi yang lain lebih ke kangen sih,
kangen bikin produk, kangen coding, gitu.
Makanya ini kan, makanya banyak-banyak yang acara live streaming
kayak gini, ngobrol sama teman-teman yang masih
intens dengan coding gitu kan,
masih intens dengan produk, live streaming juga
buat belajar-belajar sendiri.
Karena di kantor udah, basically udah nggak coding lagi.
Ya, walaupun coding, mungkin lebih ke bikin use case lah.
Bikin misalkan contoh aplikasi untuk ngajarin orang
cara penggunaan state management misalkan atau apa gitu.
Jadi bukan real product.
Ya, jadi udah selama beberapa tahun terakhir ya,
begitulah pekerjaannya.
Meminangkan, cuman ada kangen juga ke programming,
bikin produk, bikin fitur.
- Berarti bisa kan dikonekin aja sama Eka.
Bantu aja Eka ngerewrite itu.
- Ya nggak bisa, kalau udah bantuin.
Ini apa, ini commitment waktunya kan harus ada.
- Nah, ini ada komentarnya nih, lebih enak coding.
- Tuh, lebih enak coding daripada debat. Benar, setuju.
- Nah, cuman ini kalau dari aku sih kerasa banget nih,
stand-up meeting kan pengen cepetlar ya,
biasanya terus iya-iya aja.
Cuman kalau lagi ngerjain produk atau fitur yang high velocity gitulah.
Terus banyak potensi buat miss.
Mungkin misscom, entah orang produk pengennya gimana
dari sudut pandang produk, dari designer gimana, dari kita gimana.
Kadang kita harus memperjelas dari sisi kita yang programmer.
Kita kan mungkin ada kecenderungan males jelasin ke orang
yang bukan perspektif coding ya.
Cuma itu kayaknya yang harus dibiasain sih.
- Iya, tapi meeting, ya nggak tahu ya, stand-up dan lain-lain itu
sebenarnya perlu juga kan buat koordinasi.
Kalau misalnya kan kita benar-benar kerja sendiri ya,
bukan kerja, menamanya.
Nanti itu dibahas. Yang satu bikin ini, yang satu bikin itu nggak nyambung gitu kan.
- Cuma mungkin biar nggak lama ya identifai aja bagian apa
yang "wah kayaknya kita abis ini perlu janjian mojok nih."
- Nanti sih stand-up itu jangan sampai bertela-tela pastinya.
Karena stand-up itu kalau saya ya, di tempat saya,
masimal itu 15 menit aja sih, nggak boleh.
Sebisa mungkin ya, kita jarang banget lewat dari 15 menit.
Jadi cuma kayak update aja, kayak temperature check yang ini, bagian ini.
- Ada yang blocking nggak gitu ya?
- Ada yang nge-block, nggak.
Kalau ke-block, hubungi siapa?
Atau nanti jadi extent item setelah stand-up, di-unblock gitu.
Jadi karena di stand-up itu kan kita dapat attention product owner.
Kayak full attention gitu.
Oh, masalahnya ini berarti nanti dikontekin sama bagian ads, contohnya.
Oh, si ini punya masalah ini, hubungannya sama desain.
Ternyata desainnya masih ke-block sama bagian approval.
Approval bagian whatever it is.
Belum di-approved.
Berarti nanti konteksi ini kejar atau langsung dia buka slide-nya, kejar.
Ini gimana update-nya? Udah, lanjut, next.
Jadi di stand-up itu dalam 15 menit, banyak hal bisa ke-unblock.
Daripada kita ngejar-ngejar secara asingkronos.
Oh, berarti ininya harus jago.
Apa namanya?
Yang mengatur, bukan mengatur ya.
Kayak striker.
Itu organizer-nya harus ini ya.
Iya, itu tugasnya PM kalau tempat saya.
Iya, istilahnya harus.
Dia harus berani nge-cut, omongan.
Misalkan udah terlalu panjang nih, langsung ditutup.
Oke, kita nanti ngomongin ini setelah meeting ini ya.
Kita ngumpul lagi beberapa orang.
Oh iya, iya.
Harus ada gitu kan.
Yang tempat saya, oke, kita sekarang sudah jadi kayak obrolannya sudah terlalu dalam nih.
Masa nya relevan, tapi udah makin deep.
Udah di group tertentu aja.
Udah di...
Bikin janji aja.
Jadi, nggak perlu kita bahas, terpisah.
Meeting terpisah.
Iya, harus ada yang begitunya kan.
Yes.
Oke, oke.
Nah, kita udah ngelantur sedikit.
Banyak sih.
Banyak.
Jadi, topik malam ini kita akan bahas tentang media penyimpanan atau storage ya.
Storage.
Yang di browser.
Ya, yang hanya di browser, tidak ngomongin database di sisi backend.
Kita nggak ngomongin Postgre, nggak ngomongin database SQL, NoSQL, dll.
Tapi yang hanya sedia di browser.
Nggak ngomongin hard disk, nggak ngomongin SSD juga.
Yes.
Atau MMC gitu ya.
SSD card.
Masih jatuh freeze tuh.
Luh.
Luh.
Iya.
Aduh.
Bentar, kayaknya mati lampu atau internetnya down.
Wah, iya masih freeze.
Oke.
Kita lanjut, teman.
Kita lanjut aja yuk.
Jadi, Eka gimana? Ada saya atau oh Eka aja yang lanjut?
Evan aja deh.
Oke.
Jadi kita kan mau ngomongin soal storage atau media penyimpanan yang ada di web.
Nah, media penyimpanan di web tuh kan ada beberapa.
Ya, kita coba buka media, ada beberapa dan yang paling sering itu,
kalau teman-teman sering dengar itu local storage atau session storage.
Session storage ada.
Saya coba share screen.
Oh, bisa share screen ya?
Bisa.
Oh, saya bisa share tapi kayaknya nggak bisa naikin ke,
hanya bisa Mas Liza yang naikin ke live.
Iya, emang gitu.
Cerita.
Ya betul.
Buka sendiri-sendiri deh.
Minggu lalu kan kita bahas cookies ya.
Cookies, iya.
Cookies itu juga sudah masuk storage.
Cuman cookies itu ada limitationnya kan.
Dia hanya bisa 16 kilobyte dan 16 apa 64 ya.
Saya lupa.
Size-nya terbatas.
Size-nya terbatas dan hanya bisa string.
Cuma bisa string sama satu lagi.
Apa, selalu karena fungsinya emang buat nyeimbangin apa,
kirim state ke server, selalu terbawa dengan request ya.
Di request.
Nah, ada storage yang lain.
Itu pertama, local storage.
Terus kemudian session storage.
Ada index DB.
Ada web SQL.
Cuma jangan pakai lagi web SQL ya.
Karena web SQL itu sudah.
Terutama malah ada yang namanya web SQL.
Ya, web SQL jangan dipakai.
Jadi nggak usah disebut aja.
Dan terakhir ada cache yang sering teman-teman.
Caching.
Caching. Kita pernah bahas caching nggak sih?
Cache itu kita pernah bahas sekilas waktu kita bahas service worker.
Kita bisa pakai service worker buat mencegat data yang masuk.
Disimpen dulu ke cache.
Buat misalnya yang paling sering kalau lagi offline.
Kita bisa serving dari cache.
Itu juga salah satu bentuk penyimpanan di browser.
Betul.
Jadi kita mau fokus ke tiga hal.
Local storage, session storage, dan index DB.
Dan apa fungsi-fungsinya.
Eka mau lanjut.
Kayaknya Eka ada beda.
Local storage dan session storage.
Dan kapan pakai local storage, kapan pakai session.
Nah, ini sih bagusnya kalau sambil buka artikelnya.
Cuma nggak bisa ya.
Intinya itu kedua hal itu masih bersaudara sih.
Jadi dalam arti API-nya sama sintaksnya dan segala macem caranya sama
antara local storage dan session storage.
Tapi sesuai namanya session itu ya cuma persis atau tersimpan di satu session.
Apa yang dimaksud session?
Ini session browser.
Jadi kalau misalnya tab atau window-nya ditutup, ya udah datanya ilang.
Jadi session storage itu cuma buat penyimpan di satu session browser itu saja.
Sementara kalau local storage, walaupun ditutup, dibuka lagi,
ya bakal ada terus sampai dihapus atau di clear secara manual oleh user.
Storage ini nempelnya di domain kan ya.
Di domain dan subdomain, ya kan?
Local storage itu nggak nempel di browser.
Iya, tapi benar.
Maksudnya local storage nempel di browser tetapi connect-nya ke domain.
Jadi kalau kita buka domain berbeda, storage-nya container-nya beda lagi.
Jadi hanya bisa diases oleh domain yang kita pakai.
Jadi kalau misalnya web.dev atau misalnya kita session storage-nya diset melalui web.dev,
maka hanya bisa diases datanya jika di website web.dev.
Waktu setiap kita buka web.dev sama seluruh part di dalamnya.
Jadi behavior-nya mirip cookie ya.
Termasuk subdomain, kalau nggak salah ya.
Nah, karena ada perbedaan nantinya.
Sebentar lagi akan muncul juga namanya shared storage.
Shared storage API namun masih on trial.
Jadi shared storage ini bisa diases dari domain yang berbeda.
Oh iya nih. Allow access to unpartitioned cross-site data.
Cross-site, betul.
Tapi status-nya masih apa ini? Pro-posal?
Masih origin trial ya?
Origin trial. Ini iniisiatif dari Chromium team.
Jadi diperkirakan masih Chromium only ya?
Untuk beberapa tahun ke depannya.
Kalau tidak diperjuangkan secara cepat, ya mungkin masih lama.
Tapi sepertinya ini pendapat pribadi.
Saat terpati cookies nanti sudah di-cut, maka hanya bisa akses data
untuk multiple cross-site hanya bisa lewat shared storage.
Dan ini sangat berguna bagi privacy.
Karena untuk bisa website, untuk bisa akses data yang ada di shared storage,
itu butuh konsen dari si pengguna.
Penerima, misalnya website A sama website B.
Berarti dua-duanya harus konsen ya?
Betul. Untuk data itu disimpan dan data itu bisa diambil.
Biar bisa terbaca.
Nah, dari local storage dan shared storage itu sendiri,
itu ada kasus yang menarik.
Jadi begini, studi kasus bagaimana kita bisa menggunakan storage di web.
Yang paling simple.
Zaman dulu saya pernah sedikit kesal sudah nulis email panjang-panjang
via web atau nulis panjang-panjang via komen di forum.
Ternyata waktu submit internetnya masalah.
Terus akhirnya harus refresh.
Yang tulisan yang kita tulis panjang-panjang itu hilang.
Ya kan? Pernah enggak teman-teman mengalami seperti itu?
Nah, itu kayaknya orang yang menginternetan jaman dulu tuh pasti, hampir pasti.
Nah, kalau sekarang, kita sudah jarang mengalami hal seperti itu kan?
Jadi kalau misalnya, contohnya teman-teman kalau developer pakai Jira,
pakai Basecamp, pakai apapun itulah yang project management.
Pakai Gmail.
Kalau misalnya sudah nulis, ada penubuhan, dia safe, dia safe, dia safe.
Dan ke mana dia safe?
Ya itu tadi, ke local storage atau di storage-nya di browser.
Jadi kalau di refresh atau di reload akan mengambil data dari storage yang di local tersebut.
Sehingga apa yang kita sudah tuliskan tidak hilang.
Nah, itulah gunanya storage.
Nah, implementasinya nih sering nih.
Maksudnya mungkin kalau sekarang kan lebih banyak orang pakai UI framework ya,
React, Svelte, sebagian, ya cukup banyak library yang sudah integrate dengan local storage.
Jadi kita enggak harus secara manual.
Ya, kalau mau manual, nge-sync ke, nyimpan, nulis ke local storage bisa.
Cuma banyak banget state management, yang library state management,
dan semacamnya yang otomatis membantu kita nge-save di local storage.
Jadi itu memudahkan banget.
Bahkan misalnya kalau kita pakai Svelte,
Svelte itu kan untuk state di level aplikasi, pakainya store.
Itu buat nge-sync ke local storage pun udah relatif mudah.
Berarti udah bisa ya, contohnya di framework-framework tertentu.
Jadi state yang tadi itu sudah bisa disimpan di storage.
Jadi waktu di-reload, dia akan...
Ya, otomatis dia baca.
Oh, nice. Saya belum pernah pakai Svetkey soalnya.
Ya, apapun sih, misalnya kalau pakai, bahkan vanilla JavaScript nih,
kayak state library misalnya nano-stores, itu ada add-on-nya.
Ada library tambahan, kita tinggal tambahin satu baris gitu lah,
buat otomatis nge-save ke local storage.
Menarik, menarik.
Ya, saya yang studi kasus yang paling gampang itu itu.
Jadi dengan adanya storage begini, itu sangat membantu buat teman-teman
kalau ingin membangun sebuah produk di atas web platform
yang bisa bekerja secara offline.
Karena anggap aja membangun aplikasi, tetapi aplikasinya nggak perlu internet.
Jadi cuma kayak contohnya, paling gampang itu anggap aja to-do list.
Jadi mau buat to-do list, saya ada sampelnya ya, to-do-mvc.com.
Jadi teman-teman silahkan nanti bisa lihat saya coba posting aja.
Bisa nggak sih saya posting? Gak bisa.
Gak bisa.
Iya, cuma bisa Mas Riza. Karena saya nggak tahu.
Iya, ada to-do mvc. Tuduh mvc.com.
Nanti teman-teman bisa ke sana.
Itu aplikasi to-do list sampel yang dibuat dengan segala macam framework.
Namun sebagai dasarnya disitu dia menggunakan local storage untuk menyimpan data.
Jadi anggap aja teman-teman kalau membangun sebuah aplikasi PWA,
bisa menggunakan misalnya PWA to-do list, terus simpan data di lokal,
di web storage-nya di aplikasi, di web.
Lalu bisa menggunakan antara local storage atau index DB.
Index DB nanti akan ada pembahasan yang lebih dalam lagi.
Jadi kan nggak perlu connect internet.
Jadi bisa work secara offline.
Dan teman-teman bisa tambah to-do list, bisa kurangin to-do list, bisa.
Ya bisa do apa pun lah. Bisa lakukan apa pun dengan to-do list-nya.
Nah, jika nanti suatu saat mau disinkron dengan online,
aplikasinya, jadi kalau misalnya internetnya mati, bisa tetap jalan.
Dan kalau internetnya online, apa yang ada tadi di local storage,
itu bisa disinkron ulang ke database yang ada di online.
Jadi akan membuat pengalaman dari pengguna,
aplikasi teman-teman itu bisa jauh lebih baik,
tidak tergantung terhadap kondisi internet.
Dan nggak bolak-balik ngebebanin database yang remote kali ya.
Jadi nggak bolak-balik harus nge-send.
Ya bisa dikontigur lah setiap berapa.
Entah setiap berapa detik atau setelah user menyelesaikan suatu task,
baru di-sinkronize ke remote database.
Nah, penggunaan.
Saya juga pernah singgung,
saya juga pernah singgung buat aplikasi yang untuk sales,
yang secara offline, yang pakai backbone,
jaman dulu pakai backbone, cuman aplikasinya...
- Yay, Mas Rizal. - Wey.
Ini namanya teknik apa? Delegasi.
- Ya. - Maaf ya.
- Gak apa-apa. - Terus tiba-tiba banget sih.
Ya, saya mau ini Mas Rizal, kita balik sedikit ke to-do MVC ya.
- Oke, to-do MVC. - Boleh, boleh, boleh.
Jadi tadi kita udah cover apa saja storage yang ada di web.
Misalnya cookies kita udah bahas minggu lalu.
Case kita udah bahas yang lalu.
Terus ada local storage, session storage, dan index DB, iya kan?
- Iya. - Nah.
Tadi ada kasus yang saya sampaikan, itu mengenai to-do MVC.
Ini menggunakan local storage.
Jadi to-do MVC ini sampel untuk to-do list
yang dipakai menggunakan segala macam framework.
Silahkan klik saja salah satu, Mas, kayak Vue.js atau apapun lah.
Ya, react mungkin kalau mau, klik aja yang react atau Vue.js.
- No guess. - Ya, boleh lah, klik aja.
Jadi apapun frameworknya tetap pakai teknologi local storage ya.
- Clear atau nggak, diinspect? - Ya, langsung diinspect.
- Oh, insert again, sir. - Insert dulu apapun.
- Test. - Webbing.
- Eat. Sleep. - Sleep.
Oke, nah, coba lihat sekarang diinspect element.
- Inspek element. - Di bagian application.
- Di bagian application. - Di bagian application.
Kemudian di--
Dia, kalau khusus untuk to-do MVC ini, dia pakai local storage.
- Local storage. - Ya, klik local storage.
Ada ininya ya, dia terapa?
- Domein. - Domein atau sub-domein.
Lihat tuh, ada key-nya. Jadi, local storage itu key value store.
Dan hanya untuk simple to-do di sini cuma satu key-nya.
Sisanya dia semua simpan sebagai objek di value.
Itu lihat, value-nya dibawah ada 0, 1, 2, itu.
Isinya code, eat, sleep.
Oke, berarti ini local storage ini bisa menyimpan objek JavaScript ya?
- Betul. - Nggak, sebetulnya stringing fight kan itu.
- Stringing fight ya. - Kalau kita baca,
kalau kita ambil value-nya itu sebetulnya stringing fight.
Tapi di browser DevTool untuk memudahkan kita ngebajak,
itu ditampilkan sebagai objek.
Tapi kalau dipanggil, hati-hati, stringing fight.
- Harus stringing fight juga ya. - Sekarang, Mas Riza, coba reload.
- Reload. - Reload di sini.
Harusnya kalau tidak kita nggak menggunakan storage, pasti value hilang.
- Betul, dihapus di sini ya. - Iya, coba dihapus aja, Mas Riza.
- Di-clean. - Hapus.
- Hapus, hilang ya. - Kita reload.
- Jadi area kosong lagi. - Yey, nggak ada kerjaan.
Terus aja kerjaan.
- Oke. - Mbak Ika mau lanjut apa tadi?
Kepotong, lanjut Mbak Ika.
Tadi sudah ada beberapa contoh penggunaannya.
Terus salah satu penggunaan yang cocok untuk local storage,
itu untuk hal-hal yang memang cukup ada di browser user aja,
memang cukup ada di client.
Jadi kan local storage itu kontras atau bersebrangan dengan cookies ya.
Kalau cookies, ukurannya terbatas, terus dikirim di setiap request.
Kalau sebaliknya, local storage kapasitasnya lebih besar
dan memang cuma di browser user.
Kalau favorit akuma, ini selalu buat misalnya dark mode, light mode.
Itu kan biasanya nggak perlu juga untuk dikirim atau ditempelin ke request kan,
karena berurusan dengan browser aja, client.
Jadi itu cukup reasonable buat disimpan di local storage.
Nah, terus ini ada komentar.
Shopping card ini melayah abu-abu sih, sebetulnya kalau menurut aku.
Antara shopping card itu mungkin beberapa, ya itu kan tergantung requirement-nya.
Cuma biasanya shopping card tetap perlu disink dengan database.
Karena misalnya kita browsing, kan sering tuh kita browsing suatu e-commerce,
kita masuk-masukin shopping card, tapi belum check out.
Nah, kan sebisa mungkin yang diinginkan adalah kalau kita buka di entah di device lain
atau mungkin setelah uninstall.
Kita buka dimanapun, itu shopping card kita kan tetap harus ada isinya.
Jadi kalau untuk level e-commerce atau marketplace yang reputable,
biasanya itu tetap harus di-store sih.
Bukan reputable, marketplace yang 360 yang ada di mana.
Bukan 360, jadi di semua device, di semua channel ada.
Kalau hanya web platform, mungkin kita bisa tetap pakai local storage.
Tapi kalau hanya web platform, kalau dia clear cache, terus dia buka lagi?
Kalau misalkan dibuka di mobile, itu local storage-nya nggak ikut kan?
- Iya, maksudnya dia buka di browser di laptop, atau browser di mobile,
atau HP-nya dia ada 2, kan sebisa mungkin shopping card-nya harus tetap sama.
Jadi biasanya shopping card-nya harus dikirim ke database remote.
- Tergantung use cache-nya juga ya, berarti ya?
- Ya cuma itu kan seberapa kompleks aplikasi kita.
To-do juga sebetulnya kan, eventually kalau misalnya kita bikin produk
yang udah cukup besar kayak jira atau apapun,
ya to-do list-nya kan nggak boleh di lokal doang, tetap harus disimpan di database juga.
Biar bisa dibuka dari device lain.
- Iya, case-nya adalah yang saya katakan tadi,
kalau misalnya kita sudah lagi nulis komen atau nulis sesuatu,
kalau di-reload, sebisa mungkin, maksudnya sebelum di-send atau sebelum di-kirimkan ke server,
di-cache dulu di local storage, jadi waktu kita reload, dia nggak hilang.
- Iya, bisa di-kombinasikan ya berarti,
antara local storage dan sync ke remote database.
- Iya, apalagi yang ngisi konten gitu ya, tulisannya panjang gitu,
kayak ngisi forum atau konten, artikel dan lain-lain ya, udah capai panjang-panjang tiba-tiba.
- Email. - Tiba-tiba peneksi.
- Salah satu cara untuk winning solution lah, paling cepat gitu,
kita hanyalahin aja local storage, simpan gitu.
Itu udah user experience si pengguna itu meningkat secara tajam.
- Betul, betul.
- Oke, lanjut, kita bahas apa lagi nih?
Tadi udah bahas local storage, storage, terus apa lagi?
To do MVC, index DB udah dibahas?
- Belum, belum. - Index DB belum dibahas.
Nah, index DB deh, next.
- Index DB? - Iya.
- Ini adalah yang ini ya, oke. Apa itu index DB?
- Index DB ini sebenarnya anggap aja seperti kalau teman depan tau,
pernah pakai, mungkin nggak sampai, SQLite lah.
Nah, SQLite tapi sudah ada browser.
- Behavior-nya kayak database beneran ya, bukan cuma value string
yang kayak local storage atau session storage.
Jadi dia perform, performanya bagus, sudah ada indexing key-nya sudah ada
dan bisa nyimpan data lebih banyak dan bisa lakukan SQL query.
- SQL query? - Sorry, bukan SQL query.
Bisa seperti key value stored ya, key value, tetapi lebih performance.
Nah, yang enaknya di atas index DB ini banyak yang sudah framework-framework
tambahan kayak PouchDB tadi.
Oh, PouchDB itu based on index DB ya?
Iya, PouchDB ternyata ada di sini ya, client site implementation of PouchDB
in the browser using index DB. Ternyata dia pakai index DB.
Tadi kita sempat bahas di belakang air.
Sama satu lagi ini Minimongo.
Minimongo.
Minimongo DB versi client yang ada di Meteor.
Iya, jadi bisa juga NoSQL juga bisa.
NoSQL kayak RxDB itu.
RxDB, iya.
Dia juga bisa pakai index DB di belakang air.
Jadi, dan ini bisa jadi kayak, NoSQL ini kita bisa, apa namanya?
Kayak observability-nya bisa, ini lho, bisa kayak kalau ada perubahan terjadi.
Di satu tempat, update semua.
Nah, dia support index, compression, dan replication.
Jadi seperti apa yang kita miliki, seperti punya database beneran.
Jadi kalau butuh behavior dan punya kemampuan kapabilitas database,
tapi pengen di browser, di client, takkenya index DB ya.
RxDB ini berarti dia tidak ada database di sisi backend,
tapi di client aja, di browser masing-masing.
Dan dia bisa syncing dan lain-lain gitu ya, peer-to-peer gitu.
Saya nggak tahu sampai peer-to-peer-nya, tetapi dia cross-tap kan, cross-tap itu artinya,
karena cross-tap kan artinya, maksudnya kalau tab-nya banyak dibuka,
kan index DB itu kan bukan kayak session storage ya.
Index DB itu nempel di domain.
Jadi semuanya bisa akses.
Dan misalnya anggap aja buka to-do list banyak, di tab,
terus update this app, diseluruhi yang lain, ke update.
Oh, oke, oke.
Jadi sempat udah kita bahas juga di belakang layar tadi sebelum mulai,
POSDB, ini adalah pasangan dari POSDB.
POSDB itu database di sisi server ya, di sisi backend.
POSDB ini untuk synchronize.
Jadi data yang ada di client itu kita bisa save tanpa harus ada koneksi internet,
mungkin koneksi internetnya naik turun atau nggak stabil gitu kan.
Atau debatchingnya setiap sekian detik aja kirinya.
Iya, betul.
Dan kemudian ketika internetnya sudah nyala lagi,
atau dalam waktu sekian detik atau sekian menit, dia akan synchronize ke server.
Dan ini, dia bikin library-nya udah satu set ya, berpasangan.
Jadi sintaksnya lebih user-friendly.
Selama ini sih ngeliat index DB,
kayak salah satu hal yang bikin aku nggak terlalu suka,
nggak terlalu tertarik sama index DB itu, kayak penggunaannya, sintaksnya segala macam.
- Sintaksnya kurang ya? - Ya, sebetulnya nggak jelek-jelek amat sih.
Maksudnya udah cukup modern, cuma kayak tetap nggak menarik aja sih.
Kayak lebih tergoda ke superbase atau semacamnya yang udah ada SDK-nya,
ya udah sekalian pakai itu.
Cuma ternyata underlying technology-nya kan tetap penting bahwa,
yang penting konsepnya itu adalah kapabilitas database dengan segala fungsi-fungsinya,
transaksi yang ala database tapi di browser.
Jadi, solusinya ya ini mungkin semacam PouchDB ini kan enak banget tuh kan sintaksnya.
Nah, yang membedakan antara local storage dan index DB,
index DB itu karena bisa indexing, dia lebih performance.
Performance-nya lebih baik daripada local storage.
- Karena local storage itu cuma keyfairing. - Keyfairing aja ya, keyfair listore kan.
Jadi apa aja bisa disimpan, jadi nggak bisa di-structure ya.
Kalau di index DB itu lebih bisa di-structure.
Ini API-nya dia mengikuti gayanya si CouchDB ya.
Jadi, ini ada layer di atas si index DB.
Wujung-wujungnya didulis kayak index DB juga.
Sama halnya dengan Minimongo. Minimongo ini adalah database yang ada di sisi klien,
yang digunakan di framework namanya Meteor.js.
Dan API-nya itu menyelupai cara penggunaan MongoDB di server.
Dan dia bisa sincronis juga, mirip seperti PouchDB.
Nah, itu malah seru tuh, local storage iya, index DB iya, si Minimongo itu.
- Iya. - Back to my local storage.
Tapi pakai index DB juga.
Iya, dia kayak gini aja nih, misalkan nih.
Ini local DB terus add collection, upsert atau update, dan insert gitu.
- Kayak Minimongo. - Kayak Minimongo DB.
Iya, bener-bener mirip, dibuat mirip.
Kayak udah terbiasa dengan, kerja dengan Minimongo DB.
Jadi kita hanya perlu safe di sisi klien.
Nanti dia seru otomatis MongoDB-nya atau Minimongo-nya akan melakukan sincronisasi dengan server.
Kira-kira seperti itu.
- Ternyata bukan berat lagi. - Biasanya ada...
Biasanya ada kasus juga pernah menghasilkan.
Tapi sebelum jamannya ada Minimongo, PouchDB, segala macam,
itu yang membuat aplikasi yang menggunakan elektron,
buat sales yang bisa untuk aplikasi bisa bekerja secara offline.
Nah, saat itu saya pakai storage-nya pakai index DB.
Jadi sedot data dari server, file image-nya saya simpan di lokal.
Bukan pakai Vasis CPI, cuma kayak lokal aja, hard disk.
Dan database-nya pakai index DB.
Jadi kan dia nempel di elektron, cuma lokal pos, blablabla.
Jadi nempel, update, sudah.
Jadi begitu laptop-nya dibawa ke tempat klien yang butuh jualan,
karena dia kayak produk katalog, nggak butuh internet.
Jadi semua langsung bisa presentasi.
Jadi kayak terima order, ini katalognya A, B, C, D, tinggal di-search.
Bisa search juga loh. Yang ini dah catat jadi duit, dah.
Limit lebih nggak ada? Limit size-nya?
Ada, pasti ada kan?
Iya, pasti ada kan.
Tapi gede banget loh, saya nggak tahu, coba saya baca dulu.
Kayaknya gede banget loh, gede banget.
Berarti kasus yang tadi ceritakan ini sekaligus menjawab pertanyaan dari Mas Munawar.
Masih relevan nggak sih, website dashboard sekaligus dia datanya terlalu saja?
Nah, ya itu tergantung use case-nya kan.
Nah, oh iya, salah satu kelebihan index.db juga kan,
kalau local storage, atau session storage, atau cookie kan,
nggak bisa nyimpan file blob ya, B-L-O-B, binary large object.
Nah, kalau index.db, karena dia full feature database, bisa buat nyimpan blob.
Ini saya Google sebentar sedikit, untuk maximum size index.db itu
kalau di Chrome-based browser, Chromium-based browser,
dia bisa pakai 80% dari disk space.
Jadi kalau punya 1TB, ya bisa 800GB.
Iya, kan harus dikonsiderasi...
Cuma harus hati-hati juga, berarti kita... Karena masing-masing client beda kan?
Masing-masing client beda.
Ya device user juga beda, jadi berarti kalau kita bikin transaksi,
harus jangan lupa nge-catch ya.
Betul. Nah, selanjutnya, tadi setelah local storage,
ada session storage, kemudian index.db,
selanjutnya kalau misalkan masih berasa kurang powerful,
nah, ini ada sekarang kita sudah bisa menggunakan SQLite
di browser dengan menggunakan WebAssembly.
WebAssembly ini kayaknya bisa ngapa-ngapain aja ya,
sampai bikin sistem sendiri juga bisa.
Waktu dulu kita pernah bahas Figma ya?
Iya, Figma.
Figma sama apa? Codespaces.
Nah, ini kali ini bisa bikin rantai database berarti,
ngejalanin SQLite.
Betul.
Kemarin saya tunjukin WordPress bisa jalan di browser,
pakai SQLite database ya.
WordPress bisa jalan di browser kan.
Gak usah pakai XAMPP lagi ya?
Gak usah.
Gak usah install lagi gitu ya.
Jadi SQLite ini adalah salah satu database yang mungkin underrated ya,
kalau bisa dibilang ya.
Jadi kalau temen-temen nih misalkan, wah, pengen belajar SQL,
tapi terbatas device misalkan,
wah, gak bisa install macem-macem nih,
mau install Postgreel gak bisa,
ngasih SQL susah gitu misalkan,
dibatasi antara terbatas mungkin sistem requirementnya,
atau mungkin gak boleh install macem-macem di laptopnya gitu kan.
Atau pengen cepet aja.
Betul.
Nah, kalau apa, mungkin bisa melirik si SQLite ini,
karena SQLite ini ya,
bedahannya hanya satu file, kemudian udah.
Tidak ada apa,
kalau misalkan kayak Postgreel mySQL gitu,
dia ada di install dulu kan,
di install, terus ada di folder apa,
di dalamnya ada sub-folder-sub-folder lagi gitu kan.
Kalau SQL ini cuma satu file,
kita tinggal buka SQLite 3 spasi 6 file-nya udah.
Dan kita bisa menjalankan atau belajar SQL.
Semua transaksi SQL.
Iya, semua sintak SQL bisa dicoba di sini.
Jadi ini salah satu database yang cukup,
sebenarnya cukup banyak yang digunakan ya.
Di handphone semua temen-temen,
mau OS-nya apa, pasti itu ada SQLite.
Kalau di kalangan front-end developer nih,
SQLite naik-daun gara-gara remix,
apa, framework remix,
ini by default semua tutorial-nya,
dan semua kayak starter site yang paling basic,
demonstrate-nya pakai SQLite,
tapi kita bisa replace mau pakai Postgreel,
atau pakai apa lah, yang lain bisa.
Cuma by default, contoh-contohnya pakai SQLite.
Jadi di kalangan orang yang mungkin para developer
yang mungkin belum terbiasa pakai database,
nggak punya Apache, nggak punya segala macam,
ini SQLite ngebantu banget.
- Yes. Dan sekarang,
kalau misalkan merasa index DB kurang powerful,
sekarang kita bisa menjalankan SQLite di sisi browser.
Jadi dengan menganfaatkan WebAssembly,
SQLite-nya itu bisa jalan di browser,
jadi kita bisa, apa ya,
kalau misalkan bikin tutorial SQL yang interaktif,
website gitu, aplikasi web yang interaktif
untuk belajar SQL.
Itu bisa perlintah SQL-nya,
bisa dieksekusi di SQLite, di browser,
nggak perlu diinstall macam-macam.
Tapi ada balasannya ya, nggak bisa sampai,
kalau nggak salah,
SQLite bisakah sampai group by?
Bisa ya? - Bisa, bisa, bisa.
Dia udah full support SQL ANSI, kalau nggak salah.
Pokoknya udah standar lah, standar SQL itu udah bisa.
- Cuma ini sih repotnya kalau kita pakai serverless,
SSR serverless, semacam remix, atau Next.js,
itu nggak bisa sembarang nimpah file-nya
kalau udah dari remote sih.
Misalnya kita pakai Next.js atau remix gitu
yang udah CICD,
yang misalnya kita nge-deploy, nge-push ke GitHub,
ke repo, terus dia otomatis nge-build di lambda function,
itu kelihatannya nggak bisa deh, nggak bisa.
Jadi gatasnya di situ.
Kalau mau ya, kita harus... - Bikin server sendiri, tetap ya.
Atau yang gampang, jalanin transaksinya di lokal,
baru di-push lagi. - Oh, iya, iya, iya. Benar, benar.
Nah, ternyata si SQLite ini menganfatkan sebuah web API
yang namanya file-system. - Lah, balik ke file-system berarti ya?
Balik ke file-system karena
file-system ini yang membuat dia bisa berjalan, karena ya itu.
Jadi dari apa?
Mungkin buat teman-teman yang nggak familiar dengan file-system,
kalau ada yang pakai Figma,
mungkin developer jarang ya, pakai Figma ya.
Kalau dulu kan...
Karena desainnya hand-overnya di Figma.
Oh, hand-overnya lewat Figma ya.
Kalau dulu kan Figma itu,
kalau misalkan kita mau save file, itu kayak download kan.
Download file Figma kan.
Begitu kita mau load, juga kita kayak upload file-nya kan.
Nah, dengan adanya file-system itu udah perlu seperti itu.
Jadi dia bisa membaca folder yang ada di lokal komputer kita.
Tentunya dengan permisihan tertentu ya, pasti ada ininya ya.
Jadi native file-system API sudah didukung oleh browser,
dan API ini yang dimanfaatkan oleh SQLite untuk meletakkan
file data SQL-nya di folder atau di lokal komputer kita.
Makanya dia batasannya lebih besar dibandingkan sama yang tadi apa,
index DB atau lokal storage dll.
Karena dia sudah berada di lokal,
sudah berada di komputer kita masing-masing.
Nah, ini tuh udah didukung semua browser,
atau masih Chromium-only, atau gimana ya statusnya?
Mari kita lihat.
Coba paling bawah biasanya.
Masa sudah official sudah ini.
Tapi ini masih Chromium deh.
Gak ada ya di sini.
Kita buka Can I use ya?
Can I use.com
File, API.
Belum bisa, Safari dan Firefox belum bisa, sayang sekali.
Mana? Ini aja.
File API, bukan ya?
Bukan, file system.
Oh, file system.
Oh, masih kuning dan merah ya.
Itu tuh file system dan file writer.
File system access, oh ini.
WebKit support with prefix.
Kok WebKit? Oh, mati.
Duh, tapi sharing-nya bisa. Nah, aman.
Ini Safari, merah.
Firefox.
Firefox mana? Oh, merah juga.
Itu kan file system.
Kalau file system API, yang bawah gimana coba?
Yang bawah, awal lagi.
Berarti, udah bisa.
Berarti yang...
Jadi ada beberapa API-nya masih belum bisa,
tapi kayaknya yang file system API-nya, core-nya udah bisa.
Yang file writer-nya yang belum bisa.
Saya nggak tahu perbedaannya.
Belum bisa nulis ya.
Tapi saya nggak tahu itu apa.
Mungkin kita perlu baca, mungkin topik selanjutnya kali.
Ya, file system.
Return of reading and writing file to a sandbox file system.
Belum pernah dengar saya malah.
Menarik.
Banyak ya. Ada sync juga.
Ada file system entry.
Apa ini? Beda-beda ya?
Kayaknya dipecah kelasnya gitu biar granular.
Jadi ada yang bisa read aja,
ada yang sudah bisa read and write gitu ya.
Lebih step-by-stepnya, lebih kelihatan gitu kali ya.
Cuma kalau dilihat-lihat, berarti sepanjang yang semua kita bahas tadi,
yang paling aman udah ada di semua browser,
berarti kan local dan session storage sama index DB ya.
Yang udah paling stable dan udah lama bertahun-tahun ada.
Dan index DB juga udah banyak ini ya.
Library dan layer di atasnya.
Jadi kalau misalkan merasa index DB kurang menarik,
mungkin bisa cek kayak pause DB.
Mungkin pause DB harus connect sama pause DB ya.
Yang lain-lain ada banyaknya.
Nggak juga sih.
Jadi nggak perlu connect.
Oh, kalau mau syncing baru ya, oke.
Jadi tetap bisa digunakan walaupun tidak ada server kaos DB-nya ya.
Kalau nggak perlu sync ke remote database ya nggak usah pakai.
Tapi pertanyaannya apakah masih...
Iya tadi pertanyaan tadi.
Kalau Ivan tadi kayaknya nemuin ya,
ada satu kasus di mana semua aplikasi tidak membutuhkan server.
Jalan di elektron, semua teknologi web tapi offline.
Termasuk database-nya.
Itu kasus yang umum nggak sih di aplikasi jaman sekarang gitu?
Kalau aku pribadi belum pernah harus yang kayak gitu sih.
Jadi biasanya malah cuma perlu local atau session storage aja.
Ya kayak tadi buat handling misalnya user udah ngetik panjang-panjang
biar tetap safe.
Habis itu ya remote database biasa sih.
Jadi belum sejauh ini.
Biasanya aplikasi yang produk yang bisa offline mode.
Itu lebih perlindung.
Terus ingat juga ya, web worker dan service worker itu kan nggak bisa akses DOM.
Jadi perantaranya middlemanenya ya ini, si storage-storage ini.
Jadi anggap aja kalau misalnya teman-teman punya aplikasi
yang bisa fetching data dari online, tetapi jangan diakses melalui main thread.
Bisa di alokasikan, didistribusikan menggunakan web worker untuk ngambil data
synchronize ke index DB.
Nanti index DB-nya berubah, data-nya berubah.
Otomatis UI-nya berubah.
Betul. Contohnya misalnya teman-teman mau bikin spreadsheet.
Spreadsheet tabular data yang besar gitu ya.
Yang mau disinkronkan ke aplikasi yang lain secara real-type.
Jangan pakai main thread.
Karena kalau pakai main thread, kalau lagi synchron, spreadsheet-nya ngefreeze.
Jadi pakai web worker.
Bisa digabungkan dengan web RTC.
Bisa pakai web RTC. Jadi dari peer-to-peer.
Itu kayak Pub/Sub ya?
Mirip Pub/Sub.
Kayak torrent.
Jadi bisa konek ke, jadi contohnya kita ambil spreadsheet ya
yang diakses secara berbanding secara tiga orang.
Jadi web RTC sesama tiga orang.
Yang konek ke web RTC ini menggunakan jika ada update baru,
simpan dulu si web worker yang akan mengupdate ke index DB, contohnya ya.
Jadi index DB-nya, kalau terjadi perubahan di index DB,
kan tadi si library-nya ada observable-nya kayak gitu,
bisa dilihat perubahannya apa.
Dan si UI-nya kita tinggal melihat perubahan itu,
event itu didispatch, terus kemudian value-nya keupdate.
Itu bisa seperti itu juga.
Jadi aplikasinya bisa tetap performance, index DB-nya performance,
jalur koneksinya via web RTC atau kalau misalnya online,
bisa lewat web worker.
- Tapi worker class berarti bisa berinteraksi sama index DB langsung ya?
- Bisa. - Mantap.
Kan soalnya worker class, entah itu web atau service worker,
kan dia nggak bisa mengakses local storage ya,
karena itu masuknya di client site, di browser, nggak bisa mengakses langsung.
Local storage bisa sepertinya ya, local storage bisa.
- Bisanya mengakses cash kelihatannya, belum ngecek.
Penasaran gitu, kan service worker.
Kalau cash bisa, memang worker bisa interaksi sama cash.
Oh, nggak bisa.
Gak bisa? - Iya, lanjut. Local storage nggak bisa.
- Local storage nggak bisa, oke.
Ini pertanyaan lanjutan dari Damar.
Eskilite yang di browser yang tadi ya.
Jadi kalau misalkan nyimpen data, pakai file system API,
tapi bikinannya, bikinnya file XML supaya bisa mudah di-share.
Bisa. Eskilite bisa nyimpen file kan, blob ya, jadi bisa.
Possible. Jadi XML-nya disimpan di database gitu maksudnya.
Bisa? - Bisa, bisa.
- Ada pertanyaan satu lagi ini menarik juga.
Jadi dia ini Nian JS.
- Koceng.
- Iya. Masih bingung karena ada satu artikel yang bilang
kalau JWT itu aman disimpan di local storage.
Tapi di artikel yang lain, simpannya di session storage.
Lebih baik mengenak simpan token JWT di sini maksudnya ya.
Itu lebih baik disimpan di local storage atau di session storage.
- Bahkan ada yang bilang, Pak, kalau token ya,
kalau contain data yang sensitif, jangan disimpan di browser.
Cuma itu tergantung lead, team lead kalian masing-masing.
Ada yang bilang itu nggak accept kalau nggak boleh di client side,
nggak boleh di browser sama sekali, harus di cookie.
Dan cookie pun ada aliran pemikiran ya, harus HTTP only.
Maksudnya hanya bisa di server side, di request.
Jadi di handle di sisi server, nggak bisa dibaca dari document.cookie.
Cuma ya, kalau pun di local atau session storage,
sebenarnya satu-satunya perbedaannya kan
cuma session storage itu kalau tab-nya ditutup, hilang.
Jadi nanti kalau browser buka tab baru, misalnya tadi udah login.
Terus user nutup tab, buka tab lagi, dia terlockout.
Jadi itu behavior yang diinginkan seperti apa.
Gitu doang sih bedanya, antara local dan session.
- Kalau JWT ya, JWT itu kan sebisa mungkin,
payload-nya itu kan bisa dibacakan cuma base 4.
Sebisa mungkin itu kan isinya cuma data umum,
dan data validasinya itulah yang kan ada private key
yang nggak boleh di-share kan, yang untuk bisa ngevalidasi hash-nya itu.
Sebenarnya JWT itu bagi saya, pendapat pribadi,
nggak apa-apa sih disimpan di local storage, nggak masalah.
Karena itu membuat supaya aplikasi kita bisa berhubungan,
divalidasi koneksinya ke server.
Namun, sebisa mungkin pertama di sisi server validasi,
dari sisi hash-nya harus bisa divalidasi, dan timestamp.
Timestamp itu juga penting divalidasi.
- Tapi harus di-handle dari server-site ya, dari API.
Dari API atau apapun itu service buat apa, urus authorization.
- Betul.
- Iya, karena kalau apa-apa disimpan ke database,
kasian database-nya.
Berat ya, nulis database itu bukan pekerjaan ringan gitu ya.
Walaupun kalau kita simpan kayaknya cepat gitu.
Tapi kalau sudah 100 orang secara simultan kan berat gitu kan.
Dan istilahnya membutuhkan biaya yang sangat besar juga gitu.
Makanya kalau misalkan setiap kali request harus nge-check ke database,
itu nggak efisien juga kan.
Yang penting datanya itu tidak bisa dibongkar,
kalau hanya token-nya doang kan nggak ada informasi yang bisa di-extract dari situ kan.
Nah, kalau dapat hash-nya atau dapat salt-nya, itu baru.
- Tapi itu pun tetap harus siap invalidate.
Yang penting itu semua bisa segera di-invalidate
kalau terdeteksi ada kecolongan.
- Ya, kayak timestamp tadi, jadi harus ada time-out-nya berapa lama gitu ya.
Masa berlakunya, expired-nya berapa lama.
Kalau udah expired, coba dihapus lagi cookie-nya, login lagi, dan lain-lain.
Nah, ini juga pertanyaan yang bagus tuh.
Sebenarnya web platform PWA ini udah powerful buat storage.
Apa masih ada lahasan untuk pakai elektron atau tauri?
- Nah, gimana tuh? Belum ada pengalaman pribadi sih buat compare yang head-to-head.
- Kalau sebenarnya saya sekarang preferensinya nggak pakai elektron lagi.
Jadi sebenarnya udah murni langsung menuju web aja dan web-nya dipatahin service work dan PWA.
Itu defaultnya.
Kasus yang saya bilang pakai elektron itu karena itu adalah proyek 6 tahun lalu.
PWA itu masih di awang-awang.
Sudah ada tapi belum oke.
- Belum ada desktopnya, kayaknya belum terlalu ini kan?
- Desktopnya belum di-support kan? Baru akhir-akhir ini kan?
- Baru-baru. - Akhir-akhir ini baru ada.
Jadi, alasan untuk elektron.
Mungkin kalau buat aplikasinya sekelas text editor, maybe ya, kayak atom.
- Ya, atom. Atau udah mendinggal. - VSCode lah.
- VSCode lah, VSCode ya. Seperti VSCode, mungkin masih butuh elektron.
Karena butuh build-in browser. Jadi waktu kita...
Distribute able-nya kita itu waktu kita kasih ke user, mereka nggak perlu install browser lagi.
Sedangkan kalau kita PWA, mereka butuh install browser kan.
- Itu yang dialami.
Jadi misalkan saya pakai, sekarang sering pakai misalkan kayak xkaldraw atau pake tldraw dan lain-lain.
Itu kan PWA ya.
Kita mau buka aplikasi desktop-nya, kita harus buka browser-nya.
Misalkan saya waktu install aplikasi di desktop-nya itu menggunakan Brave.
Tapi sehari-hari saya menggunakan Firefox misalkan.
Lagi buka Firefox tiba-tiba mau nulis-nulis, itu kan menyata buka xkaldraw, buka lah itu Brave.
Jadi dia buka Brave dulu, baru dia buka aplikasinya.
Jadi itu yang mungkin ada kasus dimana ya memang harus desktop.
Harus desktop apps ya, elektron atau tower yang bisa menyelesaikan masalah itu mungkin ya.
Tapi kalau nggak masalah, browser-nya kebuka di belakang layar ya nggak ada masalah sebenarnya menggunakan PWA juga.
Oke, kita sudah satu jam. Masih ada yang mau didiskusikan lagi?
Oh, ini Dito. Dita, Dita.
- Wow, ada yang notice kita nggak lah. - Ada yang notice ya.
Mohon maaf ya, kita absen sehari, sehari seminggu.
Satu minggu tidak bersuai ya.
Dita ini adalah GDG Makassar ya.
Yang kemarin ngajakin makan ikan fugu Indonesia.
Wah, sepertinya sudah tidak ada lagi topik yang mau kita diskusikan, kalau begitu mungkin kita udahan dulu.
Terima kasih banyak buat semua teman-teman yang sudah menemani diskusi kita malam hari ini. Cukup seru.
Maaf tadi koneksi jadi tiba-tiba mati dan menghilang sebentar, berapa lama.
- Iya. - Mudah-mudahan tidak terjadi lagi.
Maalum koneksi saya cuma satu, nggak kayak Ivan, ada redundansinya.
Lepikasi. Loh, redundansi, redundan.
- Load balancer, nggak bisa ya. - Load balancernya, jadi ada dua provider kan.
- Ada satu. - Callback. - Sebenarnya ada gue sih, cuman lagi di PC nggak ada Wi-Fi.
- Satu juga mati. - Gak bisa titeri, jadi bingung.
- Begitu lagi harus beli Wi-Fi, dongle. - Bekabel.
Oke, kalau gitu terima kasih banyak sekali lagi buat diskusinya seru-seru.
Jadi mudah-mudahan kita ketemu lagi minggu depan di jam yang sama, di hari yang sama,
di selasa malam jam 8. Kalo takut ketinggalan, subscribe aja.
- Jadi nanti bisa... - Pencet lonceng.
Ya, ada pencet loncengnya.
Kalau ada yang mau ditanyakan lagi, di luar sesi live, teman-teman bisa ke bit.ly/nobrolinweb
Atau ke sosial media kita masih mesti tanyain aja, nggak apa-apa, di DM atau di Twitter dan lain-lain.
Oke, kita mamit. Terima kasih banyak buat teman-teman semua.
Mudah-mudahan minggu depan kita ketemu lagi dengan topik-topik yang menarik lagi.
Dan tetap di tunggu topik-topik menarik lainnya. Jangan sampai kita menggunakan CTPT untuk...
Terima kasih, selamat malam. Sampai jumpa lagi. 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
17 Nov 2022
Ngobrolin CSS
Episode ini berbenang merah CSS, dari sumber belajar sampai fitur yang baru saja tersedia. Dibuka dengan menjawab pertan...
17 Nov 2022
Ngobrolin Web Episode Perdana
Episode perdana Ngobrolin WEB, dibuka dengan perkenalan tiga pembawa acaranya: Riza, Eka, dan Ivan. Formatnya sengaja di...
22 Nov 2022
Ngobrolin Viteconf
Episode ini membahas Vite dan ViteConf yang baru saja digelar. Dimulai dari pertanyaan mendasar: kenapa kita butuh bundl...
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 .