Monorepo vs polyrepo dijelaskan untuk tim yang merilis aplikasi web, mobile, dan backend. Bandingkan dependensi, koordinasi rilis, dan taktik CI agar tetap cepat.
Tim tidak berdebat soal monorepo vs polyrepo karena filosofi Git. Mereka berdebat karena perubahan produk kecil berubah menjadi tiga perubahan terpisah di web, mobile, dan backend, lalu sesuatu rusak di tengah jalan.
Yang sering rusak pertama bukan UI. Biasanya adalah lem yang tak terlihat: kontrak API berubah tanpa pembaruan yang cocok, library bersama dinaikkan versinya di satu tempat tapi tidak di tempat lain, atau pipeline build tiba-tiba butuh langkah baru. Ketika satu bagian dirilis lebih dulu daripada yang lain, pengguna merasakannya sebagai bug seperti “tombol ada di web tapi aplikasi mobile bilang tidak didukung” atau “aplikasi loading terus karena respons backend berubah.”
Web, mobile, dan backend juga berjalan pada jam rilis yang berbeda. Web bisa rilis beberapa kali sehari. Backend bisa sering, tapi butuh rollout yang hati-hati. Mobile paling lambat karena review app store dan waktu update pengguna menambah penundaan nyata. Perubahan “sederhana” seperti mengganti nama field bisa memaksa Anda merencanakan berdasarkan jalur paling lambat, walau hanya satu layar yang membutuhkannya.
Anda kemungkinan membayar pajak koordinasi repo jika ini terus terjadi:
Ukuran tim dan kematangan produk mengubah jawaban yang tepat. Di awal, kebanyakan tim untung jika membuat koordinasi murah dan visibilitas tinggi, meski agak berantakan. Saat tim tumbuh, batasan mulai penting, tetapi hanya jika antarmuka stabil dan kepemilikan jelas.
Jika setiap perubahan berarti harus mendarat di tiga tempat, Anda akan membayar pajak itu entah bagaimana. Strategi repo sebagian besar tentang bagaimana Anda mau membayarnya.
Repo hanyalah tempat kode Anda hidup, beserta riwayatnya. Ketika Anda punya web, mobile, dan backend, pilihannya sederhana: gabungkan semuanya, atau pisahkan.
Sebuah monorepo adalah satu repositori yang berisi beberapa aplikasi dan sering juga kode bersama. Web, iOS/Android, layanan backend, dan library bersama berada berdampingan.
Sebuah polyrepo adalah kebalikan: setiap aplikasi (dan kadang setiap layanan) punya repositorinya sendiri. Kode bersama biasanya menjadi paket terpisah, atau tim menyalin potongan kecil saat diperlukan.
Sehari-hari, monorepo biasanya terasa seperti ini: berbagi kode mudah, perubahan lintas-aplikasi bisa dalam satu pull request, dan aturan konsisten. Tradeoffnya adalah sosial: kepemilikan bisa kabur kecuali Anda menetapkan batas yang jelas, dan pengecekan di seluruh repo bisa terasa ketat.
Polyrepo biasanya terasa seperti ini: setiap tim bisa bergerak mandiri, repo tetap fokus, dan kontrol akses bisa lebih sederhana. Tradeoffnya adalah koordinasi: berbagi kode butuh perencanaan, dan perubahan lintas-aplikasi sering menjadi beberapa pull request dengan penjadwalan hati-hati.
Banyak tim berakhir dengan hibrida: aplikasi di repo terpisah, kontrak bersama di satu tempat; atau satu monorepo dengan batas kuat sehingga setiap tim sebagian besar tetap di area masing-masing.
Jika Anda menggunakan platform yang menghasilkan backend, web, dan mobile dari satu sumber kebenaran, Anda mengurangi drift karena kontrak dan logika hidup bersama. AppMaster, misalnya, menghasilkan backend, web, dan aplikasi mobile native siap produksi dari satu model. Itu tidak menghapus realitas rilis (mobile masih lebih lambat), tetapi bisa menghilangkan banyak overhead “apakah kita sudah memperbarui ketiganya?”
Kode bersama adalah tempat tim kehilangan waktu, terlepas dari tata letak repo. Perubahan kecil di library bersama atau kontrak API dapat memecah build web, rilis mobile, dan deploy backend dengan cara berbeda.
Saat Anda berbagi library (komponen UI, aturan validasi, helper auth), Anda memilih antara satu versi untuk semua atau beberapa versi seiring waktu.
Client API dan skema pantas mendapat perhatian ekstra. Pembaruan manual lambat dan rentan kesalahan. Pola yang lebih baik adalah memperlakukan skema API sebagai sumber kebenaran dan menghasilkan client darinya, lalu cekin hasilnya atau hasilkan di CI. Tujuannya adalah gagal lebih cepat: jika backend menambah field wajib, client mobile harus gagal saat build, bukan tiga hari kemudian di QA.
Perubahan yang memecah kompatibilitas menyebar ketika perilaku berubah tanpa jalur aman. Utamakan perubahan aditif dulu (field baru, endpoint baru), lalu deprekasi setelahnya. Jika Anda harus memecah sesuatu, gunakan endpoint bernomor versi atau jendela kompatibilitas singkat.
Contoh konkret: backend mengganti nama status menjadi state. Jika web memperbarui hari ini tetapi mobile tidak bisa rilis selama seminggu, backend perlu menerima kedua field selama seminggu itu, atau kirim adapter yang memetakan field lama ke yang baru.
Beberapa aturan yang membuat pembaruan dependensi menjadi membosankan (dalam arti baik):
Kode yang dihasilkan dapat mengurangi drift, tetapi tidak menggantikan disiplin. Anda masih butuh satu kontrak, deprecations yang jelas, dan pembaruan yang dapat diprediksi.
Koordinasi rilis adalah tempat strategi repo berhenti menjadi teori. Jika backend mengubah nama field API, web biasanya bisa memperbarui dan rilis hari yang sama. Mobile berbeda: review app store dan waktu update pengguna bisa mengubah mismatch kecil menjadi minggu tiket dukungan.
Tujuan praktisnya sederhana: tindakan pengguna harus berfungsi tidak peduli bagian mana yang diperbarui lebih dulu. Itu berarti merencanakan untuk versi campuran, bukan mengasumsikan rilis tersinkron sempurna.
Kebanyakan tim menggunakan salah satu pendekatan berikut:
Satu release train bersama: web, mobile, dan backend dirilis sebagai satu unit bernomor versi.
Versi per-layanan dengan aturan kompatibilitas: tiap aplikasi/layanan punya versinya sendiri, dan backend mendukung rentang versi klien yang ditentukan.
Release train bersama terlihat rapi, tetapi sering runtuh saat mobile terlambat. Versi per-layanan terlihat lebih berantakan di atas kertas, tetapi sesuai kenyataan. Jika memilih per-layanan, tulis satu aturan dan tegakkan: versi backend mana harus mendukung versi mobile mana, dan berapa lama.
Penundaan mobile juga mengubah cara menangani hotfix. Hotfix backend bisa keluar cepat; hotfix mobile mungkin tidak sampai ke pengguna selama beberapa hari. Utamakan perbaikan sisi server yang menjaga build mobile lama tetap berfungsi. Saat harus mengubah client, gunakan feature flag, dan hindari menghapus field lama sampai Anda yakin sebagian besar pengguna sudah memperbarui.
Contoh: Anda menambahkan “petunjuk pengiriman” ke alur pesanan. Backend menambah field baru opsional, web langsung menampilkannya, dan mobile menampilkannya di sprint berikutnya. Jika backend menerima request lama dan menjadikan field itu opsional, semuanya tetap bekerja sementara mobile mengikuti.
Koordinasi gagal saat “semua orang yang punya,” jadi tak ada yang punya. Pemilik bisa tech lead, release manager, atau product manager dengan dukungan engineering. Tugas mereka adalah mencegah kejutan dengan menjaga ekspektasi rilis terlihat dan konsisten.
Mereka tidak perlu proses rumit. Mereka butuh beberapa kebiasaan yang bisa diulang: kalender rilis sederhana dengan cutoff dan freeze window, pengecekan lintas-tim singkat sebelum perubahan API dikirim, dan rencana jelas bila mobile tertunda (tahan backend vs pertahankan kompatibilitas).
Jika workflow Anda menghasilkan web, mobile, dan backend bersama dari satu model, Anda tetap butuh pemilik rilis. Biasanya Anda akan punya lebih sedikit momen “apakah kita memperbarui ketiganya?”, tapi Anda tidak akan lolos dari timing mobile.
CI melambat karena alasan yang sama di kedua setup: Anda membangun terlalu banyak, menginstal dependensi berulang kali, dan menjalankan semua tes pada setiap perubahan.
Pemboros waktu umum termasuk build penuh untuk perubahan kecil, cache yang hilang, suite tes yang menjalankan semuanya, dan job serial yang bisa dijalankan paralel.
Mulai dengan perbaikan yang membantu di mana-mana:
Monorepo menyakitkan ketika setiap commit memicu pipeline “membangun seluruh dunia.” Solusinya adalah membangun dan mengetes hanya apa yang terpengaruh oleh perubahan.
Gunakan path filter dan pendekatan affected-only: jika Anda mengubah kode UI mobile, jangan bangun image backend. Jika Anda menyentuh library bersama, bangun dan uji hanya aplikasi yang bergantung padanya. Banyak tim meresmikan ini dengan graf dependensi sederhana sehingga CI bisa membuat keputusan alih-alih menebak.
Polyrepo bisa cepat karena setiap repo lebih kecil, tetapi sering membuang waktu lewat duplikasi dan tooling yang tidak konsisten.
Pertahankan satu set template CI bersama (langkah yang sama, cache yang sama, konvensi yang sama) agar setiap repo tidak mengulang pipeline. Pin versi toolchain (versi runtime, build tools, linter) untuk menghindari kejutan "berfungsi di satu repo". Jika unduhan dependensi menjadi bottleneck, siapkan cache bersama atau mirror internal agar tiap repo tidak menarik seluruh dunia dari awal.
Contoh konkret: sebuah fitur menambahkan field baru “status”. Backend berubah, web menampilkannya, mobile menampilkannya. Dalam monorepo, CI harus menjalankan tes backend plus hanya bagian web dan mobile yang bergantung pada client API. Dalam setup polyrepo, tiap repo harus menjalankan pemeriksaan cepatnya sendiri, dan pipeline integrasi terpisah bisa memvalidasi bahwa ketiga rilis masih selaras.
Jika Anda mengekspor kode sumber dan menjalankan CI sendiri, aturan yang sama berlaku: bangun hanya apa yang berubah, gunakan cache agresif, dan simpan pemeriksaan lambat untuk saat mereka benar-benar menambah nilai.
Keputusan jadi lebih mudah saat Anda memulai dari kerja sehari-hari, bukan ideologi.
Pilih 5–10 fitur terbaru dan catat apa yang harus bergerak sejalan. Tandai apakah tiap fitur menyentuh layar UI, endpoint API, tabel data, aturan autentikasi, atau validasi bersama. Jika sebagian besar fitur membutuhkan perubahan terkoordinasi di ketiga area, setup terpisah akan terasa menyakitkan kecuali proses rilis Anda sangat disiplin.
Kode bersama bukan hanya library. Ini juga kontrak (skema API), pola UI, dan aturan bisnis. Catat di mana itu berada sekarang, siapa yang mengubahnya, dan bagaimana perubahan disetujui. Jika potongan bersama disalin antar repo, itu tanda Anda butuh kontrol lebih ketat, baik melalui monorepo atau aturan versioning yang ketat.
Putuskan unit-nya (aplikasi, layanan, library), lalu tetapkan pemilik untuk tiap unit. Batas lebih penting daripada tata letak repo. Tanpa pemilik, monorepo menjadi berisik. Tanpa pemilik, polyrepo menjadi terputus.
Jika Anda mau checklist sederhana, bidik: satu repo atau folder per layanan/aplikasi yang dideploy, satu tempat untuk kontrak bersama, satu tempat untuk komponen UI yang benar-benar dipakai bersama, aturan jelas untuk tempat logika bisnis berada, dan pemilik terdokumentasi untuk tiap bagian.
Jika rilis mobile tertinggal dari perubahan backend, Anda butuh rencana kompatibilitas (API bernomor versi, field backward-compatible, atau jendela dukungan yang ditentukan). Jika semuanya harus dirilis bersama, release train bisa bekerja, tetapi ini meningkatkan kebutuhan koordinasi.
Jaga aturan branching tetap sederhana: branch pendek, merge kecil, dan jalur hotfix yang jelas.
Jangan rancang CI untuk kasus terburuk pada hari pertama. Rancang untuk apa yang orang lakukan sehari-hari.
Jika sebagian besar commit hanya menyentuh UI web, jalankan lint dan unit test web secara default, dan jalankan end-to-end penuh pada jadwal atau sebelum rilis. Jika insiden paling sering berasal dari drift API, investasi pertama pada tes kontrak dan regenerasi client.
Bayangkan tim kecil membangun tiga hal sekaligus: portal pelanggan (web), aplikasi lapangan (mobile), dan API (backend). Permintaan masuk: tambahkan field baru “Service status” ke job dan tampilkan di mana-mana.
Perubahan terdengar kecil, tetapi ini adalah ujian koordinasi. Backend menambah field dan memperbarui validasi serta respons. Web menampilkannya dan memperbarui filter. Mobile perlu menampilkannya offline, menyinkronkannya, dan menangani edge case.
Masalah nyata: perubahan API memecah kompatibilitas. Nama field berubah dari status menjadi service_status, dan client lama crash jika tidak menanganinya.
Di sinilah monorepo sering terasa lebih tenang. Backend, web, dan mobile bisa mendarat dalam satu pull request (atau satu set commit yang terkoordinasi). CI dapat menjalankan tes yang terpengaruh, dan Anda bisa menandai satu rilis yang mencakup ketiga pembaruan.
Risiko utamanya bersifat sosial, bukan teknis: satu repo memudahkan merge perubahan yang memecah dengan cepat, jadi aturan review Anda perlu kuat.
Dengan repo terpisah, tiap aplikasi berjalan sesuai jadwalnya sendiri. Backend mungkin rilis dulu, dan web serta mobile berebut mengejar. Jika rilis mobile memerlukan review app store, “perbaikan” bisa memakan waktu berhari-hari walaupun kode kecil.
Tim biasanya menyelesaikannya dengan struktur lebih: endpoint bernomor versi, respons backward-compatible, jendela deprecasi yang lebih lama, dan langkah rollout yang jelas. Ini bekerja, tetapi butuh kerja terus-menerus.
Jika Anda memutuskan berdasarkan bukti, lihat beberapa bulan terakhir:
Kebanyakan tim tidak gagal karena memilih struktur repo yang “salah.” Mereka gagal karena kebiasaan sehari-hari perlahan menambah friksi sampai setiap perubahan terasa berisiko.
Library bersama menggoda: helper, tipe, potongan UI, "workaround sementara". Lama-lama jadi tempat kode lama bersembunyi, dan tak ada yang tahu apa yang aman diubah.
Jaga kode bersama kecil dan ketat. “Bersama” harus berarti dipakai banyak tim, ditinjau dengan hati-hati, dan diubah dengan sengaja.
Bahkan di repo terpisah, sistem bisa terikat erat. Ketergantungan pindah ke asumsi: format tanggal, nilai enum, aturan permission, dan “field ini selalu ada.”
Contoh: mobile menganggap status = 2 sebagai “Approved,” web menganggapnya “Confirmed,” backend mengubah urutan enum, dan semuanya rusak dengan cara yang tampak acak.
Cegah ini dengan mendokumentasikan kontrak (apa arti field, nilai yang diperbolehkan) dan perlakukan itu sebagai aturan produk, bukan trivia.
Saat siapa pun bisa mengubah apa saja, review jadi dangkal dan kesalahan lolos. Saat tak ada yang punya area tertentu, bug berhari-hari tak tersentuh.
Tentukan pemilik untuk web, mobile, backend, dan modul bersama. Kepemilikan tidak menghalangi kontribusi; itu memastikan perubahan mendapat mata yang tepat.
CI sering dimulai kecil, lalu setiap insiden menambah job baru “biar aman.” Berbulan-bulan kemudian, lambat dan mahal, dan orang menghindarinya.
Aturan sederhana membantu: tiap job CI butuh tujuan jelas dan pemilik, dan job harus dihapus jika tak lagi menangkap isu nyata.
Tanda peringatan yang perlu dibersihkan: tes duplikat antar job, job yang merah berhari-hari, “perubahan cepat” butuh waktu verifikasi lebih lama daripada build, dan pipeline yang memicu build mobile pada perubahan backend saja.
Jika rilis bergantung pada satu orang yang ingat urutan dan rahasia, Anda akan rilis lebih lambat dan sering rusak.
Tuliskan langkah rilis, buat mereka dapat diulang, dan otomatiskan pemeriksaan membosankan. Bahkan jika tooling Anda menghasilkan backend dan client yang konsisten, Anda tetap butuh aturan rilis yang jelas.
Sebelum merombak repo, cek kenyataan bagaimana tim Anda mengirim hari ini. Tujuannya bukan struktur sempurna. Tujuannya lebih sedikit kejutan saat satu perubahan menyentuh web, mobile, dan backend.
Tanyakan lima hal:
Contoh sederhana: field “address” baru ditambahkan ke checkout. Jika backend rilis dulu, aplikasi mobile lama seharusnya tetap bekerja. Itu biasanya berarti API menerima payload lama dan baru untuk sementara, dan pembaruan client bersifat opsional, bukan wajib.
Tujuannya bukan struktur repo “yang benar.” Tujuannya lebih sedikit handoff, lebih sedikit kejutan, dan lebih sedikit momen “tunggu, versi mana yang live?”
Tulis catatan keputusan singkat: mengapa Anda memilih pendekatan saat ini, apa yang Anda harapkan membaik, dan tradeoff yang Anda terima. Tinjau tiap 6–12 bulan, atau lebih cepat jika ukuran tim atau cadence rilis berubah.
Sebelum memindahkan file, pilih perubahan terkecil yang menghilangkan sakit nyata:
Jika coupling antar codebase adalah bottleneck nyata, mengurangi jumlah tempat yang harus berubah bisa lebih penting daripada tata letak repo. Beberapa tim melakukan itu dengan memindahkan lebih banyak logika dan pemodelan data ke satu sumber kebenaran.
Jika Anda ingin mengeksplorasi pendekatan itu, AppMaster (appmaster.io) dibuat untuk menghasilkan layanan backend, aplikasi web, dan aplikasi mobile native dengan model data dan logika bisnis bersama. Cara berisiko rendah untuk mengevaluasinya adalah membangun satu tool internal kecil dulu, lalu putuskan berdasarkan seberapa banyak pekerjaan koordinasi yang hilang.
Jalan yang penuh kepercayaan sengaja membosankan: dokumentasikan keputusan, kurangi coupling, otomatisasi pengecekan, dan ubah struktur repo hanya ketika angka mengatakan itu akan membantu.
How do I decide between a monorepo and a polyrepo for web, mobile, and backend?Mulailah dari seberapa sering satu fitur harus mengubah web, mobile, dan backend secara bersamaan. Jika sebagian besar pekerjaan melintasi ketiganya dan koordinasi adalah masalah utama, monorepo atau pendekatan “kontrak tunggal” yang kuat cenderung mengurangi kerusakan. Jika tim jarang menyentuh area yang sama dan butuh akses serta kontrol rilis independen, polyrepo bisa berhasil dengan aturan kompatibilitas yang ketat.
What usually causes the “everything broke after a small change” problem?Biasanya karena API drift, mismatch versi pustaka bersama, dan perbedaan waktu rilis (terutama penundaan review di app store untuk mobile). Solusinya adalah merencanakan versi campuran di dunia nyata, bukan mengandalkan rilis tersinkron sempurna, dan membuat perubahan yang memecah kompatibilitas jarang dan disengaja.
What’s the safest way to manage API contracts across web and mobile?Anggap skema API sebagai sumber kebenaran dan hasilkan client dari sana agar ketidakcocokan terdeteksi saat build, bukan di QA atau produksi. Utamakan perubahan aditif dahulu, lalu deprekasi field lama kemudian, dan tetapkan jendela kompatibilitas singkat saat harus mengubah nama atau menghapus sesuatu.
How should we handle shared libraries without creating a mess?Targetkan pembaruan kecil yang rutin (mis. mingguan) dan minta persetujuan eksplisit untuk perubahan yang memecah kompatibilitas. Sertakan catatan migrasi singkat untuk setiap perubahan dan definisikan “selesai” sebagai “build web, mobile, dan backend semuanya hijau,” bukan hanya satu repo yang lolos.
Should we ship everything on one shared version or let each part version independently?Secara default lebih baik versi per-layanan dengan aturan kompatibilitas yang jelas: versi backend mana yang mendukung versi klien mana, dan berapa lama. Release train tunggal bisa bekerja di awal, tetapi penundaan mobile sering membuatnya menyulitkan kecuali produk Anda mau menunggu timing app store.
How do we avoid breaking mobile users when the backend ships first?Buat backend tetap kompatibel sehingga build mobile lama masih berfungsi sambil menunggu pengguna melakukan update. Gunakan field aditif, jangan hapus behavior lama terlalu cepat, dan andalkan feature flag saat perlu menggulirkan perubahan yang terlihat di klien secara bertahap.
Who should own release coordination across web, mobile, and backend?Tetapkan secara eksplisit—seringkali seorang tech lead, release manager, atau product owner dengan dukungan engineering. Tujuannya adalah kalender yang sederhana dan dapat diulang serta aturan keputusan yang jelas untuk keterlambatan (tunda perubahan vs pertahankan kompatibilitas), bukan proses berat.
What’s the best first step to reduce CI time without changing repo structure?Bangun hanya dan uji hanya bagian yang berubah, serta cache sebanyak mungkin. Pisahkan pemeriksaan cepat (setiap commit) dari pemeriksaan lambat (branch utama, nightly, atau pra-rilis) agar developer cepat mendapat umpan balik tanpa selalu membayar biaya penuh pengujian.
How do monorepos keep CI from becoming “build the world” on every commit?Gunakan path filter dan pendekatan “affected-only” sehingga Anda tidak membangun seluruh sistem untuk perubahan kecil. Jika sebuah modul bersama berubah, jalankan pengecekan hanya untuk aplikasi yang bergantung padanya, dan pertahankan aturan kepemilikan serta review agar satu repo tidak menjadi tempat menumpuk kode tak terurus.
How do polyrepos avoid drift and inconsistent pipelines across teams?Standarkan tooling dan template CI di seluruh repo agar setiap repo tidak mengulang langkah, cache, dan konvensi. Tambahkan pengecekan integrasi yang memvalidasi kontrak utama antar rilis, dan pin versi toolchain untuk menghindari "berfungsi di satu repo tapi tidak di repo lain".
27 Jan 2026
7 menit
26 Jan 20268 menit
21 Jan 20266 menitEksperimen dengan AppMaster dengan paket gratis.
Saat Anda siap, Anda dapat memilih langganan yang tepat.
