Clojurians Log v2
graphql
I just merged the doc PR to master; there's a few wrinkles to work out, but we'll get those fixed.
Is https://github.com/walmartlabs / https://github.com/walmartlabs/clojure-game-geek going to be updated too?
Just pushed the update.
Thank you!!
Going to add a chapter on more testing and refactoring. Maybe this week.
I'm so grateful for these updates
Yes, I just haven't gotten around to that. Maybe tonight.
I'm really happy, steering people towards camelCaseNames, using inject-resolvers instead of attach-resolvers,, using Query fields instead of :queries, and adding more and longer discussions about important topics.
Sigh, now we have to debate in the team whether it's worth doing a refactoring against the better approach 😄
Just kidding. It's mainly inject-resolvers anyway. I will go through the new documentation with fresh eyes and see what else we have been missing.
Everything is still valid, but the tutorial is up to date with what's preferred: • inject-resolvers • pascalFieldNames • CamelCaseTypeNames • Query object vs. :queries, etc.
We were alread using camel case and pascal case after reading through the official graphql tutorial. But the Lacinia aspects we might need to change, just to avoid having to come up with :resolve keywords.
Tooling also has a much better time with namespaced keywords these days.
Yep, I like inject-resolvers because it's all in one place.
A big chunk of Lacinia is stuff I would strip out, if not for backwards compatibility.
We actually introduced a defresolver macro (initially for logging) that we were hoping could take over some of that functionality, or at the very least be amenable to tooling (e.g. find all resolvers). Perhaps with a bit of metadata you can put the graphql field together with the resolver function... but then you have to do something clever to actually load all the resolvers, and only then compile the schema.
Another consideration we had was keeping the :resolve field in the schema but use a fully qualified symbol and then use require-resolve to load the function. I think clojure-lsp now supports jump to definition from EDN files to fully qualified symbols.
(All of this doesn't have anything to do with Lacinia, we can do everything in the user level, of course)
At Walmart, we also worked on a defresolver macro, but ultimately it helped with allowing you to define a 1-arity or 3-arity function, and it would provide the other (used when one resolver directly invokes another). But that was something useful with our older schema; the newer schema has almost no resolvers at all, beyond root operations.
We like the idea of an auto-registration system too; one approach was for defresolver to place meta-data on the Var, and then use a function to load namespaces and scan them for Vars with that meta-data.
We also had a couple of code bases all jammed together in one project, supporting several different schemas, so had to watch out for globals. Avoid globals like the plague.
In the clojure-game-geek code, when I do clojure -T:dev or when I jack-in with the dev profile through calva, I see the following error:
clojure-game-geek % clojure -T:dev
Exception in thread "main" Syntax error macroexpanding at (user.clj:1:1).
at clojure.lang.Compiler.load(Compiler.java:7665)
at clojure.lang.RT.loadResourceScript(RT.java:381)
at clojure.lang.RT.loadResourceScript(RT.java:368)
at clojure.lang.RT.maybeLoadResourceScript(RT.java:364)
at clojure.lang.RT.doInit(RT.java:486)
at clojure.lang.RT.init(RT.java:467)
at clojure.main.main(main.java:38)
Caused by: java.io.FileNotFoundException: Could not locate com/stuartsierra/component__init.class, com/stuartsierra/component.clj or com/stuartsierra/component.cljc on classpath.
at clojure.lang.RT.load(RT.java:462)
at clojure.lang.RT.load(RT.java:424)
at clojure.core$load$fn__6908.invoke(core.clj:6161)
at clojure.core$load.invokeStatic(core.clj:6160)
at clojure.core$load.doInvoke(core.clj:6144)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invokeStatic(core.clj:5933)
at clojure.core$load_one.invoke(core.clj:5928)
at clojure.core$load_lib$fn__6850.invoke(core.clj:5975)
at clojure.core$load_lib.invokeStatic(core.clj:5974)
at clojure.core$load_lib.doInvoke(core.clj:5953)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invokeStatic(core.clj:669)
at clojure.core$load_libs.invokeStatic(core.clj:6016)
at clojure.core$load_libs.doInvoke(core.clj:6000)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invokeStatic(core.clj:669)
at clojure.core$require.invokeStatic(core.clj:6038)
at clojure.core$require.doInvoke(core.clj:6038)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at user$eval138$loading__6789__auto____139.invoke(user.clj:1)
at user$eval138.invokeStatic(user.clj:1)
at user$eval138.invoke(user.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:7194)
at clojure.lang.Compiler.eval(Compiler.java:7183)
at clojure.lang.Compiler.load(Compiler.java:7653)
... 6 moreI don't use Calva, but -T:dev looks wrong, as that sets up for executing a tool. Should be -M:dev perhaps?
I use Cursive day to day, and don't have experience with Calva, but am totally open to necessary changes to support Calva.