Ngobrolin Design Pattern
Ringkasan Episode
Bantu KoreksiEpisode ini membahas tentang Design Pattern dalam pengembangan software, sebuah topik permintaan dari Mas Azam Aziz. Diskusi dimulai dengan perdebatan menarik tentang apakah MVC (Model-View-Controller) termasuk dalam kategori Design Pattern atau tidak, mengingat beberapa referensi menyatakan MVC bukanlah Design Pattern melainkan Architectural Pattern. Eka dan Ivan mengulas berbagai kategori Design Pattern seperti Creational Pattern, Structural Pattern, dan Behavioral Pattern, serta membahas referensi terpercaya seperti Refactoring Guru dan Patterns.dev karya Addy Osmani. Diskusi juga mencakup perbedaan antara Front-end dan Back-end Design Pattern, serta bagaimana konsep ini berbeda dengan Rendering Method seperti SSR, CSR, dan SSG. Episode juga menyentuh topik browser security seperti CORS (Cross-Origin Resource Sharing), CORP (Cross-Origin Resource Policy), dan berbagai kebijakan keamanan browser lainnya yang relevan bagi pengembang web modern.
Poin-poin Utama
- •MVC (Model-View-Controller) sebenarnya adalah Architectural Pattern, bukan Design Pattern, dan sudah ada sejak era Smalltalk
- •Design Pattern dikategorikan menjadi tiga jenis: Creational Pattern, Structural Pattern, dan Behavioral Pattern
- •Refactoring Guru dan Patterns.dev (karya Addy Osmani) adalah dua referensi terpercaya untuk belajar Design Pattern
- •Design Pattern berbeda dengan Rendering Method seperti SSR, CSR, dan SSG yang lebih fokus pada cara rendering halaman
- •Astro direkomendasikan sebagai framework fleksibel yang bisa mengkombinasikan berbagai metode rendering dalam satu aplikasi
- •Browser security menjadi topik penting dengan berbagai kebijakan seperti CORS, CORP, CSP (Content Security Policy), dan lainnya
- •Untuk aplikasi sederhana yang tidak butuh fitur kompleks Next.js, Vite dengan React Router sudah cukup untuk membangun aplikasi
[music]
Halo-halo-halo selamat malam
Wey lagi pada nonton bola nih
Iya, selasa malam waktunya tim nah
Nonton bola ya
[tertawa]
Kan, bener kan setelah 2 tahun kita live setiap selasa malam
Dapat tuh pattern-nya kan, polanya kan
Ada tim nas ya
Ada tim nas
Desain tim nas, bukan desain pattern
Ada polanya, pola tim nas seringnya
Iya, jadwalnya selasa
Kemarin ada si kamis ya
[tertawa]
Mudah-mudahan menang ya
Di GBK dong ini
[tertawa]
PK lagi nonton bareng dia
[tertawa]
Skor berapa kosong-kosong
[tertawa]
Mata nanya in skor
[tertawa]
Ini solusi mahasiswa ini
Solusi mahasiswa
Iya, gimana kabarnya teman-teman
Malam hari ini mudah-mudahan puasanya lancar
Yang menjalankan puasa
Tinggal sedikit lagi ya
Lihat transkrip lengkap (2262 segmen lagi)
Bentar lagi lebaran
Mungkin ada yang udah mulai mudik ya
Ada yang mulai mudik
Kalau ada yang mulai mudik atau minggu depannya mudik
Lancar-lancar di jalan, hati-hati di jalan
Semoga sampai tujuan dan kembali lagi ke
Kalau yang mudik kan balik lagi kan ya
Gak apa-apa kalau gak balik juga gak apa-apa
Silahkan pilihan masing-masing
Oh iya download aja dulu offline
Bisa gak sih Youtube download offline
Bisa gak ya
Bisa
Kalau Netflix bisa kan
Oh iya bisa bisa
Youtube bisa download offline
Youtube bisa download
Downloadnya yang kecil aja kan
Buat cuma dengerin doang kan
Eh boleh sih
Kalau ada visualnya juga gak apa-apa
Iya
Yang penting jangan sambil nyetir
Lihat visualnya
Iya jangan sambil nyetir
Dengerin aja dengerin
Iya dengerin aja
Kita berusaha sebisa mungkin untuk itu ya
Bisa dikonsumsi hanya dengan mendengarkan ya
Mungkin ada beberapa visual tapi
Cukup lah ya untuk mendengarin ya
Oke malam ini
Sesuai dengan permintaan yang ada di
Apa
Di github discussion
Di sini
Sanaline/ngobrolinweb
Itu kita mau bahas
Tentang design pattern
Ini adalah
Topik permintaan dari
Mas Azam Aziz
Mudah-mudahan nonton ya
Kalau gak
Kalau gak nonton
Mungkin nanti nonton replaynya ya
Nah kalau misalkan abis
Habis dari live ini
Kita mau diskusi lagi di sini
Misalkan kayak tadi ya
Barusan saya ngobrol sama Ivan juga
MVC itu termasuk design pattern
Sementara dari
Beberapa referensi yang kita
Kumpulin
Gak ada itu MVC
Jadi sebenarnya
Definisinya sendiri pun
Masih
Belum jelas ya
Mungkin sudah jelas
Di luar sana
Di luar sana
Kita nya aja yang belum
Nah maksudnya
Mubah yang kayak
Singleton dan lain-lain
Itu kan abstrak banget ya
Di system apapun
Pasti ada
Nah sedangkan kalau MVC kan
Kayak aplikasi web
Aplikasi setif
Ya maksudnya
Udah lebih spesifik
Nah padahal kayak yang
Di pattern strutif itu
Ada yang lebih spesifik lagi
Buat kayak jokot
Kayaknya apa ya
Design pattern itu kayak
Arturilater yang kayak istilah
Yang terhubung
Yang dipakai apapun itu
Jadi kayak gak
Gak selalu sutara dan
Bisa aja kayak
Yang satu orang bayangin
Tapi kita gak perlu bayangin
Design pattern itu
Sebagai ini, ini, ini
Kalau di telepon lain
Jadi kayak yang beda
Kayak bisa bayangin
Itu sebagian yang beda juga
Maksudnya
Yang pattern apa aja
Yang sama team MVC itu
Ya mungkin kalau orangnya
Yang gak aplikasi web
Yang terlalu spesifik
Yang semakin spesifik
Hmm
MVC ini terkenal karena
Ini ya, karena di PHP
Dipakai sama
Spring
No
Sebelumnya Spring
Spring?
Eh, Spring
Iya, Spring Framework sama
Zen, Zen, Zen
Oh, Zen Framework
Zen Framework kan pakai MVC ya
Iya
Padahal sebenarnya
MVC sudah lahir
Di jamannya Smalltalk
Bahasa yang
Kita sendiri gak ngalamin ya
Eh, gak tau ada yang ngalamin gak Smalltalk
Smalltalk ini
Salah satu
Bahasa
Apa ya
Bahasa yang menjadi referensi
Bahasa, bisa dibilang bahasa
Pioneer lah
Bahasa pertama yang mengadopsi
Object Oriented Programming
Oh
Bukannya si
Smalltalk
Bukan
C++
C++ kan Object
Kalau si kan gak ya
Iya, tapi yang pertama
Yang pertama itu Smalltalk
Nah, yang menciptakan adalah
Ini
Yang juga cukup berperan untuk
Beberapa
Beberapa
Teknologi ya
Salah satunya Apple ya
Mouse juga
Mouse, ya mouse
Apa
Gui, desain gui
Ya, desain
Kalau ini gak tau, beneran Serog ini bukan
Bener gak sih Serog photocopy
Ya, mungkin
Mungkin
Ya, jadi apa
Mac ya, Mac OS
Yang awal-awal sama Windows yang awal-awal itu
Terinspirasi dari OS yang
Mereka kembangkan di
Center ini
Jadi
Nah, ini yang kita kaget, ini termasuk
MVC termasuk software
Desain Pattern, apalagi yang ada
MVC, ada MVP
Ada
MVP, kalau ada yang tau
MTV, MTV
MTV
Model, template, view
Di Django itu pakai MTV dia
Anak nongkrong
Ada lagi gak ya
Nah, ini dia disini ada tuh
Builder
Abstract Factory, Dependency Injection
Factory Method, itu ada
Dan lain-lain
Karena ada dikategorikan itu kayak
Creational Pattern, Behavior Pattern
Structural Pattern
Itu macem-macem
Tapi MVC-nya sendiri berada dimana
Konkerensi Pattern juga ada
Nah, ini kan kita bakal
Kalau menurut gue ya
MVC itu jatuhnya di
Structural Pattern
Atau Behavior, gak tau ya
Arsitekural Pattern
Walaah
Iya, Arsitektur kan
Tadi kita udah ngomongin ini kan Arsitektur
Tapi ada gak disini Arsitektural Pattern
Gak ada
Gak ada
Oke, kalau gitu
Kita bahas tentang
Desain Pattern menurut
Ya, definisi dulu ya, menurut
Refactoring Guru
Nah, ini source yang bagus banget ya
Ya, saya penjelasannya
Sama kayak spesifikannya
Nah, disini juga ada
Front-end
Beda gak sih, antara Front-end
Back-end
Ada Domain Design Driven
Domain Design Driven
DDD
Dan lain-lain
Itu beda lagi ya
Front-end kan ya, waktu itu kita udah sempat
Bahas kan, itu lebih ke
Rendering ya, Rendering Method ya
Yang
Rendering Method yang kayak itu ya
Penamanya Static Site Generate
SSG
Client Site
Rendering
Rendering Method ya, oh beda
GUL ya
GUL
Siapa yang GUL?
Indonesia kayaknya
Ya, oke
Jadi kita coba ambil definisi
Dari Design Pattern
Dua referensi kita ada
Di Refactoring Guru
Sama di Patterns.dev
Kalau Patterns.dev ini
Adalah
Yang bikin
Itu salah satunya
Adi Osmani
Dia terkenal
Di dunia web ya, jadi mungkin untuk Front-end
Kayaknya lebih cenderung
Ke arah Patterns.dev, tapi kalau
Refactoring Guru ini lebih Generic atau
Untuk Back-end kali ya, mungkin ya
Enggak sih, lebih ke konsep sih
Konsep
Fundamental
Kayaknya suaranya
Enggak kedengeran
Mungkin deketin mic-nya
Kecil banget
Dan pecah suaranya
Pake apa sih?
Ada apa sih?
Ada mic
Lapel, mic lapel
Oh, keren
Oh iya, gara-gara noisnya
Terlalu sedih
Lagi nonton bareng
Ngeri, ngeri, ngeri
Oke, lanjut
Oke, jadi
Design Pattern ini adalah
Apa ya
Pattern ya, pola yang sering ditemukan
Dalam mendesain software
Atau bentuk dari
Software design gitu ya
Kurang lebih kayak Blueprint lah
Kalau di
Arsitektur
Bangunan
Gitu ya, ada Blueprint kan, sebelum kita bikin
Bangunan kan, kita harus bikin
Desainnya dulu
Blueprint-nya dan lain-lain
Terus
Meskipun demikian kita
Nggak bisa cuma cari pattern yang
Cocok, terus
Kopi, langsung
Masukin ke
Software atau ke aplikasi kita
Nah itu kata kuncinya di kalimat
Kedua tuh bukan tentang kodenya
Tapi konsep untuk membecahkan suatu
Masalah
Ya, oh iya, ada yang track lagi
Kalau di React
Pernah pakai Smart Dump Pattern, oh iya
Ada pattern juga ya, masing-masing banyak pattern ya
Pattern tuh ada di mana-mana
Ya kalau React kan, kayak presentation component
Oh
Terus Flux
Arsitektur juga termasuk pattern kan
Apa lagi itu Flux
Arsitektur
Yang itu, yang dipakai
Redux, yang ada action
Ada
Reducer
Nah, lain-lain, nah itu kan
Flux Arsitektur
Yang namanya Flux
Ya, kalau kerja sendiri
Nggak ada pattern-pattern, nggak ada
Bebas, kobo ya
YOLO
Tapi nggak
Tidak
Sepenuhnya salah kalau
Kita, kalau kita
Punya, apa ya
Disiplin diri sendiri ya
Dipakai aja, siapa tahu
Tergantung, besarnya ukuran
Yang mau dibangun sih, kalau misalnya
Projeknya terlalu
Cuma kecil-kecilan aja pakai
Desain pattern yang
Adapter-adapter
Adapter, iya
Terlalu
Terlalu over engineer
Betul
Kalau mungkin akan
Relate, kalau kita bikin library kali ya
Misalkan kita bikin library untuk
Database
Database-nya bisa SQLite, bisa
MySQL, bisa Postgres
Nah, itu ada adapter-nya kan
Gitu
Di web framework juga banyak kan
Kayak ASURO, kayak SWELTED
Nyasuhai target deployment-nya kan
Iya, betul
Legacy code nggak ada pattern
Ada, cuman kita nggak tahu aja namanya
Siapa tahu ada
Ada-ada
Selalu ada kok dari awal
Buktinya yang tadi kita sebutkan ya
MVC
Nih, lihat nih MVC nih
Object Authentic, pattern nggak sih?
Pattern?
Iya
Iya
MVC
Itu Smalltalk
Diawali dari Smalltalk
Smalltalk itu bahasa tahun berapa itu?
Lihat nih
80-an ya, itu ada 80-nya
Itu artinya tahun ya
Nggak tahu
Iya, yang 79-an, 79-nya
Oh iya
Created in 1970-an
Kurang legacy apa ini?
Udah ada MVC mereka
Maksudnya
Ada, tapi mungkin kita nggak tahu aja
Nggak ngeh
Nah, ini juga salah satu yang menjadi
Diskusi kita beberapa hari yang lalu
Kok perasaan
Di kerjaan nggak ketemu ya
Kita nggak perlu pattern-pattern gini ya
Kalo sampai sekarang, jujur
Di group WhatsApp sih
Kita bahas bahwa
Jujur gue kalau harus jelasin design pattern itu apa
Beneran nggak tahu, karena selama ini
Cuma ngerti factory sama singleton
Nah, kebetulan
Interview kerja nggak ditanya
Dan sepanjang kerja pun, ya nggak pernah
Harus ngejelasin design pattern itu sendiri apa
Tapi, ya nggak tahu ya
Bisa aja kan prakteknya sebetulnya udah
Ketemu dan nerapin
Tanpa paham itu namanya design pattern
Yang namanya ini-ini, prinsipnya ini-ini
Walaupun ngebahas arsitektur, misalnya itu kerjaan
Kan bakal langsung dibahas kan
Maksudnya bagian-bagiannya apa aja, ini tanggung jawabnya apa
Pola alurnya kayak gimana
Itu kan
Kayak kita bisa ngejalankan itu semua
Tanpa tahu teorinya design pattern
Tahuin namanya dia
Betul
Jadi, lebih ke ini ya
Lebih ke kayak
Kayak kumpulan
Kayak jurus-jurus kali ya
Kalau kita belajar
Belah diri gitu, kayak jurus-jurus kan
Ini jurus ini
Kalau mau nangkis itu kayak gini
Tapi kan, begitu
Misalkan kita belum
Paham atau belum mahir
Pas berantem, ya
Lari aja, nggak pakai jurus
Atau pakai jurus yang
Tidak diajarkan sebelumnya gitu kan
Nah itu nggak ada pattern kan
Atau mungkin kalau pengalamannya banyak
Dia tahu cara nangkis yang betul
Yang nggak tahu teorinya itu adalah jurus
Blablabla yang harus dipakai kalau blablabla
Ya balik ke definisi yang
Di layar itu konsep untuk
Mempecahkan suatu masalah
Kalau level yang paling praktikal
Ya mungkin design pattern itu kita harus tahu
Biar kalau kebetulan interview
Terjalan ditanya bisa jawab
Ya ya ya
Kalau ada interview
Bisa jawab ya, untuk lulus
Interview ya
Ya lebih ke
Kayak apa ya
Design pattern itu ya
Kalau misalkan kita tadi ya
Latihan gitu
Mungkin kita akan belajar jurus-jurus itu
Tapi pada saat prakteknya kan belum tentu kan
Semuanya dibutuhkan gitu kan
Nah tujuan kita
Menerapkan ini atau
Melatih atau mempelajari ini adalah
Nanti pada saat kita ketemu
Di project kita udah tahu
Oh ini cocoknya pakai ini gitu
Jadi secara natural keluar
Atau
Kalau ketemu masalah baru
Oh ya itu bisa
Atau kita harus ngadepin masalah baru
Biar
Oh jangan kayak gini
Bagusan lebih cocok pakai pattern itu
Kalau jenis masalahnya
Seperti ini
Nah ini analoginya disini
Resep ya, resep masakan
Resep masakan
Stepnya jelas, tujuannya ada
Oh apanya
Algoritma itu resepnya
Jadi itu
Penterapan, implementasi
Cuma blueprint itu apa sih
Cetak biru yang tadi
Yang di awal Mas Chrisa bilang itu
Kalau mau bikin bangunan blueprint
Blueprint itu mungkin kayak yang gambar-gambar
Gitu kan ya, gambar arsitektur
Gitu kan
Oh kita bisa melihat hasilnya
Seperti apa dan fitur-fiturnya apa
Tapi cara nerapenya
Cara membangunnya
Kayak mungkin naruh batanya gimana
Semain dan lain-lainnya mungkin ya
Itu nggak di jelasin disitu
Terserah yang
Membangun
Jadi pattern itu ada
Tujuan
Dan motivasi
Strukturnya seperti apa
Ini dari ini ya
Artikel ini ya
Mengandung ini
Oke
Istori nggak usah ya
Kenapa saya harus belajar pattern
Itu tadi
Kalau uang cara ditanya
The truth is
That you might manage to work as
Programmer for many years without knowing
About a single pattern
A lot of people do just that
Even in that case
You might be implementing
Signed pattern
Karena itu
Kalau kita ketemu
Pola itu berulang-ulang
Terus kita ekstrak pola itu secara tidak
Langsung akan menjadi sebuah
Pattern kan, based practice
Design pattern dan lain-lain
Bahkan kita bisa menciptakan
Pattern kita sendiri
Siapa tahu gitu kan
Siapa tahu di luar sudah ada
Walaupun kayaknya semua sudah ada
Tapi ada kasus-kasus tertentu
Yang mungkin unik
Yang belum dijelaskan
Di design pattern
Di buku atau di mana
Bisa aja jadi design pattern kita sendiri
Tapi itu dua poin keuntungannya
Jadi yang pertama adalah
Yang gue takut sih memperluaskan
Problem solving
Kita itu
Orientated design
It teaches you how to solve all sorts of problems
Jadi kita punya pandangan yang luas
Di luar sekadar masalah-masalah
Atau kode-kode yang kita temuin
Pas kita lagi kerja kan
Terus yang kedua tuh common language
Nah common language juga penting
Karena
Untuk berkomunikasi dengan
Rakan kerja dengan
Mungkin
Client kita nggak bahas ini ya
Pokoknya dengan rakan kerja
Itu kita butuh kayak gini
Kadang-kadang butuh kayak gini
Karena kita menjelaskan itu maksudnya apa sih
Kalau kita langsung bilang mungkin
Oh kita pakai
Adapter aja
Lebih cepat dimengerti
Daripada harus kita menjelaskan satu persatu
Next, criticism
Criticism
Nggak perlu dibahas ya
Inefficient solution
Inefficient use
Kadang-kadang kita suka pakai
Karena kita suka
Atau kita menguasai suatu pattern ya
Mungkin ada pattern yang we hype up gitu
Jadi semua masalah
Suruh pakai pattern itu
Iya itu juga
Nggak boleh ya, jadi lebih ke
Disesuaikan dengan
Kebutuhan aja
It depends ya, balik lagi it depends ya
Atau itu tadi jadi terlalu kaku
Karena mikir pattern-pattern yang udah ada
Jadi semua masalah harus dimasukin ke
Salah satu pattern itu
Betul, betul
Ya jangan, apapun yang terlalu
Digmatis nyebar
Nah pola dari
Pattern ini
Eh pola apa
Klasifikasi
Kategori, pattern-pattern itu ada
Tiga kalau disini ya
Ada creational, ada structural, dan behavior
Tadi kita sempat lihat juga ada
Arsitektural, ada
Eh apa tadi
Konkaren ya, konkarensi
Ada macem-macem ya
Jadi disini hanya dibahas 3
Creational
Yang berhubungan dengan membuat
Sesuatu
Object creation
Ini udah ngomongin objek ya
OP dong
Terus
Yang structural itu adalah
Object end class
Structural itu mungkin
Overlap sama
Arsitektural kali ya, structural
Termasuk ya, structural
Struktur folder, struktur
Gitu ya
Termasuk data flow
Berarti isi next.js
Ada behavior
Berarti behavioral kali ya
Routingnya
Routingnya next.js itu kayak structural
Pattern juga berarti ya, folder structure
Ya nggak sih
Eh bisa behavioral
Bukan sih, karena
Effective communication and assignment of
Responsibilities
Bisa
Bisa, kita lihat aja salah satu
Ini kan
Structural itu termasuk
Adapter, bridge
Apa lagi ya
Composite, dekorator
Dekorator ini kan
Lumayan sering kita pake juga ya, nggak sering sih
Lumayan sering kita dengar kan
Proxy
Cuma nggak pernah pakai
Proxy
Single tone itu single tone
Single tone, kalau yang
Creational, yang bikin-bikin
Factory method, kalau misalkan
Bikin testing biasanya itu ada
Factory kan, kita bikin otomatis untuk
Data
Dummy dan lain-lain untuk membuat data
Jadi kan
Misalkan apa ya, kita mau testing
Apakah data yang di entry itu beneran
Masuk dan kelihatan di layar atau nggak gitu
Nah kadang-kadang kalau kita mau
Masukin data dalam jumlah besar
Dalam jumlah banyak, kita bikin factory-nya dulu
Jadi nanti dia akan otomatis, misalkan
Saya mau 10
User baru, nah apakah 10 user
Baru ini akan muncul di halaman index
Misalkan, nah itu
Kadang-kadang pakai factory namanya
Terus ada
Prototype, prototype ini JavaScript bukan
Bukan ya
Ya apapun yang OOP
Beda
Ada Singleton
Singleton ini lumayan
Terkenal ya
Karena dia, kalau kita bikin
Object biasanya
Ketika kita inisiasi
Kalau Object itu bisa kita inisiasi banyak
Berkali-kali kan
Kalau ini sepertinya dia hanya
Satu instant aja
Jadi ketika kita bikin instance baru
Dia akan merujuk ke instance yang satu aja
Jadi nggak banyak-banyak
Tetap satu, tujuannya apa
Ada nggak disini
Oh ini problemnya ya
Problem yang mau disolve
Ensure that
A class has just a single instance
Yang kedua, provide global access point
To the instance
Solusinya adalah
Selanjang runtime cuma ada satu instance itu
Biar nggak ketimpa-timpa
Unexpected dari file ini
Ubah suatu
Kaya property-nya
Jangan sampai ada kayak gitu
Singleton
Contohnya lucu gitu dengan Men
Itu di atas
Itu atasnya
Real-world analogy yang bukan contoh
Oh iya iya iya
Gue pernah ngeliat interview
Gara-gara salah jelasin singleton
Ditolak deh
Singleton
Berarti
Yang kita bahas disini
Kebanyakan berhubungan dengan OOP ya
Ini OOP sekali ya
Instance dan lain-lain
Kayaknya OOP itu bukan
Semua itu
Filosofi
Di filosofi atau approach
Kayaknya wikinya smalltalk
Tadi juga apa ya
Ada design patterns itu ya
Karena smalltalk itu salah satu implementer pertama
Prinsip OOP deh
Jadi emang object-oriented
Fokus banget ya
Cara-cara
Pattern-pattern ini
Berarti
Kalau misalkan di fungsional
Ada design pattern
Beda lagi gitu ya
Ya fungsional kan
Bisa
Tapi kalau misalkan kayak ini kan
Instance kan nggak ada di fungsion
Berarti nggak bisa
Dipakai
Maksudnya
Kayak kelihatannya ini lebih oriented
Lebih condong ke OOP karena
Smalltalk pun pionernya
Tapi ya
Kalau di luar OOP tetap bisa pakai
Cuma ya nggak terlalu banyak
Yang lain-lain
Adapter misalkan
Adapter-an dipakai di mana-mana termasuk di fungsional
Atau di paradigma yang lain kan
Kalau kita pikir-pikir
Model view controller nggak mesti OOP kan ya
Enggak-enggak
Funksional juga bisa kan
Funksional yang khusus untuk model
Funksional yang khusus untuk view
Sama funksional khusus controller
Ya apa ya
Phoenix kan yang
Dari Elixir juga funksional programming
Tapi dia MVC
MVC itu tidak
Berpengaruh ke
Pertanyaan yang satu aplikasi
Bisa nggak nyampur-nyampur
Ada single tone-nya
Ada
Ada
Factory method-nya
Ada adapter-nya bisa nggak sih
Bisa aja
Tergantung
Modul yang mana ya
Tergantung situasi
Kalau bagian dan fungsionalitas yang sama
Pakai pattern yang berbeda ya
Posisi sama-sama komponen UI gitu
Pattern-nya
Campur-campur mungkin agak bingung ya
Tapi kalau emang
Bagian-bagian yang dikasih sama Asus
Dikasih sama Asus
Yey
Ada kejadian apa-kejadian apa
Hehehe
Oke
Iya
Sebenernya sah-sah aja nggak ada masalah
Misalkan apalagi ya
Kayak tadi single tone
Terus ada factory method
Provide interface
For creating objects ya
Banyak banget interface-nya ini
Terus misalkan
Ya
Misalkan apalagi ya
Change of responsibility ini
Chaining method bukan?
Bukan ya
Ada hubungan sama chaining method nggak?
Dulu yang pernah
Mas Rizal jelasin kayak actor kelas itu
Design pattern juga nggak sih?
Actor
Actor model
Actor model itu design pattern
Tapi yang berhubungan dengan
Di Wikipedia tadi
Ini
Tadi kan ada
Creational
Structural
Behavior
Ada konkurrensi
Ada konkurrensi
Iya
Tapi disini nggak ada
Bukan yang tadi ya
Bukan
Bukan actor model ya
Bukan
Ini problemnya apa
Problemnya adalah
Change of responsibility
Restrict access to the system
So only authenticated user
Can create orders
Step by step
Step 2 bergantung pada step 1
Step 3 bergantung pada step 2
Itu yang problemnya
Harus disolve
Sebenarnya problem umum kan
Yang mungkin kita sudah pernah solving
Tapi kita nggak pakai ini
Dan ternyata secara tidak
Langsung kita buat ini sebenarnya
Kita pakai itu
Cuma kita nggak tahu itu namanya apa
Betul
Betul
Sebenarnya ya
Middleware aja kayak gini kan
Benar nggak
Dari request ke response
Middleware-nya ada autentikasi
Ada otorisasi
Ada nambahin session
Apa segala macam baru ke response kan
Iya
Iya
Dan kalau middleware kan biasanya
Di balik
Ya abc
Nah pas ke response cba
Iya betul
Real world analogy
I need tech support press one if
Blablabla
Gimana maksudnya
You try to boot all of them
To see whether hardware is supported
Windows detected and enable
Hardware automatically
Sebenarnya pattern ini kayak
Booting operating system
Checking satu-satunya
Di cek satu-satunya
Kita kalau jaman dulu masih ada
Ya yang Linux itu ya
Satu-satunya
Check hardware ini
Satu-satunya
Strukturnya juga ini
Didesign pakai
Class diagram ya
Ada yang belajar nggak
Di class diagram
Ini class diagram
Shadow code nya
Inheritance
Nah ini
Kalau kita pencet F1
Buttonnya jadi gerai scale
Bacanya
Salah ya
For example dialog class
Which render the main windows
Of the app would be the
Of the object tree
The dialog contents panel
Oh kalau misalkan kita bikin
Ini desktop app ya
Terus ada panel setting
Ada panel color, ada button
Pakai interface
Dan class
Bahasanya apa nih? Oh prototype ya
Shadow code
Itu adalah
Tadi jantannya apa?
Ada satu lagi
Yang menarik
Yang state machine
Ada kayak disini
Nah ini state
Ya state machine
Nah ini juga sering ya
Apalagi yang pakai
Yang semenjak
Abis redux kan banyak yang pakai
State machine ya
Status status
Jadi kayak jalan pakai
Conditional state
Per request
Finish state machine
Nah ini dia
Itu kayaknya kalau kita nge-tweet itu dulu
David K. Piano itu bakal
Yang bikin apa sih?
X state
Ya
Pernah bahas
The main idea is that
At any given moment there is a finite
Number of state which a program can be
Can be in
Within any unique state the program behave differently
And the program
Can be switched from one state to another
Instantaneously misalkan kita bikin
Game, game itu kan ada berapa
State ada awalnya loading page
Loading state
Kemudian start
Game loop kan
Terus sampai game over
Itu kan state-state nya ya
Jadi apa program kita
Di definisikan berdasarkan state disitu
Dari gambar ini
A bisa ke B, tapi A itu gak bisa
Ke E, jadi kalau mau ke E
Harus lewat B, harus ke B dulu
Ya state nya
Ada istilahnya apa
Impossible state ya
Ada state yang tidak bisa langsung
Menuju kesana gitu
Jadi ini ngaruh banget kalau
Itu kan kasusnya UI nya
Masing-masing juga beda kan
Ini mungkin kalau contoh
Nah itu tuh ada contoh yang bagus tuh
Dokumen klas, dokumen bisa draft, moderation, publish
Nah ya, kebayang kan
Nah itu kan mungkin field-field yang aktif
Atau button nya yang mana yang didisable
Itu kan juga pasti bergantung sama state kan
Saya yakin temen-temen sering
Mengerjakan ini
Kalau misalkan di database itu ada status
Tapi gak tau kan
Ini ternyata state kan
Atau gak ngeh gitu, bukan gak tau sih
Mungkin akhir-akhir ini aja taunya
Perasaan dari dulu juga
Kalau kita bikin block engine kah
CMS kah apa
Pasti ada begini, ada status
Semua pasti ada status kan
Contohnya user-user
User tuh baru publish
Masih untuk email nya belum aktif
Dia harus klik email nya
Validasi verifikasi
Terus aktif, terus inaktif
Lagi login
Lagi login terakhirnya kapan
Iya kan
Kalau UI ya
Mungkin form misalnya register user
Apakah field nya udah valid semua
Atau udah nyentang
Apa itu saya bersedia blablabla
Sudah membaca
Terms and conditions yang mana sebenernya gak
Bisa dibaca juga
Itu kan juga state kan
Kalau udah memenuhi syarat semua
Di tombol submit nya
Baru bisa di pencet
Kalau udah di pencet piring data
Ternyata dibalikin result nya error
Ada field yang harus dibikulin
Mungkin lain lagi
UI
Itu state
State itu adalah behavior ya
Behavior
Comment
Tadi ada observer juga
Observer juga
Sering kita pakai
Oh comment ini
Kayak CQRS bukan sih
Ada yang tau CQRS gak
Cater juga ternyata
Comment query
Responsible segregation
Baru pertama kali
Dengar
Oh baru pertama ya
Jadi ini
Sistem arsitektur
Sebentar, contohnya apa ya
Jadi
Ketika ada
Perintah itu
Dia cuma kirim comment aja
Gak langsung dikerjain
Jadi comment itu bisa
Disimpan dan bisa
Di reply
Bisa di reply kayak ada itu
Jadi kita bisa tau tahapan-tahapan
Si user melakukan apa itu
Dari CQRS ini
Bener gak sih
Gak ada contohnya ya
Ini mirip sekali sama ini
Nah ini
Kurang lebih kayak gini sih
Jadi ada save comment
Kemudian nanti
Si save comment ini akan melakukan apa
Apa lagi yang menarik
Itu tadi
Observer
Kita sering pakai
Semua yang bahasannya
Di belakangnya ada Observer
Interaction Observer
Mutation Observer
Ini pasti ini ya
Ah iyalah
Patternya ini, jadi apa
State apa yang terjadi
Dia ngeobserve
Sebuah
Object, elemen
Dan mengobserve itu
Dan jika ada event terjadi
Akhirnya akan ketrigger
Terjadi ketrigger
Dispatch event
Kayak PubSap juga gak sih
Publisher subscriber
Sama ya
Mereka pasti tau ya
Iya, PubSap pasti tau
Tapi gak tau kan kalau ternyata masuk ke
Sini Observer kan
Itu sih selalu
Itu kan bahasa di atas event subscriber kan
Iya bener
Kita subscribe ke satu event
Sama aja kayak subscribe ke YouTube
Ketika ada video baru kita dapat notifikasi
Kurang lebih kayak gitu kan
Kalau kayak
Bahas
Ria ini juga sih gak sih
Kayak ada behaviornya kayak gini juga
Kayak event listener gitu
Atau beda ya, kalau Ria itu
Systemnya, cycle nya
Ngereload ya
Kalau state berubah dia ngereload kan
Di belakang layar
Di virtual domnya ya
Berarti kan dia
Ngeobserve state
Bener gak sih
Betul
Tapi dia punya
Coop itu ada
Dependensi
Ada kayak element yang terakhir itu
Kalau lupa masukin
Bisa ngetrigger
Terus
Karena jadi apa yang di watch
Jadi kayak variable apa yang berubah
Nah kalau itu berubah
Dia bikin keopulasi lagi
Keseluruhan virtual dom
Nah apakah itu masuk
Observer, gak tau
Kita gak tau, oke
Nah sekarang kita coba
Masuk ke patterns.tiff ya
Ini juga salah satu web
Yang jadi referensi
Dan
Bagus banget, gitu ya
Tapi yang bikin ini lebih deket
Cenderung ke JavaScript ya, karena
Memang dia orang web banget ya
Pattern focus on plane
JavaScript and Node.js
Kalau ini, kayaknya bahasanya
Lebih ke Java
Atau Google ya
Iya, put example coba kita lihat
Yang ini
Banyak, iya bisa
Gak ada masalah
Wuh, kayak gini kan
Udah bisa diterapkan di TypeScript ya
Tapi specific TypeScript dia ya
Gak ada JavaScript ya
Hanya TypeScript ya
Tuh
Gak, ada interface kan
Kalau JavaScriptnya gak ada interface
Salah satunya
Iya
Nah, ada bukunya nih
Kalau temen-temen mau baca gitu ya
Ada bukunya
Bukunnya gratis ya
Bukunnya gratis ya
Nah, ini
Mas Adi Osmani
Yang jatuhnya web
Di Chrome ya
Kita bisa dikenalin gak sama mas Robert
Adi Osmani
Coba tanya aja ntar
Ngomongin soal like house
Page speed inside
Boleh, boleh
More like Corvoid Vital kali ya
Ya, oh disini ada
Introduction juga ya, kalau kita lihat disini
Introductionnya apa
Nggak ada ya
Tuh, hampir-hampir sama ya
Ada comment pattern, ada factory pattern
Kita lihat comment tadi bener gak
The couple object
That execute certain task from
The object that calls the method
Execute certain task from the object
We have
Online food delivery platform
User can place track and cancel orders
Oke, ini ada
Order manager, ada place order
Ada track order sama cancel
Order
On the order manager class
We have access place order, ya yang tadi kan
It will be
Totally valid JavaScript to just
Use this method directly
Bisa langsung
Ini instance dulu
Instancenya langsung
However, the downside to invoke this method
Directly on the manager instance
It could happen
That we decide to rename certain
Method later on
Or the functionality on the method changes
Say
That instead of calling place order
We no rename at
Order
This would mean that we would
Have to make sure
That we don't call place order
Method
Anywhere in our code base which
Could be very tricky in last
Application, instead we want
To decouple the methods from
Manager object
Semifunctional, maksudnya kayak
Methodnya itu gak ditempelin ke
Gak di-associate very quickly
Gak jadi method
Ya, jadi
Fungsi yang terpisah gitu ya
Contohnya ini
Jadi kita bikinin satu
Method
Buat nyalainin function kan
Buat nyalainin function external
Jadi kayak bikin semacam reusable modular
Function di luar itu kali ya
Baru kemudian kita bikin
Class atau
Bikin fungsi-fungsi yang berguna
Sebenernya gak harus functional ya
Berarti bikin class lain
Tapi untuk placing
Class berupa komando, command
Untuk placing order
Ini fungsi aja disini
Oh ya, ini ada class command ya
Class command terus execute
New command
Jadi initiate
Comment
Buat dimasukin ke
Order manager tadi
Jadi order manager ini
Hanya punya satu method yaitu
Execute apa yang mau dia execute
Comment-comment nya ada disini
Jadi in case misalkan tadi
Ada perubahan
Nama
Dan lain-lain itu jadi lebih mudah
Itu ya
Si class order manager nya sendiri
Gak ngurus, gak concern sama
Placing order nya
Kalau di contoh itu dia cuma nampung
Orderannya apa aja
Abstraction
Abstraction ya
Ini singleton yang tadi
Jadi ketika
Class udah ada instance nya
Dia hanya tinggal get instance aja
Hanya punya satu
Karena mungkin kebutuhannya ya
Counter nya cuma satu
Di satu halaman itu cuma satu, gak bisa banyak
Salah satunya
Nah, seperti itu
Misalkan tadi apa lagi, ada proxy
Prototype, prototype ini apa?
To share properties among many objects
Of the same type
Constructors contain name property
And class itself contains a bar property
When using ES6
Kemudian
Observer
Ada module
Module patternnya modular ya
Kan ini udah sangat umum ya
Kalau bikin
Nulis kode ya, kalau bisa yang modular
Salah satunya dipesah
Menjadi module-module kecil
Tinggal import, iya kan?
Ini gak ada importnya
Ini export ya
Nanti bisa di import
Ini modular kan
Sehari-hari kita
Udah melakukan itu, cuman ya kita gak tahu itu
Ya itu adalah pola sendiri
Walaupun kita gak tahu nyamanya ya
Mixin, mixin juga sering kan
Middleware yang tadi
Mixin ini buat
CSS
Ini salah satunya
CSS buat SAS
Tapi disini bukan
Ya kan bisa diterapin buat apa aja
Yang lain
Object that we can use in order
To add reusability functionality
To another object or class without using inheritance
Jadi gak harus nge-extend
Class lain untuk nge-inherit
Tapi untuk langsung
Kayak langsung nge-inject functionality-nya ya
Ya, jadi misalkan disini
Kita punya ini
Class dog dengan name
Terus basic dog
That we create doesn't have any property
But a name property
Dog should able do more than just a name
It should be able to bar
Jadi kita bikin sebuah fungsi
Yang namanya dog functionality
Kemudian
Ini
Dimixin, mixing itu apa ya
Kayak dicampur gitu ya, dicampur
Sekelompok
Functionality di-inject
Kayak dimasukin ke dalam suatu
Ya, ini
Ini caranya dengan gini
Jadi dog functionality ini
Dimasukin ke dalam
Class dog
Kalau misalkan nanti ada class cat
Cat bisa bark ga?
Ya gak bisa
Kucing bisa menggonggong
Berarti ini kurang generik ya
Mungkin apa ya
Nama itu aja dog functionality
Ya, berarti
Buat siapapun yang membutuhkan dog functionality
Dulu kan ada mixing dog shadow
Ini kan kayak
Masih ribet ya
Dog shadow itu kayak masih banyak yang
Specifik property, pokoknya ya
Sekelompok fungsionalitas itu
Di-inject, siapapun yang
Membutuhkan apa maksudnya
Selektor apapun
Yang butuh
Tetap setiap shadow
Ya, jadi ketika kita
Udah bikin seperti ini
Secara otomatis
Setiap instance dari dog
Itu dia punya name
Punya fungsi bark dan play
Dan walk tail
Kira-kira kayak gitu
Nah, ini lebih di
Generalisasi
Jadi animal functionality
Bukan hanya dog, bisa walk dan
Bisa sleep
Ini bisa kita masukkan
Ke fungsinality
Si dog ini
Jadi yang tadi ada bark, walk tail dan play
Ditambahkan walk dan sleep
Wait, kok bisa pakai
Super.walk ini dari
Gimana ceritanya
Dari si
Bapaknya
Kan ini nanti bakal di-assign ke
Dari sini ya
Di-assign ke
Prototype
Ke kelas
Yang mana itu ya
Design dulu, abis itu
Design lagi ke dog prototype
Ya, ya, ya
Itu kayak setara
Inferil
Tapi nggak mikir
In terms of class, tapi in terms of
Functionality-nya
Yes
Ada
Apa lagi yang menarik
Discourage
Discourage the use of machine
Gunakan higher
Order component instead
Ya, karena memang react itu kan dia sangat
Lumayan
Akibatnya ke fungsinality kan ya
Jadi dia lebih memilih
Menggunakan function
Yang apa, pattern-pattern
Functional dibandingkan pattern-pattern
Object
Orientate
Oke
Machine udah, middleware tadi
Kurang lebih udah ya
Lagi factory juga udah, animating
View transition
Ini beda ya
Ini apa nih
Udah beda-beda ya
Static input, dynamic input
Lebih ke front-end ya
Ya, lebih ke front-end
Goal, nggak ya
Ini design-pattern plus campur-campur
Yang
Wah, kagum
Oh nggak, nggak goal
Tapi masih menang kan
Oke, sekarang kita balik lagi
Kesini ya
Pertanyaan ya
Kita jawab pertanyaan aja ya
Secara ideal, design-pattern ini
Tentukan berdasaran apa
Berdasarkan what
Behavioral, structural
Tadi kan
Bukan, tadi, ada jawabannya tadi
Di itu, di structure
Guru
Di mana, disini, yang disini?
Di paling awal
Di design-pattern
Maksudnya
Di alamat pertama
Turun ke bawah sedikit
Berdasarkan
Intent dan motivation-nya
Tujuannya apa
Dan
Problem apa yang
Di-solve
Dan pakailah pattern yang
Sesuai
Jadi
Berdasarkan
Misalkan nih, contohnya
Mau bikin sistem payment gateway
Apakah cocok kalau kita pakai design-pattern berbasis service?
Pertama
Payment gateway yang mau dibikin, ada banyak nggak?
Iya, misalkan kita mau
Ada banyak, kalau satu aja
Atau ada banyak
Iya, kalau misalkan kita mau
Connect payment gateway-nya ke mid-trans
Terus ke mana tuh
Ke mana lagi ya
Ke
Bitcoin
Bitcoin, ya Bitcoin, atau
Apa itu?
Nah, pokoknya payment gateway lain gitu ya
Ada banyak gitu pilihannya
Nah, itu kita bisa pakai adapter
Jadi bisa ganti-ganti
Kalau misalkan cuma satu
Singleton aja singleton ya
Cuma satu ya, udah
Satu aja
Jadi
Dan pattern ini
Nggak harus diterapkan
Ketika awal project
Bisa aja di tengah-tengah
Atau lebih seringnya malah begitu kan
Awal-awal mungkin karena terlalu simpel ya udah
Nggak usah mikirin
Terlalu mikirin
Tentang design pattern dan lain-lain
Dan kayaknya di bagian-bagian
Desap-desap bagiannya bisa pakai
Macam-macam design pattern kan, kayak misalnya tadi
Apa tuh, chain of responsibility
Pasti at some point, pasti ada kan
Yang handler satu per satu
Proses kayak apa payment gateway
Ngecek credential user lah
Dan lain-lain, pasti kan aja
Kecuali
Kalau mau bangun dari awal
Sudah tau project-nya gede nih
Kayak
Project besar dah, yang apa sih project yang gede itu
Kayak Cortex misalnya
Mungkin sudah bikin asistektur
Diagramnya dan
Setiap modul-modulnya itu sudah
Sudah ada gambaran mau ngapain
Dan apa yang akan terjadi
Dan setiap modul mungkin ada design patternnya sendiri
Dan bagaimana mengkonektikan antar modul
Punya patternnya sendiri
Dan itu yang ngedeside ya
Biasanya, sistem arkitek ya
Sistem arkitek ya
Betul
Jadi
Kembali lagi ya, tergantung kepada
Scope
Dari project-nya
Team-nya
Yang kayak misalkan micro service monolitik itu
Itu pekan juga enggak?
Arkitektur itu ya
Arkitektur ya
Seandainya kalau cuma mau bangun
Company profile yang cuma 5 halaman
Ya udah, static site generator
Aja udah
5 halaman tidak berubah sama XML aja
Tidak usah SSG juga
HTML aja udah, HTML SSG
Doang cukup gitu kan
Oke
Mudah-mudahan jawab ya
Waktu memilih
Ini juga bingung ya, ini design pattern
Kita jarang sekali, tapi ya nggak apa-apa
Kebanyakan company besar itu
Pake design pattern seperti apa?
Maksudnya design pattern apa?
Biasanya nggak tahu
Tapi pasti lebih dari satu nggak sih
Kalau dilihat dari itu ya
Contoh-contoh tadi
Masa sih seluruh codenya Google atau Meta
Cuma pakai factory
Cuma pakai adapter
Pasti kombinasi macem-macem
Pertama, saya jawab dulu
Perusahaan besar itu nggak pakai
Satu aplikasi doang
Mereka punya ratusan aplikasi
Yang mereka gunakan
Ada aplikasi HR, aplikasi
Marketing
Ada marketing CRM
Terus kemudian ada
Macem-macem ya kan
Jadi tergantung setiap
Aplikasi atau setiap solver
Yang mereka gunakan punya partner sendiri
Ya contohnya operating system
Jangan kan
Setiap
Aplikasi punya sendiri
Satu halaman ini aja
Bisa aja mereka
Menggunakan bahkan framework
Yang berbeda
Dalam satu aplikasi
Terus ada banyak juga
Bagian-bagiannya
Bisa aja lebih dari satu design pattern
Lagi-lagi berdasarkan deskripsi tadi
Bisa aja ada factory
Untuk UI komponennya
Tapi ada chain of
Apa tadi yang buat
Chain of responsibility
Yang buat
Bisa nge-check user
Kalau udah, maksudnya dia
Admin atau bukan
Di repo ini bisa ngapusin
Komentar atau engga
Ya kan pokoknya pasti ada
Turut-turutannya kan
Ya betul-betul
Dan bisa
Apa ya, bisa
Dicampur-campur juga
Bisa macam-macam ya, bisa dicampur-campur, bisa digabungin
Bahkan di satu modul pun bisa
Menggunakan lebih dari satu
Pattern kan, tergantung
Apa yang mau dicapai tadi
Yang intinya adalah intent tadi ya
Observe untuk ada notifikasi baru
Atau engga misalnya, ya kalau
Di satu aplikasi yang sebesar ini
Pasti banyak kan pattern yang dipakai
Betul, betul
Jadi, kita gak bisa
Apa ya, gak bisa menjenderalisir
Oh kalau perusahaan gede itu pakenya yang ini
Perusahaan yang menengah
Kebawa pakenya ini, gak bisa
Jadi, memang
Tergantung kebutuhan, tergantung
Jenis aplikasinya, tergantung fiturnya
Banyak ya, it depends-nya
Banyak
Jadi, kita gak bisa
Tau ya, kecuali kita tanya
Tapi mungkin kalau ngomongin
Architectural atau structural
Kayak MVC gitu ya, mungkin lebih
Dimasukakan dalam satu aplikasi
Satu approach
Tapi kalau yang contoh-contoh pattern tadi
Bisa dicampur kan
Betul
Kalau web
Salah satu yang paling
Banyak dipakai MVC kan
Kalau web ya
Mungkin kalau aplikasinya
Kayak Android atau IOS
Itu mereka kadang-kadang punya
Pattern masing-masing
Ada MVVM
Ada viper lah, ada macem-macem
Jadi, mungkin itu
Bisa ditanyakan
Pada saat interview
Atau pada saat kuliah
Oh iya, betul
Compose
Itu pattern ya?
Kayaknya sih pattern
Biasanya
Gak tau, saya pernah lihat juga
Kalau misalkan loongan, misalkan familiar with IOS
Or Android, terus ada MVVM
Ada apa gitu
Familiar with MVVM pattern
Nah itu bisa dilihat di
Loongan pekerjaan
Kalau yang sifatnya itu structural ya
Structural ya
Maybe
Maybe
Itu interactnya tuh tips
Tips
Yang mau memahami design pattern
Seperti apa
Diluar komunikasi ke senior dan baca
Dokumentasi projek
Sering-sering nge-freelance
Sering-sering pindah company
Jadi pindah aplikasi yang dipacar
Sering-sering nge-code-in open source
Itu jadi jago prakteknya
Tapi kan
Tidak tentu tahu itu nama design
Patternnya apa ya
Bisa juga, sudah praktek
Terus kembali lagi ke teorinya
Ada open source
Setiap kali coding, nanya maintainernya
Ini betul patternnya ga sih?
Annoying sih
Tapi kita jadi tau
Kalau latihannya gimana ya?
Maksudnya
Apakah kita, disini kan memang jelas ya
Ada contoh code nya kan ya
Terus
Supaya bisa kita melatih itu
Gimana ya?
Baca ya
Kita coding biasa, pas kita lagi bikin sesuatu
Kita coba matchingin
Kita nebak dulu, ini singleton bukan sih
Kita tanya atau
Team lead atau maintainer
Kalau open source atau apalah
Ga tau, ini gue juga belum pernah
Ini teori doang
Karena kalau mulai dari singleton
Kita suruh coding singleton doang
Gak bisa ya
Kita disediakan dulu, baru kita mikir
Oh mungkin ini singleton nih
Tapi kan kita butuh di confirm ya
Ya mungkin tanya ke AI kali ya
Apakah betul ini contoh
Codo dari desain pattern singleton
Iya
Benar juga
Kalau kita misalkan kita
Kita ambil salah satu dari sini
Terus kita bikin sesuatu
Kayaknya kebalik ya
Jadi apa solusi yang mencari masalah
Yang mencari solusi
Iya betul
Agak
Agak triki dua ya
Cari-cari masalah dia
Masalahnya ga ada
Kan masalahnya ga ada, kita mau belajar aja gitu
Iya kan
Ya harus sering mungkin ini ya
Ada ini juga itu
Ada perumpamannya, kayak baju
Sebenarnya
Bukan baju yang
Sorry
Bukan kita yang menyesuaikan ke ukuran baju
Tetapi baju lah yang menyesuaikan ke ukuran kita
Lebih sering
Mungkin salah satu tipsnya adalah
Sering-sering baca kode ya
Kita bisa
Belajar teorinya dulu
Tujuannya apa
Ini menolong masalah apa
Jadi ketika kita loading beneran
Bukan cuman latihan
Ternyata ini cocok buat
Dipakai singleton nih
Kita tau, ya pasti kayak gitu sih
Sering-sering baca kode sama sering-sering nulis kode
Itulah standar ya
Tips dia
Kalau non-conventionalnya
Dokumentasi dari refactoring guru itu
Misalnya masukin ke LLM
Misalnya jembenai atau apalah
Terus setiap kita coding
Kita jelasin aja
Masalahnya ini saya menyelesaikan dengan
Patter singleton
Contoh kode ini
Betul atau enggak
Biar kita serahkan
Perkembangan skill kita pada LLM
Dia ngejawab
Oh bukan, atau kita nanya apakah
Ada pattern lain yang sebaiknya kita pakai
Gak tau, ini yang
Experimental, solusinya
Pasti gitu
Benar-benar
Tanyaan dari penonton tuh
Gimana caranya biar CQRS
Sama Event Sourcing bisa jalan badangan tanpa sistem
Jadi ribet
Kita CQRS aja nggak tau
Masih nebak-nebak
Itu yang tadi nasi desa bilang kan
Yang di awal baru
Tapi jadi nggak tau
Iya, cuman ya
Prakteknya gimana nggak tau
Kenapa harus
Pakai dua-duanya
Nggak bisa salah satu
Karena ketika sebuah sistem
Menjalankan satu
Atau lebih dari satu
Apa ya, arsitektur
Atau pattern
Pasti akan jadi kompleks
Ujung-ujungnya ribet
Event Sourcing ya
Event Sourcing itu apa
Design Pattern juga nih katanya
Menurut Gemini
Design Pattern
Where changes to an application state
Are stored as a sequence of immutable events
Nah, tadi yang saya jelaskan itu
Maksudnya
Yang mana?
Yang tadi kayak CQRS
Jadi CQRS itu
Yang sepengetauan saya
Ternyata salah ya
Itu dia
Perubahan state
Itu disimpan
Ke event-event
Jadi dia nyimpan event aja
Misalkan insert data, update data
Delete data, gitu
Dia nyimpenya
Dalam bentuk event
Comment ya, state
Terus nanti baru dijalankan
Ceritanya
Berarti kayak
Queuing dong ya
Kurang lebih
Kayak
Queuing, jadi sudah di queue
Nanti baru dijalankan satu-satu
Ke service yang perlu menjalankan
Yang bisa menjalankan comment itu
Betul
Message queue, message queue ceritanya
Yes, kurang lebih
Ini ada
Dari Stack Overflow
Yang sudah jarang dibuka
Semenjak ada
Ada chatbot
CQRS
Creation of two object
Where there was previously only one
Bukan? Salah kan?
Apa ini? Kok nggak ngerti?
Nggak ngerti
Typically this means that each of
The object will use different representation
Of data
Tergantung purpose-nya
Commonly used here, write model
Read model, jadi kalau misalkan
Ada, kalau misalkan kita pakai MVC kan
Model VA Controller
Itu mau delete, mau update, mau itu kan
Satu model itu, kalau ini dia write
Berbeda, read-nya berbeda, jadi dipisah
Kayaknya ya
The key benefit here
Is that you can tune the data
Structure for your read
Use case and your write
Use case independently
Jadi kan ada beberapa database yang
Cepet untuk read
Tapi lambat untuk write, begitu juga sebaliknya
Mungkin ini yang bisa jadi solusi, mungkin ya
Kalau event sourcing
Yang tadi
Yang tadi sudah disempat saya ilaskan barusan
Dia
Apa nih?
Kok nggak ada?
The system by replaying
That series of events, jadi kayak queuing
Jadi si comment-nya itu
Bisa di queuing
Oh berarti emang
Pasangan ya?
Nah ini pertanyaannya adalah
Ribetnya dimana?
Kita nggak tahu soalnya
Apa yang bikin ribet gitu
Karena kita nggak pernah pakai
Sample-nya mungkin saya pernah pakai
Ya kan bener ya, kalau kayak
Itu tadi ada contohnya
Nah bener kan
Kalau kita
Untuk read queries itu pakai yang cepat
Seperti redis
Kalau yang write-nya cepat itu pakai
MySQL atau MongoDB
Misalkan
Itu CQRS
Event sourcing itu yang Pub/Sub seperti MQ
Ya event sourcing ya
Kalau digabung
Ketika ada
Event untuk menyimpan data
Dia akan simpan di
MySQL
Kalau ada kebutuhan
Untuk read, dia akan
Mengarah ke read model gitu ya
Berarti event sourcing
Ini lebih ke source-nya ya
Database-nya yang mana ya
CQRS ini lebih ke
Memilah
Ini model untuk read
Ini model untuk write gitu ya
Kalau event sourcing
Lebih ke Pub/Sub
Nah tapi kan ini contoh doang ya
Contoh doang
Contoh doang, iya
Sepertinya kita tidak bisa menjawab
Secara utuh ya
Harus itu dulu
Harus konsultasi dulu
Harus interview dulu
Ini CQRS-nya dipakai
Buat apa, event sourcingnya
Di level system kan
Iya, kita nggak bisa
Pertanyaan sangat
Spesifik dan kita nggak tahu konteksnya
Kita juga nggak ngerti CQRS sama event sourcing
Baru teori doang
Ini juga belum ngerti sepenuhnya
Jadi belum bisa menjawab ya
Oke, ada pertanyaan menarik lagi
Iya
Kalau di front-end tadi kita
Udah bahas ya di patterns.dev
Teman-teman bisa langsung ke patterns.dev aja
Ini ada
Pola-pola yang berhubungan dengan
Back-end
Ya, back-end yang ini kurang lebih ya
Karena dia kan bahasnya JavaScript
Dan Node.js ya
Yang front-end juga ada
Misalkan ketris checking
Road-based splitting
Bundle splitting
Preface preload
Kayaknya ada lagi deh
Ada ya
Udah segitu aja ya, oke
Itu yang lengkap banget ada di bukunya
Oh iya, bukunya ya
MVC
Di front-end juga ada yang MVC
Ada dulu namanya Ember.js
Itu dia pakai MVC, tapi udah
Sudah tidak begitu
Terdengar lagi sekarang
Masih di-maintain nggak sih?
Coba aja lihat
Ember.js
Malah dia lebih duluan
Malah kalah sama Angular
Angular aja masih
Masih
Kedengeran gitu
Masih 4 hari yang lalu
Ya, ini
Dia pakai MVC
Setau saya, dan ini front-end
Design pattern sama design
Arsitektur sepertinya beda
Iya, beda
Yang satu pola
Yang satu arsitektur
Tadi ini udah kita bahas ya
Smartdom pattern
Ada Smartdom component
Ada presentation
Container
Container, iya betul
Dia dulu pakai container yang
Yang ada state, dia itu container
Yang
Cuma view doang itu
Dump component ya
Terus
Apa nih
Bahas security hole di Next.js
Yang kemarin ya
Baru kita bahas tentang security ya
Tiba-tiba ada security hole
Critical nya 9.1
Belum 10 sih
Belum 0 day
Wah ada event apa tuh
Kita mau dong Papsap
Kalau ada GUL
Kayaknya kejadian yang hampir GUL
Atau kebobolan
Masih 1-0
Masih 1-0
Mantap
Oke
Next
Kita bahas
Kita ga gitu ngerti sih ya
Problem utamanya apa?
Ada yang tau ga sih, tail dare nya
Authentication kayaknya ya
Oh, oke
Bisa di bypass
Oh wow
Pakai
Custom header
Yang bikin heboh adalah
Di Cloudflare
CEO nya Cloudflare bilang
Ya gausah pake Fairsell, pake Cloudflare aja sih
Kita sudah patch header itu
Terus dibalas lagi
Sama CEO nya si Fairsell
Iya
Kalau udah patch kenapa ga di pull request ya
Bukan
Di block
Custom header itu di block
Cuma kalau custom header itu di block
Ada yang ga bisa working
Kayak super base kayaknya
Atau ada base tertentu yang menggunakan
Menggunakan
Custom header itu
Hmm
Ya
Kompleks
Ya, drama lah ya
Kompleks juga sih
Masalahnya
Bug nya terjadi karena logic
Jadi logic bug bukan karena
Bukan karena
Bug ke goblokan
Bukan goblok
Bukan goblok Mak
Ini berarti karena kompleksitas
Maksudnya kompleksitas kebutuhan ya
Ya, pure complexity logic
Mak
Hmm
Oke
Kemarin saya tanya-tanya AI
Tentang SSR, dia bilang kalau SPA
Juga bisa SSR menggunakan
VT
SPA, React, Vue
Juga bisa SSR, bisa
VT ada server nya kan
Ada plugin nya, tapi engga
Bukan by default
Harus di install dulu
Hit server ya
Iya, bisa-bisa
Dari dulu juga bisa
Yang CSR juga kita bungkus pakai express
Bisa jadi SSR kok
Sebenernya
Bisa-bisa aja
Misal di aplikasi kita hanya butuh sebagian
Membutuhkan SEO, apakah mending pakai VT
Atau langsung Next.js VT
Jangan
Jangan apa-apa Next.js dulu
Ya, misal di aplikasi kita hanya butuh
Sebagian yang membutuhkan SEO
Saya lebih mending
Aplikasi yang hanya untuk
Frontend yang untuk SEO sesingin
Pakain WordPress aja
Aplikasi internal bikin lah pakai
Next.js atau pakai
Content, aplikasi-aplikasi
Dipisahkan aja
Jangan, kalau jawaban gue lain
Butuh fitur-fiturnya Next.js engga
Butuh build and whistle nya
Next.js engga, kayak yang otomatis
Handphone optimization
Image optimization
Routing nya
Routing nya banyak
Denerbit atau engga, pokoknya
Fitur yang apa
Itu kan mempermudah hal-hal kompleks ya
Kalau misalnya website nya besar dan emang butuh
Itu semua ya udah pakai aja
Tapi kalau engga terlalu butuh
Kalau namanya dikit ya udah
Web sama
Router-router yang sebetul-sebetul
Sekarang kan banyak-banyak kan
Alternatif lain mungkin
Astro bisa jadi pilihan juga karena
Astro bisa kita set kan, oh saya mau
Ini client saya render, oh saya mau server saya render
Oh saya mau, by default engga perlu
JavaScript, terus misalkan di bagian bawahnya ya
Island, Citilator gitu-gitu
Kayaknya bisa juga, gitu
Jadi kalau misalkan mau jadi satu aplikasi, engga mau
Dipisah, aplikasi nya tetep sama
Framework nya tetep sama, ya bisa pakai
Astro, karena Astro juga bisa pakai
Vue, bisa pakai React, mau
Gak suka Vue atau React, bisa pakai
Svelte gitu kan, jadi
Cukup flexible lah ya
Kalau yang simple banget
Malah Vite sama React Router
Udah jalan ya
Kalau misalnya simple banget
Dan engga pengen pakai Framework ya, kasusnya
Gak butuh rasa, engga butuh sama
Offeringnya reksial, Astro
Ya setiap
State internal nya React aja
Misalnya cuma butuh itu ya Vite dan React
Router, udah cukup ya
Yes
Pertanyaan berikutnya, baru tau
Ternyata engga cuma back-end API doang
Yang bisa di blockir, sekarang gambar pun
Bisa, ah namanya Corp
Oh, Corp ya
Kalau dulu Corp, sekarang namanya Corp
Gitu ya, kepanilannya apa?
Ya itu buat gambar mungkin, ya coba aja
Picture ya, cross origin
Cross origin, resource, picture gitu
Bener ini, origin
Resource
Picture
Policy
Adanya resource policy
Kalau dulu kan
Kita sering pake htaccess
No, ini hotlinking
Kalau di hotlinking image kita
Dibikin no hotlinking
Ini adanya
Corp
Cross origin resource policy
Oh ada nih resource ya bentar
Ada co-op
Corp course
Coba buka deh hit nya
Banyak banget
Snigel
Kayaknya bisa
Pembahasan sendiri deh course ini segala macem
Dan brossel integrity
Nanti kita bahas sendiri deh ini
Brossel integrity, course
Terus kemudian
Corp
Langsung aja kita tulis
Wah
Sign in dulu ya, oke
Saya klik aja disini
Ya, jadi
Ada banyak ya, ada course
Yang biasa kita kena tuh
Kalau main-main api
Ada co-op, ada co-ep
Apa nih, kita pengen tahu aja
Nah ini dia
Kalau kita
Mau loading
Ads, font, video, image
Maps, dan payment solution
Content security policy
Berarti ya
Source, font, script
Betul
Berarti
Course origin, embedded
Policy, course origin
Opener, policy
Makanya semua terkait header ya
Iya
Jadi ada yang boleh ditampilkan
Ada yang gak boleh, itu diatur disini ya
Biasanya harusnya, yang paling
Yang paling aman kan same origin ya
Window opener
Ini bisa kita bahas
Nanti
Jadi material sendiri
New discussion
Browser security lah bahasanya
Browser
Security
Ya
Policy ya
Oke, ada macem-macem
Nanti juga sekalian kita sambungin ke itu
Ke
Content security policy
Ya
Apa lagi ya
Ya udah policy kan chat-nya
Yes
Strict transport
Strict transport
Yes
Yes, protection header banyak
Oke, ada lagi yang mau ditanyakan
Gak ada ya
Sudah berapa score-nya
Masih 1-0
Indonesia bakal lulus gak
Masih ada kemungkinan lulus
Pilar dunia
Masih kalau menang ya, bener gak
Iya, ini masih
Keringkat ke-4
Kalau keringkat 3 atau 4 itu
Ada 1-2 lagi playoff
Berarti masih ada harapan
Masih, cuma
Terus ya
Mungkin gak
Minimal lulus ke
Round selanjutnya
Oh, jadi
Kalo misalkan peringkat 2 atau peringkat 3
Terbaik, nanti dia akan
Tanding lagi sama lawan yang lain
Nanti baru bisa masuk gitu ya
1-2, 1-2 itu
Langsung lulus ke babak pinjisi
Yang ke dunia, 3 dan 4-nya
Diadu lagi sama 3 dan 4 yang lain
Oh, iya iya iya
Oke
Oke, kalau gitu untuk malam ini
Cukup?
Cukup ya
Kalo misalkan
Ada yang kurang
Kita minggu depan liburkan ya
Minggu depan kita libur
Sementara, lebaran dulu lah
Kalo nanti misalkan
Oh, mau dibahas
Sekarang?
3 menit aja
Boleh, siap siap siap
Kalo temen-temen nanti
Ada yang mau dibahas lebih lanjut tentang design pattern
Bisa langsung kesini ya
Nanyain lagi, nanti kita jawab lagi
Karena kita pun
Gak belajar gimana-gimana
Tentang design pattern sebenernya
Jadi kita juga agak-agak bingung juga
Mau bahas apa
Dari sisi mananya
Oke
Kalau kita anggap itu selesai, berarti
Kita berdasarkan
Bedah situs mau
Yuk, bedah situs
Bedah situs, oke
Bedah situs baru ada satu
Yang tadi
Iya
Yang tadi
Boleh, boleh, boleh
Bedah situs ya
Kalo temen-temen ada
Ada website yang mau di bedah
Baik itu secara performance
Apa lagi ya
Aspeknya apa? Security, performance
Maksudnya dari course ya
Security policy, content security policy
Dari browser security
Mungkin desainnya
Minta di apa
SEO-nya
Apa lagi
Ya performance yang ukuran
Blocking ke apa segala macem
Ya itu performance yang masuk performance
Best practice, best practice
Kodenya mau dikomentarin
Boleh, silahkan ya
Silahkan
Tulis aja disini
Website-nya, ini contohnya
Saya seng-seng bikin
Website buat ngobrolin web
Jadi kalo
Kalo temen-temen punya website
Pribadi atau project yang mau
Di bedah
Nanti kita dahulukan
Yang temen-temen dulu ya
Ini cadangan aja
Oke, berarti
Ini episode 2 minggu lagi ya
Untuk pedas titus ya
Oh ini ada gak?
Share github-nya, baru join
Ada di kesana.in/ngobrolinweb
Langsung aja
Ini kita kasih
Shortener-nya
Atau github.com/ngobrolin
Sama
Oke, cukup
Cukup ya
Cukup
Oke, kalo gitu
Terima kasih banyak buat temen-temen semuanya
Yang sudah meramaikan
Sambil nonton bola
Kita ketemu lagi
2 minggu lagi
Karena minggu depan
Lebaran, jadi sekalian aja
Buat temen-temen yang merayakan
Selamat lebaran
Yang mudik juga hati-hati di jalan
Selama sampai tujuan
Itu aja buat malam ini
Terima kasih banyak semuanya
Selamat malam, 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://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
9 Agu 2023
Ngobrolin URL
Episode ini bagian dari niat baru mereka: menyelipkan topik yang benar-benar mendasar setidaknya sebulan sekali, alih-al...
16 Apr 2025
Ngobrolin CORS & Browser Policy
Episode Ngobrolin WEB ini membahas secara mendalam tentang kebijakan keamanan browser (browser security policy) dengan f...
2 Jan 2024
Yang Seru di 2024
Episode ini membahas tentang hal-hal seru yang dinantikan di dunia web development pada tahun 2024. Para host membahas p...
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 .