This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-18
Channels
- # babashka (12)
- # beginners (35)
- # biff (6)
- # calva (23)
- # cider (7)
- # clj-kondo (10)
- # cljs-dev (15)
- # clojure (81)
- # clojure-dev (2)
- # clojure-europe (13)
- # clojure-germany (1)
- # clojure-korea (2)
- # clojure-nl (1)
- # clojure-norway (19)
- # clojure-uk (7)
- # clojurescript (23)
- # core-typed (33)
- # cursive (7)
- # data-science (7)
- # datalevin (9)
- # hyperfiddle (1)
- # introduce-yourself (2)
- # malli (1)
- # matrix (17)
- # missionary (24)
- # music (1)
- # off-topic (15)
- # polylith (6)
- # reagent (10)
- # releases (5)
- # remote-jobs (1)
- # shadow-cljs (3)
- # squint (7)
- # xtdb (11)
- # yamlscript (6)
Noob question: Is there a rule-of-thumb for project size, that helps determine whether polylith will be a net benefit for a project or just overhead due to redundant granularization?
isn't that one of the key points of polylith? atomic modules?
to me the selling point is that it's easy to granularize for reuse across deployables if and when you have to
but it isn't forced on you - you can have a workspace with a single project and a single base starting out
My feeling is that Polylith is worth adopting as soon as you're building more than one deployable application from a single source repo.
➕ 1
👍 1