This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (2)
- # announcements (2)
- # babashka (10)
- # beginners (117)
- # calva (11)
- # cider (19)
- # clj-kondo (27)
- # cljs-dev (24)
- # cljsjs (1)
- # clojure (73)
- # clojure-europe (3)
- # clojure-italy (2)
- # clojure-nl (47)
- # clojure-spec (23)
- # clojure-uk (28)
- # clojurescript (71)
- # cursive (7)
- # data-science (17)
- # datascript (1)
- # datomic (7)
- # duct (23)
- # emacs (23)
- # fulcro (6)
- # graalvm (41)
- # jobs (2)
- # luminus (1)
- # malli (1)
- # off-topic (151)
- # pathom (1)
- # portkey (10)
- # re-frame (12)
- # reitit (17)
- # shadow-cljs (158)
- # spacemacs (14)
- # sql (8)
- # tools-deps (17)
- # xtdb (9)
Yeah @iarenaza, I issued
However, I much prefer your suggestion of externalising the commands…
lein clean lein uberjar docker build . -t film-ratings-app docker-compose up -d && docker-compose logs -f
bolx, it was a Docker problem. The above commands were correctly rebuilding
film-ratings-app but my docker-compose.yml was referencing
film-ratings_filmapp and thus you were correct, I was starting stale images. Cheers, and I’ll refactored to externalised config next. Thank you.
hi 👋:skin-tone-2: would you recommend Duct as a good framework for a greenfield project? I have previously used just plain Ring in one project and Pedestal in another. With Pedestal I faced some frustration because the documentation wasn’t very comprehensive
The documentation of Duct isn’t particularly good right now. So if you’re frustrated by Pedestal’s documentation, you’re likely not going to be impressed with Duct’s. That said, if you can get over the rough edges, it will get better in future.
Though not exactly the same thing, Luminus had reasonable documentation last time I looked.
I was able to found sample code for Pedestal quite easily. I faced this problem when I was dockerizing the application https://github.com/pedestal/pedestal/issues/604 which felt kinda random issue and took some time to figure it out
That’s good to know. Maybe I do a small spike with Duct and see how it is to use
You may want to start here: https://github.com/duct-framework/docs/blob/master/GUIDE.rst
Just to pile up on @U0BKWMG5B comment, we at Magnet are using Duct in all of our projects since the beginning of 2018. And all of them are Dockerized since day one. Using docker-compose to develop locally, and deploying to AWS Elastic Beanstalk for testing/production. No issues related to Docker so far.
@UJZ6S8YR2 also maybe this repo will be useful https://github.com/khmelevskii/duct-pedestal-reitit
I had a shot at using
duct internally at our place and we bounced off it pretty hard. To be fair to @U0BKWMG5B he's spent some time in private conversation with me around the painpoints we've had with it but I'm simply not convinced by duct's half-open modules - I think the way they're implemented is a design defect that removes any advantages out of using them, and it has everything to do with how they're configured and documented.
I can probably recommend Luminus - we're using some of the libraries which that framework uses, and only don't use the template as a whole because we have our own spin on certain things and don't need a good half or more what Luminus gives you. That said,
mount ring and
cprop have been the underpinnings of our services and have served us very well.
I would probably suggest building out your own template using the libraries you like as that means you can tailor everything to your specific use case.
@U067BPAB1 can I see the details of the painpoints and design defect somewhere?
I can't show any code but it boils down to the duct modules having their own set of keys through which you can configure them in a limited fashion, and a bunch of underlying integrant methods that you can override if you know what they are - but then you need to open the sources to see what they are. Which kind of defeats the point of using the module in the first place. The configuration of the modules is also strange, because internal overrides for the aforementioned integrant methods cannot be dropped into the module's config map, but need to be top level if I remember correctly. It feels like a semi-opaque wrapper that just gives you some default functionality but still expects you to read the sources.
Thanks @iarenaza and @U067BPAB1 for your insight! It good to know that there are services using Duct in production. I’m not familiar with integrant but I have used Component library before. The EDN style configuration sounds interesting but I haven’t heard many people using it
Just to clarify, Duct modules are pure functions that transform the configuration. Typically this is used to add default configuration.
It’s intended as a mechanism for developers to add their own configuration changes independent of source control.