Ngobrolin Monorepo
Ringkasan Episode
Bantu KoreksiEpisode ini membahas konsep Monorepo dalam pengembangan software, sebuah strategi di mana kode dari banyak proyek disimpan dalam satu repository. Host membahas definisi Monorepo, perbedaannya dengan monolitik dan multirepo, serta kelebihan dan kekurangannya. Diskusi mencakup berbagai tools yang mendukung Monorepo seperti Lerna, NX, Turborepo, dan workspace features dari NPM, Yarn, PNPM, dan Bun. Episode juga menampilkan contoh implementasi Monorepo dari perusahaan besar seperti Google dan proyek open source populer seperti React, Next.js, dan Bun.
Poin-poin Utama
- •Monorepo adalah strategi pengembangan software di mana kode dari banyak proyek disimpan dalam satu repository, berbeda dengan multirepo yang memisahkan setiap proyek
- •Kelebihan Monorepo termasuk berbagi resource dan business logic dengan mudah, dependensi yang terpusat, dan memudahkan onboarding tim baru
- •Kekurangan Monorepo meliputi ukuran repository yang besar, proses build yang menjadi satu, dan kurang cocok untuk organisasi dengan silo unit bisnis yang rahasia
- •Tools populer untuk Monorepo: Lerna (sekarang diakuisisi oleh NX), NX, Turborepo (ekosistem Vercel), dan workspace features dari package manager modern
- •Perusahaan besar seperti Google menggunakan Monorepo dengan miliaran baris kode dalam satu repository, menggunakan tools proprietary seperti Bazel
- •Contoh implementasi Monorepo di proyek open source: React repository menggunakan NX, Next.js dan Bun juga menggunakan struktur Monorepo
- •Workspace features dari NPM, Yarn, PNPM, dan Bun memungkinkan pengelolaan dependensi yang efisien dengan symbolic linking untuk menghemat storage
- •Episode disponsori oleh Hektivate yang menawarkan bootcamp dengan diskon Rp 10 juta untuk full-time dan Rp 4 juta untuk night bootcamp selama Ramadhan
- •Topik minggu depan akan membahas Basic Web Security berdasarkan voting dari penonton
[Music]
[Music]
[Music]
Udah sering ya? Halo-halo-halo kebiasaan.
Harus ganti ya, berarti next-nya aja.
[Music]
Delolet-delolet ya.
Selamat malam semuanya, gimana kabarnya?
Gimana cuaca malam hari ini?
Iya, selamat menaikan di Bada Kepuasa.
Banjir ya, wah mudah-mudahan teman-teman gak ada yang kena ya atau kalau udah beraluh lah, mudah-mudahan.
Tadi barusan ujan sih, ujan lagi ya.
Di tengsal dan sekitarnya.
Tapi lokasi parah juga ya, ternyata ya.
Dairah saya sih alhamdulillah aman, cuma keluar dari daerah saya gak bisa gitu misalnya kemana-mana, jadi ya stay at home.
Untung sekolah anak-anak masih dalam komplek.
Oh iya tadi anak saya juga gak sekolah.
Diliburkan?
Enggak sih, karena kita meliburkan saya dan istri saya meliburkan anak saya, karena jalan menuju ke sekolah, banjir.
Macet, oh banjir.
Iya, lumayan kata yang lewat hanya mobil Pak Jero, sudah saya mundur teratur.
Yang bisa lewat cuma Pak Jero gitu.
Atau Fortuner, jadi kan tinggi ya.
Di mobil saya kayaknya, ah udahlah males gitu kan. Pernah sekali maksa, akhirnya nyesel gitu, karena kayak keter-ketir selama jalan, aduh masuk gak ya, masuk gak ya.
Gitu, setelah efeknya tuh, ini ya panjang ya.
Iya, jadi ya meskipun pendek, tapi kan kalau kena gelombang kan.
Kayak masuk juga ya.
Masuk juga, kayak risiko.
Lagi mobil saya ada baterainya, bahaya.
Hybrid, hybrid.
Lihat transkrip lengkap (1259 segmen lagi)
Iya.
Ini Dui, Mas atau Umba?
Namanya umum ya. Selamat malam Mas Riki, kalau ini kita tau ya Mas ya.
Selamat malam.
Mbak Eka mana Mbak Eka?
Mbak Eka mana dia?
Oh masih OTW ya.
Iya, jadi malam hari ini kita akan membahas satu topik yang sebenarnya sudah cukup lama disarankan oleh salah satu penonton.
Cuman baru kita realisasikan malam ini.
Jadi 2 minggu yang lalu kita buka GitHub Discussion.
Kita buka GitHub Discussion, terus ternyata salah satu yang paling banyak foodnya adalah Monorepo.
Yang paling tinggi sebenarnya Web Security.
Cuman Web Security ini kayaknya kita butuh narasumber.
Sebenarnya Monorepo juga sebenarnya butuh narasumber nih, karena kita gak tau banyak tentang Monorepo.
Jadi berhubung belum ada yang bisa digadikan narasumber, jadi kita sambil belajar aja.
Karena Ivan udah pengalaman belum pakai Monorepo.
Jadi satu Repo bisa untuk host beberapa komponen kan maksudnya kan ya?
Untuk banyak aplikasi.
Apa sih definisinya?
Definisinya? Oke kita langsung, ini aja ya. Langsung, eh bentar jangan langsung-langsung dong.
Ada pesan sponsor dulu.
Oh iya. Nah harus ada ini nih, harus ada rundownnya di kita sekarang.
Jadi episode ini disponsori oleh Hektivate yang kebetulan lagi buka promo selama Ramadhan.
Kalau temen-temen tertarik ya, mau meningkatkan skill, mau ikutan bootcamp.
Jadi bootcamp yang ada diskonnya itu ada dua.
Yang pertama untuk full time yang bootcampnya itu pagi sampai malam lah ya, sampai sore.
Eh eh kak, kita lagi sponsor nih.
Bootcamp ya. Bootcamp, jadi kalau yang full time bootcamp itu setidaknya sampai Jumat. Kayak kerja lah ya, jam 9 sampai jam 5, jam 6.
Nah kalau yang bekerja dan gak mau full time ada kelas malam atau night bootcamp.
Diskonnya kalau yang full time itu 10 juta, kalau yang night bootcamp itu 4 juta selama Ramadhan.
Jadi langsung aja, kalau ada yang tertarik langsung ke hektivate.com.
Kalau yang kena banjir ada diskon tambahan gak?
Promo code, saya yang korban banjir.
Korban banjir misalnya.
Jadi saya lagi ngungsi ya kan, lagi ngungsi gak bisa kerja, yaudah ikut bootcamp online aja.
Ikut bootcamp aja gitu ya.
Lendem banget.
Mudah-mudahan ya temen-temen yang susah keluar, aksesnya kena banjir atau ada keluar yang kena banjir, mudah-mudahan cepat beralulah ya.
Ngeri juga ngeliatnya, sampai ke puncak segala ya.
Uar biasa.
Oh longsor, kira puncak bisa banjir gimana ceritanya.
Kalau puncak banjir kita keren dong mas, abis.
Bukan banjir, longsor, longsor ya.
Apa namanya, apa sih banjir, longsor, gunung melektos itu namanya apa?
Pencana alam.
Pencana alam, pencana alam, ya ampun.
Banjir bukan pencana alam ya?
Ya dia apa?
Nggak, banjir bukan pencana alam.
Pencana alam lah.
Tapi kita kira kebanjir, air tergenang.
Semantik.
Gara-gara ujan, atau gara-gara orang yang buang sampah sembarangan gitu ya.
Nggak sih, kan gara-gara seru-seru dibekasi mah.
Namanya sama, ngobrolin banjir.
Ngobrolin banjir.
Terima kasih kepada sponsor Hektifate untuk setelah memponsori episode malam ini.
Oke, kita kembali ke Monorepo.
Monoservice lagi, Monorepo.
Tadi Ivan nanyain tentang definisi.
Definisi.
Definisi, Monorepo adalah mono itu single.
Repo itu adalah singkasan dari repository.
Jadi repository yang jumlo.
Single kan?
Gue nggak punya soundboard.
Tapi sebenarnya gagal.
Tapi sebenarnya berisi keluarga besar.
Ini biasanya Eka suka mengeluarkan analogi-analogi yang di luar nurul ya biasanya.
Jadi kita tuh lagi.
Monorepo.
Jadi terdiri dari dua kata, mono dan repo.
Mono itu kan satu.
Repo itu repository kumpulan kode lah ya.
Nah, ini adalah salah satu strategi di dalam software development.
Dimana kode dari banyak project disimpan di satu tempat.
Ya.
Gitu.
Jadi ini tidak ada hubungannya dengan monolitik ya?
Ya, saya pernah menggunakan Monorepo kalau definisinya begini.
Oh, pernah ya?
Saya nggak tahu itu namanya Monorepo jaman itu.
Ini kan mungkin kapan sih ditulis?
View history coba, view history kapan ditulis?
Ini? 2000?
Nggak, ini view history, penjelasan view history-nya.
Kapan ditulis?
Karena terlalu banyak istilahnya.
Iya, terlalu banyak repo kayak saya tahun 2015.
2015 tuh nggak ada gitu, saya nggak nggak nggak nggak nggak.
Jadi praktiknya udah ada, tapi namanya Monorepo belum pakai itu lah gitu kan maksudnya.
Berarti jaman itu saya belum menyebutnya Monorepo.
Eh 2018, sorry 2018 belum ada ya.
Dan saya pakai itu di 2015.
Tapi ini katanya praktiknya sudah ada di tahun 2000an.
Iya.
Katanya.
Contohnya Gnu.
Gnu kan?
SSG gitu kan udah dipakai dari SSG lah.
Iya.
Cuma istilahnya nggak tahu ya.
Itu Gnu kan project yang ini kan?
Monorepo ya.
Monorepo yang sesemua isi utilitasnya dalam situ semua kan, satu repo.
Nggak tahu ya kalau jaman itu pakai repo ya?
Iya kayaknya.
Nah soal terminologi nih, coba deh buka di private chat.
Ada penjelasan yang lumayan bagus soal perbandingnya.
Oh ini bagus nih, monolid, multirepo, monorepo.
Monolid, multirepo, monorepo.
Hello awesome people.
Ini micro front-end, beda lagi ya micro front-end ya.
Nah kalau ini kan kita pernah bahas ya sama Rehow.
Ya jadi satu aplikasi, satu aplikasi berisi micro apps.
Banyak micro apps dijalankan di satu environment yang sama gitu ya.
Gnu patokannya apa sih kita butuh itu kalau anggota tim kita mulai berantem ya.
Mulai berantem, betul.
Ya kalau udah tenyok-tenyokan.
Kalau nggak salah kalau dependensi, urusan dependensi.
Jadi kalau misalnya tim ini sudah butuh dependensi A dan tim B.
Maksudnya sama-sama ada react nih.
Satu tim sudah naik ke 19, satu lagi masih 18, tetapi belum mau naik.
Akhirnya udah bikin aja sendiri gitu.
Ya itu di episode 105, berarti 15 episode yang lalu.
Kita sekarang sudah di episode 120.
Oke, jadi kurang lebih micro front-end itu adalah satu aplikasi bisa terdiri dari banyak micro-micro apps gitu ya.
Yang bisa dikerjakan oleh orang yang independen, tim independen ya masing-masing ada.
Ya ada yang recommendation, tim popular, popular recommendation, ada yang search, ada yang playlist, macem-macem ya.
Kurang lebih kayak gitu.
Nah kalau monolitik, apa nih, monolitik ya.
Satu projek yang besar, satu projek yang besar, dijadikan satu projek secara keseluruhan.
Jadi dia tightly coupled ya, artinya sangat tergantung satu dengan yang lain, sulit terpisahkan.
Lawannya adalah micro service, micro service itu hampir sama kayak micro front-end.
Yang ini kan kalau micro service back-end ya berarti ya.
Yang satu service itu, satu service itu bisa berdiri sendiri.
Ya mungkin dia tetap butuh dependency, misalkan kayak login itu kan sama ya service yang sama.
Dia bisa konsumsi service lain tapi dia bisa istilahnya tidak tergantung,
tidak banyak tergantung kepada tim yang lain atau dengan service yang lain.
Jadi bisa asingkronus lah kerjanya ya, tidak tergantung.
Kalau biasanya misalkan kita udah mulai mengarah ke micro front-end atau micro service gitu ya,
kita kan biasanya karena tim yang terpisah secara otomatis repo-nya juga biasanya dipisahkan.
Itu kan nalurinya ya, ideal, bukan idealnya, biasanya gitu ya.
Biasanya.
Ya kita bikin tim, ya udah kita bikin repo baru gitu kan, atau bikin service kita bikin repo baru.
Bikin repo, bikin repo, bikin repo jadi banyak kan, multi repo kan istilahnya kan.
Ini juga saya pernah bikin bikini dulu juga, jaman dulu.
Waktu jamannya micro service saya bikin multi repo, micro service.
Problemnya apa kalau banyak repo kayak gini?
Maintainnya susah, pindah-pindah repo.
Betul, kalau kita mau jalani aplikasinya, semua repo-nya harus kita klon,
kita jalani npm start, terus tiba-tiba ada yang konflik portnya kah, atau apa, terus dependensinya banyak.
Misalkan yang satu pakai React versi berapa?
Iya.
Berapa sekarang React?
Kalau jaman itu belum jaman, waktu saya pakai multi repo, belum jamannya React React kan.
Anggap itu masih PHP, dan masih pakai Code Inventor.
Di query?
Nggak, Code Inventor, jadi backend-nya.
Oh, CI, oke.
Jadi micro service saya buatnya.
Jadi saya pisah-pisah, oke, payment endpoint sendiri repo-nya, terus admin.
Admin dashboard sendiri.
Admin dashboard sendiri, terus kemudian untuk shop, apa, public shop front-end-nya sendiri.
Landing page sendiri.
Landing page, lebih tepatnya untuk redirect.
Oh, user facing-nya sendiri, admin-nya sendiri, back-office sama front-office-nya.
Iya, betul. Jadi pisah-pisah. Aku pisah-pisah proses deployment-nya pun yang bisa nge-deploy sendiri ya.
Terus dependensi, misalnya payment butuh REST API dari database mana, gitu.
Terus REST API-nya yang di sini harus di-update, yang di sana harus di-update.
Kalau misalnya skema-nya berbeda ya, dua-duanya harus di-update berbarengan dan di-deploy.
Jadi maintain-nya jadi, cost of maintenance-nya jadi tinggi.
Hmm, oke.
Kalau multi repo.
Termasuk juga ini, kalau kita punya bisnis logic yang sama, yang digunakan oleh banyak project kan nggak bisa dipakai ya.
Harus masing-masing punya sendiri kan. Harus di-duplicate, gitu kan.
Nggak, atau dipublish jadi package.
Oh iya, dipublish sama package.
Dan jaman itu juga saya melakukan sebuah kesalahan. Jadi setiap aplikasi itu bisa langsung akses ke database.
Wah!
Jadi kalau misalnya di aplikasi tertentu update skema database, di aplikasi yang lain berusak, bisa jadi rusak.
Soal proses migrasi database-nya.
Wah, ini bukan microservice ini. Belum masih tightly coupled.
Itu namanya Cowboy Service lah.
Cowboy Service.
Kesalahan asetiknya saya jaman dulu.
Soal apa istilahnya terbakan hype.
Ikutin hype.
Iya, tapi salah kamu.
Ngesan.
Akhirnya dibangun, karena sudah terjadi masalah, dibangunlah satu aplikasi middle layer yang digunakan.
Jadi semuanya aplikasi harus lewat API. Jadi API Gateway gitu ya.
Ya udah, berarti secara cost of maintenance-nya lagi nambah.
Jadi ada satu-satu tim lagi yang ngurus API.
Oh, kirain tadi mau ngomong akhirnya, akhirnya saya resign gitu.
Reset kabur.
Mumut ah gitu dah, terlalu banyak.
Timnya kecil, repo yang diurus banyak. Jadi nggak imbang.
Terus update link-in, implement microservice.
Implement API Gateway gitu ya.
Itu apa, problem atau masalah-masalah yang terjadi di multi repo dan juga microservice ya.
Bukan hanya multi repo.
Nah, bayangin aja misalkan yang tadi ya, kayak microservice yang beneran lah ya.
Yang beneran yang sudah independent, masing-masing.
Terus repo-nya masing-masing.
Misalkan saya mau cobain ada nambahin fitur yang bisa konek ke Payment Gateway
di project kita, di Git yang satunya.
Ya, kita kan harus klon dulu, jalanin dulu kan.
Jadi sangat sulit gitu.
Belum lagi yang tadi ya apa, kayak mau share code atau mau share bisnis, ya bisnis logic.
Lojik yang pure function lah, yang sebenarnya bisa dipisah, tapi akhirnya jadi harus kopas-kopas.
Apalagi project 1, project 2, project 3, project 4.
Desain sistemnya, kayak kalau di front-end UI kan, kalau bisa aja kita punya banyak web app,
tapi kan kayak warna, bright colors-nya, desain toker-nya kan sama.
Itu juga jadi nggak bisa di-use.
Betul. Jadi anggap kata-kata kita pakai teknologi yang sama lah ya.
Project 1, 2, 3, 4 ini 4-4-nya adalah Node.js Application.
Tapi bisa aja di project 1 Node.js versi 20, yang ini versi 21, versi 22, versi 23 gitu.
Masing-masing juga pakai express.
Express-nya juga entah mungkin sama, entah juga berbeda.
Kalaupun sama, masing-masing punya node module sendiri.
Jadi besar sekali kan.
Makanya muncul lah solusi Monorepo.
Monorepo ini kita masih di dalam satu Git, tapi project-nya ada di dalam situ.
Jadi kalau misalkan kita mau jalanin aplikasinya, kita nggak usah repot-repot Git satu-satu,
tapi kita klon semuanya, jalankan yang kita butuhkan.
Install dan jalankan yang kita butuhkan.
Benar nggak sih?
Betul.
Betul ya.
Nah ini ada monolitik ya. Ini bahasa monolitik.
Nah itu Monorepo.
Monorepo is well-defined relationship between multiple different repos and each other.
Ini case statement-nya terlalu philosophic ya.
Terlalu philosophic ya.
Tapi sekejap lagi kelebihan kekurangannya bagus sih, penjelasan kelebihan kekurangannya.
DG to share resource tadi ya. Codebase atau business logic ya.
Itu bisa di-share di berbagai lapisan.
Kayak lerna salah satu ini ya.
Nah saya dulu pernah pakai lerna.
Dependensinya jadi satu. Oh lerna ya.
Selamat malam Mas Abu Lucu.
Halo.
Ini lucu banget.
Common dependencies tadi. Dependensisnya jadi satu.
Ya nggak sih ya.
Kalau sekarang.
Karena lerna itu udah lama banget.
Kayaknya udah.
Emang udah outdated deh lerna.
Iya udah outdated.
Jadi gampang sih.
Saya bikin ini.
Bikin satu repo sendiri, Monorepo.
Terus khusus untuk komponen-komponen.
Dump komponennya saya. Semua-semua dump komponen dimasukin situ.
Dan apa namanya?
Pernah nggak sih kalian mendengarkan?
Atomic architecture.
Atomic architecture.
Atomic architecture tapi di front-end taunya.
Ya front-end.
Iya taunya CSS.
Atomic CSS.
Jadi dari.
Atomic komponen.
Organism.
Itu kan yang website dokumentasinya warna orange itu kan?
Molekul.
Iya betul ada molekul.
Terus segala macem.
Jadi saya bikin Atomic architecture.
Atomic komponen disitu.
Jadi mulai dari paling kecil nih misalnya button.
Di atas button ada.
Ada text.
Habis itu ada card.
Habis ada card.
Ada.
I don't know.
Bisa makin lama makin isinya komposite dari berbagai macam atom-atom-atom.
Jadi komposite jadi molekul.
Di molekul jadi apa?
Organism.
Sampai sebuah satu page misalnya.
Jadi saya publish itu pakai learner semua ke github.
Untuk sebagai kayak NPM-nya gitu ya.
Jadi NPM-nya tapi koniknya ke private repo.
Ini dia atom design.
Design system.
Mana yang gambarnya?
Gambar atom-atom itu?
Di mana ya?
Iya itu desainnya.
Read now, read now.
Ini.
Atomic design dulu nih.
Mungkin yang 2.
Nah ini.
Pusing-pusing lah.
Mau bikin UI doang harus ketemu kimia.
Nah ini dia.
Atom, Molekul, Organism, Template, Pages.
Jadi semuanya dipublish ke...
Jadi satu repo, tetapi komponennya dipublish semua ke private.
Kayak NPM-nya tapi private di github.
Jadi saat di projeknya, saya tinggal kayak install komponen-komponen ini.
Tinggal pakai.
Jadi mau pakai di aplikasinya, saya hanya tinggal pakai organismnya aja.
Mau postcard, articlecard, apekard.
Itu tinggal import-import pasang-pasang.
Itu pun ada, tapi ada challenge-nya juga.
Nggak semuanya bahagia di situ.
Pastilah.
Versioning itu bahaya di situ.
Versioning-nya susah.
Kalau mau update sebuah komponen, itu runtetannya banyak yang harus diupdate.
Jadi kalau saya update satu yang paling kecil atomnya, button misalnya, jadi semuanya kena.
Harus diupdate.
Dan kalau udah banyak projek yang pakai, ya harus hati-hati mengupdate sebuah komponen.
Karena bisa jadi regression di tempat lain.
Nah ini kan tadi kita udah lihat keunggulannya, kekurangannya juga ada.
Yang pertama adalah reponnya jadi besar.
Terus untuk deploy-nya juga jadi satu.
Lama jadi satu semuanya sekaligus.
Yang ketiga adalah kalau teman-teman bekerja di perusahaan yang silo,
yang masing-masing unit bisnisnya itu punya rahasia,
yang tidak boleh diketahui oleh unit bisnis lain, ya nggak bisa.
Reponnya jadi satu, kita bisa lihat semua kodenya.
Berarti emang peruntukannya bukan buat tim-tim yang tertisah.
Mungkin lebih baik buat solo developer atau tim kecil.
Tim kecil, ya kalau tim yang istilahnya yang transparan dan mungkin secara,
kalau misalkan microservice itu dia masih ada, apa ya,
masih ada ketergantungan dengan fungsi-fungsi atau dengan service-service yang lain,
kan kalau microservice kan kayaknya dia bener-bener terpisah gitu kan.
Kalau ini masih ada hubungannya, masih konek lah, masih harus konek gitu ya kayaknya lebih cocok gitu.
Untuk hal-hal yang seperti itu.
Terus apa lagi tadi? Nah ini, storage ya udah pasti ya, jadi lebih besar gitu ya.
Cuman kalau dipikir-pikir kalau misalkan kita punya empat versi Node.js lebih gede dong gitu kan,
dibandingkan cuma satu versi Node.js yang dipakai rame-rame.
Halaman wiki ini mungkin apa, lama kali, lama nggak diupdate.
Kan sekarang ada rolling stack membantu ya, kayak yarnwork spaces aja udah ngebantu.
Habis itu sekarang ada kayak turbo repo atau semacamnya, justru lebih kecil sih.
Node modules-nya tuh kayak ada semacam same link gitu, jadi kalau yang dependensinya sama,
pnpm contohnya, untuk parallel packages, yarnwork spaces-nya tuh paling enak, the best.
Iya, jadi perusahaan-perusahaan yang menggunakan juga perusahaan-perusahaan besar ya,
kayak Google itu codebase-nya jadi satu semua, jadi satu repo.
Jadi kalau temen-temen join salah satu perusahaan ini, kalau kita mau mulai onboarding dan masuk ke project-nya,
itu kita bisa lihat semua code-nya dalam satu repo.
Oh? Serius?
Kalau yang udah ke Google, masih nggak ya?
Masalah kan, Mas Risa kan ex-Meta, ex-Google, ex-Microsoft kan?
Amin, amin. Masuk aja belum udah ex gimana sih?
Ini ada paper-nya. Ada paper-nya, billions of lines of code in a single repository.
Dan mereka punya ini sendiri.
Ya, makanya dibikin artikel-nya karena itu menarik berarti kan?
Kan yang waktu kita interview, Mas siapa tuh yang kita di Google sama Mas Arya Hidayat juga?
Saya masih ada fotonya.
Mas Bram.
Oh iya Mas Bram.
Bukan Bramus ya, bukan Bramus.
Bukan Bramus.
Mas Bram, orang Surabaya. Iya kan dia bilang semuanya jadi satu.
Nggak ingat. Saya kan sibuk merekam dan mempertahankan stand-nya kamera.
Nggak boleh geraknya.
Dan kedinginan.
Ini semua perusahaan yang besar ini ya itu.
Apa?
Itu kapan?
CDS kan itu ya?
Chrome Dev Summit 2018.
Ya, bulan November ya.
Belum kenal kalian sama sekarang ya.
Belum kenal.
Iya, dingin.
Ya, intinya adalah jadi satu repo besar itu dijadikan satu.
Meskipun, ada tadi yang Ivan sebutkan di PNPM atau NPM itu ada namanya workspaces.
Jadi meskipun kita download semuanya jadi satu, tapi bisa aja kita NPM installnya yang paket-paket tertentu aja.
Atau proyek-proyek tertentu aja nggak semua.
Itu kelebihan ya kan dibanding monolith, kalau tadi kan monolith ya skopnya luas banget.
Tapi kalau dianggap satu proyek.
Nah, kalau ini kalau mono repo itu kita mindset-nya banyak proyek, tapi dalam satu kontainer lah bisa dianggap.
Jadi perproyek itu bisa punya paket sendiri.
Kalau yang nggak, bukan kapan dependensi kan bisa nginstall paket masing-masing, bisa saling menginstall sama lain.
Paket A punya dependensi B, B punya dependensi C.
Kalau dulu mungkin itu repo, tapi kalau sekarang dengan tooling-tooling yang udah ada, itu kayak bisa diurusin lah sama situs itu.
Nah, terus bisa juga dipapis.
Basal ya, salah satunya ya?
Bisa dipapis separately juga, jadi misalnya kalau konteksnya kita bikin UI library atau komponen library kan kadang-kadang tuh yang diinstallnya satu persatu.
Maksudnya kita cuma mau nginstall kartu komponen atau data picker.
Kalau mau, proyek-proyek itu juga bisa dipapis ke NPM separately.
Atau kalau misalnya web app, Next.js atau apapun, ya bisa di deploy secara terpisah juga ya.
Jadi publishingnya itu bisa terpisah-pisah walaupun dalam satu mono repo.
Itu salah satu kelebihan utamanya juga nggak sih?
Ya. Basal ini yang dipakai Google ya?
Kayaknya iya ya. Yang bikin Google ya.
Oh iya benar. Tools, semua tools-nya.
Dari style UI-nya aja udah.
Oh iya, material design ya.
Ini adalah tools untuk mono repo-nya mereka kan?
Basal, ada Lerna, ada banyak sih sekarang Turbo Repo, NX.
Mau contoh lagi, ada contohnya di sini ada,
kalau temen-temen pernah buka repository-nya React.
React library-nya ya, yang buat development-nya, bukan buat make-nya.
Kalau make-nya kan tinggal NPM install ya.
Tadi soalnya ada yang nanya juga sekalian ya. Masih rekomendasi, masih.
Jadi kalau di Repo-nya React di sini, NX mono repo, ya NX betul.
NX itu ternyata mengakuisisi Lerna. Nah kita bahas nanti aja dulu.
Ya, ada packages. Jadi di package-nya React itu ada banyak dependensi lain.
Tapi dependensi-nya bukan di NPM. Dependensi-nya di Repo-nya sendiri.
Contohnya ada React DOM pasti di sini. React DOM.
Mau dipublish ke, itu masih-masih kan dipublish ke NPM juga.
Jadi maksudnya secara external, orang kan kita bisa install React DOM.
Pakai apa dia di sini?
Iya, pakai apa dia?
Pakai package design.
Kalau dulu saya pakai Lerna.
Bukan. Untuk nge-publishnya itu.
Workspace.
Pakai workspace.
NPM workspace kan? NPM workspace, PNPM workspace,
Deno workspace, Boon workspace, semuanya pakai package design aja.
Kayak gini aja udah sama dia.
Jadi bisa gontah-ganti sebenarnya.
Eh, nggak tahu sih bisa gontah-ganti atau nggak.
Tapi mereka pakai notasi yang sama.
Ih, pakai roll-up mereka.
Iya.
Nah, tuh lihat aja build script-nya. Build for dev tools.
Build lah, kalau React mah yarn lah pastinya ya. Karena yarn juga dibikin oleh timnya React kan.
Pakai yarn ya.
Coba aja, apa, scroll ke bawah, ada nggak publish?
Publish?
Publish pre-releases.
Ini, this comment has been deprecated.
Oh, dia ganti.
Ya, intinya gitu. Ada lagi, contoh lagi, misalkan Boon.
Boon juga repo-nya menggunakan Monorepo.
Sveil.
Sama.
Ini, ah, spell. Apanya spell?
Nggak, maksudnya Sveil juga Monorepo kan.
Oh, iya.
Ada packages juga.
Berarti proyek-proyek open source yang populer tuh rata-rata Monorepo ya?
Karena nggak makes sense itu.
Kalau core-nya, maksudnya package yang disupport dari core-nya.
Nggak makes sense sih kalau dibikin repo terpisah.
Nah, handle-nya susah. Maintaining-nya susah.
Karena sudah bisa beda repo, beda build tools, harus di-maintain, dependensi.
Itu cost of maintenance-nya tinggi.
Wah, Mas Ricky juga sudah pakai Boon workspace ya.
Mantap.
Di Deno juga ada, jadi sudah lengkap ya.
IARN ada, NPM ada, PNPM ada, Deno, Boon, ada semua.
Kalau kita pakai workspace ya.
Tapi adanya teknologi workspace itu membantu banget sih sekarang.
Untuk bisa Monorepo sangat-sangat membantu.
Iya.
Karena setiap packages itu kita bisa define itu tadi.
Bisa ada global dependency.
Bisa ada workspace dependency atau private dependencies-nya.
Dan bisa interlink antar packages kita sendiri.
Waktu nge-build dia cukup.
Itu kan kalau ngurus sendiri rada ribet ya. Masa rawan bahaya.
Dependensinya A, bergantung pada B.
B bergantung pada C dan seterusnya.
Kalau pakai tools yang sudah ada, kita bikin command-command-nya saja.
Abis itu diurus sama tools.
Ini ada contoh juga.
Next.js Monorepo ya.
Nah, ini nih favorite sih.
Jadi ini kalau buat yang front-end, front-end atau full stack.
Ini contoh yang ini unofficial.
Tapi, aduh, gue seneng banget nih.
Karena, apa ya, well-structured sama well-documented kayak rapih banget.
Penjelasannya juga bagus.
Tuh, lihat kontributurnya yang di kanan atas.
Sampai pernah full request.
Eka ada Eka.
Itu benar-benar sesuatu. Nggak tahu, nggak inget apa.
Nah, cuma kalau pengen tahu...
Bukan. Nggak kelihatan nih.
Jadi kepu Eka commit apa nih?
Minorefix sih. Karena pakai...
Mana?
Ya, pokoknya pernah.
Nggak tahu, itu 5 commit.
Klik 5 commit.
Nggak ada.
No, no, no, no.
Di reset.
Karena kelihatannya 5 commit ada.
Gimana bisa masuk kalau...
Kenapa sih nggak mungkin ada?
Kenapa dianggap 0 ya?
Oh iya, dulu belum digerasi Gavik VT.
Sekarang itu untuk digerasi Pulley ke VT.
Ya, ininya sih nggak penting.
Tapi itu minorefonnya menarik deh.
Jadi, skenario-nya adalah Web App Next.js.
Tapi ada UI library-nya yang separate.
Nah, terus UI library-nya itu dibikin pakai storybook.
Dulu kita pernah pakai storybook.
Jadi maksudnya enak kan?
Untuk utility, core, ada UI-nya.
Ada storybook-nya.
Kalau yang bukan UI, nggak ada storybook-nya.
Ya, UI-nya dipisah di satu tempat.
Web App-nya, kita mau bikin 1 web app...
Atau mau bikin 10 web app, misalnya.
Kita punya macem-macem, misalnya.
Micro-site atau apapun itu.
Ya, nggak harus pakai NCS juga kan.
Misalnya kita satu produk pakai NCS.
Produk lain, kita cuma pakai.
Lebih simpel nih.
Pengen read sama react yang client-site aja misalnya.
Atau pakai apapun itu.
Ya, udah ditambah. Ini mau 1, mau 2, mau 10.
Bisa kayak dengan relatif gampang tambahin di sini.
Nah kan, kalau hal-hal kayak branding,
mungkin design tokens, yang UI yang common,
itu bisa di-install dari CUI lib tadi.
Tapi ya, sebetulnya kalau ada yang khusus internal di web app tadi,
ya bikin UI di web app-nya sendiri juga bisa.
Nah, terus itu tadi ada package juga.
Jadi buat kayak logic-logic yang pure JavaScript function,
utility, itu bisa kepisah juga.
Terus ada yang mirip sama yang dibahas event tadi
buat interaksi sama database.
Kayak ada satu package-nya sendiri.
Itu kalau yang di starter template ini pakai Prisma.
-Pakai apa? -Prisma.
Prisma atau database ORM.
Jadi ini nggak spesifik ke Next.js ya?
Kenapa disebutnya Next.js Monorepo?
Ya, karena awalnya itu buat contoh pakai web Next.js.
Tapi kan buat perintilannya kayak bisa interaksi ke database-nya,
ORM database layer-nya sendiri,
UI-nya sendiri, UI pakai Storybook, ada Tailwind-nya,
terus Pure Function Utility sendiri.
Nah, cuma kan udah.
Nah, tunggu, kalau nggak salah gue ada yang propose.
Ya udah, gimana kalau tambahin satu contoh
buat bikin beat app biasa?
Nah, terus cuma ini yang bikin impressed,
itu kayak penjelasan ini sama contoh-contohnya tuh jelas banget.
Detail buat seneng deh kalau lihat contoh kayak gini.
Jadi apa ya? Jadi lebih gampang ngerti.
Kalau misalnya tadi kan kayak baca artikel,
"Oke, kita paham konsepnya, cuma maksudnya bentuknya kayak gimana?"
Apa? Ini sih.
Lihat contoh ini jadi, "Oh, ya, ngerti."
Nah, itu juga ada internationalization-nya tuh,
jadi kayak buat apa? Language Key-nya,
misalnya kita pakai multiple language,
bisa apa?
Oh, nggak deh, itu di web app-nya, di Next.js-nya.
Ini ada packet common.
Oh, ada common-nya.
Itu kayaknya cuma JSON, ya JSON keys.
Tapi kan usual-lah.
Itu sampe ada contoh-contoh yang udah di-deploy-nya.
Terus, readme-nya juga, apa sih, readme-nya lengkap.
Jadi kalau kita nge-port, tinggal find and replace semua.
Kayak your app nama-nama gitu.
Oh, iya, jadi gampang di duplikasi, ya.
Find, replace.
Contohnya juga, apanya semua ada contohnya.
Ini, eh, bukan. New York App.
Minus, oh, nggak ada.
New York Dash, nggak tahu.
New York Dash apa?
Ini, bukan. My App.
Oh, My Dash App.
My Dash App.
Ini, tinggal diganti aja ya semuanya?
Iya.
Oke.
Kalau ini, contoh, ini pakai yardmode spaces.
Terus ada kayak itu, nah, ini common-common-nya.
Kayak test, build, clean.
Clean, ya, oke.
Oh, menarik ya.
Oke, ini contoh yang menarik juga.
Tentang per-package, testing-nya bisa per-package.
Iya, per-project ya, per-package ya benar-benar.
Per-project, per-package.
Ya, unit testing-nya per-package.
Kalau end-to-end kan sebetulnya ya web app-nya aja kan.
Kalau yang lain-lainnya nggak perlu.
Ya, itu namanya ada unit testing, habis itu ada integration testing.
Atau ada end-to-end testing. Jadi bisa unit test-nya bisa per-package.
Iya, tadi kita ngomongin tentang tools-nya kan ya.
Tools-nya tadi ada Bazel.
Terus ada Lerna. Lerna berarti udah di...
Lerna itu cloporn-nya, tapi menarik sih buka aja coba.
Lerna.js.
Masih hidup nggak sih Lerna?
Masih ada, tapi itu makanya buka website-nya.
Itu cloporn-nya ya, ternyata itu cloporn tooling.
Iya, juga GitHub-nya.
Masih ada.
Masih, masih, cuma konteksnya buka website-nya.
Tadi itu Pernadon.js.
Nah, itu kan original tool for JavaScript Monorepo.
Nah, itu yang di atas ada link to new, NRWL.
NRWL itu produknya NX.
Narwhal, NX.
Jadi ini si maintainernya, dia stepping down.
Terima kasih, dia mengundurkan diri.
Karena burn out standarnya.
Nah, lanjutannya adalah itu.
The company behind NX ya.
A tool already recommended for too many folks looking for a Lerna replacement.
Jadi kayak semacam diurus sama si Narwhal ya.
Diurus? Diurus ya, berarti bukan dimatiin ya?
Ya, mungkin nggak di-develop lebih lanjut, tapi di-maintain lah.
Tapi bakasnya di-maintain, kodenya di-maintain.
Baksanya di-maintain, kodenya dihilangin, fiturnya dihilangin.
Jadi sudah diakuisisi oleh CNX ini ya, nggak tahu nih Lernanya mau diapain, mungkin dalam maintenance mode ya.
Bukan akuisisi, tapi kayak diurusin lah.
Diurusin, dibantuin lah ya.
Karena maintainer aslinya burn out.
Stepping down, mengundurkan diri.
Kenapa ya burn out?
Kita nggak sanggup, Pak.
Dunia open source itu berat.
Biar Dilan aja yang itu open source.
Sudah, nggak enaknya open source itu sudah kita volunteer, habis itu dikejar-kejar.
Memakai-makai orang.
Memakai-makai orang, yang dapat duit orang lain.
Oke, kalau kita mau mulai gimana?
Misalkan saya punya project baru, saya mau pakai Monorepo.
Mulainya dari mana?
Pakai apa yang paling gampang?
Itu siapa yang paling gampang?
Turborepo.
Turborepo, oke.
Yang gue pernah pakai cuma satu sih, jadi nggak bisa bilang paling gampang.
Yang sama Yarnwork Spaces tadi.
Yang pernah dipakai, jadi kan yang familiar, jadi kan bisa ngajarin gitu ya.
Turborepo kan bagian dari Turborepo.
Ya kayak helper buat Monorepo, khususnya yang aplikasi berbasis JavaScript sih.
Ya ekosistemnya Vercel lah.
Jadi kalau buat yang penggunanya Next.js, yang udah familiar.
Turbopec ini masih belum bisa replacement webpec ya?
Untuk project lain.
Belum.
Belum, non-next.
Selain Next.js ya.
Belum bisa kayaknya.
Turborepo, The Monorepo Problem.
Ini juga ada ya, kita bisa baca dari sini ya.
Tapi ini kan kurang objektif.
Kurang objektif, bukan kurang subjektif.
Vercel Universe ya.
Jadi sama kayak tadi kan sebenarnya kan.
Packages, terus ada apps, ada misalkan docsnya mau pakai spelt disini, contohkan boleh-boleh aja.
Terus apa lagi?
Solusinya adalah, ini kan beda repo nih.
Nah, kalau Monorepo dia jadi satu.
Semuanya yang tiga-tiga ini.
Tinggal jalankan turbo run, lean, build, test.
Ya salah satu kali ya, turbo run, lean.
Dia ngelinting semuanya.
Tiga proyek ini sekaligus gitu ya.
Enggak satu-satu.
Banyak banget tuh, run, lean, build, test.
Bisa di, ini ya.
Bisa di apa?
Di chaining.
Chaining, di chaining.
Mungkin, gak tau juga.
Lean, build, test.
Jadi kayak CI.
Kalau CI kan jawabnya satu-satu tuh.
Keren ya.
Installing turbo.
Terus, ada generator nya, turbo generate.
Masih pake RAS gak sih, mereka buildnya ini.
Ini ada, ada GitHub repo nya gak?
Oh masih-masih RAS-RAS, tadi tulisannya di atas.
Ada kok tadi tulisannya build with RAS.
Mana? Nih, RAS.
Iya.
Paling atas, di ininya dia.
Tuh, written in RAS.
Makeshift happen.
Oh ini, ini jadi itu ya, jadi, apa namanya?
Jadi Unix selling point ya.
Iya.
Everything in RAS.
Kan kan cepat, kan apa identiknya cepat?
500 kali lipat atau 1000 kali lipat atau?
500 kali lipat.
Hanya terjadi di perusahaan Indonesia.
Nggak ada mereka berapa kali lipat.
Coba aja lihat nih, turbo pack, berapa kali lipat dibandingkan webpack.
Nggak ada dia banding-bandingin.
Ada tuh.
Ada sih, ada ya, ada yang bandingin ya.
Tapi nggak sampai 500 kali lipat juga.
Ada.
Itu benchmark tuh benchmark, benchmark di kiri bawah.
Nah.
Mana?
Oh sudah nggak ada.
Di benchmark.
Dulu kan ada.
Belum stabil berarti.
Ada, bandingin antara Shell sama Vivo misalnya.
Bukan dengan Pertamax ya.
Kasian.
Kasian. Kita baru minggu lalu ya waktu ketemu ngobrolin Shell ya.
Terus tiba-tiba muncul beritanya seminggu kemudian.
Kacau, kacau.
Oke, Turbo Repo. Caranya pertama install dulu kan.
Ini bisa langsung generate ya?
Ini langsung generate ya?
Iya kan NPX.
Iya, NPX.
Ini kayak create rate app-nya nih.
Iya kayak from template.
Create from official starter template.
Itu penyelesaannya, starter repository will have blah-blah-blah.
2 deployable applications, 3 shared libraries for use in the rest of the monorepo.
Wow, langsung bikin monorepo, dan arkitekturnya tuh.
Ya, ya, that's the point.
Pertanyaannya apakah ini akan menjadi vendor login?
Kalau kita pakai ini, tapi kita nggak mau pakai NXJS.
Kalau nggak mau deploy Covarsel, bisa nggak?
Coba aja.
Iya, nggak apa-apa. Tapi ini didesain untuk JavaScript Ecosystem.
Apa yang kemarin itu? Tutorial kit ya?
Yang buat ngetes kayak ada VM sendiri buat ngetes ini.
Stack Blitz.
Banyak sih sekarang.
Tutorial kit ya, tutorial kit?
Iya, tutorial kit.
Install, oh ini kalau mau install sendiri.
Nah, kayak UI Library ini, kalau cuma React UI Library biasa,
mau publish ya publish aja kan, nggak Covarsel pun, bebas.
Tapi kalau misalnya app-nya NXJS, ya apa?
Masalah standar web app NXJS apapun, yang kalau kayak pakai fitur SSR-nya kan,
nggak bisa langsung di deploy ke postingan lain,
atau apa sih yang image, image library-nya nggak jalan.
Masalahnya sama standar.
Ini example-nya ada spelt, tapi yang NXJS-nya nggak ada ya?
Apa by default udah NXJS ya?
Ada, defaultnya ada NXJS ya.
Ini spelt doang adanya sih?
Nggak, ada NXJS.
Banyak banget, itu puluhan.
Kayaknya yang default dari TurboRepo itu ada NXJS.
Oh defaultnya udah next.
Minimum requirement specifying, sama ya, pakai all spaces juga.
Terus sama yang kayak tadi ya, contoh repo tadi, ada apps dan repackages.
Packages ini adalah shared code atau business logic ya,
atau package yang dipakai bersama.
Library-library yang dipakai bersama.
Kalau apps itu berarti aplikasinya.
Apakah misalkan landing page, ada back office, ada front office, ada apa lagi itu, banyak ya.
Ada dokumentasi. Yang mengkonsum package.
Ya, yang menggunakan si packages.
Jadi kalau pattern yang umum, masing-masing package,
di dalam package itu bisa saling bergantung.
Maksud saya packages kan misalnya ada TS utility, ada business logic,
itu bisa saling bergantung.
Cuma kalau apps, nggak boleh saling, nggak boleh punya dependensi dari project lain di apps juga.
Cuma bisa bergantung pada packages.
Bentar, kalau gitu packagesnya cuma satu yang di-root level doang ya, berarti ya?
- Nggak, masing-masing. - Di dalam packages ada ya?
Di dalam packages ada, iya iya benar benar.
Terus itu buat identifinya kan, namenya.
Iya, iya iya.
Untuk menjalankan app-nya, baru yang pakai di packages yang di-root level ya?
Kalau di app-nya sendiri nggak ada kan?
Ada lah, ada semua.
- Ada juga ya? - Semua punya packages yang bukan.
- Masing-masing punya sendiri ya? - Iya.
Jadi itu sebetulnya, ini kayak package Next.js biasa, kayak web app.
Hampir seperti web app Next.js biasa pada umumnya yang bukan monorepo.
Cuma bedanya dia bisa dengan gampang pakai dependensi dari packages ini.
Iya, oh ini kayak git repo sendiri sebenarnya kan?
Cuman ini sekarang jadi satu, kira-kira gitu ya?
Ini packages juga sama, misalkan ada kita pakai UI library di sini.
Ada package JSON, ada storybook dependensi, atas macamnya.
Dibuild nanti jadi sebuah distributable sendiri.
Mau jadi NPM packages sendiri, mau jadi installable sendiri, ya terserah sih.
Dan itu bisa diikutin masing-masing project-nya.
Jadi kalau misalkan Next.js app, kita build, kalau emang perlu build kan di disk-nya,
HTML, JavaScript, jadi static HTML asset kan.
Nah sedangkan kalau misalnya UI library, JavaScript, React lah.
React UI library, kita misalnya masih harus yang banyak formatnya tuh,
yang harus jadi command.js lah, harus jadi ngjs.
Nah itu kan terus harus generate type script definition lah.
Itu kan ada setting-nya sendiri, jadi masing-masing project bisa punya build setting
sesuai nature-nya, sesuai jenis project-nya.
Dan dia ini pakai TurboRepo ternyata ya.
Iya, ini kan ekosistem fair-sell banget lah ini.
Iya, iya, iya.
Menarik, menarik. Nah ini mas Ricky ada opinion ini.
Sebelumnya sempat kepikiran pakai TurboRepo, cuman pas nyoba workspace-nya lebih simpel,
karena cuman mau share dependency.
Ya, kalau mau yang simpel ya pakai workspace-nya saja.
Udah aja semua ya. Sekarang IARN workspace-nya ada.
Dulu banget pertama kali kan cuma di IARN ya, IARN workspace-nya.
NPM belum ada, sekarang udah ada semua.
Semua udah ada. Termasuk Deno, Bun, dan lain-lain juga udah ngikut juga ya.
Ini saya punya artikel sebenarnya ya, artikel yang berhubungan dengan Monorepo juga.
Cuman dia ada kasih contoh, dan contohnya bagus.
Contohnya itu kita bikin dari bener-bener enggak pakai TurboRepo dan lain-lain.
Ini kan dia bilang the most popular, blablabla, Lerna, NX sama TurboRepo.
Tapi kita bisa set up sendiri.
Nah, tujuannya supaya dia ngerti, supaya dia mengerti behind the scene-nya,
cara kerjaannya, ini dia pakai manual.
Jadi kita bikin directory structure-nya dulu, ada packages, ada SRC.
Terus abis itu, ini kita bikin folder-nya terus di-init.
Terus dibikin packages-nya ditambahin workspaces.
Jadi nanti ketika kita tulis atau kita bikin tambahin package di sini, secara otomatis,
dia akan masuk kesini, dia akan nge-simling ya, atau linking kesini.
Apa kepanjangan simling?
Ya, kepanjangan simling apa?
Simling-nya ya?
Simbolik.
Apa?
Simbolik.
Simbolik, iya simbolik.
Ada satu lagi yang mirip kan, tapi heartlink atau apa ya?
Heartlink.
Simling, heartlink, ya itulah.
Ya itu.
Terus dia contohin juga disini kalau dependensinya,
kalau semuanya pakai TypeScript, ya diinstall-nya di root level.
Termasuk juga TSNode kalau semuanya pakai TSNode.
Terus pakai Yeslin, Prettier juga semuanya kan, jadi seragam, biar seragam.
Ini sekarang lagi cerita di global.
Bukan di global, di root level.
Di root level kan.
Bukan global, install global bukan ya?
Terus, ya kan tujuannya supaya seragam kan.
Oh Yeslin rule-nya daripada satu-satu, ya udah satu project aja semuanya sama gitu kan.
Biar nggak capek.
Tapi bisa di-extend, tapi mengkonsumsi kan.
Oh iya betul, bisa di-extend.
Terus misalkan ada utility.
Kita bikin init lagi, tapi scope-nya adalah monorepo.
Monorepo ini adalah nama project-nya.
workspace-nya di packages/utils.
Jadi di init juga.
Nah, dia punya packages-nya sendiri.
Terus ada tsconfig dan lain-lain lain.
Misalkan UI kita butuh react lah, atau UI library lain.
Terus kalau misalkan dibuild, dia akan masuk ke node modules yang di root level.
Terus kalau mau global tsconfig juga boleh.
Sendri-sendri juga boleh.
Apalagi yang menarik ya.
Misalkan kita mau add package terparti.
Ada nggak contohnya?
Nah ini external package.
Misalkan moment, moment.js.
Itu kita bisa install satu dipakai buat ke semua.
Ada yang tahu loh, simbolik link.
Nantap.
Palu gada developer.
Ini cocok buat monorepo.
Palu gada.
Iya, pakai Google ya.
Palu gada.
Kita install moment.js hanya di package UI ya, berarti ya?
Kalau gini ya?
Kenapa sih pakai moment?
Contoh.
Dari antar dukungan ini.
Biar gede itu.
Dfns aja cukup kok.
Dfns ya.
Pakai temporal aja temporal.
Pakai web API aja.
Beda konteks ya kita ngomongnya ya.
Beda konteks.
Udah, jadi ini salah satu contoh yang
mungkin kalau temen-temen mau bikin dari scratch nggak pakai Turborepo, NS, dll.
Bisa belajarnya di sini.
Karena cukup pakai...
Sama biar tahu juga, biar nggak magic kan.
Maksudnya biar nggak...
Habis kita bikin ini, kita jadi tahu Turborepo itu ngapain.
Jadi kayak bukan sulap, bukan sihir ya sebenarnya.
Bukan sulap, bukan sihir.
Langkah-langkahnya.
Langkah-langkahnya.
Dan dengan itu aja udah solving masalahnya ya udah.
Nggak usah pakai Turborepo, nggak usah pakai yang lain.
Cukup, box spaces aja.
Seperti yang Mas Ricky mencoba juga.
Kalau cuma muser dependensi ya cukup kan.
Oh ya kalau Turborepo itu kelebihannya kayak proyek versi lainnya.
Dokumentasinya bagus sih.
Mantap ya.
Mengapun.
Ya karena emang mereka hire orang buat itu kan.
Jadi dibayar untuk supaya proyeknya laku.
Dijual dengan cara ini kan.
Developer experience-nya harus bagus.
Supaya vendor locking.
Supaya orang mau...
Karena itu ya bisnis ya.
Ya wajar lah, bener.
Nggak salah, nggak salah.
Bukan sesuatu yang salah.
Dan Turborepo-nya sendiri kan fully open source.
Maksudnya biar kita terpikat masuk ke ekosistem mereka.
Pakai Next.js, deploy, cover, sell.
Terus banyak pake cloud function dan fitur-fitur semacamnya.
Akhirnya jadi bayar cloud jasa-jasa posting sama cloud-nya kan.
Ini cara menjebak yang elegan.
Tapi sebetulnya kalau proyeknya nggak terlalu besar, ya nggak bakal...
Masih gratis kan?
Ya Turborepo-nya kan ini tooling yang tinggal diinstall aja.
Next.js-nya maksudnya.
Betul.
Fender lock-in kita bang.
Handphone-nya apa ayo?
Pengennya Apple, tapi nggak mampu.
Android kan?
Itu vendor lock-in juga.
Ya iya.
Tapi kan bisa mengurang-urangi.
Kalau hape, opsinya kan cuma dua.
Iya, ke Apple juga vendor lock-in.
Memang ada yang netral, handphone.
Lebih vendor lock-in lagi sih.
Ada dulu.
Nokia.
Nokia bikin.
Tapi gagal.
Firefox bikin.
Gak ada duitnya.
Gak ada duitnya.
Iya kan vendor lock-in itu kan buat cari duit.
Bisnis.
Masalahnya vendor lock-in yang kita senang terjebak di situ,
atau yang kita sedih terjebak di situ?
Tinggal pilihannya itu aja.
Sama kita sadar atau nggak jebakannya itu dimana.
Maksudnya kita kalau emang dengan, kita konsen nih kita bersedia,
ya udahlah bayar.
Ya kan nggak apa-apa.
Terus kalau ternyata kita nggak cocok atau apa,
kita anggap nggak worth it,
ya kita harus tahu jebakannya dimana biar kita muter kan.
Terus kalau dari sisi CDN, Cloudflare.
Cloudflare juga ya.
Kita vendor lock-in loh.
Memang gratis.
Karena bayar to entry-nya sudah mulai masuk.
Masuk bayar, buah halnya minta ampun.
Iya, tapi vendor lock-in,
bayar to entry-nya Cloudflare itu gampang sekali.
Tipis.
Kita tinggal register, terus masukin DNS, setup DNS dan lain-lain, udah.
Dibandingkan coba kalau pakai service cloud.
Panjang jalannya.
Tapi ya itu kan, balik lagi, vendor lock-in.
Kalau untuk sekedar hanya blok personal pribadi yang trafficnya biasa-biasa,
nggak perlu pusing.
Gak perlu pusing. - Tapi begitu sudah mulai bayar, sakit.
Ya sama kan, Versal juga gitu kan.
Versal juga gitu kan, kalau hobis atau bahkan aplikasi yang sekaligus.
Ya, aman.
Over the tear, cukup.
Cukup.
Cuman kan dia menjebakan.
Kalau misalkan ternyata aplikasi ini berkembang, diakses banyak orang,
nah baru kena asli.
Itu kan fair kan, ya maksud saya, at least dalam dunia kapitalis,
ya itu fair kan, kalau misalnya aplikasinya besar,
kan makan banyak resursi dan kemungkinan, itu project yang udah ada duitnya kan,
maksud saya yang udah komersil, atau emang udah populer banget, bisa diguitin.
Masih ada yang penganur anti-kapitalis.
Torrent world, misalnya. - Ya bikin sendiri.
Anti-kapitalis berarti, dia itu ya, nulis,
apa kalau nge-tick-tick keyboard itu nggak pakai urus besar ya?
Lowercase ya?
Saya nggak punya soundboard, Mas.
Menjipin soundboard sendiri.
Versal ada loongan DX engineer, iya kayaknya ada.
Jadi sampai DX nya dioptimalkan ya?
Betul.
DX engineer tuh ngapain coba?
Ya ini, dokumentasi termasuk kan.
Developer experience, ya cara installnya,
desain CLI, desain CLI-nya itu harus detail gitu,
sesuai, bukan sesuai.
Oh berarti dia kayak ngetes ya, kalau misalnya step-stepnya yang gampang dipahami gimana,
terus yang enak, yang kemungkinan banyak developer senang tuh,
stepnya gimana, kata-katanya apa.
Bisa jadi kita juga topik selanjutnya untuk desain CLI.
Desain CLI, iya menarik ya.
CLI nggak pernah kan dibahas sama sekali kita ya.
Karena interface-nya bukan web.
Ya tapi buat web.
Tamina bisa jalan di web, ngeles mode on.
Enggak, kalau mau developer harus pake terminal kan.
Kalau mau jalanin localhost 8 ribu, 3 ribu kan harus pake terminal.
Kecuali pake stack bits.
Kecuali pake CSS, itu ya.
Gedein SAP-nya, sebelum susunnya diperah.
Enggak, ada satu lagi konsepnya agak absurd ya.
SAP itu kan ada sendiri kan?
SAP? Apa lagi itu?
S-A-P-I.
Bentar, ada ini.
Ada aplikasi.
S-A-P-I apa ya?
Ada korba, korba itu kan kayak korba jadi cobra gitu kan.
Ini SAP-I.
S-A-P-I itu adalah Server Application Programming Interface, SAP.
Server Application Programming Interface.
Iya makanya saya...
SAP.
Iya, PSP, S-A-P-I, S-A-P-I.
S-A-P-I.
Ada, makanya SAP.
Loh, saya langsung pikirannya...
S-A-P-I.
Oh, S-A-P-I.
Direct Module Interface to Web Server.
Oh, modul PHP itu namanya SAPI.
Iya, betul.
Betul, tongket itu SAPI.
Dari dulu pake tapi nggak tahu istilahnya.
SAPI.
Besok kalau bikin tiket tolong buatkan SAPI.
Tolong buatkan SAPI.
Kacau, kacau.
Oke.
Udah ada aja ngerti tuh PHP SAPI.
Ngerti ya.
Oke, yang berkaitan dengan Monorepo ada lagi yang mau dibahas?
Udah, itu aja.
Kayaknya menurut saya penuntutnya saat ini masih trendingnya itu dan akan kayaknya future-nya masih pake Monorepo sih.
Saya nggak terlalu banyak pembahas sebuah future-nya application ini saya ganti lagi ke microservices beda Repo kan.
Beda Repo.
Oh, beda penuntut kan tadi maksudnya apa? Beda audience, beda target.
Gimana kalau misalkan kita baru bikin project, kita ya kan kita estimasinya oh ini project-nya bakal kompleks nih, bakal berkembang nih.
Apakah kita langsung Monorepo atau nggak usah dulu?
Kita bisa sambil jalan.
Lebih baik standard by default Monorepo dulu.
Oh gitu.
Karena udah gampang juga.
Udah gampang juga ya, tinggal workspace-nya saja ya.
Sekarang misalnya saat ini satu project saya yang salah satu saya maintain, beda Repo akhirnya ujung-ujungnya jadi submodule.
Oh ya gitu submodule ya.
Iya dan itu memaintainnya lebih susah.
Lebih ribet lagi ya.
Di sana sudah selesai di update, saya harus update lagi di main Repo, update submodulnya supaya pakai hash yang terakhir, di commit lagi.
Aduh belum lagi, eh lambat lah.
Jadi nggak mau, kalau kedepannya saya juga nggak mau lagi.
Kalau memang mau project satu, bikin aja packages di dalamnya langsung Monorepo aja.
Bisa kok, nggak ada.
Gampang kok ya.
Ya jadi composer packages juga bisa, nggak perlu pusing-pusing.
Kalau untuk PHP base ya.
Kalau JavaScript base ya itu tadi aja Turbo Repo, MPX Repo.
PNPM aja kalau saya mah, langsung PNPM workspace.
Iya PNPM.
Karena PNPM package lock-nya flat kan, jadi lebih efisien.
Lebih emas.
Having hard disk space.
Yes, okay kalau gitu pembahasan tentang Monorepo kita tutup, jadi sekarang kita diskusi untuk bahas topik minggu depan.
Monorepo kita bisa close.
Masukin ini ya, link YouTube-nya bisa dimasukin di sini.
Link YouTube-nya bisa, bisa.
Benar juga ya.
Iya jadi kalau kita rajin dapetin atau nanti bisa project kita yang terhambat ngobrolin.webnya, ngobrol.in/webnya, nanti bisa diambil kayaknya link-linknya ini.
Tuh, apa gambar apa, link atau iframe?
Nantilah disini.
Kamu saling dulu aja ya.
Oke untuk bahasan berikut, apa episode berikutnya kira-kira apa?
Gas.
Gas.
Apa?
Gas.
Oh iya bahas gas ya?
Gak tau.
Sama siapa?
Belum dapet.
Kita gak, eh ini lah tadi top all.
Mana sih?
Oh gas yang ini, yang baru.
Google Ads Script.
Google Ads Script.
Google Ads Script.
Google Ads Script.
Google Ads Script.
Apa sih?
Gas.
Iya.
Google Ads Script.
Google Ads Script.
Google Ads Script.
Oh.
Gua pernah pake sih, cuma gak detail banget.
Belum apa?
Yang gak ditulis.
Siapa ya?
GDI Ads Script.
GDI Spreadsheet.
Iya, iya, iya.
Nah yang kayak misalnya Spreadsheet atau apapun di produknya Google, ya buat satu sama lain.
Jadi kayak kalau ada yang isi Google Form, otomatis ngeformat dan lain-lainnya ke Google Sheets.
Iya, iya.
Saya pernah, baru saja di Whatcom Asia, saya bikin Google Spreadsheet pake Apps Script ini
untuk nge-fetch data di Spreadsheet.
Terus ada salah satu ini, apa namanya?
Kayak formnya istri saya gitu buat jauh-jauh para dokter.
Terus kemudian dia bikin jadi kayak matrix jarang gitu, tau gak?
Matrix jarang.
Gak?
Gak.
Hah?
Jadi kalau kayak nge-mapping misalnya, kalau dia jaga 1, kalau gak jaga 0, jadi 1, 0, 1, 0, 1, 0.
Jadi kelihatan itu jumlah, jumlah berapa jaganya.
Terus saya pake Apps Script ini untuk totalnya dan bisa pake color coded.
Asik.
Tapi nantilah.
Kalau gue cuma pernah simple banget sih dari Google Forms.
Ya pokoknya ada opsi jawaban yes sama no.
Tapi ada detail-detailnya juga, ya cuma dibisah bikin Spreadsheet, tapi Tabsheet terpisah, yes sama no.
Sama kayak tabel kolom-kolomnya jadi beda tergantung kalau yang jawab.
Ini maksudnya CLI Design?
Ya, CLI Design.
Masukin di sini, saya pakainya dulu YARGS.
YARGS, Y-A-R-G-S-D-G-S.
Kenapa?
Itu juga saya suka.
YARGS.
Untuk ini apa? Untuk tools desainnya?
Ya buka aja ini tools desainnya, YARGS.org.
Oh .ARG.
Jadi kayak script untuk membantu untuk membuat CLI script.
Jadi kalau gue dulu pakainya buat apa sih?
Komponen generator. Apakah mau bikin apa ya?
Kalau dia kan dulu ada misalnya functional component, smart component,
atau DOM component, atau apa, RDS no.
Bisa checklist kayak di centang gitu, single option, multiple option.
Nanti terakhirnya ponenya dapat JavaScript Object berisi interaksi jawaban-jawaban dari interaksi CLI itu.
Gini ya?
Kalau kita lagi sesuai, kita satu aja ngomongin ini pusing ga?
Oh AI.
Ada yang mau bahas AI code assistant?
Ya di IDE.
Di code assistant di editor.
Code assistant ya di IDE kan?
Iya sih.
Mungkin ada yang tertarik, silahkan kita lihat.
Di code silahkan.
Atau kalau ada yang punya IDE, bisa langsung di submit juga.
Kalau misalkan belum ada, yang apa, eh sudah ada, ya tinggal di code aja.
Eh Interop 2025 bikin itunya.
Si Eka seneng banget tuh, transition masuk.
Topik favorit.
Si Eka seneng feed transition, si Mas Johan WebRTC.
WebRTC, everybody happy.
Udah?
Tapi kita belum buat minggu depan apa.
Mau yang mana, yang di vote apa?
Kita vote di YouTube aja ya.
Basic web security?
Mau, tapi harus ada dana sumber.
Ajar Mas Ipan aja kali ya.
Mas Ipan aja, Mas Ipan atau Mas Riza aja coba hubungi nanti.
Mas Riza.
Oh, hubungi diri sendiri gitu.
Hubungi diri sendiri.
Oke, ya udah.
Banyak, tinggal pilih ya.
Banyak ya, ini udah 2 halaman nih.
Sama yang ditutup juga ada kan?
Enggak, ini yang sudah ini aja.
Ini yang baru-baru aja, yang open.
Oke, security ya?
Gak tau, kita vote dulu ya.
Temen-temen di sini pengen apa?
Untuk minggu depan?
Pengen topiknya apa?
Boleh kita vote, mungkin ya.
Topik minggu depan.
Base security dari YouTube.
Security, Interop, CLA, udah itu aja 3 itu.
Interop, oke.
2025 sama CLA ya.
C-L-E.
Design and Development.
Ayo, kita kasih waktu 2 menit.
1 menit.
2 menit.
Mana tadi yang CLA?
CLA-nya bukan cuma desain berarti kan?
Sampai bikin kan?
Iya, propanya.
CLA, desain dan development.
Mas, ada live coding.
Best practice, terus kayak flag.
Flag-flag-nya gimana?
Kita kan sebentar lagi udah Ayo Extended nih.
Kita harus mulai minggu depan, harus mulai mencari arah-arah.
Practice itu gimana sih tulisannya?
Best practice.
Best practice.
Practice gini ya?
Masa sih?
Ya betul.
Terus apalagi tools.
Itulah, nanti lanjutin lagi ya.
Basic security 100%.
Ayo, 1 menit lagi, 1 menit lagi.
Sekalian nyari topik kita buat Ayo Extended.
Ayo Extended.
Memang udah keluar?
Belum, tapi kan sudah mulai udah mendengar.
Buat bukain test-nya keluar aja, biar bisa brainstorming-nya enak.
Saya sih kemungkinan kalau topik web nggak ada yang menarik sih yang tadi.
Bahas AI, tools, AI assistance.
Kan si Gumi ini udah keluarin kan?
Iya, kalau web nggak menarik.
Kalau web nggak ada yang menarik.
Tapi kalau web ada yang menarik, mau bahas web.
Bahas, oh itu buat build with AI aja ya.
Benar juga.
Web kira-kira apa yang dibahas?
Itu, transition, scroll-driven animation.
Kalau UI sih kayaknya banyak.
UI banyak, untung.
Karena gue-gue UI.
Senang.
Sudah? Seberapa hasilnya?
Hasilnya adalah basic security 100%.
Oke, udah basic security.
Mudah-mudahan Mas Irvan-nya mau dan bisa.
Atau narasumber yang lain kita coba ya.
Doakan saja, semoga bisa.
Jadi, untuk malam ini, kita tutup dulu.
Terima kasih banyak buat semuanya yang sudah hadir.
Sudah meramaikan, komen-komen.
Belajar bareng tentang Monorepo.
Kita ketemu lagi minggu depan.
Sampai jumpa.
Jam 9 ya.
Jangan lupa ya jam 9.
Karena selama Ramadhan kita mundurin.
Setelah terawih.
Oke, sampai jumpa.
Selamat malam, bye-bye.
[Sampai jumpa di video selanjutnya]
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...
2 Okt 2024
Ngobrolin Drama Trademark & Open Source
Episode ini membahas drama perseteruan antara Matt Mullenweg (co-founder WordPress) dengan WP Engine, sebuah perusahaan ...
16 Apr 2025
Ngobrolin CORS & Browser Policy
Episode Ngobrolin WEB ini membahas secara mendalam tentang kebijakan keamanan browser (browser security policy) dengan f...
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 .