@kenny we're building a new app with lacinia & datomic and try to match the schema as much as possible with the datomic schema

by default a field resolves to a datomic attribute and we use the Entity API to resolve those

With lacinia 0.17.0 this will become a easier as a resolver will be able to return a datomic Entity (https://github.com/walmartlabs/lacinia/pull/59)

the namespace problem we solve by convention: take the entity keys, find the 'id' field and take its namespace.

this covers about 85% of our resolvers

for the other 15% we set a custom resolver on the lacinia schema

you could solve the namespace problem also by e.g. taking the graphql type of the surrounding object and using that as the namespace

in the context there is :com.walmartlabs.lacinia/selection which provides you all the information about what you're trying to resolve at this point

I've been working on some stuff and would love feedback before it's committed. https://github.com/walmartlabs/lacinia/issues/65

https://github.com/walmartlabs/lacinia/issues/64

BTW, in terms of resolvers for namespaced keys. We haven't documented this yet, but in a schema, a resolver entry can be a list rather than a simple keyword. attach-resolvers treats this differently, it treats it as a function call with parameters, rather than a simple lookup.

Eg.

{:fields {:name {:type String
                          :resolve (:get :user/name)}}}

In this case, the attach-resolvers call could include;

:get (fn [k] (fn [_ _ value] (get value k)))

... resolver function factory, rather than a direct resolver function.

@hlship Oh, that's awesome! Looking at the attach-resolvers impl I can see that now.

@stijn Are you guys using CLJS on the frontend?