Similar motivations.

Not wanting to start a fight but have you considered integrant? Having used component and mount it’s in my mind by far and away the best of the bunch. It’s basically component but done in a way that works flawlessly with an external EDN config. I’ve been meaning to suggest it could be a good fit for lacina schemas. cc @U0539NJF7

I do prefer integrant nowadays, since it supports any return value for dependencies, which makes some things a lot simpler (e.g. you can only return the datomic connection instead of a record that has a connection and implements the component protocol). Also, the multimethod approach is more concise. external edn config is also a big win (we use aero)

That said, I'm not really sure what the added value is for adding this to lacinia?

Adding it to something like https://github.com/danielsz/system is a possibility too

@U0539NJF7: yes aero and integrant can work well together, I’ve done the same. Regarding value add; thanks for calling me out on not mentioning it… Basically I think the value of using something like integrant is in extensibility. For example we have a prototype graphql service which provides a common core that can dynamically generate a schema from a database structure… However there are aspects which may need to be extended/customised by other downstream projects/clients… Integrant could help users plugin/override these things. Though that could definitely be done in our app anyway.

I think the thing that perhaps lacinia could learn from integrant though, would be to remove the need for attach-resolvers, as resolvers in the schema edn could just be namespaced keywords (or even just namespaced symbols) that map to functions themselves directly. e.g. instead of :resolve :human you could have :resolve :my.namespace/human and skip the need to then map {:human my.namespace/human}

The beauty of Clojure & EDN is that you could implement that yourself as a function to pass the parsed schema through before it gets to c.w.l.schema/compile.

yeah I think you’re right that preprocessing by us is almost certainly the better option.

I think it's the app's responsibility, not lacinia's to define those 'overrides'

also, I don't think that a component definition really belongs in the library either. people are using different dependency injection libs, so why 'force' any one of them onto the users?

Yeah I agree, it’s more of an application concern than a library one… but there’s lacinia and lacinia-pedestal; and lacinia-pedestal which seems to sit much closer to the application side.