Fork me on GitHub

Hi, I'm getting Failed to compile GraphQL Schema. Got message: clojure.lang.ExceptionInfo: Resolver specified in schema not provided. {:reference :default-value, :callbacks (:interfaces :root-schema :of-type :enum-values :input-fields :fields :possible-types :root-type :nested-type)}


What I find bizarre is that I've checked out the commit way back when I first committed a test to check our schema compiles and it now fails, I'm sure it passed when I checked it in


I've tried deleting my .m2 repo, bit baffled as to what could be the issue


The schema file is within the git repo btw 🙂


I don't know if it's relevant but we're using Relay, which needs a graphql schema, so we're also using Lacinia parser/parse-schema rather than EDN


I'm running the test with lein test :only ... to avoid any stale-REPL issues


I was using lacinia-0.29.0-rc-1 but 0.30.0 behaves the same


If you were using EDN, that error means that you had a :resolve :my-resolver-fn somewhere, and you’re not attaching a resolver function anywhere.


Perhaps the :default-value should mean something to you?


Nothing to do with .m2 or anything else BTW. This is Lacinia complaining that your schema is invalid.

Joe Lane16:10:56

Hey friends, i’m trying to get a handle on what the current state of consuming graphql (from AWS AppSync, not Lacinia if it matters) from clojurescript is. I’m not sure if this is one of the scenarios where nobody does it so there aren’t resources on the web or if its the other scenario where its so trivial to do that nobody bothered to write a blog post on how to do it. Does anyone have pointers to an example that has mutations, queries, and subscriptions?


@alee That looks to be in the part of the code that applies some Introspection resolvers to the Introspection types (these are merged into the schema provided by the application). I can't imagine a scenario where this should happen; if there's any way you could shave down your SDL schema so that it still manifests this problem I'd be happy to dig down into it.


@lanejo01 I'd recommend using Apollo. I can't provide any open-source examples though.

Joe Lane18:10:44

Just use the straight apollo-client from clojurescript?

Joe Lane18:10:03

Have you integrated it with reagent at all? I know you’ve done work with React Native.


@lanejo01 Yes, Apollo is easy to use with Reagent. Unfortunately, I don't have open-source code on this that I can share as the only times I've written Reagent wrappers for Apollo were for consulting clients. I'd like to make a library for this; the biggest issue is just figuring out how to package all of the Apollo deps. Anyway, the gist of it is that you can wrap ApolloClient's watchQuery (not ApolloReact) with reagent.ratom/make-reaction. Then you can treat query results like reactive atoms (watching components will rerender when query results change).

Joe Lane19:10:20

Beautiful. Thats enough for me to get started. Thanks @domkm!


My company has open-sourced artemis, based on a lot of ideas from apollo, it's minimal but might be useful: