Fork me on GitHub
#pathom
<
2021-08-22
>
nivekuil01:08:11

cleaned up the pathom-based dependency injection framework I had talked about in this channel earlier. no release yet but please give the SHA a try https://github.com/nivekuil/nexus

👀 4
pithyless09:08:38

Interesting use-case for pathom! One thing I'm not clear on after reading the README: can I run two instances of :my.ns/server with different ports? My first impression is that there is a missing layer of indirection, because the fully-qualified names represent both the identity of a specific instance as well as the reference to the implementation.

nivekuil10:08:29

thanks for the feedback! the keys are for maps that are stored in the pathom env, so I think that would be possible, you'd just have to call nx/init twice and keep both references to the returned env around. I think it'd be pretty much the same as how you'd do it in integrant? not sure what the use case would be though

pithyless13:08:01

It's good to know you can just call nx/init twice and have multiple envs (so no issue with global state), but these 2 envs would be share-nothing envs (i.e. you couldn't have a component dependent on two such servers.. since they're in separate envs and know nothing about each other). Integrant tries to resolve this issue with composite keys and composite references (https://github.com/weavejester/integrant#composite-keys).

pithyless13:08:07

We've had use-cases where we want to spin up several instances of some component and give it unique global names; but then have an explicit separate step to bind those to local names for dependent components. (i.e. we can spin up both :some.ns/handler-1 and :some.ns/handler-2 and then explicitly pass in a dependency graph that says :component/x has a dependency: e.g. {:handler :some.ns/handler-1} )

pithyless13:08:48

This is why we ended up not using integrant, but a homegrown solution that borrows a lot from https://github.com/juxt/clip and https://github.com/walmartlabs/schematic.

pithyless13:08:43

There's no right way to skin the DI-cat, so I'm always interested in learning about how others approach this problem. :)

nivekuil13:08:29

that's an interesting problem. how many instances are we talking about, are they manually differentiated, or programatically generated?

nivekuil13:08:49

why not just use clip?

nivekuil13:08:02

afaict the best you can do with nexus now is just to make a different component with different inputs that shares implementation e.g. a common function for the body (so sharing implementation would be done at a level below the component, unlike in integrant where the component itself is the implementation to be shared). This seems mostly ok if it's only a handful of components, and in theory you could dynamically generate resolvers with a macro but that could be dicey. I haven't looked into the new dynamic resolvers much, maybe there's something there, especially wrt. passing in new dependencies.. intuitively it seems like pathom would be pretty good at dealing with fine-grained data sharing/differentiation requirements

nivekuil14:08:30

I think the easiest change to facilitate that use would be to allow overriding pco/output , and then you could pass in a vector of inputs and return a pco/output with multiple keys

nivekuil14:08:55

actually, aren't derived keywords essentially a join? I've only tested with flat queries but I wonder if what you describe is already addressed thanks to pathom's existing behavior