@hlship Can you include "-" into spec for identifiers? Maybe add some explicit flag to compile function or some other way. It will allow to have all internals kebab-cased, while requests and responses can be automatically transformed from/in camelCase for Accept/Content-Type application/json and kebab-case for application/edn it is a case, which will not break graphiql and will allow to keep existing clojure codebase untouched, while adding graphql endpoint.

Key transformation seems like a step that can be done by users of the library, no?

Partially yes, but I really don't want to transform keys for each call of resolver. What I want is to do transformation only when app getting request and sending response. Inside application/resolvers it is expensive and error prone to do tons of transformations.

@andrewtropin we translate our namespaced keywords back and forth between datomic / lacinia. we do this by annotating the lacinia schema (e.g. add a :namespace to each type and use that information in the resolver to determine the datomic attribute) and wrapping each resolver on the way out with a function that strips the keywords

that way, inside each resolver you only handle namespaced keywords. you can do the same with casing

@hlship we only compared alumbra and lacinia and the reason we chose lacinia was: 1/ the schema is edn. this has proven to be very flexible for e.g. implementing generic types and automatically generating basic mutations/queries from the schema 2/ I didn't really grasp claro (which is used by alumbra), but that might not be a very good reason as I didn't look at it long enough maybe

@stijn Did you see that lacinia generates namespaced keywords itself? maybe useful in some cases.

{:type {:kind :root, :type :String},
     :field-name :name,
     :qualified-field-name :human/name,
     :args nil,
     :type-name :human,

so first of all we set the default-resolver to this

(defn default-resolver
  [field-name]
  ^ResolverResult (fn [{:keys [::auth/db]} args v]
                    (resolve/resolve-as
                      (if (instance? Entity v)
                        (get v (keyword->namespaced db v field-name))
                        (get v field-name)))))

if anything that comes back is a datomic entity, we try to get the namespaced variant of the field-name om the entity

that alone already solves most of the translation

another place where you have to translate is in the input of mutations, and what we do there is to add a :namespace attribute to the input-objects and add that to each field

some context: we are building a new thing, so we match our lacinia schema with the datomic schema. if you can't do this, it all becomes a bit more complex

Yep, we already have codebase designed with RESTapi in mind. Seems like there are too many places with translations will be needed.

FYI we're testing Lacinia 0.21.0 now in our staging environment. Once its running in production (a few days from now) we'll do an official release. We weren't happy with some issues in 0.20.0 (in some cases, the code would fail because org.clojure/test.check was not present) so we're "eating our own dog food" using an internal release candidate.