@hmaurer currently what we're doing is declaring the lacinia schema with :objects and generating mutations and queries based on that schema. We annotate the schema with some extra information to configure the resolvers. Mutations are create/update with arbitrary nesting (depending on which side the relations are managed in datomic) and delete. Queries are by-id and search by object type. We declare in the objects which fields are searchable and generate input-object by type (e.g. date fields you can query with before and after, string with contains equals startswith etc).

I think though that it's possible to store the information for generating the entire lacinia schema in datomic by annotating the datomic schema, but I have to think about it some more

For mutations we have 2 steps that are performed on the input: transformation on the peer (e.g. get extra information from other services, in our case google places api), validation with database functions at the transactor. This is all based on data declaration in the schema, so the code for the resolvers is generic

and I'm also curious about your approach 🙂

@hmaurer I got that message yesterday. It was an issue with casing the field, took me a while to hunt down (damn automatic camel casing)

We're also on an ancient version

@stijn oh, I am doing something very similar, especially with regard to allowing nested creates

I haven't added querying capabilities yet though

@stijn I took the approach of generating the Lacinia schema from the Datomic schema + some extra config map

nice

@stijn I think what would be interesting is to have a “core” which handles data access (validation, authorisation) and exposes a declarative schema

then a module which generates a graphql schema from that

but independent from the core

so you could also generate a REST api or whatnot

yes, was thinking the same about generating an om-next backend

which is probably very similar to a lacinia endpoint