I'll rephrase the question that I asked in a different thread. If I start work on a GraphQL server that is written in Clojure, what work could I build off of? I see others have discussed the use of InstaParse and that does seem like the obvious starting point. Did anyone get very far using InstaParse to build a grammar for GraphQL?
On Saturday, February 27, 2016 at 10:00:28 AM UTC-5, marc fawzi wrote: > 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: > > 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.
