Clojurians Log v2
graphql
@hlship Do you have a ballpark idea of how much effort it would take to add parsers and serializers to Objects and Input Objects as a Lacinia feature? This is something I've grafted on in my resolvers (including leveraging the schema to make it mostly automatic), but it'd be nice if it were supported the same way enum serializers/parsers are supported.
(it's something I'd like to explore implementing unless you say it'd be hard or impossible for some reason)
I'm not sure I fully understand what do you mean by add parsers and serializers to Objects/Input Objects. Aren't they automatically converted when using plain Clojure objects?
I'm not sure what the ask is here either.
Sorry, serialize and parse in the same way enums are parsed/serialized– transform in an arbitrary way. In this case, with the request context in hand. e.g., {:name "Joe" :age 10} -> {:user/name "Joe" :user/estimated-birth-year 2012} My use-case is adapting from graphql to domain data and back
So the graphql field is “name” and you want to return user/name , and Lacinia should do the right thing ? Or more arbitrary transformations?
more arbitrary transformations. Of course, my resovers can do the work, but since input objects can be composed it's nice to be able to define at graphql->domain mapping once and use it everywhere.
That sounds interesting. We are trying to use the graphql names everywhere (eg in our SQL queries) - but having a top level converter function that accepts the resolver-returned data plus the current field schema might be useful. Though, it might be complicated
I try to avoid conflating my business domain with external APIs– we expose data via GraphQL, Pathom, and some REST endpoints and those APIs cater to their respective audiences. There's a lot of leverage to be had in having a layer of indirection– we don't conflate how we store data in the DB with how we expose it, at a minimum.
Well, you wouldn't need a parser for an Object, just an Input Object. I wonder if this could be done using GraphQL directives perhaps. It's a bit tricky if we want to support both SDL and EDN schemas, though it could be something injected between parsing SDL and compilation. Essentially you are just looking for a (bi-directional) mapping from domain keys (e.g., :user/estimated-birth-year) to GraphQL keys (e.g., :age). In your example though it isn't just a rename of the key, it's a computation. I think this takes more thought about where and how to plug it in. Alas, my time to work on Lacinia is limited.