Clojurians Log v2
graphql
If your schema is written in SDL, and you’re using parse-schema how are you supposed to attach the resolvers?
The guide still seems to document passing them in the attach map however the docstring says the :resolvers key is now deprecated.
I tried using attach-resolvers but I’m not sure what convention you’re supposed to use to identify them… I tried :Query/myfield and :query/myfield and neither seemed to work
It looks like attach-resolvers isn’t right, because it expects a :resolve key to be present… in the schema edn; but parse-schema doesn’t set it.
There is inject-resolvers , takes a map of schema coordinates (`TypeName/fieldName`) and a normal resolver function
Thanks that looks like what I need
I’m curious about adding some type and field level directives. To essentially provide a mapping of annotations to other identifiers in the backend systems. Does lacinia provide any good ways to access these in resolvers, or to post pre/post process requests and responses? The docs seem to indicate this is an area under development.
You're seeing the evolution of the library over time - I now always use inject-resolvers.
Also look at the :apply-field-directives option to compile (https://walmartlabs.github.io/apidocs/lacinia/com.walmartlabs.lacinia.schema.html#var-compile)
@lennart.buit Thanks for linking to that discussion, there are some interesting points there… though I’m not sure I follow all of them…
> There is no consensus on standardizing custom directives in introspection
is that true though? The latest draft of the spec includes quite a lot on the __Directive type in particular it states:
https://spec.graphql.org/draft/#sec-The-__Directive-Type
> This includes both any built-in directive and any custom directive.
And as far as I can tell the __Directive type has been documented to some extent in every version of the spec since the first spec in July 2015.
I understand many aspects of Directives are unstandardised; but it seems this particular one is, and isn’t yet supported in lacinia… or am I missing something?
Hmm interesting; directive definitions do appear to have an introspection schema indeed. I stand corrected
Thanks.
I’m still trying to figure out precisely how directives are supposed to work in graphql and lacinia.
Am I right that the :locations keyword states where a given directive is allowed to occur in the AST?
In which case I’m assuming the allowed values are:
• :field-definition for annotating a field
• :enum for annotating an enum
• :object for annotating a type?!
ahh I see “locations” is a concept from the graphql spec 👀
Does lacinia support all the specified locations?
I see from the docs also this: > Introspection hasn’t caught up to to these changes; custom directives are not identified, nor are directives on elements. I’m assuming this is why:
__schema {
directives {
name
description
locations
args {
name
description
}
}:directive-defs
Are there plans to add support for introspection on directives? Strictly speaking I probably don’t require this at the minute, but I can imagine applications for it.Ahh cool the lacinia SDL parser supports directive defs 👌
directive @foo(
foo: String = "foo"
) on FIELD_DEFINITION | ENUM_VALUEThere is no consensus on standardizing custom directives in introspection
Some directives have custom introspection schema, @deprecated for example
That said, some GraphQL implementations, most notably Java and .net, have semi standardized directive introspection schemas
Finally, some servers work around this. For example Apollo Federation has a top level ‘sdl’ query. SDL does support directives