Fork me on GitHub

What are people thinking about ? It's very similar to something I'm prototyping internally right now (with an eye to open sourcing).


Similar motivations.


From what I quickly read it seems great, but since amazon takes a lot of work out of your hands it will also become hard to break with amazon if you would want to.


Who else is using Lacinia with Component? I'm thinking of adding a protocol that components can implement, and some logic in schema/compile to recognize and invoke that protocol method.


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 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.