File Upload Strategy
Ringkasan Episode
Bantu KoreksiEpisode ini membahas berbagai strategi upload file dalam pengembangan aplikasi web. Eka dan Ivan berdiskusi tentang trade-off dari setiap pendekatan mulai dari local storage, database blob, hingga cloud storage seperti S3, GCP, dan Azure. Diskusi dimulai dengan cerita horor pengalaman masa lalu ketika menyimpan file di server yang sama dengan aplikasi, masalah scalability, hingga solusi modern menggunakan cloud storage. Topik ini diajukan oleh Kaisa yang memberikan konteks diskusi yang lengkap.
Poin-poin Utama
- •Local storage (menyimpan file di folder server) adalah solusi paling sederhana namun memiliki masalah scalability ketika aplikasi perlu horizontal scaling
- •Menyimpan file sebagai BLOB di database umumnya tidak direkomendasikan kecuali untuk use case sangat spesifik seperti avatar kecil yang jarang berubah
- •Cloud storage (S3, GCP Storage, Azure Blob) adalah best practice untuk aplikasi modern karena mendukung horizontal scaling dan CDN
- •Biaya cloud storage biasanya dihitung berdasarkan bandwidth transfer (transfer in/out) bukan jumlah file atau storage size
- •MinIO adalah alternatif open source yang kompatibel dengan S3 untuk self-hosted atau development environment
- •Tools modern seperti Docker, Docker Compose, dan Local by Flywheel mempermudah development workflow
- •Pemilihan strategi harus berdasarkan analisis trade-off antara performa, keamanan, biaya, dan user experience
(musik)
Halo!
Halo-halo!
Udah nggak boleh katanya telolet-telolet.
Hah? Nggak boleh?
Iya, di jalan.
Di itu? Apa?
Eh, nggak tahu ya?
Antara telolet itu apa yang punya-nya pejabat, nggak boleh bunyi lagi.
Wup-wup-wup-wup.
Itu strobo.
Oh, strobo ya, nggak boleh ya?
Strobo ya, namanya ya.
Masa sih nggak boleh?
Iya, kemarin di Razia.
Nggak mengganggu sih.
Emang kena Razia ya sekarang ya?
Iya.
Kalau bukan lagi tugas kena negaraan, nggak boleh pakai.
Oh, iya.
Nanti semua jadi tugas negara.
Oke, anyway.
Selamat malam semuanya.
Semoga...
Malam ini...
Banyak umur dan sehat selalu.
Semoga...
Semoga teman-teman semua baru gajian ya, akhir bulan, awal...
Besok, awal bulan.
Hmm...
Lihat transkrip lengkap (2491 segmen lagi)
Jadi semangatnya masih ini ya, masih full ya.
Biasanya kalau gajian itu awal bulan apa akhir bulan?
Kalau diaktifkan, akhir bulan.
Tergantung pesan kan?
Jadi sebelum tanggal 1 udah...
Jadi minggu terakhir ya teman-teman?
Hari ini, hari ini.
Kepat hari ini.
Kalau teman-teman yang lain, saya rasa mungkin tanggal 25 udah gajian ya.
Beberapa, beberapa yang lain.
Pemilik ini, biasanya kalau bagi founder atau pemilik...
Biasanya kalau lagi gajian itu agak merengut dia.
Agak pusing gitu.
Langsung berkurang...
Cash flow.
Cashnya berkurang langsung kelihatan gitu ya.
Karena langsung mikirnya cash flow gitu.
Betul, betul, betul.
Kalau pekerja remot, tanggal berapa?
Sama kan? Sama aja kan?
25 gitu?
Enggak lah.
Kita jatuhnya freelance ya.
Atau apa kontraktor namanya?
Kontraktor lah ya.
Kontraktor, jadi 3 hari-harian?
Bisa jadi, 3 hari-harian.
Kalau kayak teman saya, maunya dia mingguan.
Jadi setiap minggu kirim voice.
Ya, setiap minggu kirim voice.
Jadi macam-macam lain.
Kalau ada yang company-nya per...
Biasanya kirimin voice, nanti +5 hari, +10 hari baru cair.
H+5 lah, bisa H+5 sampai H+15.
Lata-lata begitu.
Jadi bukan kayak ATM deh, nggak ada yang kayak ATM setau saya,
yang kayak kirim besok keluar nggak ada.
Biasanya H+15.
Tapi nggak otomatis kan harus kirimin voice kan ya?
Ada yang sistemnya sudah...
Sudah reka ring gitu langsung?
Ada yang sistem invoice, ada yang system invoice, ada yang nggak.
Kalau tergantung negaranya sih mas.
Kalau beberapa negara yang...
Kan biasanya kalau kita mengirumkan voice kan itu buat bukti ke mereka sebenarnya.
Buat pencatatan ke accounting mereka dan untuk urusan-urusan pajak sebenarnya.
Anyway, ada macam-macam lah caranya.
Dan saya menuruti apa katanya aja, bagaimana begitu caranya sistemnya.
Ya begitulah, dilakukan.
Wah, iya iya iya eka muncul.
Muncul.
Sudah selesai kerjanya.
- Udah. - Belum.
- Tapi belum. - Eka nih gimana?
- Apa? - Invoice-nya per...
- Invoice-nya per bulan, per... - Gaji.
Gajinya per harian, mingguan atau bulanan.
Iya.
Bulanan.
- Bulanan. - Perlu kirim invoice ya?
Iya.
- Oh kirim tiap bulan? - Iya.
Kalau nggak kirim berarti nggak digaji gitu.
- Enggak, tapi diikuti. - Lupa misalkan.
- Jadi pernah. - Oh diikuti.
Iya kalau, iya di proses kalau udah kirim.
- Dan... - Kan outside contractor bahasanya ya.
Iya benar, providing ya consultancy lah.
Intinya menyediakan jasa expert.
- Oke, oke. Menarik. - Terus adur dingnya gitu.
Apanya jadi kayak itu emang hal yang wajar untuk menggaji,
membayar jasa suatu apa?
Consultant.
Hmm.
- Iya. - Oke.
- Iya, kita lihat gaji. - Kalau founder?
- Kalau founder? - Kalau founder, kenapa?
- Digaji nggak? - Founder nggak digaji, Pak.
Digaji.
Tapi dipotong gajinya.
- Nggak full, nggak full. - Demi kemaselatan perusahaan.
Tapi maksudnya itu gaji, start, bukan income, bukan apa gitu.
- Itunya salary. - Salary.
Salary, posisi sebagai founder.
- Nggak lah, kan ada posisi. - Iya, kita menggaji.
Kan ada jabatan ini juga, operasionalnya.
- Oh. - Iya.
Jadi ibaratnya kalau misalkan masih founder-foundernya aja, misalkan berdua, bertiga.
Kita seolah-olah kalau misalkan duitnya belum ada, misalkan masih bootstrapping,
masih kumpulin duit, kita menggaji diri kita sendiri, sepantasnya.
Karena kita kan bekerja.
Kecuali kalau kita meng-hire orang untuk kerjain pekerjaan kita, kita nggak kerja, ya mungkin ya.
Nggak digaji, ya.
Enak nih, kapan-kapan kita cerita suka-duka.
Suka-duka startup dan founder dan cashflow.
Kalau sekarang kayaknya masih berduka ya, jadi kayaknya nggak enak ceritanya ya.
Nantilah ya, kalau sudah mulai ada titik cerah ya.
- Selamat malam. - Kalau udah ganti jadi...
Apa itu? Abis winter apa sih? Spring ya?
- Kalau udah jadi spring. - Spring.
- Kalau udah jadi spring ya, kalau udah exit ya. - Take winter.
- Amin. - Amin.
Eh ngomong-ngomong exit itu EA, tau nggak sih EA? Game?
- EA? Oh iya. Kenapa? - EA yang football itu.
- Dibeli kan? - Iya, dibelis.
Iya, 900 triliun coba.
- Dibeli sama siapa? - Diakuisisi.
Dibeli sama investor Silver Lake sama Saudi Arabia punya konsorsium gitu dah.
- Waduh. - Sultan-sultan lah, konsorsium.
Sepada sultan-sultan membeli EA.
- Itu kayaknya kalau yang Saudi pemerintah deh. - 900 triliun.
Duitnya dari pemerintah.
Iya, mereka pemerintah itu bikin konsorsium, yaitu yang...
Apalah yang beli-beli pemain bola in real life juga, itu punya klap-klapnya itu kayak intinya dapet duit dari pemerintah.
Karena pemerintah sadar, ya duit minyak kan, minyak kumi kan nggak bakal ada forever.
Jadi ya emang diputar lah.
Saya cuma mendoakan aktifin exitnya kayak gitu ntar.
- Amin. - Exitnya kayak EA.
- Amin. Triliun ya. Jangan nyampe sih. - Amin, amin, amin.
Amin, amin.
- Kita makan-makan dong, Red. - Oke.
- Gila. - Oh iya. Boleh.
Makan-makan sama minum-minum pasti. Kalau nggak selalu gini kan, seret kan.
Itu juga.
Oke. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Terlalu jauh belanturnya. Terlalu jauh belanturnya. Terlalu jauh belanturnya.
Nanti ini bisa kita upload file-file-nya dulu. Nah upload-nya itu bisa ke contohnya Amazon S3.
Boleh, boleh, boleh.
Nah cara untuk upload ke Amazon S3 itu kita butuh kaya ada signed URL.
Tapi strategi-strategi upload file itu gimana coba kita bicarakan malemnya.
Iya, segway yang luar biasa ya. Mantap gak?
Mengalakan view transition ya. Jadi transitionnya itu lebih hebat daripada view transition.
View transition internal. Webdev banget.
Jadi Ivan gak cuma bisa mengeluarkan jok-jok receh ya, tapi juga bisa mengeluarkan transition.
Terpijuk bermutut dan niche webdev.
Iya, jadi topik malam ini kita harus berterima kasih kepada Kaisa.
Karena selain memberikan ide topik besarnya, dia juga memberikan topik diskusinya sangat lengkap.
Jadi mengurangi pekerjaan kita. Kita tinggal baca aja. Enggak sih. Tinggal diskusi aja ya.
Jadi terima kasih Kaisa. Mudah-mudahan Kaisa nanti bisa bergabung ya di chat ataupun kalau mau langsung juga bisa.
Masuk aja. Bisa kan. Udah di-share. Udah di-share.
Udah-udah. Tapi dia kayaknya gak mau. Malu katanya.
Belum muncul juga itu kayaknya. Mungkin belum. Iya, Kaisanya belum ada.
Jadi saya udah kasih di bawah sini untuk link-nya, tapi Kaisa menjawab kayaknya gak dulu.
Hai, bagus banget. Gue belum sempet belajar lagi. Iya, ini maksudnya kontennya bagus banget.
Kontennya luar biasa sih. Jadi intinya adalah Kaisa ini pengen punya apa ya?
Pengen berdiskusi dengan kita semua tentang bagaimana strategi.
Karena opsi-opsi itu trade of trade. Kayak pro dan konten.
Baik itu performa keamanan biaya sama pengalaman pengguna atau user experience.
Jadi masing-masing ada plus minusnya. Gimana?
Cuma mau kasih intro aja kenapa file upload strategy ini penting.
Sebelum kita pergi ganti ke masing-masing pilihannya itu.
Jadi saya mau mengajak temen-temen semua berpikir seperti ini.
Kita punya web application. Awalnya kecil. Masih di share hosting misalnya.
Tentu waktu kita upload file, ya udah. Taruh aja di upload folder.
Selesai kan? Kita cuma tinggal dari sisi aplikasi kita link ke upload folder.
www.lizafalmy.com/upload/
Lama file-nya. Kayak gitu. Beres ya. Gak usah pusing.
Pusing? Kalau penuh?
Iya. Habis itu storage-nya penuh.
Terus sama share hostingnya bilang, atau si dominasi. Boleh gak sih sebut?
Ini maaf katanya storage-nya penuh. Harus segera di upgrade.
Upgrade-nya kemana? Biasanya ke VPS.
Yang storage-nya lebih besar.
Jadi bisa punya sendiri. Tadinya kan mungkin storage-nya cuma 10GB.
Atau ada kadang share hosting yang menawarkan unlimited storage. Ada.
Tapi downside-nya dia nanti akan batasi mengatakan i-notes-nya harus maksimal sekitar 2000.
Jadi hanya bisa total jumlah file-nya itu cuma bisa 2000 file.
Meskipun unlimited storage. Tapi jumlah file-nya terbatas.
Share hosting dan unlimited juga itu udah gak logis sih. Jadi pasti ada limitasi somewhere.
Cuma ternyata maksudnya exactly apa limitasinya itu ya? Jumlah.
Ya biasanya i-notes-nya dibatasi.
Oh jadi kalau misalkan nih kita punya file gede-gede 1GB, 1GB gitu.
Tapi dibatasi hanya 20. Jadi kita bisa punya 20GB?
Iya.
Asal file-nya sebesar itu. Bukan kalau file-nya kecil-kecil.
Hanya bisa punya 20 file. Tetapi at some point dia akan batasi secara bandwidth.
Bandwidth juga dibatasi nih ya?
Iya. Atau bisa dibatasi juga secara i-notes.
I-notes. Itu jumlah file.
Jadi identifier file-nya itu kan.
Jadi kayak ini ya.
Tapi harus file itu kan.
Kayak paket internet lah ya.
Ada FUP-nya.
Terus KPE-nya misalnya.
Oke gimana kalau saya upload zip file satu yang gede gitu.
Bisa aja kan.
Dibatasi. Nanti misalnya dibatasi dari.
Oke kalau dari PHP max upload limit-nya paling cuma bisa 64 MB.
Contohnya. Atau dari sisi FTP dibatasi juga jumlah bandwidth yang bisa upload.
Macam-macam lah akal-akalan montirnya.
Lalu lanjut di-upload ke VPS. Masih satu server.
Ya udah. Karo aja seperti biasa.
Pertanyaannya ternyata yang pakai aplikasi risafami ini makin lama makin banyak.
Butuh scale. Scale yang bukan vertikal.
Karena kalau vertikal terus oke tambah storage, tambah storage.
Tapi eventually penuh.
Butuh yang namanya scale secara horizontal.
Akhirnya nambah server.
Pertanyaannya kalau nambah server.
Storage-nya harus dimana?
Iya jadi distributed kan.
Iya kalau upload-nya ke server A tentu disimpan di server A.
Kalau upload ke server A tentunya upload.
Nanti kalau di-link ya file-nya gak sincron.
Gak sincron iya.
Jaman dulu akal-akalan montir saya dipakai 2 server tapi satu di-share pakai remote mount.
Jadi kayak share ini pakai SSHFS di-remote.
Ya kalau kalian.
Tapi SSHFS kan ada bottleneck lagi.
Ada request menuju sana.
Akhirnya aplikasinya jadi lambat otomatis.
Disitulah yang namanya file upload strategy yang sudah diberikan si Kaisa ini.
Kepakai.
Berarti tool-nya meremkan bukan cuma file upload strategy-nya sendiri.
Tapi infradesign-nya kan ini.
Iya termasuk.
Jadi ada yang makanya harus pakai namanya network attach storage.
Bisa pakai network attach storage.
Jadi satu dibounding ke beberapa tempat.
Atau kayak pakai cloud storage.
Jadi memang storage yang terpisah.
Pertanyaannya kalau pakai cloud storage seperti S3, GCP, Azure.
Bagaimana kita bisa memastikan yang sah hanya aplikasi kita saja yang bisa upload ke sana.
Gak boleh orang lain.
Itulah sejarahnya.
Atau pola pikirnya kenapa kita butuh file upload strategy.
Dah itu introduksinya. Sekarang kita bahas apa saja strategy-nya.
Local storage ini kayaknya penamannya agak ambigu ya.
Local storage-nya browser.
Bukan, bukan. Ini maksudnya yang tadi di file upload ya.
Ini yang tadi disegut event itu kan.
Di satu tempat sama server kita beneran image-nya ya.
Di situ juga bareng file code source code.
Jadi kita kalau di waktu pada saat pengembangan atau bikin aplikasi kayaknya ini yang paling sederhana ya.
Kita sediakan satu folder atau bikin satu folder.
Upload something gitu ya.
Terus kalau misalkan kita mau pisah berdasarkan user.
Upload/username/apa gitu.
Atau berdasarkan tahun, bulan, tanggal, dan seterusnya gitu ya.
Itu bebas kita isikan.
Atau mungkin random.
Kejadiannya banyak masalahnya seperti ini.
Ada contohnya pernah saya memperbahagi aplikasi Blat Merah.
Sebut saja.
Sebut saja.
Inisialnya, inisialnya.
Gak usah.
Saya waktu itu di hire sebagai outside consultant menanyakan.
Kita kebanjiran traffic.
Dan gak bisa handle lagi gitu.
Terus gimana cara optimize performance.
Saya masuk, ya ampun.
Aplikasinya pakai web server.
Setiap di uploads bikin kopinya puluhan kali gitu.
Web server-nya di Windows Server.
Terus kemudian pakai XMPP.
Pakai XMPP.
Iya.
Terus pakai share folder dari Windows yang lain.
Dan di taruh di sini jadi share folder sebagai storage-nya.
Dan ditambahin XMPP-nya di-clone sebanyak.
Jadi kayak supaya me-ibaratkan web server-nya itu ada 10.
Maka XMPP instansnya ada 10 dijalankan.
Ini ya.
Gak pakai EES, pakai XMPP.
XMPP?
XMPP tau gak XMPP?
Sam, Sam.
Iya Sam.
Serius?
Yang buat PHP itu kan?
PHP MySQL itu kan?
Apa aja PHP MySQL ya?
Kalau belajar tutorial WordPress 15 tahun lalu pakai itu pasti.
Dia gak pakai WordPress.
Pake code igniter waktu itu server-nya.
Oke.
Dan dia teriak.
Gak bisa saat traffic banjir dia gak bisa lagi ngerimot ke server itu.
Ya iyalah abis.
Ya iyalah.
Sam berapa sih kemukaran user?
Ya.
Komputernya dimatiin aja langsung mati servisnya semua.
Iya.
Itulah.
Itulah yang terjadi akibat developnya di lokal.
Tetapi mungkin dikejar waktu.
Akhirnya apapun yang ada di lokal ya udah copy aja dulu ke production.
Itu bukan di copy.
Yang ada di lokal dijadikan production.
Mungkin.
Kegunaan set up lokal.
Iya bener set up lokal dipakai buat production.
Jadi bukan di copy.
Itu kan set up lokal kan.
Kalau yang buka dia doang sama intranet networknya dia doang mah gak apa-apa.
Gak masalah.
Tapi set up itu dipakai buat production.
Apa user-nya concurrent user-nya ratusan ribuan.
Iya.
Nah ini orangnya muncul nih Kaisa.
Terima kasih ya Kaisa.
Tulisannya luar biasa.
Buat kita diskusinya seru.
Di bug mode masih nyala.
Ya pastilah.
Sam kan development.
Ini gimana ya antara ketidaktauan atau apa ya.
Maksudnya.
Tapi itu kejadiannya.
Sudah bukan di tahun 2020 ya.
Sudah kayak 6-7 tahun yang lalu lah.
Tapi kayaknya sekarang masih ada yang begitu.
Ya mungkin bukan.
Ya mudah-mudahan.
Menurut saya masih pernah lihat.
Mudah-mudahan gak ada dengan adanya generasi baru.
Atau kayak lulusan-lulusan haktifate.
Yang sudah mulai kemana-mana perginya.
Merubah konsep berpikir itu.
Dan munculnya apa?
Kayak platform as a service gitu kan.
Jadi kita bisa uploadnya pakai.
Ya.
Sudah banyak berubah pola pikir.
Tapi kayak ini cerita 7-8 tahun yang lalu ya.
Jadi banyak kejadian yang sudah berubah dari semuanya.
Cuma saya cerita pengalaman saja.
Hmm.
Ya.
Ketidaktauan sih.
Dulu saya juga pernah mengalami itu.
Sampai, apa namanya kayak billing.
Billingnya langsung naik.
Sampai saya kena SP.
Terus harus potong gaji untuk membayar itu.
Bertang jawab lah gitu.
Itu cerita horor ini sebenarnya.
Horor juga.
Cerita horor ya.
Gua gak punya pengalaman kayak gitu selain karena...
Belum, belum, belum.
Pas kerja, eh jangan. Pas kerjanya.
Ya paling pas baru belajar sih ngoprek WordPress.
Itu kan WP Image itu pasti yang melar duluan kan.
Jadi penuh gara-gara itu.
Udah gitu doang sih.
Apa pertama kali tau konsep image.
File image.
File binary image ditaro di server buat.
Yang apa?
Space yang buat source code-nya juga ternyata jadi berat.
Terus setting apa? Cache-nya revert.
Terus kalau cari-cari di tutorial ya udah berarti solusinya CDN.
Kayaknya knowledge waktu itu sih cuma di situ doang.
Cuma untungnya belum pernah kena horor apapun.
Kejar tayang biasanya.
Bener kejar tayang.
Antara kejar tayang atau memang...
Belum tau konsep antara...
Computer personal, personal computer sama server.
Enggak tau juga sih.
Ya mudah-mudahan kejar tayang ya.
Kayak sinetron.
Oh kalau dulu ada yang bikin service.
Sum to production.
Jadi sum-nya dicemplungin semua ke server langsung jalan gitu kan keren ya.
Satu folder sum di zip terus di server dilakukan otomasi untuk melakukan deployment.
Tapi sekarang sih sudah nggak ada yang kayak gitu ya saya.
Maksudnya kalau dari tools-tools ya sekarang tuh DevEx-nya sudah jauh lebih bagus.
Contohnya kalau di dunia WordPress contohnya ada namanya tools namanya local.
Dulu namanya local by flywheel contohnya gitu ya.
Nah tapi sekarang namanya local doang.
Jadi local ini kita bisa create instance baru.
Pakai container.
Terus kemudian langsung WordPressnya terinstall blablabla bisa akses.
Dan langsung bisa generate live link.
Nah nanti pakai infrastrukturnya si local itu generate live link.
Jadi kalau misalnya kayak mau nunjukin si klien itu bisa ngeproxy gitu ke local-nya kita.
Tapi hanya sementara nanti generate ulang nanti live link-nya berubah lagi.
Jadi kalau si Cloudflare juga punya kan ya pakai yang namanya tunnel.
Tunnel-nya si Cloudflare kan juga bisa.
Kalau ada lagi yang satu lagi.
NG Rock.
NG Rock juga hal yang sama.
Tunnel ya.
Cuman itu kan misalnya kalau kita nggak tahu fungsinya kan bisa berbahaya kan.
Maksudnya itu digedikan server juga.
Ya kalau beneran home server atau home lab ya ok lah gitu kan.
Tapi kalau.
Ya lagi lagi sih kalau dibuka ribuan user sekaligus.
Tergantung fungsi jangan dipakai yang untuk urusan publik.
Betul.
Some juga dibuka ke production kan buat publik akhirnya.
Kalau untuk aplikasi internal juga tetap aja nggak bisa kan.
Maksudnya nggak kuat gitu.
Suatu saat akan ini juga kan.
Tapi yang jelas karena developer experience-nya juga udah berkembang bagus.
Kalau di kan kalau dulu ingin install gitu ribet ya.
Kita mau install apa aja ribet.
Install mySQL ribet.
Install APHP ribet.
Kalau sekarang kan udah pakai Homebrew.
Pakai APT Gate.
Udah pakai Kontonerize.
Kayaknya udah lebih sederhana.
Docker.
Docker Compose Up.
Iya.
Docker Compose Up udah selesai gitu kan.
Gak perlu install macem-macem lagi gitu.
Jadi memang sekarang sih udah ada.
Walaupun tools-tools seperti itu masih banyak.
Masih ada.
Kalau di dunia-nya PHP Laravel kan masih ada tuh.
Walaupun udah nggak pakai same lagi tapi ada kan ya.
Laravel kan punya server sendiri.
Iya.
Nggak.
Udah pakai versiening.
Ada tools-nya.
Ada aplikasinya untuk PHP versi berapa gitu.
Oh iya, iya, iya.
Buat versiening.
Yang kalau misalkan kita pakai, note biasa pakai NVM lah.
Atau semacamnya ya.
PSP ENV.
Ya.
Apa Laravel?
Laravel Hurt.
Hurt iya.
Hurt iya.
Bener nggak?
Iya.
Yang ada GUI-nya.
Yang mirip lah.
Bukan mirip ya.
Maksudnya fungsinya seperti SAM jaman dulu ya.
Laravel Hurt.
Iya.
Jadi tetap aja kan harus punya apa ya.
One Click PHP Development Environment Zero Dependency Zero Headage ya.
Tapi ini kan buat development ya.
Bukan buat deployment ya.
Hati-hati juga.
Terus opsi selanjutnya tuh database.
Jujur ini kayaknya apa opsi yang belum pernah liat,
belum pernah dengar ataupun atau liat siapapun pakai deh.
Sebenernya apa ya kecuali baru development baru testing ya.
Blob disimpen di database tuh nggak kebayang besarnya kayak apa.
Saya pernah mengintip sebuah aplikasi.
Saya nggak punya.
Tapi saya tidak bisa sebut namanya.
Dan saya mengintip aplikasi.
Jadi dia, X ini berhasil mendump aplikasi dari situs.
Dan di aplikasi itu menyimpan image tangkapan dari KTP disimpan di database.
Hah?
Oke.
Sebenernya.
Dan ini bukan situs plat merah bukan.
Jadi sebuah kak seperti ini apa tuh namanya yang buat pinjol.
Kan pinjol kan merekam KTP.
Iya iya iya KTP.
Ada tuh pertanyaannya di bawah.
Pinjolnya ini tidak resmi.
Jadi si X ini.
Pinjolnya tidak resmi.
Dan si X ini sedang merusak.
Dan mengambil database.
Iya maksudnya jahilin.
Teman saya menjahilin si pinjol yang tidak resmi ini.
Dan mengambil database-nya.
Dan database-nya ternyata isinya.
KTP disimpan di database.
Sebagai blog.
Saya juga pertama.
Kenapa isi disimpan database?
Oh ternyata ada ya.
Tapi pertanyaannya.
Kayak back up.
Ukuran back up.
Kan database ada daily back up-nya kan ya.
Biasanya itu kayak standar lah.
Eh gak kebayang size-nya seberapa.
Gede sih.
Gak tapi pertanyaan saya adalah.
Kenapa si database menyediakan kolom untuk blog?
Tidak aja sih.
Ada blog ada long blog ya.
Kalau gak salah.
Karena bisa jadi menyimpan ini jaman dulu kan bisa menyimpan binary.
Iya, menyimpan binary.
Termasuk image kan.
Image kan nanti di-convert jadi binary disitu.
Iya.
Binary.
Use case-nya nyimpan file gitu ya.
Nyimpan file gitu ya.
Text segala macem ya.
Karena ini kan fitur dari jaman 90-an ya.
90-an.
Jadi jaman itu butuh.
Apa, maksudnya ukuran image.
Terus apa, seberapa sering orang nyimpan image.
Masih kecil ya ukuran image.
Iya.
Sama usage aplikasi pada umumnya hari ini.
Jaman itu kan mungkin simpan CLI-CLI tool.
Atau utility-utility kan.
Atau DLL.
Biasanya DLL-DLL.
Simpan kan disitu.
Iya, file-file dependency, benar-benar.
Cuman sekarang udah tidak direkomendasikan lagi ya untuk nyimpan di Blob ya.
Dan Blob kan gak bisa diindeks.
Gimana cara ngeindeks Blob?
Yang gak bisa.
Gak bisa.
Oke.
Mungkin kita bingung.
Tapi bisa jadi kalian coba berpikir sebuah aplikasi.
Pernah dengar Sazem gak Sazem?
Yang mencari lagu perdasarkan kita itu ya.
Kita bercemandung ya.
Bisa juga.
Tapi kan kita misalnya, oh ini lagu apa ya.
Lagi di kafir.
Terus kita pakai Sazem bisa tahu.
Kebayang gak bagaimana Sazem menyimpan datanya?
Enggak.
Kan data itu kan bentuknya music kan.
Terus melakukan pencarian berdasarkan sampling.
Tentu kan disimpan di database kan.
Nah disitulah.
Kita bicara dulu ya.
Mungkin.
Ada algoritma cara untuk mengkompres.
Tapi yang jelas data yang disimpan di database.
Pasti bentuknya bukan teks seperti yang kita bayangkan.
Iya.
Kalau misalkan nih.
Saya akhirnya memutuskan untuk menyimpan image avatar.
Avatar mungkin kecil lah ukurannya.
100x100 lah.
Avatar yang baru.
Harap dia apresiasi.
Image representasi user.
Image profile user.
100x100 pixel.
Apakah bisa disimpan.
Apakah direkomendasikan untuk disimpan di database.
Ya bisa aja sih.
Apa gainnya?
Apa gainnya?
Mungkin ga best practice ya.
Sederhana aja biar gampang aja.
Gak bisa di cache.
Kalau.
Oke.
Let's say kita punya aplikasi.
Dimana aplikasi kita itu gak butuh-butuh aman untuk upload image.
Tetapi upload image yang digunakan hanya untuk avatar.
Jadi daripada saya punya.
Parti storage.
Ya ini saya simpen di database.
Karena sudah pasti centralized.
Bisa jadi.
Ya kan.
Oke.
Karena.
Kalau daripada punya service tambahan.
Iya.
Tetap database ya.
Iya.
Kalau misalnya aplikasi kita itu gak ada upload image yang lain.
Dan hanya upload image nya untuk avatar.
Ya kan.
Terus.
Daripada saya menambah.
Service baru.
Untuk file storage.
Centralized file storage.
Ngapain? Mending simpan database aja.
Iya.
Oke.
Ya bener-bener.
Daripada harus kita bikin bucket baru.
Terus aplikasi kita harus di rewrite.
Mendingan langsung database gitu ya.
Iya.
Iya.
Kalau disimpan di VPS gimana?
Tadi kita sudah sempat bahas ya.
Di awal ya.
Bisa penuh. Karena kan VPS.
Berapa sih? 10GB.
Terus kalau misalkan kita.
Storage nya penuh kita upgrade gitu.
Ke 20GB.
Cuma satu user satu avatar kan.
Dan penggunanya.
Ya kalau avatar ya.
Bisa aja sih.
Bisa aja sih.
Gak ada fitur upload file lain.
Apapun yang selain si avatar itu.
Iya.
Ini VPS.
Iya ini VPS.
Jadi VPS maksudnya kan disimpan di folder kan.
Kalau dibandingkan
sama Blob.
Ya mendingan di VPS sih.
Kalau avatar ya.
Apalagi jarang di update ya.
Karena pasti ada performa
yang dikorbankan
ketika kita insert atau update kan.
Itu kan akan lama kan ya.
Karena Blob itu gede kadang-kadang ya.
Dan kayak apa sih kayak
in the long run kayak
buat daily backup database nya itu
makin lama makin besar juga kan.
Tapi kalau, gak tahu ya.
Cuma mungkin kalau perbandingan
biayanya ya kayak harus
real life.
Harus di tes beneran.
Maksudnya VPS yang kecil aja.
Ini kan kasusnya dikit ya satu user.
Apa? Satu avatar.
Ya 100 kali 100 kan ya.
Apa? Ditaruh di database.
Versus itu tadi
VPS.
Ya kan di tes speed nya
buat speed
query database nya.
Affected nya seberapa signifikan atau enggak.
Perbedaan cost nya biayanya.
Signifikan atau enggak.
Dan speed-speed lainnya lah kayak
quality of life ya itu
routine backup database nya kan
pasti berubah. Itu kayak
affecting quality of life nya
seberapa signifikan.
Iya, iya, iya.
Oke. Benar, Mas Jayo.
Gak ada benar, gak ada salah.
Tapi kita harus ini lah ya.
Procontra nya.
Itu tadi kan.
Ini kan cuma ngayal doang.
Tapi kalau beneran ada
range kira-kira user nya sekian sampai sekian
file nya begini-gini ya
berarti itu harus di
kayak A/B testing kali ya.
Maksudnya harus dicoba lah, harus
dikalkulasi.
Betul, betul.
Kalau kita ngomongin
apa jawaban the ultimate
answer adalah it depends kan.
Tapi kita gak bisa ngomong
depends kan. Jadi kalau
kalau kita jawabnya it depends ya udah
selesai episode ini.
Tapi minimal kita punya playbook
maksudnya apa aja ya
harus dicompare. Maksudnya kita kan ini
gak mungkin kita iseng sendiri tiba-tiba gini.
Pasti kan kemungkinan kalau kita
ketinggalkan ini sama kolega
atau sama client ya. Maksudnya kita bisa
present dengan helpful lah.
Oh iya, tadi kita lupa
ngomong, lupa bahas ini nih.
Itu ada
mending nanti itu bagian diskusi, ada
diskusinya. Oke, oke.
Ada di bagian bawah.
Oke, tadi
database udah, ya udah clear ya.
Ini cloud storage yang paling standar ya
sekarang. Sangat jarang
dipakai, sangat jarang jadi best practice
ya. Sebaiknya digunakan, menggunakan
taro di folder aja.
Seperti contoh yang di sini.
Oke, yang ketiga yang
sekarang, loh ini muncul-muncul
mulu.
Cloud storage, ya cloud storage.
Kalau aplikasi ini cukup besar
ini kayaknya hampir pasti sekarang
mah udah pakai ini semua ya.
Kalau user generated content kayaknya
most likely ya.
Pakai storage ya.
SDK itu dari Amazon,
GCP itu dari Google,
Azure itu dari Microsoft.
Azure dari Microsoft.
MinIU ini versi
open source yang
compatible sama S3.
Jadi kita bisa hosting
sendiri. Self-hosted.
Ya.
Kalau saya pakai MinIU itu
justru supaya
emulate S3 di local
development.
Oh, nggak perlu
ada perubahan kode sama sekali ya.
Iya, jadi sama kayak
S3, tapi ya
compatible.
Tanpa jalanin di link ya.
Nah,
bagi temen-temen yang nggak
belum tahu, S3, GCP,
dan Azure untuk
cloud storage-nya mereka ini
bayarnya itu per bandwidth.
Bandwidth transfer in
sama transfer out.
Transfer out.
Jadi bukan berdasarkan jumlah
jumlah storage
atau jumlah file yang kita masukin.
Total file-nya
bisa sebanyak mau yang kita mau, tapi
bayarnya per transfer.
Ada cara kita upload dan download.
Jadi kalau kalian
streaming.
Ya, kalau up itunya ibaratnya kita cuma punya satu gambar
atau satu file, tapi
se-Indonesia atau se-dunia buka
file itu semua jempol.
Jempol.
Tapi
berarti ini storage-storage ini
cocok digunakan untuk menyimpan
file back up dong ya.
File back up yang gede kita simpen.
Terus jarang digunakan sampai ada sesuatu.
Iya kan?
Ini ininya 0,01
dolar ya pokoknya.
Iya.
Saya pernah bikin script sederhana
dulu pakai shell untuk upload
backup
VPS server
ke S3.
Oke, oke.
Wah ini info baru nih.
ID Cloud House S3-nya berdasarkan gigabyte.
Oke.
File size berarti ya.
File size ya.
Kalau dulu saya pernah pengalaman
pakai kalau lokal itu
CloudKilat. CloudKilat itu
ada S3 compatible-nya juga.
CloudKilat.
Oh, kok
saya cari CloudKilat yang keluar
merk lain ya?
Udah nggak ada ya? Oh, ada.
Udah, masih ada.
Budget iklannya. Oh, paling atas kok nih.
Kalau gue search
di input itu.
Iya.
Jadi
tapi dia unlimited ya.
Unlimited kalau
selain ID Cloud House ya.
Storage-nya unlimited.
Mau berapa banyak kita
upload ya selama kita
mampu bayar
biaya upload dan download-nya itu
apa namanya?
Flexible gitu.
Scalable.
Scalable bisa
dihubungkan dengan CDN.
Aman dari serangan.
Eksekusi file.
Iya, karena dia bukan server
mesin.
Bukan VM maksudnya.
Iya, object storage.
Iya, object storage.
Cuman
kekurangannya adalah
biaya storage atau biaya transfer sama
setup di aplikasi kita itu
lebih kompleks. Biasanya harus
pakai library tambahan.
Atau harus ada kode yang diubah.
Yang penting harus ada developer
yang tahu cara setup-nya.
Karena masing-masing itu kan
lumayan, apa ya, bukan perkara
coding ya. Ini bukan perkara coding skill
tapi perkara familiarity dengan
service itu. Kayak
apa, nambah service-nya,
caranya gimana, setting-nya apa,
itu kalau nggak biasa
itu pasti bingung.
Sama kalian perlu tahu
kalau S3 itu flat
file system.
Dia hanya object storage.
Tidak ada yang namanya di situ
folder.
Di S3 tidak ada folder.
Jadi
semua file
flat.
Dan property dari file itu
punya pack.
Jadi kalau misalnya upload/
2025/nama file
itu adalah property dari
si objek itu.
Tapi
di behind the scene dia flat.
Tidak ada
folder-folderan di sana.
Menarik ini. Yang
local, cloud-cloud-local, banyak kan
ada per gigabyte per bulan ya.
Jadi idea crowd-house ya.
Transfer, itu transfer
bandwidth itu.
Per gigabyte
per bulan.
Ini per gigabyte per bulan.
Nambah kapasitas.
Gigabyte itu file size ya di situ ya?
Dibatasiin. Dibatasiin kan.
Bukan traffic.
Bukan unlimited kan.
Gratis.
Oh, dibalik ya.
Jadi ini
upload/downloadnya gratis.
Tapi dibatasiin
per gigabyte-nya ya.
Menarik. Menarik.
Cuma, agak skeptis sih jujur. Maksudnya
kalau ada yang mau coba deh
punya aplikasi atau apapun yang populer
banget.
Size, mungkin size file
image atau
kecil-kecil. Cuma
user-nya banyak banget. Itu jembol
atau enggak. Maksudnya kena
lebih atau enggak.
Ini pakai mean I/O
berdasarkan protocol
S3 ya.
Ini juga per gigabyte
per bulan sama kayak tadi
Kaisa bilang ya.
Berdasarkan gigabyte.
Ini teori-nya kan
asal
ukuran-ukuran file yang disimpan itu
kecil, mau digeber, mau
setiap hari
user-nya jutaan.
Gitu, nggak apa-apa, nggak naruh ke...
Maksudnya nggak bikin
biaya jadi naik.
Oke juga.
Iya.
CloudLocker rata-rata saya pakai size ya.
Oh iya, oke. Baru tahu saya.
Tapi sebenarnya bukan pakai, dia bukan Amazon
S3 ya. Maksudnya pakai
kemungkinan yang compatible
pakai S3 API.
Supaya gampang kan.
Gampang berpindah-pindah.
Maksudnya pakai mean I/O
sebenarnya. Iya, pakai mean I/O.
Atau sejenis ya.
Cuman saya penasaran sama ininya
kenapa alasannya
CloudLocker itu
membatasi
size.
Karena di belakangnya, dia belakangnya ini.
Size-nya terbatas dia.
Kalau storanya terbatas.
Kalau mereka punya bare metal server sendiri
atau gimana sih itu
provider CloudLocker
mereka punya warehouse
yang mengisi server?
Enggak, data center.
Mereka bayar
service untuk
supaya ada server di data center.
Terus kenapa Amazon bisa
unlimited,
nggak dibatasi per gigabyte?
Karena bagi mereka, storage
karena ini
gede banget, storagenya gede banget
dan efisien, storage itu
murah. Tapi yang lebih mahal itu
justru bandwidth.
Bandwidth yang lebih mahal.
Uploading, belum pernah.
Uploading itu apa?
Uploading.com. Ini
S3 compatible juga, Kak?
Better, katanya.
Better than S3.
Oh, ini ada
ada widget-nya ya.
Jadi kita bisa drag and drop gitu ya.
Sekaligus jadi
udah jadi satu paket.
Tapi jadi opinionated dong.
Tuh kan bener.
Udah ada
komponennya.
Langsung. Gampang ini.
Gampang pakainya.
Pak Thiel.
Wow.
2GB app.
Gratis.
Iya, storage-nya.
Ini juga by storage berarti ya.
By storage juga ya.
Tapi ini udah dibundling istilahnya ya.
Bukan cuma storage-nya doang.
Tapi ada komponennya.
Jadi kalau mau
apa? Pakai
apa?
Framework tertentu yang ada di sini,
yang di support, udah tinggal begini.
Gitu.
Gak jadi lebih gampang lagi.
Nick, itu apa?
NEC.
Network interface.
Enggak tau.
Ngasal-ngasal.
Tolong.
Diinfokan ya.
Contaboo. Contaboo ini service juga ya.
Limit.
Kok OVH Cloud?
Ya.
Network interface card.
Ini ada ya.
VPS dedicated server.
More. Mana?
VPS. Storage.
Ini lokal bukan?
Bukan ya? Oh.
German ya.
German.
4 euro
per month.
Oh ini VPS.
Mungkin macem-macem.
Itu storage tuh.
Tadi udah.
Kalau Dominasia?
Ada nggak?
Ada nggak?
Nggak ada CDN.
Object storage.
Wah ada object storage
Dominasia ada.
S3 compatible object storage.
Neva Cloud dong. Neva Cloud.
Ada ada. Dominasia ada.
Bayarnya juga sama sih.
Kayak itu.
Kayak per gigabyte.
Per gigabyte juga ya?
Object storage per 250 gigabyte.
S3 compatible ya.
Ternyata menawarkan hal yang sama.
Cuma menarik nih.
Baru tau maksudnya berarti ini
kamen banget ya. Udah umum banget.
Yang di-billing yang di-charge adalah
total ukuran file-nya bukan
traffic-nya.
Ternyata ada gitu.
Jadi ada opsi lah buat kita ya.
Kalau nggak ada
acara begini, gue nggak ngeliat-ngeliat itu
karena so far
nge-develop itu udah urusan infra.
Bodoh banget mau pake berapa.
Sebenarnya
gara-gara
topik ini
saya jadi explore lagi. Tadi Ivan
sempat ngomong kan di awal.
Sebenarnya ada opsi lagi selain
S3 atau
object storage.
Itu yang
di VPS.
Tapi kita bisa
nambahin NAS.
Nambahin storage.
Namanya kalau di AWS itu
Elastic File System.
EFS.
EFS.
Amazon Elastic File System.
Jadi
si drive-nya, si storage-nya
dimounting ke mana-mana.
Iya. Jadi kita kayak
beli hard disk.
Terus
nanti di server kita
disimling kesitu lah
kira-kira gitu lah. Di SSA
EFS kesitu.
Disamba server.
Disambahin.
Pernah mendengar kata sambah?
Samba file-shell.
Iya.
Disambah.
Disambah.
Jadi di cloud server kita ada
directory yang nyambung ke
file system ini.
Jadi kalau misalkan
kalau tadi ya, yang opsi
pertama kan, penuh nih
di VPS.
Kita bikin folder
itu menjadi
file server.
Connect ke file server. Gitu lah kira-kira.
Samba.
Bukan email server.
Email server itu squirrel.
Squirrel.
Samba itu file
sharing ya.
Ini pada tau ya.
Yang tau
sebagai anak lama.
Anak lama.
Berarti
Samba musuh patuh.
Kalau NFS itu
protokolnya.
Samba server juga
bisa support NFS.
Bisa. Cuma Samba itu
sudah kayak complete di dalamnya.
Samba juga ada protokolnya sendiri sih.
SMB.
Jadi kelebihan menggunakan
apa? Yang tadi
Elastic file system atau NIS
itu adalah pada saat kita
develop
itu sama seperti kita pakai
folder lokal. Jadi uploadnya ke lokal aja
seolah-olah. Gak perlu
ada perubahan kode.
Cuma ada di sisi devopsnya.
Itu tambahan satu lagi.
Sekarang
kita coba masuk ke
diskusi tambahan.
Diskusi berikutnya.
Yang tadi, ada yang nanya juga ya
kalau file KTP disimpan di mana?
Setahu saya
kalau sesuai dengan regulasi
itu harus di lokal.
Gak boleh di luar. Bener gak?
Amazon S3 ada region
Jakarta gak sih?
Ada ya? Dia kan global.
Gak boleh.
Nggak ada.
Kalau object storage itu
dia sifatnya
diduplicate ke mana-mana.
Jadi kayak CDN.
Kayak edge server.
Are you sure?
Iya.
Kalau kita buka dashboard
itu gak ada pilihannya kalau di S3.
Gak ada pilihan kita mau region mana.
Gak ada regionnya ya?
Cuma S3 itu aja.
Baru tahu.
Iya.
Berarti solusinya harus di VPS
lokal ya? Kalau misalnya gak mau di
server.
Data storage lokal.
Pake min.io bisa.
Ada yang kompatibel object storage kan?
Ada, ada yang tadi kan?
Kaya ID cloud house.
Dominesia.
Ada apa tadi lagi?
Cloud Killat dan lain-lain.
Business view dan lain-lainnya.
Ada banyak.
Tapi sebenarnya kayak ada
apa ya? Kayak ada
industry standardnya gak sih?
Kalau misalnya file sensitive kayak gitu itu kayak
harus di encrypt.
Atau harus apa gitu?
Gak pernah. Gue juga gak pernah.
Apa? Alamin
harus.
Yang jelas jangan di database seperti yang
Ivan temukan tadi.
Oke.
Itu gak di region mana-mana sih.
Gak boleh ya.
Kalau saya prefernya
di VPS.
Bukan VPS.
Jadi kayak S3 kompatibel
yang lokal aja sih.
S3 kompatibel yang lokal.
Yang
provider yang kalian
percaya aja.
Yang menawarkan
bisa duplikasi backup
dan segala macem dan
high availability.
Maksudnya file yang kita itu
bisa mereka backupin.
Ada disaster recovery-nya.
Dan secure.
Sama
kalau perlu
di gali juga.
Latar belakangnya. Apakah pernah
jebol datanya ya?
Pernah tersebar itu jangan ya.
Dan harus tahu
data centernya dimana.
Jangan sampai yang
pernah kebakaran.
Lo pernah tau data center
di Jakarta kebakaran satu
sampai dua hari.
Pernah. Macem aku juga pernah.
Jadi intinya
nggak boleh langsung S3 ya.
Kalau data sensitive.
Kalau sesuai regulasi.
Bikin koloktisin sendiri
mahal.
Cape tau boleh
pada data center yang pernah.
Apalagi dengan macetnya Jakarta.
Gak tau yang mana itu.
Ini yang tadi yang kebakaran itu?
Oh iya kayaknya ada korban ya?
Mungkin.
Yang terakhir ya?
Terakhir.
Soalnya sering ya?
Beberapa kali ya kejadian.
Sedih.
Cape juga sih bolak
data center.
Udah gitu dingin banget lagi.
Kalau saya
KTP perlu di encrypt nggak?
Saya nggak akan encrypt-encrypt sih.
Karena
sedih yakin.
Itu kan file image ya.
Enggak encrypt file image itu
lumayan
ini.
Lumayan kos dan berat ya.
Karena kalau nggak encrypt
kan pasti
harus bisa di decrypt. Jadi harus pakai
two way encryption kan.
Kalau
saya yang bikin aplikasi
ya simpan
KTP-nya itu hanya saat
proses verifikasi saja.
Setelah verifikasi saya akan
hapus.
Jadi nggak perlu simpan.
Jadi
tidak perlu encrypt
pakai AI
buat
ngebandingin
atau
verifikasi.
Kalau lolos pakai AI ya sudah langsung pass.
Kalau misalnya butuh manual ya
simpan sementara.
Setelah selesai, hapus.
Atau
Dan pasti
file name-nya di random.
Terus ada nama, ada nick gitu ya.
File name-nya di random pakai UUID
aja biar simple.
Sekarang kalau mau lebih simple lagi
nggak mau ngurusin hal kayak gitu, kan ada ya service
yang khusus untuk verifikasi user ya?
Ada nggak sih?
KYC gitu-gitu?
Ada.
Ada kan ya?
Kalau nggak ada kita bikin aja.
Ada kali.
Jadi
service itu
kayak autentikasi.
Autentikasi juga kita udah
zero lah, pakai apa sekarang,
better out lah, dan lain-lain kan.
Untuk
verifikasi user
ya bisa juga pakai service
Indonesia ada apa aja ya?
KYC.
Know your customer.
KYC.
Oke.
Jadi biar lebih
apa ya? Jadi kalau
mendelegasikan hal-hal yang
penting itu kita delegasikan
ke pihak-pihak yang
sudah lebih, ya memang
ekspertisnya di sana ya?
Yang penting dan ngerisikan ya, maksud saya
itu kan ada risikonya.
Nah, kalau kita delegasiin
ke pihak yang spesialis, ya maksud saya
sebelum kita pakai jasa mereka kan kita bisa minta
apa lah jaminan atau
jaminan, iya. Atau mungkin
kaya legal liability misalnya ada
apa-apa, itu yang dipenuh mereka atau
kita, kita make sure
di situnya kan.
Oh kayak ini, Privi,
ada Privi, ada
Vida, ada
beberapa ya.
Oh Privi ini
dulu saya
yang mentorin nih
waktu dia di Google
for Startup.
Ada kan, kayak wasi.
Keren.
Ada Mas Liza, namanya Mas Liza gak sih nih?
Nggak ada lah.
Nggak ada.
Terima kasih, Mas Liza,
gitu.
Segetunya.
Nggak ada.
Iya.
Terus satu lagi, Vida.
Vida.
Vida ini.
Ada yang ingat ini gak?
Kok WTF?
Where the fraud.
Mana?
KYC.
Bisa pakai servis ini.
Dulu sempat ada
namanya,
aduh, gue namanya siapa ya?
Daniel, Daniel ya.
Bukan, bukan.
Di GDE,
GDE,
dia dulu di Google
handle GDE bareng sama Janis.
Dulu, tahun 2018.
Yang waktu
kita ke
ke Montain View.
Dulu.
Yang dia handle group
South East Asia.
Ada namanya Dan. Daniel ya.
Oh Dan, ya.
Ya, Dan. Dia kerja disini sekarang.
Vida.
Mana, cara-cara pakenya gimana?
Tuh kan?
Ada verification, segala macem kan?
Udah diatur. Kita tinggal pakai aja.
Tinggal pakai servisnya maksudnya.
Nanti setelah itu baru dikirim.
Oh.
Vida-nya dipakai di GoPay ya?
Saya nggak tahu kalau itu.
Sudah terbukti juga kan ya?
Yang dulu,
kalau apa?
Gojek dulu
juga punya problem dengan itu kan?
Yang orang mau validasi
pakai topeng segala macem.
Topeng perin-perinan muka ya?
Makanya sekarang ada.
Iya, topeng perin-perinan muka.
Iya, kalau bikin sendiri kan
edge casenya banyak kan?
Yang harus difikirkan.
Apa maksudnya biaya buat pakai layanan
yang spesialis kini dibanding
total man hour, dev hour,
bikin sendiri,
terus resource-nya kalau di total
yang mirip-mirip.
Kalau yang udah sebesar
GoPay ya?
Iya, iya, iya.
Untuk data di DB-nya
saja berarti yang di-encrypt?
Kalau, iya,
kalau ada data.
Data sensitif ya?
Kalau data sensitif di DB,
di-encrypt, yes.
Jadi ini sudah terjawab.
Oke, sekarang
pertanyaan kedua.
Ada yang pernah kena kasus file upload
jelas serangan?
Biasa itu. Jaman dulu.
Ini bisa saya jawab. Solusinya
ya pertama ya waktu upload
sudah, udah pastikan
apa namanya, dokumen
type-nya, file type-nya
main type-nya
sudah benar di-check. Jadi
jangan pakai sistem yang
pakai sistem yang
exclusion atau
whitelisted. Jadi
block semua kecuali
meme type-nya yang kita butuhkan
saja kayak PNG,
GPEG
yang kita pakai saja. Jangan
bisa pakai file yang lain.
Meme type beda sama
extension ya teman-teman ya.
Meme type itu membaca
di file header.
Jadi jangan cuma baca
extension-nya saja.
Lalu kalau misalnya
file yang di-upload,
taro lah di folder upload
yang dikhususkan.
Dimana
kita bisa
melakukan setting
dari sisi server.
Kalau share hosting ya
bisa pakai
HT Access.
Kalau di Nginx kita bisa
melakukan settings di Nginx
config-nya.
Dimana folder tersebut
tidak di-execusi pakai PHP
atau tidak di-execusi pakai
runtime apapun.
Hanya khusus melakukan
exekusi dengan ya udah
sebagai static file.
Jadi tidak bisa dijalankan
pakai runtime.
Di Nginx gampang banget kok
setting-nya itu. Cuma cukup kayak
ini folder-nya serve
pakai static. Jadi nggak usah di-proxy
ke runtime apapun.
Bisa jadi Ruby, bisa jadi PHP,
bisa jadi
apa lagi yang runtime di backend ya?
Java dan lain-lain.
Dengan hanya melakukan
proteksi
dua hal itu saja,
kita sudah bisa
menutup
99,99% celah serangan.
Karena dia tidak bisa
nge-execusi dari file itu.
Kalau seandainya kita deploy-nya
ke dalam container juga itu
lebih aman lagi kan ya?
Karena itu kan bukan root level kan?
Dari sisi, kalau misalnya kita
sudah pakai container base,
ini contohnya ya,
aplikasi kalian itu bisa
dibuat, misalnya kalian bikin
JavaScript application atau
PHP lah, gampang ya.
Aplikasi kalian dibuild
jadi satu image saja.
Jadi file apapun
yang ada di, yang misalnya
ada yang berusaha meroba,
file misalnya anggap aja ada
celah, ke-inject sama
shell, terus file-nya ada ini
berubah. Karena cukup nge-redeploy
file-file yang tadinya ada di dalam
image itu, ilang kan?
Karena image itu kan pristine dan
sebisa mungkin di dalam image itu
files yang ada
yang menjalankan PHP
itu
apa namanya?
Immutable.
Nggak bisa dirubah. Nggak bisa, jadi
nggak bisa upload file, nggak bisa
modify file, nggak bisa
nge-delete juga. Ephemeral
betul katanya.
Bisa kembang kempis
dan short-live.
Nah, ephemeral itu
artinya short-live.
Itu lebih aman
lagi.
Pakalasan, kenapa
aplikasi berbasis PHP sering dianggap
rentan?
Karena tidak tahu cara melakukan
melakukan
proteksinya.
Kalau
apa yang saya sebutkan tadi dilakukan sebenarnya
nggak rentan-rentan apa,
nggak jadi sangat strong malah.
Ini contohnya Filament. Filament ini apa ya?
Boleh
Filament apa itu?
File upload. Oh, file upload.
Keamanan file name.
Bentar, saya pengen tahu
Filament ini apa?
Kayaknya dari Laravel ya?
Iya, Laravel.
Apa ini?
Introduction. Apa Filament?
Server-driven UI.
Ini pakai apa sih, docusaurus ya?
Nggak.
Bukan ya?
Kayaknya pernah lihat.
Server-driven UI.
Oh, ini kayak live view-nya
Phoenix ya?
Jadi, HTML over the wire
dari server, HTML-nya baru
dilempar pakai
live wire gitu.
Bisa jadi.
Ke klien.
What is server-driven UI?
Move control of UI to the server.
Nggak enak banget.
Penjelasan UI server-driven.
SDO is a proven architecture.
Used by.
Itu kan bukan definisi ya?
Iya.
Contohnya ada nggak?
Penasaran jadinya.
Oke, kita balik dulu deh.
Nanti,
di eksplor lagi
Filament ini. Coba, mana Kaisang?
Kaisa coba, tolong.
Bukan Kaisang.
Kaisa ya, Kaisa, salah-salah.
Security implication
of controlling filename.
Semua juga pasti ada.
Didox pasti ada security implication sih.
Nggak enaknya
kalau kita nggak kontrol filename-nya
atau nggak kita nggak ngerendom filename.
Bisa jadi file yang di-upload
oleh orang lain.
Ngenimpa
file yang kita sudah punya sebelumnya.
Override.
Oke.
Kenapa?
Iya, hilang-hilangnya terus.
Nggak tahu nih, koneksinya terus-terus.
Ujan semangatnya.
Oh, masih tentang keamanan.
Keamanan di PHP itu kan
kayaknya lumayan rentan ya.
Antara
penggunanya banyak
sehingga ada beberapa contoh
aplikasi yang rentan
di PHP, seperti yang
kita diskusikan sebelumnya.
Ada yang hanya menggunakan SAM,
Dijadikan Production, itu kan rentan ya.
Yang sama bisa langsung
execute the user, kan?
Masa-masa batasan antara
front-end ke back-end, itu kan
jadi satu, kan? Markup.
Karena tidak melakukan
konfigurasi yang benar.
Jadi, default
konfigurasinya tidak
memikirkan
tidak menambahkan opinion untuk
mengeamankan upload folder, karena
dia sendiri nggak tahu upload folder mana yang kita
gunakan. Jadi, ya
bisa execute apa aja, gitu.
By default.
Itu ada demo lagi Filament.
Di mana?
Ini Filament Docs memang
kayaknya ini ya.
Kok beda?
Oh, ini yang versi 4.
Misalnya ini kayaknya pakai Astro deh.
Astro yang kemarin.
Starlight.
Oh, jadi ini.
Ini, ini, ini.
Ya kan?
Berasa nggak kayak Starlight?
Ya kan?
Iya.
Itu apa? Itu komponen built-in-nya.
Contohnya mana?
Demonya. Demonya Filament
di mana?
Demo. Apa?
Introduction.
Getting started.
Ya, anyway.
Secara umum, memang
PHP
karena jumlah user-nya sih, kalau
saya bilang. Kalau dibilang
keaman-nggaaman itu
kembali lagi tergantung.
It depends. It depends ya.
Jadi,
kalau orang yang, apa?
Memang
keamanan itu menjadi
syarat
mutlak, gitu.
Syarat mutlak sebelum Go Production.
Pasti bisa dihindari.
WordPress juga
banyak, apa ya?
Banyak diserang, kan?
WordPress juga banyak diserang, karena
memang yang menggunakan atau yang
yang pakai banyak.
Yang pakai banyak. Jadi, pas
hal pertama, yang biasanya
diserang, pada saat
orang mau menyerang sebuah, atau mau
meng-audit sebuah
website, itu pasti, biasanya,
bukan pasti ya, biasanya yang diserang
pertama adalah /wp-admin.
Itu kan nggak umum banget, kan?
Karena penggunaan
WordPress berapa persen? 90 persen?
Berapa persen? Nggak 90, ya.
42, 43 persen.
43 persen.
Hampir setengahnya lah. Hampir setengahnya
web di dunia
WordPress. Jadi, pasti yang diserang pertama itu.
Jadi, ya.
Plus minus lah ya. Plus minus. / 40 persen dari
sampling 10 juta top
top website.
Sampling ya, bukan.
Real.
Tapi ya, bisa merepresentasif.
Sikan lah.
Iya, iya, iya. Coba
teman-teman bikin web pakai
bahasa yang jarang
digunakan. Bingung orang
nyerangnya. / Nggak apa-apa.
Bikin aja. Bisa untuk loginnya
/wp-admin.
/wp-admin, iya. / Iya.
Terus, abis mereka
coba login, weh, ini bukan
WordPress, weh. Gitu.
Ini bukan
WordPress. Ini adalah
Drupal, gitu ya.
Jadi,
ya, pastikan lah. Kalo teman-teman
bikin aplikasi web, ngikutin yang itu
yang kita sempet bahas ya
sama Mas Irvan ya, kalo nggak salah ya.
Yang 10, apa?
Yang
OASP, ya. O-A-S-P.
/ OASP. / Top 10
OASP, the security.
/ Top 10 security. / Nah, itu.
Itu yang harus diikutin.
Jadi, sebelum produksi ini, itu dulu aja
diikutin, harusnya
semua platform, semua bahasa
insya'Allah aman.
Insya'Allah aman.
Nggak
tergantung ke bahasa tertentu.
Minimal
menutup celah yang komon.
Menutup celah.
Kalo pake Larafer,
sudah ada metode buat periksaan URL.
Ya. / Ya.
Periksaan itu adalah?
Memberi
ini.
Apa namanya? / Tanda tangan.
Untuk
betul. Supaya
hanya bisa pake itu sekali untuk
upload-nya.
Temporary. / Jadi, itu dikirim dari
di payload-nya. Jujur
gue belum pernah sih.
Di URL-nya kan ya? / Di URL-nya.
Di URL-nya.
Coba aja liat
itu buat saya.
Coba buka. Nah, itu buka aja coba.
Oke.
Oh, kok vilamin lagi?
Emang itu vilamin?
Vilamin lagi?
Larafer kan?
Oh, ini. / Nah, itu
beda tab. Salah tab.
Salah tab.
Ini ya? / So, my sync temporary
URL.
Build
temporary URL using.
Oh, ini nih.
Oh, udah dia metode. / You need to generate temporary URL.
S3 driver.
Oh, dia sudah
menyediakan S3 driver ya.
You need to generate temporary
URL that can be used to upload file
directly from your client-side application.
You may
use temporary upload URL
method. This method accept path
and that time
when the URL
should expire.
Jadi
kita buat. / Kan untuk upload ke
S3 itu kan dia
beda sistem kan supaya
dan kita kan maunya upload
langsung dari aplikasi
browser ke S3-nya.
Ke S3-nya. / Iya kan? Tidak
melewati, nggak lewat server kita
sebagai proxy.
Ya, jadi ini adalah aplikasi
lokal ke S3.
Supaya tahu, supaya si S3-nya
bisa ngerti, oh, ini
diijinkan, berarti kan
si server kita, oke, create presigned
URL, dan
dipakai di aplikasi lokal untuk
upload ke sana supaya sah.
Seperti itu.
Ya.
Oke.
Enak juga ya, sudah disediakan ya.
Nah, karena itu tadi
bisa, kalau strategi upload
seperti yang di Next itu,
via API, API server,
jadi pakai proxy, atau pakai
sign URL tadi.
Sign URL. / Iya.
File URL upload bagus buat upload
file version lebih dari 4,5
mega.
Karena bisa jadi
server-nya kita, misalnya serverless.
Biasa sih. / Bukan,
serverless, nggak punya
server.
C.
Bukan nggak punya server, serverless itu
sedikit server.
Kalau nggak punya server, no server.
Atau miskin.
Miskin, enggak, enggak, enggak. Canda-canda.
Jadi, sama aja kayak
caseless ya. Caseless itu kan bukan
nggak punya uang kan?
Kalau nggak punya uang, no case.
Cuma beda format aja.
Nggak punya uang jangan belanja. / Nggak punya uang,
kere, kere.
Bawah mau ngomong soal caseless,
caseless itu sebenarnya
caseless itu sebenarnya
mengurangi value atau menambah value,
sih nggak sih? / Si.
Caseless itu
mengurangi. / Value-nya apa? / Menambah lah.
Kita bahas lah di lain waktu.
Karena saya punya pendapat berbeda.
Ini udah satu jam lebih, tapi
baru sampai download. Eh, baru sampai?
Upload. / Menyimpan.
Menyimpan file. Terus ada
strategi upload. Oh, tadi udah kita bahas ya.
Iya, udah kita bahas di QN.
Kalau sebagai
API atau pakai
sign juara yang saya sebut tadi.
Iya.
Kalau direct to storage dari
browser, bisa langsung ke
S3 atau ke storage lain.
Dari mobile,
Android, iOS bisa langsung juga.
Upload file sign URL itu pakai put
atau post?
Kayaknya post ya? / Belum pernah.
Kayaknya post.
Dan sebetulnya, ini nggak ngejawab
sih. Cuma sebetulnya, kalau buat
layanan yang populer, kan
kadang udah ada SDK-nya ya.
Kayak biasanya. / Iya. / Kalau
pengalaman pribadi, bukan pribadi,
pengalaman gue di tempat kerja,
kalau dari QN mah, udah tinggal kayak
API aja sih. Kalau yang apa,
gue bikin dari browser,
udah ada endpoint API yang
dibuatin oleh pekan kerja.
Nah itu API golong, ya standar
lah. Dan itu
kita pakai S3, AWS,
official dari AWS itu
udah ada SDK-nya
buat golong, buat note,
apa-apa.
Bahasa masing-masing umum,
udah ada SDK-nya ya. / Iya, udah ada.
Itu penggunaannya kayak SDK pada umumnya sih.
Jadi... / Betul.
Kayak, ya masukin
token dari N, apa?
environment variable.
Variable.
Bisa diakses, itu ya.
Iya, bahkan
di abstraksi lagi.
Iya. Kadang-kadang
di abstraksi lagi, ada library-nya,
lebih gampang lagi.
Dibungkus terus kan, jadi nggak
ketauan. Setahu saya
sih. / Kayak itu SDK-nya kan udah berupa
library, pos-nya udah tinggal
diinstall aja, dan itu official
dari AWS-nya. / Oh iya, iya, iya.
Ya GCP juga mungkin ada.
Iya, iya, iya.
Kalau langsung sign URL
validation, berarti hanya bisa di sisi klien.
Kalau mau validation seperti ukuran
file maksimum 10
mega, wajib
image
tidak bisa pakai sign URL.
Sebenarnya dua-dua
bisa. / Nah, itu ya... / Bisa, bisa.
Mau pakai PUT atau POST bisa.
Itu di klien site dulu.
Oh, kaya top-nya.
Nggak masalah berarti. / Kaya top-nya bisa ya
dua-duanya. / Itu tadi kalau perkara
nge-check size sama type,
kalau yang di tempat kerja
sih ya di klien site,
di browser, di JavaScript
klien site,
gue udah nge-check juga, itu mah tinggal
file object-nya, file.type,
nge-check mime-nya kan,
mime-nya, sama nge-check
size-nya, terus
di server site, di API-nya juga
yang API golong tadi,
nge-check size sama type-nya juga.
Udah gitu doang sih.
POST-nya cukup simple. / Kak.
Tapi ada perbedaan
policy. / Nah, cuma ini bukan sign-order kan?
Iya, kalau yang sign-order
ada beda policy.
Kalau mau simple aja, pakai
PUT, tapi nggak bisa,
ya itu, nggak bisa nge-check
ukuran file, segala macem, itu nggak bisa.
Oh, nggak bisa baca object
yang di-upload-nya ya?
Nggak, nggak bisa. Maksudnya,
kalau mau di... Jadi ada
di S3, ini khusus S3 ya.
Jadi di S3 itu kan
bisa dikasih policy.
Nah,
kalau kita mau bikin presign
POST policy-nya itu,
mau misalnya file size, terus kemudian
file type,
itu
bisa dikasih POST policy.
Jadi, kalau mau PUSH
pakai policy ini,
harus pakai HTTP POST.
Baru bisa.
Karena PUT itu, dia hanya
yang...
simple aja.
Nggak bisa ditambahin policy.
Jadi,
karena di PUT itu kan kita nggak bisa bawa
atribut lain.
Hanya kayak file-nya aja dikirim
pakai sign URL itu.
Kalau di-setting dari S3-nya,
berarti kalau misalnya file yang dikirim
di POST request tadi nggak memenuhi syarat,
otomatis, maksudnya bakal
ke-reject, bakal di-error sama
S3-nya.
Karena jadinya ini kan,
S3 itu kan sebenarnya S3 API kan
REST API.
Belakangnya REST API Endpoint.
Jadi, nanti akan return
error message-nya.
Ya, punya responnya error.
Kalau ini bisa di-validasi
di sisi klien, bisa...
kalau emang butuh yang lebih strict,
kayaknya harus di sisi server dulu ya?
Nah, cuma kalau ini kan tadi
ternyata kasusnya kalau mau direct kan?
Iya, kalau mau direct pakai
sign URL bisa.
Pake POST policy.
Ada policy.
Itu tadi yang dibilang event kan?
Jadi, apa?
Tanpa lapisan server,
client-side browser lah.
Script-nya di-check aja dulu filenya,
abis itu di-S3-nya dibuat
POST policy.
Ya, oke.
Strategi upload lain, ya tadi
saya nambahin tadi yang itu
elastic file storage
dari AWS.
Saya nggak tahu itu...
Yang belum pernah, apa? Belum pernah pakai
upload file aneh-aneh.
Ya, selain itu tadi apa? KPI.
Ada namanya Torrent.
Oh iya benar, peer-to-peer.
Torrent, benar-benar.
Oh iya, peer-to-peer.
Kenapa? Karena Torrent itu
konotasinya negatif, biasanya.
Padahal sebenarnya itu adalah bagian dari...
Ya, karena penggunaannya lebih banyak
kuat file-file
illegal. Padahal ya file yang legal
kan nggak bisa buka aja di Torrent.
Ada, iya.
Peer, ya.
Itu juga penyimpanan data yang
cukup ini
tergantung usernya juga, ya. Semakin banyak user,
semakin cepat, ya.
Kalau saya yang tadi Amazon
elastic file system, saya nggak tahu
di cloud lain
ada yang sama
atau nggak, gitu. Tapi
itu menarik karena
secara developer experience lebih simple.
Karena kayak folder biasa aja.
Ingress, itu yang kita sebut tadi ya?
Upload-download
traffic, bukan?
Ingress itu adalah
outgoing.
Ingress adalah
incoming.
Ingress itu adalah outgoing.
External, outgoing.
Ya, jadi kalau misalnya dibilang
Ingress,
jadi sesama
S3A
ke S3B,
S3B itu Ingress.
Itu nggak bayar.
Kalau ke traffic
luar baru Ingress.
Kalau dimanggil, baru.
Dari luar
masuk ke dalam,
itu Ingress.
Jadi secara lingkup,
ya. Jadi kalau di dalam
aja, percakapan di dalam
rumah. Kayak LAN sama
ini ya, LAN sama apa?
One, one.
Iya ya, Cloudflare juga ada ya. Namanya R2 ya.
Betul.
R2D2
R2D2 temunya C3PU.
C3PU?
C3PU?
Ada yang nonton nggak sih?
Ada lah. Masa nggak ada
yang nonton sih?
Itu film apa coba?
Ini coba jangan sebutkan
judul filmnya. Kira-kira itu film apa?
Dengan temen yang ada di chat.
Jadi franchise baru
kan? Ya tanpa menyebut
video. Iya, yang baru-baru. Tapi yang baru-baru
apakah ada R2D2?
Oh nggak. Nggak tahu. Nggak nonton.
Ada yang keren yang bisa
yang dia
bola doang.
Oh iya, yang orang orange ya?
Iya.
Proxmox
Lanjut, apakah
ada yang pakai Minio?
Perang bintang.
Perang bintang.
Benar, benar, benar.
Pake Minio
di perusahaannya. Belum, belum ada.
Saya pakai, tapi hanya untuk
lokal server saya tadi yang untuk
mengganti
S3 bucket
lokal.
Minio remove most management
from web UI. Jadi web UI-nya
mau dihapus, gitu ya?
Menggantinya apa? Kenapa dihapus?
Alasannya apa?
Atau di remove some sekali?
Atau jadi berbayar gitu maksudnya?
Nah itu mungkin
kalau dihapus kayak iseng doang
kayaknya apa ya? Why?
Iya.
Bukan pakai, stress dihapus.
Tapi, read Minio.
Oh ya itu
ya itu apa
dibuat
premium kali.
Ada forknya.
Selalu ya.
Apapun, kayaknya apapun pasti.
Open Max I/O
Lo coba
itu Minio, jadi
Open Max I/O.
Iya, boleh. Iya, ini lebih terbuka
gitu ya. Object Browser.
Astaga.
Dinamita
open source software.
Penamaannya sangat tidak
kreatif ya.
Open by CEO.
Garage. Oh, Garage.
Ini keren loh namanya.
Garage Band.
Garage Band.
Tempat nyimpan storage.
Tempat nyimpan barang.
Oh tempat nyimpan barang di Garage ya.
Iya.
Daripada
Open Max I/O kan
maksa banget.
Open Max I/O fork.
Ada yang di fork lagi.
Si Open Max I/Onya di fork lagi gitu.
Iya, ini rasanya berbayar.
Hah?
Gak tahu.
Komen, komen. Komen di sini.
Komen apa?
Good job, Gan.
Pertama kesendaya.
Nggak, apa tuh pas Hektoberfest
itu yang dulu orang pull request
biar dapet kaos, ya cuma nice
atau apa.
Nice.
Masih ya.
Sekarang
udah kurang ya.
Nah, atau sisanya buat episode 2 nih.
Sequelnya. Iya.
Sequel, sequel.
Setengah jam kita.
Udah cukup ya? Cukup dulu ya?
Kalau...
Mas Kaisahnya diajak ikut juga, siapa tahu.
Iya.
Kalau nggak, kita diskusi lanjutin diskusi aja
di GitHub Discussion-nya.
Kasih dong link-nya supaya
temen-temen bisa pada kesana.
Sudah tadi di atas.
Saya kasih lagi ya.
Kasih lagi dong.
Kasih lagi. Baiklah.
Silahkan
kita diskusi lebih lanjut
di GitHub Discussion ya.
Iya.
Sudah setengah 10.
Apa ini? Nggak, kita mau
paham kok.
Part 2, ya
tergantung. Tergantung kemauan.
Tergantung keinginan.
Soalnya udah
masih banyak sih.
Sayang banget. Kaisah
kayaknya perlu bikin
blogpost nih. Bagus nih buat bikin blogpost.
Sayang banget.
Discussion kita dia masukin
jam 9, terus dia atur
sedikit, terus jadi blogpost.
Sampai ada
Activity Diagram-nya segala nih.
Saya udah lama nggak liat
UML Activity Diagram
eh bukan Activity,
apa nih? Sequence Diagram.
Iya, Sequence Diagram.
Sekarang bisa pake LLMF
gue. Pake Mermaid.
Generate Mermaid, kita ngasih
flow-nya, terus
bikinin. Kan malu
mermaid, kalo waffle itu udah
bikin ininya.
Sekarang udah bisa minta
LLM buatin. Gue sering bikin ini
soalnya akan lebih pekerjaan, kalo buat digira,
tiket, maksudnya buat clarify,
maksudnya saling
mastiin flow-nya dulu,
sebelum coding.
Iya,
enak sekarang bisa minta LLM
untuk bikinin.
Super lengkap ya.
Jadi sekali lagi terima kasih buat Kaisa,
mudah-mudahan kita bisa diskusi lagi.
Nah, Kaisanya punya blog atau website nggak
atau channel,
siapa tau misalnya konten ini dibikin
diposting di blog atau
dibikin video di YouTube,
masukin aja link-nya kesitu.
Konten yang,
bisa jadi konten yang bagus.
Ada nggak blognya?
Ayo, diliat.
Gimana?
Project?
Gak ada artiturnya.
Learning, learning.
Catatan belajar. Lengkap.
Lengkap sekali.
Ada UML segala.
Nah, kayak gini.
Ada Tufel, ada Tufel.
Ini pakai dokusaurus ya.
Dokusaurus kayaknya.
Oh iya?
Gak tau.
Tanya aja sama Kaisa.
Kayaknya iya.
Learning.
Tadi apa?
Upload. Belum ada nih.
Upload kan? Belum ada lainnya?
Nggak ada.
Minecraft.
RBC.
Oout. Lengkap loh.
Ya, walaupun.
Ini digital learning.
Ulu kan kita pernah bahas ya.
Iya, namanya catatan.
Yang nggak harus, maksudnya nggak harus
lengkap dulu rakyat dulu semua.
Nah malah lebih rapi konten yang di posting.
Maksudnya lebih, lebih lengkap
yang di GitHub Discussion tadi tuh.
Betul, betul.
Iya, bisa dipindah kesitu.
Dikopas kesitu ya.
Karena banyak banget ininya.
Pertanyaan terakhir.
Kalau saya lagi develop aplikasi Kontakt.
Oke, tadi ya.
Nyimpen avatar ya.
Profil Kontakt.
Baiknya image-nya dikompres.
Harus dikompres.
Biasanya
image yang gede-nya
disimpan.
Javascript mah.
Ya, nah.
Image aslinya disimpan atau nggak
itu apa ya?
Terserah.
Soalnya kadang gede-nya tuh ya
kalau dari hape. Apalagi sekarang kamera
hape itu kan 50
mega atau 40
mega. Perlu nggak? Nah itu kan
tergantung kalau cuma foto profil Kontakt.
Ya, pertama dikompres
dulu pakai Sharp biasanya.
Yang pasti harus dikompres.
Dan
diseragamkan kurangnya.
Lalu
selanjutnya, pertanyaannya
dikembalikan bagi si pengguna
yang di sisi backend.
Butuhnya ngeliat sampai sedetail apa?
Kalau hanya sekedar
hanya
tampil gitu.
Terus ada nama orangnya ya
ngapain disimpan gede-gede?
Tergantung kebutuhan.
Atau memang kebutuhannya
butuh diklik, bisa
ngezoom, bisa dizoom
sampai sedetail. Mungkin orang ada tail alatnya nggak sih?
Ya, itu
beda.
Ini kan profile Kontakt
harusnya nggak terlalu syarat.
Cuma kalau profile Kontakt ya itu yang
bayangan kita standar kan ya itu cuma
kecil di apa
nama, sampingnya ada avatar
kecil gitu ya.
Pake gravatar aja udah.
Iya, model-model yang
generated avatar ya.
Iya.
Kecuali
kalau aplikasinya profile Kontakt
tapi buat model. Nah itu bisa
dizoom gede itu.
Makanya tadi itu business decision
ya. Itu
penang kita.
Atau kalau mau lebih mudah
ya, pakai
service image yang
otomatis kita upload file kayak gimana aja
kita bisa dapat
output yang mau ukuran dari
100x100 sampai 1000x1000
bisa mau
dipikin
kayak gimana juga bisa. Itu kayak
cloud, eh bukan cloud
yang image buat itu
image service tuh. Ada sih beberapa
ya. Yang paling terkenal
itu apa namanya?
Lupa kan?
Image service apa nih?
Image service yang buat ngeresize
buat. Cloudinary.
Cloudinary.
Oh, Cloudinary.
Iya. Jadi kan kita bisa
define cause saya mau
kan kalau mau gampang.
Ada preview-nya, kalau user-nya udah banyak
itu apa sih? Itu
perhitungan itu sih. Apa?
Onotation coffee kalau
dibawah sekian gratis kok.
Nah kalau yang
bisa kok, si Cloudflare bisa
bisa bikin sendiri. Bisa bikin sendiri
kok. Gak susah-susah banget.
Cloudflare yang enterprise
bisa
yang enterprise.
Katanya mahal.
Nawarin yang enterprise.
Gimana sih? Yang community edition dong.
Kalau udah pake
Cloudflare enterprise, ya
mungkin justified. Nah
hukumnya, it depends.
Projek-projek
projek-projek
buka di private.
Projek-projek yang saya handle
pakenya Cloudflare enterprise.
Jadi saya gak mikirin callinary lagi.
Nah, ya berarti justified kan.
Gak emang udah Cloudflare enterprise
anyway.
Ini
gak melenggar
trademark ya? Sharp ini ya?
Kenapa?
Kan ada brand Sharp.
Beda kategori.
Beda kategori.
Sudah di trademark.
Tapi beda kategori.
Ya itu kan
consumer goods.
Kalau gak bisa dianggap sebagai kompetitor
orang ini open source.
Iya, kalau gak kompetitor gak apa-apa.
Kecuali nanti si Sharp mengeluarkan
image library.
Atau Sharp ini carinya
bikin
jualan kulkas.
Iya, atau dia ini open source jualan
kulkas.
Iya, saya dulu pernah bikin. Jadi
konsepnya tuh
sederhananya ya. Sederhananya itu kayak gini
bentar.
Misalkan saya punya
images.rizafami.com
/profile.png
Terus disininya saya kasih
100x100
nanti itu digenerate
dan digenerate-nya
habis itu disimpan ke server.
Nanti ketika
ini dipanggil kedua kali dia gak perlu generate
lagi dia langsung ambil dari folder.
Berarti ini
ada dimana?
Ada gak yang ini?
Ada gak?
Live gak?
Biar saya
spam dan DDoS
jadi saya bikin random number semua sebanyak-banyaknya.
Gak bisa, gak bisa.
Ini internal, internal aplikasi.
Oke.
Baru mau bikin.
Gak bisa, gak bisa.
Udah gak ada kali, udah gak dipake.
Takut ya.
Bengkak ya, takut bengkak ya.
Soalnya dulu
kalau temen-temen main
Google+ ya.
Ada main Google+ ya.
Umur berapa sih mas?
Ah, udah tua, udah tua gue.
Itu salah satu produk.
Google di-pushmail kan Google+
Nah Google+ itu
kayak gini persis.
Konceptnya.
Image itu bisa kita, bisa dinamis.
Kayak gitu.
Akhirnya kita contoh.
Kayaknya placeholder
image ada deh, placeholder image itu bisa.
Placeholder.it itu
kayak gitu konser.
Karena perlu generate
Google+ image
textnya lain-lain
sengaja bikin
post request, enter-enter-enter aja
pakai curl.
Kayaknya coba cari di Google dulu deh.
Placeholder.it
Nah tuh kayaknya, ya banyak sih
sekarang. Ini, tapi bukan image kan.
Eh, image ya.
Image, click aja, click aja
open in it.
Kukurannya apa, itu udah.
Nah ganti aja 5.
Tapi kalau mau berusaha
4.000.
Iya, tapi bentuknya
tidak seperti image ya. Seperti
gambar, eh, seperti gambar. Seperti
text.
Ada color juga.
Menarik ya.
Oke.
Textnya juga bisa disesuaikan.
Keren.
Keren, keren, keren.
Placeholder.so.
Nanti di dosenya kena retimit.
Kalau jaman dulu, banyak ya.
Service service kayak gini ya.
Ada kitten, kitten, placeholder
gitu. Iya, iya.
Kalau yang
suka kucing.
Tuh.
Place kitten.
Lucu-lucu. Place kitten.
Ya, anyway.
Gimana?
Kita mau bahas
untuk minggu depan. Apakah mau
episode 2 atau mau
bahas yang lain dulu?
Bahas yang lain dulu lah.
Bahas yang lain dulu ya.
Kita kan mau meeting dulu sama
DN, DN.
Bahas
apa dong?
Licensing.
Licensing apa sih?
Semantik versioning.
Atau cerita horon mau nggak?
Cerita horon udah cukup.
Bahwa belum ada bahan.
Baru ada satu.
Baru ada satu. Dua sama cerita saya tadi.
Baru ada dua. Masih-masih ada.
Masih dulu anon.
Ada, ada. Saya banyak.
Banyak ya? Oh banyak.
Minggu depannya lagi deh.
Kita bikin form dulu ya.
Form anon.
Kalau yang sungkan ngeposting
pakai atem github.
Saya banyak
bikin masalah
sepanjang karir.
Kalau gue
cuma komedi sih bukan horror.
Maksudnya nggak se
serem, nggak se ngeri itu.
Untungnya klien-klien saya
sangat
pengertian.
Ayo lah.
Kayaknya ini dari gue deh.
Ini Veto atau mau
voting?
Oke.
Terima ya teman-teman.
Udah mau jam 10.
Baiklah.
Terima kasih
buat semuanya.
Jadi minggu depan kita akan bahas tentang
CLI Design. Kita ketemu lagi
minggu depan.
Selamat malam, selamat istirahat.
Sampai jumpa. Bye-bye.
Sampai jumpa. Bye-bye.
Deskripsi asli dari YouTube
🗣️🕸️ Selasa malam waktunya #ngobrolinWEB! Malam ini akan mendiskusikan topik yang dikirimkan oleh penonton setia kita tentang berbagai strategi mengunggah file. Tentu saja bersama Ivan dan juga Eka. 🔔 Akan mulai mengudara pukul 20:00WIB ya. Yuk mari diramaikan! Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
3 Jul 2024
Ngobrolin Elixir
Episode ini membahas tentang Elixir, bahasa pemrograman fungsional yang berjalan di BEAM (Erlang Virtual Machine), bersa...
11 Mar 2026
Ngobrolin Otorisasi
Episode ini membahas otorisasi (authorization) dan bagaimana ia berbeda dari otentikasi yang pernah dibahas di episode s...
9 Agu 2023
Ngobrolin URL
Episode ini bagian dari niat baru mereka: menyelipkan topik yang benar-benar mendasar setidaknya sebulan sekali, alih-al...
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 .