Fork me on GitHub
#duct
<
2018-10-30
>
rboyd01:10:04

can anyone recommend a good approach for different boundary extend-protocol implementations for dev vs prod? I'd like to use one type of datastore in dev vs a different one in prod. github search reveals something like https://github.com/TechEmpower/FrameworkBenchmarks/blob/82eadc9dce3badda758f9f9cbb0ff2bcdec15002/frameworks/Clojure/duct/src/hello/boundary/world_db.clj and https://github.com/wbtcb/anti-fraud/blob/508c7e7eb914a06da1366c95cece84e1d3d91033/src/antifraud/boundaries/sms.clj -- but would prefer not to include all impl in a single file. even better if the dev impl doesn't get included in prod build

rboyd01:10:07

I toyed around with putting the dev impl in dev/src/* and (load)'ing in dev/src/dev.clj but that way seems to break (reset)

dadair01:10:18

Ensure dev/src is a specified source-path in project.clj for the dev profile; then you could have the appropriate namespace under dev/src. In that namespace have an integrant init-key defmethod (`ig/init-key ..`) to construct your dev-implementation. In the development config map (`dev.edn`, believe it is under dev/resources/dev.edn), add the appropriate key-value pair that you would normally use in the config.edn. Unless your duct configuration is different from the current template, dev.edn will be merged into config.edn, which means your dev-implementation should be swapped into the system.

dadair01:10:59

That’s one way of doing it.

🎉 4
rboyd01:10:42

thanks, I'll try that