Clojurians Log v2
polylith
Hej! A question regarding polylith and top namespaces not matching what’s in workspace.edn for old code (trying to do some migration work).
How serious is Non top namespace api was found in… ? Our current monolith src is structured this way:
/src/app
/src/api
/src/ops
/src/common
… workspace.edn file contains top-namespace "ourcompanyname" but in the old code under src e.g. src/ops the top level is ops
Moving it all to a single base gives us a lot of these warnings 🙂
Are there any known ‘rough edges’ when migrating such a structure to polylith?
We went through this too (I talk a bit about it in my long series of blog posts on http://corfield.org) and the bottom line is: when you move legacy code into a base, you have to update the namespaces everywhere to conform to the new top-ns convention.
What about namespaced keywords? We do event-sourcing and base the schema off our specs
mynamespace/foo
We always have to be backwards compatible
We had a couple of large apps that were the last ones to migrate and were pretty massive sets of renaming to make things work...
That's the downside of tying keywords to physical namespaces, I'm afraid.
You could use :as-alias to make those aliases refer to the old ns but then you also have to refactor any code that uses the same aliases 😐
> You could use :as-alias to make those aliases refer to the old ns but then you also have to refactor any code that uses the same aliases
Yeah, I figured. That’s thousands of files 😄
We try to keep :: style keywords private to a single ns and use the full :my.namespace/foo name outside of it, if needed, but that also doesn't help you if you have those fully-qualified keywords stored externally.
I think the big thing we've learned is: don't tie public keywords to physical code namespaces.
Yeah, personally I prefer never sending fully namespaced keywords over the wire. Even if it’s edn. Rather have :payment/payment-id than ::payment/payment-id.