Fork me on GitHub

Yeah @iarenaza, I issued

lein clean
lein uberjar 
docker build . -t film-ratings-app 
docker-compose up -d  && docker-compose logs -f
However, I much prefer your suggestion of externalising the commands…


Oh 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.

Janne Sauvala14:11:04

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.

Janne Sauvala14:11:53

I was able to found sample code for Pedestal quite easily. I faced this problem when I was dockerizing the application which felt kinda random issue and took some time to figure it out

Janne Sauvala14:11:19

I would be happy if I don’t have to see that kind of problems with Duct 😄


I do know that Duct has been used by several people in containers without issue.

Janne Sauvala15:11:43

That’s good to know. Maybe I do a small spike with Duct and see how it is to use

Janne Sauvala16:11:24

I’ll take a look, cheers 👌:skin-tone-2:


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.


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.

Janne Sauvala11:11:08

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.


Does :duct.profile/local always get merged or with the system configuration?


It gets added while in development, but isn’t added to production environments.


It’s intended as a mechanism for developers to add their own configuration changes independent of source control.


For example, adding a database URL to a database running on their local machine.


I’ve created a new test profile and it seems to override that profile’s config despite not passing :duct.profile/local to the prep-config function