This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-08
Channels
- # bangalore-clj (4)
- # beginners (160)
- # calva (132)
- # cider (18)
- # clara (1)
- # cljsrn (2)
- # clojure (129)
- # clojure-boston (1)
- # clojure-europe (5)
- # clojure-italy (5)
- # clojure-losangeles (1)
- # clojure-nl (33)
- # clojure-uk (49)
- # clojurescript (88)
- # cursive (20)
- # datomic (5)
- # duct (3)
- # fulcro (33)
- # graphql (7)
- # jobs (3)
- # kaocha (3)
- # nrepl (41)
- # off-topic (58)
- # pathom (18)
- # re-frame (1)
- # reagent (5)
- # shadow-cljs (148)
- # spacemacs (7)
- # tools-deps (7)
I have a schema design question. My object graph is a DAG with a few potential root types. I have been exposing those root objects as queries, but I find myself now replicating the same set of args on the object and the corresponding query, e.g. for queries by indexed fields, and it feels redundant. I almost want to introduce a single synthetic root query and have all of the root object types available off of it to eliminate this redundancy. Has anyone else experienced this dissonance? I can’t tell if I’m using graphql poorly or if this is just a typical redundancy.
You aren’t able to share attributes between input objects (your query arguments) and the returned objects - but you could easily write some Clojure code to do it for you.
There are a subset of fields which are both arguments for filtering objects as well as arguments for filtering their corresponding queries… so these queries are just pure projections of their corresponding objects.