Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Split Front-end and Back-end Clojure Code Into Two Git Repositories or Keep It All Together?
;; This is a collection of thoughts to help one decide between separating a clojure server/api codebase
;; from a clojurescript client/ui or keeping them both together.
;;;; Split PROS:
;; "When you split code into multiple repos you can scale them independently. For example,
;; you could throw client code on a CDN while spinning up a lot of AWS servers for the backend.
;; This greater flexibility in scaling can save money on hosting and hardware costs and improves
;; your ability to modify your setup as your user base grows."
;; -
;;;; Split CONS:
;; "In my experience working with a team, with a less disciplined group having separate repos for
;; the frontend and backend leads to chaos and friction." - noisesmith
;; "Depending on how tightly the two are coupled, it's probably just less overhead to keep them together."
;; - roninhacker
;; Harder to "share Spec/Schema definitions or data helpers across client/server codebases" without cut and pasting.
;; "I've already started implementing in .cljc files [but] making it it's own lib but it seems like overkill."
;; - agile_geek
;; "Lots of tedious manual steps, leading to contemplating building higher-level build tools, which was only going to
;; take time away from delivering value to clients" - mccraigmccrai
;;;; More perspective...
;; "To me it comes down to dev workflow - which would be worse, not knowing if your front and backend versions match
;; (eg. can your team keep things flexible and compatible?) or having frequent merges in one codebase for totally
;; unrelated work.
;; The more disciplined / careful the coding style, the more an advantage to separation." - noisesmith
;;;; A third way with modules and subtrees...
;; "you could configure the top level project.clj to have the subtrees src paths in the parent src path,
;; this one approach" - jonpither
;; "we've had a nice time with a single repo with multiple modules (managed with lein-modules)...
;; We started with a single repo, but wanted to enforce some module separation, so went straight
;; to multiple repos, but even with lein-voom the overhead was painful so we pulled back to a single
;; repo with multiple modules and have been happy ever since."
;; "if you are wanting to try `lein-modules`, this snapshot has a patch which makes version management nicer
;; - `[lein-modules-bpk/lein-modules "0.3.13.bpk-20160816.002513-1"]` - you can use `"_"` in your submodule
;; `project.clj` versions (to inherit the version from the top-level `project.clj`)"
;; - mccraigmccrai
;; "Another vote for multiple modules in single repo from me. It really is the "best of the both worlds" solution:
;; you can develop the frontend and the backend separately, but you don't have to face the friction of having
;; multiple repos." - miikka
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment