To close the loop on the Limitations part of my GraphQL/Relay conceptual ealuation :)
Limitations Query resolution in GraphQL is defined in the schema, which implements data model transformations that maybe evaluated as part of the the query, e.g. OrderBy, InRange, hasSomeRelation etc. This carries the interesting implication that GraphQL cannot be used (on its own) to support the kind of cient-defined queries that require ad-hoc model transformations. An example would be an app that allows the user to slice and dice her data in an arbitrary fashion. Here are the responses I got to the above: [image: twitter response] <https://camo.githubusercontent.com/070b3a13d64b2a4cfa1292127b86bdbc0fd3eba0/687474703a2f2f692e696d6775722e636f6d2f704a726c5859662e706e67> If we stop thinking of GraphQL as a Graph Query Language in the Graph DB sense, which it's not, and instead think of it as Graph-y RPC Language then it makes sense to use a Query DSL. The confusion beginners often have is with the idea implied by GraphQL, i.e. a graph query language. The chosen name is GraphQL where Q stands for "Query" but in reality it's a "Graph-y RPC Language" or "Graph-based Extensible API Protocol." >><< *So my question is do we have something similar or better than GraphQL/Relay in the Clojure/Script world? Om.Next/Datomic? or is that a very different model? asking naively since I've not had a chance to play with Om.Next/Datomic yet, but is there a reason to? Can it be better than the GraphQL/Relay combination? If so, in what ways?* On Thu, Feb 25, 2016 at 6:19 PM, Marc Fawzi <[email protected]> wrote: > Didn't take me long before I zoomed in on the dark side of GraphQL :) like > a magnet > > See under "Limitations" > > https://gist.github.com/idibidiart/49a095b6bc528638f34f > > Sent from my iPhone > > On Feb 19, 2016, at 8:41 PM, Marc Fawzi <[email protected]> wrote: > > > So, I'm having great fun playing with an in-house implementation of the > GraphQL spec (extended to do more, and some custom-y things) and I wanted > to share the rational for our adoption of GraphQL/Relay with the > Clojure/Script in hope that I can see how it differs from Om.Next + Datomic > (or whatever Om.Next uses on the backend) from enlightened folks > > For me this kind of 'deep architecture' is unattainable via things like > Reagent/Reframe and Om.Next is probably (I'm thinking out loud here) the > closest option for those of us who like to stay within the Clojure/Script > ecosystem. > > Please feel free to take this post apart > > https://gist.github.com/idibidiart/49a095b6bc528638f34f > > and let us know if we're missing anything. > > I focused on Redux + Reselect in my critique but the same applies to > Reframe, which is what Redux/Reselect aims to mimic in the JS world. > > Also, for another perspective on this topic of comparing advances in JS to > state of the art in ClojureScript, someone from the GraphQL team tweeted > this last week, and so I feel obliged to include it, although I've yet to > read it myself (life is short) > > > http://hueypetersen.com/posts/2016/02/13/om-next-from-a-relay-graphql-perspective/ > > Cheers > > Marc > > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
