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.
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
@sgerguri 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 @sgerguri 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.
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
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.
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
I’ll take a look, cheers 👌:skin-tone-2:
Just to pile up on @weavejester 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.
@janne.sauvala also maybe this repo will be useful https://github.com/khmelevskii/duct-pedestal-reitit
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
I had a shot at using duct
internally at our place and we bounced off it pretty hard. To be fair to @weavejester 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.