Mono-repo vs Git Submodules vs repo terpisah: mana yang Anda lebih sukai?

Beberapa proyek yang sifatnya berbeda tetapi saling terkait, bagaimana Anda lebih suka mengintegrasikannya (atau tidak mengintegrasikannya)?

Misalnya, untuk layanan yang sama ada front-end, back-end (api), serverless, batch, pipeline, dan lain-lain.

1. Mono-repo
   Kalau layanannya sama, maka repositorinya satu! Tiap proyek dibagi dengan struktur paket/folder.
   -> Lalu bagaimana mengelola commit-nya..? Hook seperti CI/CD atau pre-commit akan jadi makin rumit..

2. Git Submodules
   Kalau sifatnya berbeda, setidaknya histori git harus dikelola terpisah! Tapi tetap sebisa mungkin disatukan..
   -> Ada learning curve seperti submodule sync.. merge juga jadi lebih rumit.. apakah developer lain akan bisa mengikuti?

3. Repo terpisah masing-masing
   Sederhana! Kalau proyeknya berbeda, repo-nya juga berbeda!
   -> Kalau mau melihat layanan A, repo yang mana ya? Oh, yang ini, yang itu,.. lalu apa lagi ya...

Sepertinya tidak ada jawaban yang mutlak, tapi saya penasaran Anda lebih suka yang mana/dan alasannya!

[aer0700]

Saya lebih memilih repo yang berdiri sendiri...
Saat muncul pertanyaan seperti, kalau saya ingin melihat riwayat API yang terkait dengan fitur ini, saya harus melihat yang mana?, menurut saya lebih praktis jika satu repo dipasangkan dengan satu fitur.

[nemorize]

Saya cenderung memakai monorepo dalam kebanyakan situasi, tetapi ada dua kasus di mana saya menggunakan submodule.

1. Saat mempekerjakan publisher eksternal.
   Saya menggunakan submodule ketika tidak ingin mengungkapkan hal-hal selain informasi yang diperlukan untuk publishing kepada publisher eksternal.

2. Saat harus melakukan kustomisasi pada solusi eksternal.
   Saya terutama menggunakan submodule jika solusi tersebut menyediakan fungsi plugin.
   Solusi eksternal tersebut didaftarkan sebagai submodule, lalu plugin milik saya dimasukkan ke dalam jalur plugin dengan symlink dan semacamnya. Plugin saya dikelola versinya secara terpisah, sementara solusi eksternal tetap bisa mempertahankan version control mereka apa adanya; ini menjadi kelebihannya.

[bbulbum]

Sepertinya pengalaman semua orang dengan penggunaan submodule memang kurang baik.. akan bagus jika ada alat yang bisa memperbaikinya

[iolothebard]

Kalau yakin hanya akan membuat merge commit, pilih monorepo.
Kalau akan sering rebase, pilih multi-repo.
Submodule? Pakai saja tautan direktori yang disediakan OS…

[ilotoki0804]

Dulu saya hanya memakai repo-repo yang berdiri sendiri, tetapi belakangan saya sepenuhnya beralih ke cara menggunakan submodule.
Sebelumnya pemahaman saya tentang git masih kurang, jadi saya tidak bisa memanfaatkan submodule dengan baik, tetapi sekarang saya merasa memakai submodule adalah pilihan yang lebih baik.
Namun, saat memakai submodule kita harus commit pada submodule tersebut lalu commit lagi di repo induk, dan akibatnya ada jeda waktu antara keduanya, sehingga muncul masalah berkurangnya konsistensi repo.

[tested]

https://monorepo.tools/
Kalau belum pernah melihat situs di atas, sepertinya bagus untuk sekali dicek.

Berdasarkan pengalaman pribadi, saya kurang merekomendasikan submodule.
Kalau ingin berbagi kode dari repositori lain lewat submodule, sepertinya lebih baik sekalian didistribusikan sebagai package.

[savvykang]

1. Jika mengimplementasikan server API sendiri, kami menggunakan monorepo frontend-backend untuk menyelaraskan spesifikasi API
2. Untuk proyek arsitektur 2-tier yang sangat bergantung pada DB seperti Supabase, kami memisahkan frontend dan backend ke repo terpisah dengan mengandalkan alat pembuat skema otomatis
3. Untuk design system, kami masih belum sepenuhnya menyelesaikannya, tetapi untuk saat ini submodule kami batalkan karena kurva belajarnya terjal, dan kami berpikir template proyek adalah arah yang lebih baik

Dalam kasus perusahaan kami, jumlah anggota tim per proyek sedikit, dan karena bahasa serta tech stack frontend dan backend terpisah, hampir tidak ada kontribusi lintas peran. Seperti semua sistem TI, pada akhirnya tampaknya mengikuti struktur organisasi.

[curiousotter]

Oh.. jadi ini pendekatan untuk menyesuaikan visibilitas kode pihak lain tergantung apakah manusialah yang menyelaraskan antarmuka atau alat yang melakukannya.

[laeyoung]

Saya belum punya pengalaman dengan mono-repo, jadi ada satu hal yang saya penasaran. Saat memakai mono-repo, apakah modul yang umum dipakai di beberapa proyek atau layanan (mis. design system) biasanya ikut dimasukkan ke masing-masing mono-repo? Atau apakah untuk yang seperti ini mau tidak mau dipisahkan ke repo terpisah lalu direferensikan?

[curiousotter]

Sepertinya untuk mengakses modul bersama, saya menggunakan bantuan seperti yarn workspace sehingga bisa diakses dalam bentuk symlink!

[twinstae]

Saya, baik di kantor maupun pada proyek pribadi, mengelola frontend, backend, batch, dan lainnya dalam satu git tanpa memisahkannya.

Ada kalanya lebih praktis jika keduanya diubah bersama daripada menjaga kompatibilitas ke belakang. Selain itu, karena ukuran tim di kedua kasus sama-sama kecil, rasanya tidak ada banyak manfaatnya jika dipisah-pisah... Upaya tambahan seperti mengatur GitHub Actions agar hanya menjalankan bagian yang berubah masih terasa layak dijalani. Yang paling penting, dibanding memisahkan backend dan frontend, saya suka karena masing-masing bisa saling berkontribusi. (Misalnya, saat mengerjakan frontend lalu ada kebutuhan di backend, bisa langsung saya tambahkan sendiri, atau memperbaiki error sendiri, dan sebagainya...)

[curiousotter]

Hmm, kalau skalanya memang kecil atau pembagian perannya tidak terlalu ketat, sepertinya Anda lebih cenderung memilih monorepo ya! Soal riwayat Git yang tercampur juga tidak terlalu dipermasalahkan? (Soalnya toh semuanya tetap kode yang dilihat bersama?)

[rabolution]

Yang menarik, ini juga terjadi di proyek sampingan saya. Saat ini saya bekerja bersama sekitar 12 orang. Setiap orang mengerjakan dari frontend sampai backend dalam satu alur. Rasanya ini juga mirip dengan vertical slice.

[rabolution]

Saya cenderung tidak menganggap itu tercampur. Soalnya cukup sering dalam satu PR kami mengubah frontend dan backend sekaligus. Di tim kami, prinsipnya semua orang adalah full-stack, total 4 orang, jadi tanpa membedakan backend/frontend, kami saling me-review dan juga perlu mengetahui perubahan yang ada.

[aaaapple123]

Kalau modulnya tidak terlalu besar, mono-repo
Kalau modulnya besar, submodule

Atau kalau saat mendistribusikan open source Anda ingin hanya submodule yang bisa dikontribusikan, sementara repo utama dikelola secara internal,
sepertinya dipisahkan sebagai submodule.

Tapi kalau memakai submodule, saat dibuat open source rasanya jadi sedikit lebih rumit bagi pengguna lain untuk menulis dokumentasi terkait pengujian atau build demi berkontribusi.

Jadi secara pribadi, kalau pola kontribusi keduanya tidak berbeda, saya cenderung memakai mono-repo,
atau menggunakan GitHub yang berbeda lalu mengelola masing-masing dengan mendistribusikannya sebagai package atau image Docker.

[curiousotter]

Saya belum memikirkan soal open source, tetapi terima kasih atas masukannya!