This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-07
Channels
- # announcements (10)
- # babashka (11)
- # beginners (69)
- # calva (1)
- # cider (2)
- # clj-kondo (35)
- # cljdoc (48)
- # cljs-dev (3)
- # clojure (60)
- # clojurescript (10)
- # community-development (6)
- # cursive (4)
- # datahike (1)
- # datalog (33)
- # deps-new (2)
- # depstar (8)
- # docker (24)
- # fulcro (1)
- # graphql (4)
- # honeysql (5)
- # java (2)
- # leiningen (2)
- # missionary (3)
- # off-topic (104)
- # pedestal (8)
- # polylith (18)
- # portkey (3)
- # reagent (7)
- # reveal (1)
- # rewrite-clj (4)
- # shadow-cljs (19)
- # specter (3)
- # tools-deps (2)
This was recently answered by @U04V70XH6 and @furkan3ayraktar at the end of https://clojurians.slack.com/archives/C013B7MQHJQ/p1628149477109800 thread.
but (realistically) the kinds of apps i've made have been one "main" deploy target, with a few smaller ones for periphery jobs or a really large codebase with multiple teams mostly independent projects
@emccue I talk a bit about that in https://corfield.org/blog/2021/06/06/deps-edn-monorepo-3/ which focuses on naming, modularization, and dependencies. I don't think there's a "too big" or "too small" line to be drawn with any hardness but I think those three dimensions are something Polylith makes you think about.
(In part IV I talk briefly about us switching to using projects
for every deployable artifact -- and we have since moved all of our amorphous "batch jobs" code into bases
(as batch-jobs
) with a single -main
entry point so that was a "large" block of code in a single brick (1,040 lines src
+ 170 lines test
). Our largest two components
are about 700 lines, but many of them are 100 lines at most. That just naturally seemed to be the granularity of things that we could identify as having as well-defined name, that represented a single, modular concept, with just the right amount of dependencies.
Small and many components gives a lot of flexibility and ease during development time. Makes it easier to refactor, locate bugs, and communicate about the codebase within the team. In my opinion a codebase should not optimize the deployment or the artifact, it should optimize the developer experience.
@furkan3ayraktar: Rumour has it that you posted some pictures of your project dependencies here a while ago. It seems to have died at the 10K messages limits. Can you post again?
I think the dependency diagram looks like something taken from The Matrix! 🙂
Hahah, “You get used to it, I don’t even see the code”