EP 76

Ngobrolin Cache - Ngobrolin WEB

Bagikan:

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://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.

Ringkasan Episode

Bantu Koreksi

Episode ini membahas topik caching secara komprehensif mulai dari konsep dasar hingga implementasi praktis di berbagai layer aplikasi. Diskusi dimulai dengan analogi dompet dan penjelasan tentang sejarah caching dari hardware (L1, L2 cache) hingga implementasi di software. Pembahasan mencakup multi-layer caching yang mencakup DNS cache, client cache (browser), CDN caching, web server caching, application caching, hingga database query level caching. Episode juga menyinggung perubahan lisensi Redis dari BSD ke RSPL dan dampaknya terhadap industri, serta membahas strategi cache invalidation dan tantangan dalam mengelola cache di sisi client yang berada di luar kontrol developer. Episode lebih lanjut membahas berbagai strategi cache update untuk traffic tinggi seperti stale-while-revalidate, cache update melalui endpoint tersembunyi, dan penggunaan cron job untuk memperbarui cache secara berkala. Diskusi juga menyentuh konsep memoization di React (useMemo), opcode cache di PHP, dan perbandingan antara teori normalisasi database dengan praktek denormalisasi di dunia kerja yang lebih mengutamakan performa. Topik Big O notation dan time complexity juga dibahas dalam konteks memilih operasi Redis yang tepat untuk performa optimal.

Poin-poin Utama

  • Caching adalah metode menyimpan data sementara untuk membuat aplikasi lebih cepat dan service lebih ringan secara finansial
  • Multi-layer caching mencakup DNS cache, client cache (browser/local storage/session storage), CDN, web server, application, dan database query level
  • Redis sering digunakan untuk object level caching karena kecepatannya dan cocok untuk centralize session di lingkungan dengan multiple web servers
  • Cache invalidation di sisi client sulit dikontrol karena berada di luar kendali developer, memerlukan strategi seperti tombol reload atau service worker update
  • Strategi cache update untuk traffic tinggi meliputi stale-while-revalidate, endpoint tersembunyi untuk revalidation, dan cron job untuk update berkala
  • Opcode cache di PHP menyimpan kompilasi kode di memori untuk menghindari kompilasi ulang, membuat eksekusi PHP 8 jauh lebih cepat
  • Memoization di React (useMemo) adalah bentuk caching frontend yang mengingat hasil komputasi berdasarkan input untuk mencegah re-render yang tidak perlu
  • Denormalisasi di dunia kerja sering lebih dipilih daripada normalisasi murni karena storage sekarang lebih murah dan performa lebih prioritas
Transkrip Bantu Koreksi

0:00selamat malam semuanya

0:15apa kabar semoga sehat-sehat puasanya lancar ya Amin ya sudah hampir-hampir di akhir-akhir ya

0:26Biasanya kalau udah dekat akhir itu

0:30Gembira apa

0:31Kok ya habis deh

0:34Ramadannya gimana

0:35Apa tuh biasanya

0:36Iya biasanya sedih sih

0:38Atau dua

0:40Bercampur aduk

0:41Kompleks

0:43It's complicated ya

0:46Kalau di kantor bisa makin lama makin sepi ya

0:51Mulai banyak yang

0:52Nyolong cuti dulu

0:54Ini teman-teman sekarang

0:56sudah cuti THR sudah cair atau belum atau ada yang sudah berpindah ke kantor yang baru biasanya ya

1:08musim-musim ini ya habis THR ya habis lebaran cabut migrasi-migrasi biasa sih Iya Halo Torik

1:19Hai apa kabar ya story jadi mana kabar Surabaya Surabaya mudah-mudahan eh Surabaya bakal banyak

1:29acara nih bakal ada acara bekerja Hai uh terus biluidea ya Iya ada ada workshopnya juga ya kalau

1:38ya sudah lama nggak dapet HR Wow self-employed Oh iya kalau itu berarti antara freelancer Iya atau

1:53gajinya dolar di luar kayak Ivan tuh THR dia dollar lagi dollar lagi naik loh 15.900 15.900

2:04sekarang waduh mengkhawatirkan sebenarnya mengkhawatirkan tapi kalau ini tergantung

2:11kalau yang dapat gaji dolar dirupiahin sekarang berarti lumayan ya lagi biar naik marginnya

2:18lumayan ya iya iya iya sama aja value-nya nanti dia udah munculnya bahannya naik juga inflasi

2:26Iya. Kalau Ivan atau Eka gitu yang tidak merayakan lebaran, apakah ada THR di Natal atau Tahun Baru?

2:36Gak ada juga ya? Jadi normal aja?

2:38Kalau zaman, kalau saat.

2:40Gak ada THR masalahnya.

2:43Kalau zaman.

Lihat transkrip lengkap

2:44Kalau Natal Tahun Baru nyepi.

2:47Waktu kerja di company Indonesia dapatnya di, bisa milih, bisa milih.

2:53Bisa milih, iya, iya, iya.

2:55bisa ada alternatif bisa di tahun baru Khabisat bisa di tahun baru China

3:03boleh boleh boleh tergantung tergantung tergantung bosnya ya kan kalau bosnya

3:11Chinese ya bisa bisa milih di Imlek iya iya itu kalau biasanya pusing sih

3:17yang non-programming cuma dua sih pilihannya cuma pas Natal atau lebaran lebaran waktu go

3:26waktu gue punya waktu saya punya company justru lebih Happy Mas Iya nggak semua numpuk di lebaran

3:35nggak semua numpuk di lebaran Iya gitu duitnya jadi bisa Iya jadi ada jadi bagian waktu dulu

3:43sudah yang kita ngasihnya di Natal dan tahun baru ada juga yang mau diimlek ada di lebaran jadi

3:50bisa bisa lebih tiga itu nggak ada minta di satu Muharam lagi kan kalau minta lagi satu Muharam

3:58pusing kita waisat dengan orang yang gak lebaran pun perlu apa perlu extra cashnya pas barang karena

4:06misalnya ngasih THR ya maksudnya kalau itu sih di kantor yang dulu kayak terserah hapo turun sekali setahun confirm dulu beforehand tapi ngomong soal THR dan company itu mirip dengan topik kita kali ini cashing

4:25anggap aja duit kita tuh cash gitu ya cash cash cash cash cash cash cash cash cash cash cash

4:39ini sesuai sama topiknya ini juga lompat lewat kan betanya Iya jadi itu analoginya adalah dompet

4:49Iya dompet kalau ada diambil kalau enggak ada ke bank atau ATM Iya kalau enggak ada tarik dulu

4:57di ATM kalau ada dipakai itu bener kan sekarang zaman sekarang udah cashless pakai kris sama aja

5:05sama aja isi itunya eh harus digitalnya kan harus ditop up juga juga walaupun digital e-wallet Iya

5:16oke Wah ini saya baru nyadar nih sekarang kok apa eh account-nya udah muncul ya kalau cuma

5:24apa karakternya pink waving hand apa green ini pink streamingnya udah di ya udah update nih

5:32ada Abdul Malik juga

5:35Bandung

5:35halo Bandung

5:38udah macet belum Bandung?

5:41sudah mulai dekat lebaran begini

5:43kalau lihat

5:45isinya mobil

5:47masalah standar

5:48kita mulai ngobrol

5:53tentang tembolok

5:55tembolok

5:57oh iya tembolok

5:58bahasa indonesianya tembolok ya

6:01kecing ya

6:01ini pronunciasinya juga bingung ya caching ada caching ada cacing

6:08yang benarnya apa sih yang benarnya

6:12cash

6:13cash

6:14jadi salah satu metode yang bisa membuat aplikasi kita lebih cepat

6:25sekaligus membuat service kita lebih ringan

6:30secara finansial bisa saving buat ngasih THR ke karyawan nyambung nyambungin aja ada yang punya

6:40sejarah sejarah cash gak sih sejarah apa cash ini kenapa ada cash ini dari oh iya ini dari

6:49temannya prosesor dan memory kan ya memilih prosesor ada sesuai ya itu proses yaitu l1

6:58cash dan l2 cash itu cash ya itu kan jadi secara umum adalah hardware atau software ya Oh bisa

7:07hardware juga yang pun baru tahu dong ya menyimpan data sementara l1 cash dan l2 cash hardware hardware

7:16jadi terlihat data sementara

7:19di store di situ ya

7:20yes, untuk menyimpan

7:23data sementara ketika ada request

7:25yang sering muncul

7:27dia gak perlu

7:28reach out atau memanggil ke database

7:31kenapa?

7:32dan kalau kasusnya hardware mungkin nge-save

7:34kayak memorinya ya

7:36gak perlu nge-compute ulang

7:39compute ulang gak perlu

7:40kalau misalkan komputasinya cukup

7:42berat gitu kan

7:44atau cukup memakan waktu memakan resource yang cukup besar gitu udah hasilnya disimpan aja ke

7:50cash tuh ada tulisannya tuh cash cash cash cash cash cash cash cash cash cash dan biasanya ke

8:02cash ini disimpan di memori kalau database kan disimpan di disk kan di storage kan dan IO ya IO

8:13dan kalau mau baca data, ngambil data dari database itu cenderung lebih lambat daripada baca data dari memori RAM

8:23itu basic komputer banget ya motivasinya ada ini ya sejarahnya nggak ada ya nggak ada

8:35Nah ini salah satu workflow-nya, jadi kalau ada yang request,

8:42dia cek dulu apakah di cache-nya ada, eh bukan ya, bukan ya, bukan.

8:47Iya benar-benar.

8:48Oh benar ya?

8:49Benar.

8:49Tapi ini doanya, oh read ya.

8:51kalau ada di catch maka dia langsung baca data kalau tidak ada langsung di return kalau nggak

8:58ada kalau nggak ada cari tempat cari terus kalau misalkan sudah ketemu dia akan masukkan ke catch

9:05nya dan dia return datanya sekaligus ya begitu juga dengan ride ya kalau ride ini yang di catch

9:15Iya, jadi dia sebelum

9:18Dia kan gini, kan dia komputasi

9:21Dan cepat, jadi pada dia nunggu

9:23I, oh dia tulis dulu

9:24Ke blog

9:26Kalau disini ke lower memory

9:29Dia tulis dulu

9:31Sebelum dari memory dipindahkan ke disk

9:33Misalnya, jadi hasilnya itu

9:35Nggak langsung dari CPU ke disk

9:37Tetapi CPU ke memory

9:39Dari memory baru ke

9:41Disk

9:41Jadi kayak cycle-nya gitu

9:45dan cache ini bukan hanya di sisi server ya ada di berbedis apa ya hampir di semua layer ya dari

9:56frontend ya multi layer cash dari browser sampai ke server bahkan kayak CDN itu termasuk cache

10:08juga karya itu bisa buka bisa buka link dari saya tuh multi level webcache perlu kita mau

10:16spesifik soal web marketing doang ya yang bisa multi level jualan kalau itu bisa level webcache

10:23nah ok dulu ya dulu lulu ada oke salah pencet ke bawah sedikit ada nah client

10:34dari client caching, cdn caching, web caching, database, application, and so on

10:40database query level, object level

10:42bahkan disini masih ada yang kurang nih, ada network caching

10:46contohnya DNS cache

10:50jadi waktu kita type enter

10:54DNS itu kan disimpan juga di browser kan cache nya

10:58supaya tidak kemana-mana

11:01itu cache pertama DNS cache kedua client cache itu yang ada di browser browser browser atau OS

11:10browser tuh cache nya juga ada banyak tuh cache nya web cache nya itu ada cache yang ntar kok

11:21lupa sih kalau kita pakai apa tuh yang service worker ada lagi ya ada yang bisa dibuka di

11:35DevTools itu kan ya masih ada beda loh sama storage itu itu bukan cash itu story tapi

11:46bisa dipakai kan bisa dipakai untuk nama kalau api storage Iya maksudnya gini kalau kalau oke

11:58mungkin gue harus bedain antara webcast yang eh tahu nggak kalau misalnya ada header cache

12:04control yang oh itu itu header itu kan itu itu itu webcast dan ada lagi untuk web API yang pakai

12:15untuk si application kalau mau simpan cashnya manually di browser bisa di di

12:21browser dari di local storage bisa di share storage sudah ada belum sih sudah

12:27ada ya share storage bisa sama di terakhir di yang database apa namanya

12:32index tv juga storage juga web storage terus itu di browser sisi browser client ya istilahnya ya kalau yang diheader tadi ya itu udah masuk server kan

12:52karena HTTP network ya

12:54request response

12:55ya terus ada CDN juga kalau kita nyimpen apa static file seperti HTML CSS, JavaScript, foto, image, video dan lain-lain

13:07itu termasuk kekej juga ya statik asetnya Iya jadi juga termasuk asidien kesini juga dipengaruhi sama

13:17dari case control header header-header case control nya kita yang kita kirimkan dari ah

13:24voice dari Origin bahasanya dari Origin kalau origin bilang oke ini ini bisa dikes tiga menit

13:32nanti itu HTML nya bisa di cash itu di CDN 3 menit kalau static file biasanya kan dari

13:40nginx atau webserver lainnya kita bisa konfigur kalau dia static file bisa di cash tahun selamanya

13:47selama ini bisa juga sih mungkin pokoknya di set panjang amat CSS JavaScript font semua static deh

13:59semua saya itu bisa di cash di CDN kalau kita ngasih headernya either cash kontrolnya itu

14:06jadi mempengaruhi kalau misalnya kita si klien atau si user kita waktu request request kita

14:17enggak perlu diteruskan ke ke Origin hanya tinggal ngambil dari CDN makanya di cash biar

14:25makanya untuk performance web performance biasanya dianjurkan ayo pakai CDN cash utilize CDN cash dengan benar makanya

14:36dan salah satu talknya saya itu waktu soal performance itu berdasarkan web almanac ya

14:43yang memakai website yang sudah menggunakan HTML cache di CDN itu

14:52less than 50%.

14:54Masih di bawah 50% yang benar-benar memanfaatkan CDN untuk nge-cache HTML-nya.

15:01Kalau CSS segala macam sudah benar.

15:03Itu sudah biasanya dari CDN-nya sudah bahkan bisa mem-bypass itu

15:08atau memperbaiki itu bisa.

15:09Cuma kalau HTML masih baru di bawah 50%.

15:13statistik statistik Nah dari CDN terus ada webserver web server caching ini biasanya reverse

15:23proxy bisa nginx atau yang lebih spesifik ke Farnis ya Farnis ada nama bisa macam-macam

15:30ya ada-ada HA-HA proksi-proksi ya itu termasuk untuk webserver caching ini juga sama hampir

15:42seperti CDN tapi ini kayak bikin sendiri gitu ya kita diplo sendiri ya kurang lebih ya terus

15:47juga ada database caching ini apa nih database data biasanya sudah dari misalnya kalau server

15:56dari servernya ini si database sendiri sudah punya oh iya ada caching sendiri read cash

16:06sama red price sudah punya jadi sudah built-in Maxit masih sudah punya built-in kecing itu

16:13sudah punya jadi developernya itu enggak perlu ngekonfigur apa-apa ya ya Mas Enggak modding

16:19ada settingan ya by default sudah ada by default sudah ada kalau mau di-custom silakan betul

16:27biasanya kalau mau di-custom itu biasanya kalau kalau mau di-increase atau di-decrease atau

16:35Misalnya cluster, kalau write cache itu harus benar.

16:42Tetapi biasanya sudah dari sound-ownya sudah ada database cache itu sudah ada.

16:46Ya database update it's automatically.

16:50Ya dan berikutnya application caching ini salah satunya adalah LRU ya, list resource.

16:58ini konsep yang cukup umum ya seperti yang khas bilang adalah redis masuk ke application

17:11cache ini kita bikin manual ya redis itu server service untuk apapun yang key value storage mau

17:20dipakai buat database mau dipakai cuma sering dipakai buat cache salah satu use case yang paling

17:26digunakan ya karena deskripsi value-value story value storage ya memcatch yang yang paling bener-bener

17:35apa ya peruntukannya untuk catching ya namanya sesuai namanya ya memcatch itu yang kayaknya lebih

17:41populer dibandingkan redis ya sebelum redis ada itu memcatch duluan saya dulu pernah buat plugin

17:50wordpress untuk database cache ya benar untuk database cache yang saya pakai file jadi cuma

18:02file cache Oke gitu jadi query-nya saya md5 dan saya simpan sebagai ii txt dan dalam hasil dari

18:16database nya itu hasil resultnya itu saya serialize masukin ke dalam txt nya jadi saya sebelum dia

18:25lakukan read ke database saya cek dulu txt file nya ada nggak kalau ada tinggal baca file nya

18:33doang lebih cepet daripada baca query ke database sebenarnya karena database saat itu terpisah

18:41server jadi perlu ada network jauh ini latensi sedekolom baca file lebih cepet jadi itu juga

18:48bisa jadi sebenarnya Redis itu ya salah satu service yang yang sangat bagus sebenarnya untuk

18:56untuk karena deki value dan bisa di klaster sih sebenarnya makanya dia keren ya saya juga melakukan

19:04hal yang hampir sama tapi waktu itu menggunakan memkej jadi setiap query yang dibikin itu di md5

19:11jadi inki value-nya ya hasilnya masukin ke memkej waktu itu habis itu baru muncul Redis

19:17meskipun peruntukannya bisa banyak diskis yang banyak tapi yang salah satu yang paling terkenal

19:22adalah digunakan untuk catching karena dia terkenal cepat kalau file itu masih red kedis

19:30kan masih menulis ke storage kayao-kaya iya-iya mesinnya sakit redis juga ada persisten storage

19:39kan ada betul-betul tapi enggak setiap request ya enggak jadi dia bisa settingan

19:45dia jalan di jalan di memori memori setelah jalannya memori kalau kita buat

19:52setiap ya Jadi kalau misalnya kita write dia akan write ke memori nanti ada

19:58background process yang write ke storage file ya eh sorry ya ke storage ke storage

20:03jadi sebenarnya redis ini lebih bukan hanya sekedar catching tapi bisa juga dipakai sebelah untuk full

20:12untuk full database bener ya jadi juga ada yang model-model apa namanya tapi nggak bisa lagi

20:19ini juga tapi dia nggak bisa itu kan anggap jadi kalau misalnya tidak relasional ya tidak bisa

20:27jadi hanya tipe listron aja masuknya kesebelian OSG ya jadi kayak table a kamu punya table a

20:35key value nya apa table B kivyol ingin jason-jason

20:41iya betul-betul ini apa tapi seri live jadi nteks Iya nggak bisa nggak bisa query

20:51nggak bisa join-join nggak bisa kamu yang rumit-rumit kita ya set-up betabas beneran

20:57lah nah ini juga kalau misalkan failure misalkan memorinya hampir penuh gitu ya

21:03dia bisa tulis ke otomatis bahkan disuruh ke ya dis juga betul baik itu application catching eh ada juga database query level caching Ini apa nih

21:18Ini yang seperti...

21:20Yang tadi ya?

21:21Yang tadi kita lakukan ya?

21:24Oh ini beberapa ini kali ya.

21:26Beberapa contoh dari...

21:27Oh enggak ya?

21:28Enggak, ini kayak layer.

21:30Layer-layernya ya.

21:31Level-levelnya ya.

21:32Object level caching.

21:34Oh untuk session.

21:35Ini juga yang di-share biasanya gini, objek level caching ini sangat berguna kalau misalnya web servernya lebih dari satu.

21:53Kan kita butuh, jadi kalau misalnya PHP, kan ada sessionnya, PHP session.

22:01PHP session kan nempelnya di mana?

22:03PHP session nempelnya di web server.

22:05di PHP FPM nya, di PHP Process.

22:08Kalau misalnya kita login, masa kita login ke, pas kita request kita login ke web server A,

22:14masa waktu pindah request nya ke web server B kita ke log out?

22:19Kan gak cocok.

22:21Maka semua session nya itu harus di centralize.

22:24Di object, sebagai object level caching.

22:28Jadi disinilah gunanya.

22:31Oh jadi bakalnya jadi bisa bisa website bisa 10 sedangkan sessionnya disimpan di redis karena

22:40semua untuk Centralize ya Centralize session yaitu disimpan di redis kalau disimpan di database

22:50sebenarnya bisa aja cuman kerjanya lebih berat ya karena nyimpan session itu kan ekspire cepat harus

22:57dan baca ada ada kekurangan yang lain Mas Riza kalau misalnya kita lagi ke ngeraj ke database

23:06kita lagi ngeraj ke database read yang kedatabis akan ke log kalau bisa lebih dia harus nunggu dia

23:14harus nunggu database right nya selesai baru bisa di selek contohnya anggap kalian punya

23:22table namanya session user session ya user session dan login akan login session disimpan ke database

23:32kalau misalnya ada 1000 orang berbarengan dalam 10 detik atau 5 detik 1000 orang sekaligus tuh login

23:42maka database kita akan ke lock sampai itu selesai mas mas saya waktu kita dia sudah selesai untuk

23:49request selanjutnya dia akan nunggu orang lain selesai ngelog itu kan

23:54database write itu kan sehingga dia nggak bisa baca

23:57nggak bisa nge-select data yang ada di table user session itu sampai selesai

24:03nggak bisa-bisa sampai masing-masing

24:06nanti akan terjadi yang namanya bottleneck

24:09nah disini siapa yang masih menggunakan database sebagai session

24:14harus hati-hati eh database sebagai session storage ya

24:18Iya saya pernah kena kasusnya ini karena dulu si CI, CI3 itu by, dia bisa pilih 3, dia bisa milih kan mau ke file, database, atau ke redis.

24:36susahnya dengan Redis itu

24:40itu extensionnya itu

24:43membingungkan

24:44mau pakai PCL atau pakai yang lain

24:47ada Redis client itu ada

24:49ada dua

24:49yang populer dua ya

24:52dan itu kalau misalnya salah

24:55salah satu

24:57salah pilih

24:57dan nggak bisa dari

25:00CA3 itu nggak bisa

25:01CA3 itu nggak bisa connect

25:03jadi kalau dia nggak connect

25:05dia akan fallback ke database nah atau ke file sedangkan waktu itu kan ya kira jadi lambat

25:14kenanya di sini ya dan apa aja data yang bisa kita ke sini kita ngomongin dari buahnya sampai di database level ya kalau kalau kita ngomongin HTML CSS JavaScript udah pasti ke cache kan Misalkan dari database lah apa aja yang bisa kita simpan ke cache ya hal yang jarang terjadi perubahan

25:40Misalkan username, email.

25:43Jadi kan kalau misalkan kita bikin aplikasi terus di kanan atas itu biasanya habis login kan ada,

25:48Welcome Riza atau Welcome Eka

25:50Atau Rizafamilie.gmail.com

25:53Itu berapa

25:54Tahun sekali sih berubah

25:56Apalagi unik ya

25:58Jadi itu disimpan aja

25:59Gak usah baca ke database

26:02Karena setiap kali kita reload

26:04Atau setiap kali kita pindah page

26:05Nanti dia ngequery lagi

26:07Itu

26:09Itu secara

26:11Mungkin kalau usernya

26:1310, 20, 100

26:16Masih belum

26:17terlalu kelihatan, tapi kalau udah seribu

26:20apalagi tadi yang konkurrennya sampai

26:22ratusan

26:24bakal database-nya

26:26bakal bengek itu

26:27hanya untuk read username

26:30atau email

26:31setiap page, ya itu

26:34bahaya sekali sih

26:35terus kalau konten mah

26:38front page konten sih, kayak

26:40landing page konten misalnya ada feature

26:42itu harus banget kan

26:44di caching

26:46karena selain biar gak berat di biaya juga biar orang setiap visitor baru datang udah cepet kan

26:52biasanya gini juga kalau imagine ada di halaman itu trending ya

27:01trending topik

27:03trending article

27:04nah itu kan komputasinya anggap aja trending article itu kita berdasarkan jumlah komen dan view dari page itu

27:15itu kan ngekalkulasi nya lumayan misalnya kalau artikelnya cuma 100-200 simple imagine kalau

27:25kayak detik yang artikelnya jutaan udah bertahun-tahun artikel mau dibuat trendingnya itu gimana gitu kan

27:33dan nggak signifikan juga kan bedanya detik ini sama lima detik lagi gitu loh jumlah

27:39Jadi biasanya kalkulasinya dilakukan di separate proses.

27:48Jangan di page load.

27:50Bisa di background proses segala macam.

27:52Dan hasil dari kalkulasinya ya mau disimpan di cache boleh, mau disimpan di database boleh.

28:01Tetapi kan cuma hasil.

28:02Jadi cuma tinggal kayak oke yang trend artikel satu jam terakhir 10 ID ini aja gitu.

28:13Jadi waktu si aplikasi cuma tinggal ambil satu row itu.

28:17Query mungkin information atau mungkin sudah disimpan sebagai serialized atau JSON.

28:22Yang image-nya sudah ada, title-nya sudah ada.

28:25Jadi cuma tinggal ngambil JSON itu.

28:28Jemplokin ke HTML.

28:30ya selesai kan jadi itu cash namanya jadi komputasi untuk mencari trending itu dilakukan di background

28:39halo Audi banyak wah halo oke ada banyak deh oh ya cashing itu juga nggak untuk database query

28:55bisa jadi network request yang terjadi dari server backend.

29:02Contohnya,

29:02contohnya kalian mau

29:07ngambil data dari Google Analytics.

29:13Mungkin punya integrasi

29:15kembali lagi ke trending article.

29:20Kalau misalnya mau ngambil trending article,

29:22kita bisa baca data dari Google Analytics,

29:24mengambil short range nya oke satu minggu terakhir ini 10 artikel yang paling sering dibuka satu minggu terakhir

29:35atau bahkan macam querinya mau satu minggu terakhir dari daerah mana itu bisa dari country mana Bisa dipisah lah kita serahkan Intinya yang mau saya katakan adalah network request yang terjadi ke Google Analytics

29:51Dari server kita.

29:54Data yang kita ambil itu kan kita proses dan kita simpan di cache-nya kita.

30:00Itu bisa di, saya paling suka pakai di Redis.

30:06ngomongin soal Redis lagi heboh ya ini apa namanya dual resensing kasus Redis yang ini

30:21sebenernya enggak ada hubungannya sama caching sama sekali sih cuma karena redis pasti ya

30:26selamat tinggal Redis Oh kok selamat tinggal sebenarnya dampaknya lebih ke ini ya lebih ke

30:34company kan ke bisnis kan bukan ke personal sebenarnya coba cari artikelnya yang jelas deh

30:40dia mengganti dia mengubah licensenya ini nih harus teknika Oh ada yang lain yang lebih jelas

30:53ada yang ada yang versi ada yang versi I'm not a lawyer nya enggak sih ada yang versi

31:00tldr nya kan Iya kan kalau baca begini gak intinya ini kan redis yang akan datang akan

31:08dirilis dengan free and permissive use of source code under ini inilah alisensinya udah ganti yang

31:17tadinya BSD

31:21sekarang jadi RSHL

31:22iya

31:23udah pindah dia dari BSD

31:26BSD joke lagi ya

31:29kayaknya baru kemarin

31:30pindah dari BSD

31:32ke Gading Serpuk

31:33dampaknya apa? dampaknya adalah

31:37perusahaan-perusahaan terutama

31:39cloud company gak bisa sembarangan

31:40menggunakan service credit

31:42buat di layanan

31:45yang terbaru

31:45ya terbayar layanan komersil mereka ya setelah di update company saya kan menyediakan layanan ini

31:54hosting makanya kena memikirkan ini saya nggak tahu masalah gimana tapi kayaknya mereka sedang

32:04internally sedang membicarakan ini oke kurang lebih gitu lah kira-kira jadi mungkin torik bisa

32:12menjelaskannya versi anot a lawyer kain ya tuh yang menyediakan service Redis yang paling kedapat

32:20ya redis ya mungkin kalau pengguna individu enggak enggak terdampak ya berarti mau saya mau

32:26lisensinya apa ya kan kita pakai secara langsung tidak secara langsung kalau misalkan service-service

32:34sudah tidak menggunakan Redis lagi secara tidak langsung kita jadi berkurangkan penggunaan

32:39redisnya kan kalau kita pakai misalkan project yang selanjutnya lah gitu kan project yang udah

32:45jalan masih pakai redis okelah gitu kan tapi kalau project baru kayaknya kita harus mikir-mikir pakai

32:49redis atau yang lain gitu alternatif yang lain gitu kan ya ini kan switch its licensing from

32:57BSD to source available license and server-side public license nah toponya yang paragraf tiga

33:06itu tldr nya kan aws dan teman-teman you cannot nanti seling redis as a service

33:13kasusnya milip elastixers betul betul sekali dan terraform yang berjuga itu

33:23juga sama ini ini bukan sesuatu yang salah ya perusahaan-perusahaan open source

33:32boleh melakukan ini karena ya mereka kan butuh duit ya butuh makan kan butuh menggaji orang

33:39kan ya dan itu bisnis kayak bisnis decisionnya bisnis strateginya siren bisnis strateginya

33:46hanya saja ya mungkin berdampak ke beberapa kalangan terutama ya tadi apa penyedia perusahaan

33:56jasa Redis Cloud itu yang berdampak dan harus dipikirkan lagi apakah kita harus menggunakan Redis atau alternatif yang lain.

34:07Karena ada banyak alternatif juga kan ya.

34:10Nah cuma menariknya baru sadar nih kalau si Redis ini mengubah license.

34:16Ini versi yang ke depan, versi yang selanjutnya besok.

34:20Berarti versi yang sekarang dan kemarin-kemarin itu ya tetap.

34:23Masih bisa dipakai.

34:24jangan dipakai kita tadi bahas alfaz of air ya udah di for aja betul sama kayak

34:32EWS melakukan for sebelum mereka pindah lisensi akhirnya menjadi open search ya

34:40kalau nggak salah ya dan mereka tetap jalan dengan itu redis juga kemungkinan

34:44akan melakukan hal yang sama seperti itu open this open this elastic elastic

34:52elastikas lay-lay aws-nya elastikas Ken elastikas yaitu pakai redis Iya mungkin

35:03dia ganti produk nama elastikas Iya oke ini salah satu alternatifnya namanya dragonfly

35:11katanya eh API sama marketing teksnya aja redis with wings jadi mereka memang memposisikan diri

35:17sebagai buat menampung para refuginya ekstremis Dragonfly is fully compatible with redis API

35:27sebat without the redis manajemen kompleksiti tinggal ganti dari redis url ke Dragonfall

35:35url mungkin udah bisa jalan semua mungkin ya saya enggak tahu ya tapi katanya begitu enggak pernah

35:40pakai ada di semen jemen karena semuanya lewat CLI nya dia doang taunya cium kayak ngapus cash

35:45kita lihat ya disini ya getting started karena bayarkan manajemennya lebih semuanya bayar Oh

35:53iya bayar-bayar tapi yang dijual lagi sama Redis adalah service-services karena banyak plugin ya

36:01bahkan kayak Vector database yang kalau kita ngomongin AI itu mereka ada gitu dia jualannya

36:09itu yang hilang ya kalau ini mah mirip-mirip semua ya udah sama gitu cuman ganti ganti tinggal apa

36:19komentar comment option FB redditor dengan karyawan kayak gitu saya dikodenya misalnya punya shell

36:29script atau apapun itu tinggal Iya variabel tetap redis tapi url-nya mengarah ke Dragon

36:35jadi nggak usah diganti

36:37oh, serial DB juga ya

36:41saya nggak tahu nih, serial DB ini database apa ya

36:44serial DB apa sih, belum pernah pakai

36:45jadi kepo

36:47serial DB

36:49ultimate multimodal database

36:52nah, tadi kan

36:56kita udah bahas

36:57sampai ke dari

36:59atas sampai bawah ya, objek

37:01sampai dari awal

37:03sampai ke application caching database webserver CDN client caching nah ini kan kita kalau teman-teman

37:12yang sudah mungkin sudah cukup familiar dengan react ya pasti ada istilahnya memori-mori pertama

37:22pertama ketemu sebelumnya itu typo Oh bukan bukan typo memori-wari ini ini konsep ilmu komputer

37:34sebenarnya bukan hanya di front-end tapi digunakan di dimanapun ya termasuk di front-end akhirnya

37:40apa react juga menggunakan apa yusmemo ya yusmemo ya ini adalah salah satu tipe casing juga kan ya

37:48Jadi cara kerjanya adalah seperti remember.

37:53Mengingat apa yang hasil terakhir ya.

37:56Hasil corresponding result gitu ya.

38:00Dari input.

38:00Misalkan kita bikin search bar.

38:02Terus misalkan kita ketik ngobrolin.

38:05Yang muncul adalah ngobrolin web gitu kan Nah itu disimpan Jadi ketika user lain mengetikan kata kunci ngobrolin dia akan memunculkan ngobrolin web gitu

38:17Tanpa harus mengkalkulasi ulang, maksudnya nyari mana sih yang matching sama string itu.

38:22Ini juga caching. Jadi caching itu ada di hampir semua level dari aplikasi kita ya.

38:30mulai dari server sampai networknya juga http caching ada, sampai ke depan paling depan sampai ke browser juga ada.

38:40Nah kalau konteksnya diriakan, virtual DOM misalnya ada yang berubah satu variable aja di dalam satu komponen kan,

38:48nge-trigger update semua tuh, seluruh aplikasi.

38:52Nah itu kan boros ya, misalnya nggak efektif meng-occupy browser main thread.

38:58jadi ya udah di memori ini mirip sama kalau di PHP ada itu yang saya yang saya bilang tadi

39:06opcash opcash ya coba buka itu linknya biar ada ini ada opcash ada bagannya digedein aja biar

39:24gampang langsung mengerti ini itu dia nah set memory Nah jadi dari kalau kan PHP kan just in

39:35time execution ya jadi begitu udah sampai mau dieksekut sebuah kodenya terus kemudian dia cek

39:44dulu opcode case-nya ada opcachenya ada nggak kalau ada langsung ambil reset memory langsung

39:50kalau enggak dia di parts dulu di-compile the safe dulu baru dieksekut makanya setelah PHP 8

40:00itu kan kenceng banget ya ya karena execution execution dari binary nya itu sudah disimpan

40:09di setmemory jadi enggak di-compile sorry bukan ya bukan executionnya compile codenya itu sudah

40:18disimpan di memori jadi enggak dikomplikasi ulang-ulang di rantai kalau dia selesai dengan

40:25garbage collective itu hilang berarti kalau itu cuma ada sepanjang dia jalan no no ini terus jadi

40:33misalnya Oh di apa namanya di request lainnya juga sama dia akan Oh ada ada ada ada ini ada

40:42ada ada maksudnya ada lifetime juga pasti ada saya bahkan terlalu cuma maksudnya enggak langsung

40:50hilang sekali kelar kan BMM saya pasti buka lagi Oh ada pengunjung lagi itu tetap ada

40:56persistennya entah dimana ini mirip dengan konsep yang memoisation tadi jadi si php-nya

41:03remember kompile code-nya tadi dia sudah remember kompil code-nya dan kalau sama persis jalanin

41:12laptop pengaturan di php.ini ada settingannya ya iya tapi ini kan kita ngomongin apa ya user

41:22experience gimana caranya optimis aplikasi kita supaya kenceng database nya juga kerjanya lebih

41:29ringan secara otomatis kosnya atau biaya server kita berkurang menurun dan lain-lain kan tapi

41:35gimana dengan developer experience ini kan suka kesel ya ini kok nggak berubah ya udah

41:40kodenya udah ngubah tetapi yang paling sering set gitu yang paling sering itu paling sering

41:47terjadi adalah di tempat kita sudah berubah tetapi tempat klien belum usernya berubah

41:54Nah itu lebih bahaya lagi sih kan lebih serem karena kita buka kita buka devtool devtool kan

42:01devtool itu kita disable cash contohnya kita bypass cash nah itu tuh paling gawat itu iya

42:07Jadi di ilmu komputer itu ada dua hal yang sulit. Yang pertama adalah case invalidation, yang kedua adalah menamai variable atau menamai fungsi atau menamai sesuatu.

42:19Betul Jadi istilahnya itu adalah case invalidation ngecek apakah cashnya masih valid atau tidak Ketika misalkan tadi gimana

42:32Soalnya kalau misalnya kita cashnya nggak di invalidate sama sekali, ya gawat juga.

42:39Maksudnya user dapet data yang udah basi.

42:41Tapi kalau misalnya kita terlalu agresif ngapus cash, ya sama juga bohong.

42:47Kita nggak dapet manfaatnya cash kan.

42:49betul

42:51jadi ketika datanya berubah

42:54misalkan kayak apa ya

42:55datanya yang berubah cepat kayak counter gitu

42:58terus kita cache

43:00ya telat kan

43:02gimana caranya

43:04cache ini kan

43:06di berbagai level kan

43:07yang mulai dari browser

43:10database

43:12application

43:13nah ketika ada perubahan kita harus

43:16kayak ngeblast

43:17broadcast ke semua, tolong ini diubah

43:20untuk kasih tahu bahwa ini datanya sudah berubah

43:23itu yang

43:23membuat aplikasi kita menjadi

43:26kompleks, lebih kompleks

43:28itu yang sering terjadi

43:30adalah mismatching

43:32antara

43:33pertama browser cache

43:35browser cache itu kan punya time to live

43:37ada TTLnya, ada punya

43:39counternya sendiri itu, time to livenya

43:42expirednya kapan

43:43terus kedua CDN cache

43:45CDN cache itu juga punya

43:47Lifetime nya juga ada

43:49Terus ketiga

43:51Itu application

43:52Sorry reverse proxy tadi

43:54Yang reverse proxy itu kan punya cache

43:56Itu juga

43:58Sama terakhir adalah application cache

44:01Itu juga punya

44:02Lifetime jadi kalau misalnya

44:043 cache layer ini aja

44:07Saya gak ngomong

44:08Saya gak ngomong yang kebelakang lagi yang database cache

44:11Gak ada macam ya ini masih dari application

44:13Ke atas itu aja sudah

44:15Pusing urusannya karena

44:16kalau lifetime-nya ini beda

44:19jadi kalau misalnya

44:22di belakang sudah berubah

44:24itu belum tentu invalidation-nya

44:26sampai ke depan itu berapa lama

44:28misalnya

44:29kita sudah invalidate yang application

44:32sudah kita flush

44:33tetapi di

44:35tadi yang di

44:38reverse proxy

44:40bagaimana

44:40bahasanya page case

44:43dia ada page case

44:44yang di pesek ya ada pesek yang di sisi reverse boxing itu harus diinvalidasi habis diinvalidasi

44:51dianya juga diinvalidasi lagi nah invalidation yang disediakan nah di browser kan yang di client

44:59itu kan di luar kontrol kita nggak bisa di itu bisa ya karena harus nunggu timenya expired dulu

45:11harus tunggu time-nya expires atau bisa perintahkan tolong hard reset hard reload

45:17atau kita sering bilang oke sudah coba di incognito belum

45:20kan seperti itu makanya cash itu serba salah

45:27bukan serba susah ngaturnya susah manage ya

45:32kalau atau itu kan service worker kan ada itu bisa yang tahu nggak sih yang ngedit pake versi

45:39pakai ada kemungkinan ada versi baru nah terus sering lihat nggak sih ui-nya ada perubahan

45:48silakan reload nah ada button deh kita punca win button user ngeklik kalau on click ya udah cash

45:55Cash-nya di-clear harus di-load ulang.

45:58Di-load ulang biar manggil yang baru.

46:02Cash buster.

46:03Di mana tadi? Back-end?

46:05Kalau di back-end kita masih bisa, mungkin bisa sedikit kontrol.

46:10Kita manually.

46:10Jadi misalkan kita trigger ketika database-nya berubah

46:16atau di satu data berubah, kita bisa kirim event mungkin ke proxy server

46:23atau ke berbagai casing-casing yang lain tolong di flash tolong datanya dihapus di memori misalkan

46:32di redis atau dimana itu bisa kan gitu tapi kalau di klien ya tadi solusinya Eka sih kalau di klien kan yang kontrol bukan kita ya Kalau misalkan tadi ada tombol wah datanya berubah silakan klik OK

46:45Dia nggak mau klik juga jadi nggak berubah.

46:46Dia nggak mau update yaudah.

46:48Itu risikonya.

46:49Masalahnya dia.

46:51Jadi kalau di web itu jadinya begitu.

46:56Komplikasinya karena ada hal-hal yang tidak bisa kita kontrol sama sekali.

47:02Nah ini nih contohnya.

47:03coba buka Oke biar kalau ada yang belum pernah pakai pengen mencari bisa itu sendiri

47:12How to display new version available Oke pwa Oh ini ya ini biasanya Iya ini biasanya sih dari

47:24application-nya kita ada background refresh kan ya background Oh ya bingung tak meminta refresh

47:30di page itu ada versioningnya

47:33ya kita harus bikin dulu versionnya

47:37harus bikin ya

47:38nanti si background request inilah yang meminta terus ke

47:42akan melakukan request ya

47:46ada yang baru gak, ada yang baru gak gitu

47:49dia akan pulling

47:50konsepnya

47:53jadi kayak ini ya

47:57kayak long polling gitu ya

47:59dia terima event versi pasang-pasang listener pasang listener aja nanti

48:08dapet event kok kalau ada ada listener nya oke oke cuma kalau usernya nggak mau

48:15ngeklik refresh ya itu kayaknya udah di luar di luar kendali ya betul cuma penasaran deh

48:24Kalau misalnya website yang kayak apa ya, yang saham gitu, yang pokoknya yang time-sensitive banget, itu settingnya kayak gimana ya?

48:33Mereka nggak pakai cash yang seperti itu.

48:37Saya pernah bikin yang untuk situs olahraga, saya nggak bisa sebut judulnya, NDA, tetapi situs olahraga itu ada live score.

48:52ada live score

48:54basketball

48:55ada live score

48:57bola dan segala macamnya

49:00dan itu dia cuma kayak ini

49:02kayak snippet

49:04kayak widget aja gitu

49:05satu bar gitu jadi kalau misalnya ada

49:07goal dia

49:09hijau

49:10harus ada bunyinya gitu jadi

49:13kalau misalnya dia lagi orang yang lagi baca

49:15beritanya ada score yang naik

49:17dia akan ada

49:18animasinya nah itu tekniknya

49:21yang saya buat itu si bagian widgetnya itu sendiri itu enggak pakai apa namanya pakai

49:30application sendiri waktu itu saya pakai react pakai react application sendiri yang connect

49:36via web socket ya dan itu yang akan nge-pooling terus dari data yang web socketnya itu pergi

49:44meminta ke live data gitu langsung request yang di yang didapat itu cuman sebenarnya di server itu dia

49:52sudah dapat file txt aja sih jadi enggak enggak ada aneh-aneh prosesnya txt kalau ada ada data yang

50:00yang baru masuk dia akan langsung kalau enggak terjadi apa-apa kosong karena data awalnya sudah

50:09base-nya ada terus mendengarkan event yang kalau terjadi baru dia cuma langsung data langsung saya

50:16baca langsung kirimkan jadi bisa cepet jadi yang jadi yang diposting ditunggu dedakan tuh adalah

50:26update-nya ya bukan seluruhan data score-nya dan itu pakai socket ya jadi terpisah thread

50:33ini ada contoh kalau di sisi server misalkan menggunakan Express gitu ya atau not server lah ya

50:44jadi kalau misalkan ada update gitu pakai event misalkan ada sesuatu yang di pos kita datanya di update masuk ke

50:54Apa?

50:54Tadi dia tunjukin apa sih?

50:56Udah di-share belum?

50:57Nggak kelihatan ya?

50:58Belum ya?

50:58Iya, iya.

50:59Nah, ini dia.

51:00Zoom in, zoom in.

51:03Ya, ini.

51:05Jadi, ini contohnya kayaknya pakai Redis ya.

51:09Udah gitu ketika ada update terjadi

51:13dan mungkin ini update ke entah itu ORM atau ke database,

51:18kemudian secara otomatis juga kita melakukan deletion.

51:20menghapus data yang ada di Redisnya.

51:24Sehingga nanti ketika user mengakses,

51:27datanya nggak ada di caching,

51:28akhirnya diambil baru, baru di caching yang baru lagi.

51:32Contoh sederhananya.

51:33Nah ini related sama, coba buka yang SWR deh,

51:37yang Still Well Revalidate.

51:39Still Well Revalidate.

51:41Ini another case strategy.

51:44Kalau ini beda sih, beda tapi related.

51:46Jadi intinya dikasih dulu yang lama,

51:49yang terancur ada nih sampai sampai udah kalau ya dikasih dulu tapi setelah jadi yang lama udah

51:59dikasih ke user di balik layar dia nyari ngecek lagi tapi enggak buru-buru nih udah-udah santai

52:05nah user selanjutnya yang dapat yang baru Oh oke oke nah kalau detailnya itu kecelakaan apa

52:15bego-begonya sekitar gitu ya gue project running ya harus ada yang pencet cold nggak ke cash di

52:24matiin Iya otomatis mati kan iya iya iya di jenganing because version of notice to

52:36Oh karena setingan mani.

52:39By the way, kalau begini-gini bisa loh kalau misalnya kita mau bantuin update kodenya.

52:46Tinggal lecet aja sama postnik.

52:49Jeff postnik kan ini?

52:51Iya masih di Google ya.

52:53Ini bikin Workbox kan ya?

52:55Iya Workbox.js

52:57Dan web.dev itu kan ada di GitHub kan ini ya kan?

53:00Ada ada.

53:02dulu pernah pernah bikin full request nggak bisa full request kok bisa perempuan enggak

53:07maksudnya yang swr demo ini kan bisa di bisa default bisa di for dibenerin nanti

53:14dipulai di pulangnya kalau mau benerin itu lumayan nambah-nambah portfolio nah ini penjelas

53:26bagus deh tadi yang atas sikit nah ini contohnya aja

53:30hmm cash respon is fresh and use as is to fulfill browser request no revalidation

53:38nah ini kan baru banget ya belum berubah

53:401-60 1 detik sampai 60 detik ya 1 detik sampai 1 menit gitu ya

53:47cash respon is stale stale ini artinya apa

53:50masih masih Mbak mungkin belum basi banget ya tahu nggak sih kalau kaya roti atau apa mulai keras

54:00gitu sebenarnya makan juga nggak papa kan tapi udah nggak seger apa ya bahasa Indonesia nya

54:05basi ya istilahnya datanya udah udah nggak kalau berhasil kan dimakan kita masuk ke masyarakat ya

54:14itu yang yang bahaya banget kalau ini kan sebenarnya udah mulai agak keras-keras agak

54:19enak tapi ya dimakan gapapa ya gitu kalau kalau bahasa Jakarta Selatan itu daripada bilang basi

54:26lu style lu ah gitu Oh ya ini perkara 6 angka 60 nya dari mana itu yang Scroll ke atas sedikit

54:34ini kan cuma contoh doang ya apa tergantung kita pasang kita pasang header apa eh cash control

54:43tidak harus 60

54:48terserah kita nih ya mau ngisi berapa ya

54:52pokoknya prinsipnya cara kerjanya kayak gitu

54:55kalau ada service worker lebih susah lagi loh ngurus casenya

55:00karena service workernya harus di invalidate lagi manual kalau service workernya juga stel itu pusing jadi ya kes ini sangat membantu untuk user tapi juga

55:14tapi agaknya saya developer untuk mau developer experience kurangnya mau bahas di posisi casing

55:22manajemen untuk yang advance nggak bisa mau boleh mau demo dulu enggak enggak demo enggak demo cuma

55:32ada kode ada kode-kodenya artikel aja dulu pernah waktu di company lama ini sambil nunggu nih ada

55:44minta bahas

55:45load balancing, wah menarik ya

55:48bisa

55:49tolong sapit dong

55:52disini kesana.in slash ngobrolinweb

55:54nanti kita diskusikan

55:56siapa tau

55:58bisa kita bahas di topik-topik

56:00berikutnya

56:01bahas tentang data scaling

56:04nah ini juga benar, bisa juga

56:06tolong dibantu ya, dibantu

56:08biar kita diskusi disana

56:10oke

56:12sudah

56:13udah ready silakan udah dimasukin belum screennya jadi dulu waktu saya kerja di sini di kampanye

56:30ini ten up ten up dan nama Ivan kristof kirain karen ganti nama teman saya satu tim satu tim

56:39saya dulu sebutan saya eh dia karena kita sama-sama Ivan kah dulu ada insight joknya

56:47dulu dia panggilannya kewan dan saya ke itu jadi k1 k2 nggak sampai 8 ya keberlepas nanti

56:56nah ini kodenya mungkin kode WordPress tapi sebenarnya kode umum layak body terapi PHP

57:04goleng atau javascript bisa ya intinya ini server-side cash itu anggap kalian punya redis

57:13cash atau memory cash atau atau apa whatever cash ya jadi cash get sama catch at set biasanya ya

57:21set ya apa yang masalahnya dari kode ini kalau kita lihat ya kita kan ada keskinya datanya kita

57:28ambil kalau datanya ada return data kalau datanya enggak ada eh baca data ngapain lah gitu ya

57:36pokoknya sebuah proses yang mau operation untuk membuat data itu dan data itu kita simpan ke cash

57:44selama time satu jam di sini ya satu jam apa yang salah sebenarnya nggak ada yang salah kan

57:51ini sebenarnya cara nge-tune yang tadi sample yang Mas Rizal kasih juga contohnya seperti ini

57:57kurang lebih kurang lebih kalau misalnya workflow yang umum kan ya Iya betul kalau misalnya under

58:06serve apa yang masalah di sini kalau misalnya yang terjadi kalau cashnya cold atau habis

58:14Yang terjadi di sini adalah semua request tersebut akan menghantam masuk ke dalam sini saat cache code.

58:23Ya nggak?

58:24Jadi...

58:25Karena dengan juru kosong ya?

58:27Ya, kan misalnya anggap aja kita untuk proses data itu 10 detik.

58:33Sedangkan request kita per detiknya aja sudah 1000.

58:37Berarti ada 10.000 request yang nggak punya cache.

58:42Betul nggak?

58:44karena proses penelitian cashnya butuh 10 detik sendiri

58:49iya maka 10 ribu kali lakukan operation dan 10 ribu kali nge-add ke cash

58:56betul nggak?

58:58oh maka cashnya ikut kena di dos gitu

59:01iya betul nggak?

59:03benar-benar

59:04itu konsep berpikirnya

59:06jadi nggak ada yang salah dalam kode ini kalau misalnya

59:10cashnya aman-aman aja

59:12bukan

59:13requestnya loadnya rendah

59:16loadnya rendah ya aman aja tapi kalau sudah di atas 1000 per detik ya hancur nih kayak gitu ya nah cara yang lain ya macam jadi untuk mempersingkat waktu ya tentunya kita kan ada

59:34ada enam strategi pertama do nothing kedua bla bla bla enam tapi yang nomor satunya do nothing

59:42ya jadi ada bagiannya dibuat contohnya gini dari start Apakah server kita banyak trafiknya kalau

59:50nggak ya sudah dulu aja nah kalau medium traffic nanti bisa pakai mutex mutex itu gini anggap aja

1:00:03yang kayak si Eka sampai ke tadi cash while sorry stale while revalidating jadi kita punya tiga

1:00:12kita punya dua cash key yang pertama stale dan ketiga updating jadi si cash nya kita itu enggak

1:00:20pernah enggak pernah invalid tetapi kalau misalnya dia apa namanya dia expired kasih dulu kasih dulu

1:00:33yang style-nya

1:00:35kasih dulu yang style

1:00:37kasih seandainya

1:00:39kasih yang style ini

1:00:41cash key, yang style

1:00:43sorry, yang ini, yang ini

1:00:45yang style, data ada dari style-nya

1:00:47dan sekaligus

1:00:49nge-update nantinya

1:00:50tapi

1:00:52ada proses untuk nge-update

1:00:54itu yang mirip dengan apa yang Eka bilang

1:00:57style while revalidate

1:00:59itu yang

1:01:00kalau misalnya medium traffic

1:01:03tapi yang sambil update-nya di satu lagi kan yang di yang ketiga tadi kan yang di baris ketiga tadi

1:01:09yang mana sih yang ini bentar-bentar kasih updating kan ya ya kalau sudah kasih ngasih

1:01:19stale ternyata dia jadi kalau misalnya lagi nge-update lagi belum selesai kasih yang stale

1:01:27jadi kasih ke user dulu biar yang apa di update yang di full key updating itu

1:01:34dia tetap melakukan updating jadi kita ada key updating sendiri gitu ya

1:01:38nah di updating itu menjalankan ini

1:01:41nah kalau misalnya ternyata traffic yang gede kita punya engine X gak?

1:01:48kalau punya di caching ya itu 5 itu misalnya gini

1:01:54apa namanya kayak pakai kalau di kalau di kita bisa bikin sebuah endpoint baru ya hanya untuk

1:02:11nge-update cash jadi kes kita itu kes kita itu umurnya panjang atau unlimited ya selama mungkin

1:02:21terus kemudian ternyata kalau cash-nya habis kita open new connection dari server kita untuk

1:02:31ke server kita sendiri ngerti nggak jadi kode kita nge-request ke server kita sendiri yang

1:02:42endpoint sendiri yang hanya untuk nge-update cash jadi endpoint itu kan nggak ada yang tahu

1:02:48nggak ada gak di open secara publik jadi endpoint itu akan bergerak untuk menghitung sekali doang

1:02:55Iya ngehitnya sekali doang untuk memperbarui cash kita itu bisa dengan cara seperti itu kalau kita

1:03:03misalnya mau pakai kron kita bisa juga pakai namanya CLI jadi kita jalanin pakai CLI yang

1:03:12setiap satu jam, dua jam, yang CLI-nya ini yang untuk nge-re-cash.

1:03:20Jadi yang di-serve ke customer itu tetap cash yang selalu ada, nggak expired.

1:03:30Tetapi untuk memperbarui cash kita pakai cron lewat CLI untuk memperbarui Cron job lah ya bahasanya background job ya terus yang ketiga itu ya sama sih yang kayak ini kayak crown job juga tapi dia perbarui

1:03:50sama mirip nomor 3 sama nomor 5 sama

1:03:52so itu kira-kira maksudnya kalau kalian punya masih trafficnya rendah ya udah

1:04:03nggak usah pikirin tapi kalau sudah mulai banyak ya perlu strategi yang berbeda untuk

1:04:10memperbarui cash karena kalau kalian tetap pakai metode seperti ini akan eventually

1:04:16gitu akan fail ya seperti itulah kira-kira karena sih nambah layer lagi kan di tengah-tengah antara

1:04:27database layer sama application layer tengah-tengahnya ada cache layer cache layer ini kalau misalkan requestnya

1:04:33banyak dia akan overload juga kan Apakah si cache server ini harus kita scaling lagi jadinya nanti

1:04:41yang tadinya costnya murah malah jadi mahal juga ujung-ujungnya kan

1:04:47supaya mengantisipasi request yang banyak ini

1:04:52kalau kita tidak mengantisipasinya juga di sisi kode kita

1:04:57saya sampai punya pengalaman bahkan project masih jalan kayak gini

1:05:04ada satu project itu nggak boleh nge nuke cash

1:05:09karena yaitu kalau di nyukai clear cash nya itu server akan servernya langsung akan spike servernya

1:05:23akan spike semuanya akan dapat 504 Oh serem juga time out ya time out itu gua-gua dari nyemirnya

1:05:35ini pernah kejadian kayaknya sore Oh paling dimarahin sama leader siapa yang siapa yang

1:05:44aku di cash ini itu nggak bisa kayak misalkan over the weekend di jam 12 malam gitu di kronjob di

1:05:52clear case gitu ngapain jangan langsung naik ya langsung naik bukan yang bener tuh jangan jangan

1:05:59dinuk semua jadi iya yang butuh i perubahan aja yang butuh dirubah aja yang dirubahin jangan

1:06:08semuanya ya jangan nah makanya di company saya itu ada redisnya pun ada failover jadi kalau

1:06:18misalnya satu servisnya down dia bisa fellow ke-3 di sapa in itu juga ada kasternya ya ya ada

1:06:25ready-ready berarti harus ada semua kan harus sama dia kayak gua bilang tadi kayak kalau gua

1:06:32nge-clear case aja itu 504 itu semua karena si originnya itu sibuk memperbarui cash dan sibuk

1:06:41trafficnya gede banget tuh jadi dia begitu satu traffic nge-build case dan kalau dia nge-build

1:06:51belum selesai sudah ditimpa terus dengan request semuanya kembali kan ke build cash lagi ya nge-spike

1:06:57itu bisa bisa bisa 100% dan tiba-tiba si apa namanya si webservernya itu kembang jadi banyak

1:07:07salah satu pentingnya belajar big annotation juga ya jadi mustahil apa baru sadar complexitynya

1:07:15kompleksitinya kalau banyak yang visit kayak gitu kalau cuma satu-dua apa-apa kan sebetulnya

1:07:22betul-betul singa belum lagi Network request ke bisa ke Google Analytics Elasticsearch segala

1:07:32macam itu banyak tapi ya pengalaman kalau jangan takut ya nggak clear case paling dimarahin doang

1:07:44Nah ngomongin tadi

1:07:49Big O

1:07:52Hai ini mungkin bisa kita mention juga tentang Redis karena salah satu dokumentasi yang apa

1:08:02menyediakan informasi tentang bigotu Redis salah satunya mana ya ada komen ya kalau salah ya

1:08:10misalkan kita mau set banyak ya banyak sekali misalkan get set get set dia ada kasih tahu

1:08:22bahwa ini operasi ada di atas tadi ada di atas top stop itu time complexity complexity nih Iya

1:08:31soalnya kasus-kasus gini yang perlu di apa kita kita kebanyakan kalau cuma nyoba sekali kita

1:08:37coba sendiri pas lagi development semua semua nggak papa mana-mana aja cuma yang kayak tadi

1:08:42Evan jelasin begitu 100 orang visit tiba-tiba boom ya ini kan kalau kita belajar BIO biasanya

1:08:51kan kurang praktikal kan kalau ini kan udah dipakai istilahnya di banyak yang pakai dan

1:08:58kita bisa tahu kapan kalau increment itu eh kompleksitas seberapa kalau yang kompleksitasnya

1:09:06yang gede apa ya pop pop pop ya Oh ini ini ini ini ini Insertnya on Insert itu apa left

1:09:17Insert ya masukin ke sebelah kiri ya paling depannya pop pop juga lumayan loh karena dia

1:09:25ambil terus geser coba pop pop pop kalau pink pink satu sama ada pop-pop nih yang mana banyak

1:09:38dia soalnya pop-pop apa-apa ini pop-pop apa aja sih pop-pop komen kan di komen kan enggak ada

1:09:47Pop yang mana aja sama sih, airpop juga boleh.

1:09:53Airpop, airpop, airpop.

1:09:55ON.

1:09:56Karena dia ngambil terus geser Terus geser Ini eksponensial ya Enggak Linear apa eksponensial

1:10:08Where n is the number of elements.

1:10:12Jumlah elements-nya.

1:10:14Kalau sejuta, itu berarti sejuta ya.

1:10:19Iya. Kalau eksponensial kan yang pangkat kan?

1:10:22Pangkat n.

1:10:23Iya.

1:10:24Nah ini bagus nih

1:10:27Dokumentasinya bagus karena menyediakan ini

1:10:31Jadi kita bisa relate lah

1:10:32Kalau teman-teman gak tau tentang Big O baru belajar

1:10:35Terus gimana sih

1:10:37Saya juga gak ngerti-ngerti amat

1:10:38Harus baca lagi deh

1:10:39Kalau baca gini ngerti dong maksudnya apa

1:10:42Pokoknya kita secara kasar kebayang

1:10:45Gak sembarangan pake ini

1:10:47Kalau misalnya kita aware

1:10:48Kita tau resiko

1:10:50Gimana ada alternatif lain gak?

1:10:54yang bisa kita lakukan mungkin yang tadinya kita pakai lpop tapi kita pakai dua komen cuman kalau

1:11:00digabungin hasilnya lebih rendah daripada ON misalkan contohnya contoh kasus di dunia nyata

1:11:07contohnya just ya contohnya kita kan diajarkan relational database contohnya gini kalau misalnya

1:11:19table A sama table B itu

1:11:23many to many

1:11:24kita bikin satu temple

1:11:26temporary untuk mapping di tengahnya

1:11:28oh table transisi

1:11:31ada isinya

1:11:32foreign key kan

1:11:34jadi buat

1:11:35mapping

1:11:37itu teorinya sih begitu

1:11:40tetapi di dunia nyata

1:11:43bagus mana sih

1:11:44kalau misalnya itu dipisah table

1:11:47normalisasi

1:11:48Atau mungkin lebih cepat one to many.

1:11:54Misalnya person sama department misalnya.

1:11:58Yang kita masukin departmentnya itu ID-nya doang di table employee.

1:12:07Dan waktu kita select kan harus di join Tetapi kalau misalnya hanya sekedar hanya nama itu aja kalau misalnya ya sudah 1 tambah 1 kolom aja

1:12:23di dunia nyata lebih cepat mana sebenarnya untuk seleknya.

1:12:27Contohnya, itu yang masih normalisasi sama denormalisasi untuk kompleksitas,

1:12:34kadang kita ngedesain

1:12:36table aja juga harus dipikirin

1:12:39kalau misalnya gak butuh-butuh

1:12:41amat di table baru yaudah

1:12:42ditambahin aja di

1:12:44table yang sebelumnya

1:12:46makanya kan di

1:12:48kalau waktu di kuliah kita belajar

1:12:51normalisasi yang tadinya

1:12:52table itu gak boleh ada duplikasi

1:12:55makanya dibikin table terpisah

1:12:57di dunia kerja

1:12:59kita belajar denormalisasi

1:13:01ada beberapa data yang gak apa-apa

1:13:03biarin apa namanya duplikasi itu karena mungkin ya waktu di apa eh normalisasi itu diciptakan

1:13:13itu harga storage masih mahal kalau sekarang kan storage cenderung lebih murah kan jadi biar aja

1:13:19duplikasi gitu asal ada apa source of truth nya jelas itu ini update-nya di dari mana gitu intinya

1:13:28itu contohnya pantara teori sama praktek eh antara musik teori akademis sama kondisi di

1:13:36lapangan Iya ini kayaknya menarik juga ya kalau kita bahas kayak apa ya teori kompleksitas Big

1:13:43O lain ya seru ya kayaknya ya itu berhubungan dengan performance juga ya kadang saya juga ah

1:13:49daripada pusing-pusing bikin table baru saya simpan aja di table sebelumnya tetapi kontennya

1:13:54saya simpan sebagai jason. Why? I don't care. Yang penting masukin aja sebagai jason karena datanya

1:14:03sudah saya butuhkan satu tempat ngapain saya harus query kemana-mana udah satu table jason

1:14:08karena butuhnya cuma itu. Iya betul betul betul jadi ya yang penting aware aja kitanya aware

1:14:16terhadap operasi yang Dan itu sudah ada di arsitektur arsitektur decisionnya kan ada ada jadi tinggal tinggal pilih yang mana yang paling optimis untuk keperluan pada saat itu jadi selalu kalau ditanya jawabannya adalah it depends ya

1:14:34oke menarik ya malam hari ini selain kita bahas tentang tembolok atau kecing kita juga dapat

1:14:45Topik-topik baru ada yang minta load balancing, ada yang...

1:14:48Load balancing, scaling.

1:14:50Terima kasih database scaling tadi sudah dimasukkan ke GitHub discussion.

1:14:55Nanti kita lanjut diskusi di sana.

1:14:57Tadi juga tentang kompleksitas juga kayaknya menarik ya.

1:15:00Untuk kita bahas sekali-sekali back to basic gitu.

1:15:05Butuh juga kita nge-refresh yang mungkin sudah terlupakan gitu ya.

1:15:12Nah, untuk malam ini mungkin cukup dulu.

1:15:15untuk malam ini kita ketemu lagi kecil depan minggu depan itu cacing nyaris lebaran ya udah

1:15:25lebaran ya hari selesai lagi menghit lagi lagi lagi meneropong hilal lagi menolong

1:15:31tanggal 9 belum belum lebaran tapi udah libur kan ya udah libur dan yang mudik juga pasti

1:15:38di kampung halaman perjalanan bermacet-macet ya Selamat liburan Selamat lebaran tetapi kita tetap

1:15:48ada walaupun rekaman ya kita tetap hadir garang teman-teman lagi mungkin lagi di perjalanan naik

1:15:55kereta atau kenalan aja in ya bisa nonton kita ya bersosialisasi sama keluarga ya pakai-pakai

1:16:05setanya perpura sibuk

1:16:07perpura sibuk atau anggota keluarganya diajak nonton bareng

1:16:11selamat dapat THR bagi yang dapat ada yang nggak dapat juga nggak papa

1:16:16jadi untuk malam ini udahan dulu Terima kasih banyak buat semuanya yang sudah hadir dan sudah meramaikan kita ketemu lagi selasa depan

1:16:24sampai jumpa

1:16:26minggu depan bye bye

1:16:35Terima kasih.

Suka episode ini?

Langganan untuk update episode terbaru setiap Selasa malam!

Langganan Sekarang

Episode Terkait

Ngobrolin Big-O - Ngobrolin WEB
EP 92

30 Jul 2024

Ngobrolin Big-O - Ngobrolin WEB

Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. ...

Ngobrolin OOP di JS - Ngobrolin WEB
EP 78

17 Apr 2024

Ngobrolin OOP di JS - Ngobrolin WEB

Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. ...

Ngobrolin React Server Component
EP 129

21 Mei 2025

Ngobrolin React Server Component

Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. ...

Komentar