Fork me on GitHub
#graphql
<
2017-09-21
>
stijn07:09:19

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

stijn07:09:08

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

stijn07:09:19

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

stijn07:09:29

and I'm also curious about your approach 🙂

dominicm08:09:36

@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)

dominicm08:09:47

We're also on an ancient version

hmaurer08:09:28

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

hmaurer08:09:02

I haven't added querying capabilities yet though

hmaurer09:09:59

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

hmaurer10:09:54

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

hmaurer10:09:11

then a module which generates a graphql schema from that

hmaurer10:09:14

but independent from the core

hmaurer10:09:23

so you could also generate a REST api or whatnot

stijn10:09:29

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

stijn10:09:01

which is probably very similar to a lacinia endpoint