My pleasure; Happy to have been helpful. I'll clarify that I think om-next is probably going to be the most Clojuric and well-trod approach to GraphQL style web development with Clojure/Script. However, I personally prefer Reagent over Om. This is part of why I started down the route of developing Datsync. I hoped that I'd be able to decouple from the particulars of the React wrapper (om vs reagent vs rum vs quiescent etc), and have something more standalone. But we're quite a bit further from being generally production ready, so factor that in as you will. And to be clear, I think Om is great, so don't let my preferences steer you away. But maybe also consider tinkering with Reagent a bit for contrast.
Cheers Chris On Wed, Jul 5, 2017 at 11:25 AM, Nick Pavlica <lini...@gmail.com> wrote: > Hi Chris, > Lots of great information here! It sounds like your preference is > Om(next), which sounds very interesting. I think that I'll have to dig in > and play with it before things really start to click. I'm sure I'll have > many more questions once I get a better handle on Clojurescript approach. > > Thanks Again!! > -- Nick > > On Saturday, July 1, 2017 at 3:19:59 PM UTC-6, Christopher Small wrote: >> >> Hi Nick >> >> I'll try not to get carried away here... >> >> First off, folks in the Clojure and ClojureScript communities are >> absolutely familiar with, inspired by, and building on top of or in the >> direction of GraphQL. David Nolen, the author of Om and the lead >> ClojureScript developer, has build om-next which is more or less a Clojury >> take on the GraphQL idea. The insight there, which Dustin hints to, is that >> Datomic has this thing called a pull query you can execute, which is more >> or less isomorphic (I guess if it's more or less I should just say >> homomorphic...) to the GraphQL query. Om-next is basically just "let's >> close that gap", and most of the gap is stuff like pagination and sorting >> of collections. So it gives you a way of describing these things directly >> in your pull queries. The nice thing about the pull query, is it's just a >> data structure, so it's very composable. You can build queries up >> programatically, which is really lovely. This pattern of building programs >> around the composition of data structures is really a cornerstone of the >> Clojure philosophy. >> >> As I think some others have pointed out here, there seem to be others >> experimenting more directly with the GraphQL api. But om-next is really no >> less agnostic about a lot of things than GraphQL. It's not really tied to >> Datomic, except in that it inherits the pull query syntax. But you can >> implement the resolvers and such to work with any backend storage mechanism >> (and long as you can traverse the relationships). The Datomic integration >> happens to be trivial, which is nice, and opens up other possibilities. >> However, Datomic is not the only "Datomic" in a sense. DataScript is a cljc >> (meaning, it can compile to and be used from both Clojure AND ClojureScript >> (And JS actually)) implementation of an in memory version of the Datomic >> API. It's actually surprisingly feature complete, and a great way to >> experiment with the underlying data model, pull queries, and even Datalog >> (a query language also baked into Datomic which is more expressive than >> SQL, and better for querying graph relations). The folks at Mozilla have >> also started working on Mentat, a Rust (I believe) implementation of a >> Datomic like database on top of SQLite. It's very clear to me with all the >> activity around these projects that while Datomic remains a very powerful >> system with many features these other projects will likely never aim for, >> the overall idea has started catching on, and is worth paying attention to. >> >> Part of what makes the om-next approach so fascinating is that Datomic's >> data model is based on RDF. If you're not familiar with it, RDF is a web >> standard, and the de facto data language of the Semantic Web (also manifest >> as web standards). It's part of the vision of the computable web of data. >> The idea is that all data should be self-describing, globally meaningful, >> and infinitely extensible. There are vocabularies which can be described in >> RDF data, which themselves describe the schema and meaning of other data. >> It's super brilliant stuff, and actually really simple! Data is organized >> as (entity, attribute, value) triples of "facts". The key is that as long >> as your attributes are globally meaningful, you can merge information about >> an entity without ever worrying about overwriting other information about >> that entity. This gives us extensibility. In Clojure and Datomic, these >> globally meaninful attributes are achieved via namespaced keywords, which >> is also: brilliant and simple. We can also have entities that point to >> other entities, giving us polymorphic entity relationships. Datomic owes >> some of it's brilliance and I think success to making this collection of >> ideas a bit simpler, more approachable and more idiomatic. RDF has been a >> great idea waiting for someone to come around and maximize it. And Datomic >> is not alone. Look at other companies like MarkLogic who've built big >> businesses around RDF technology. By contrast, GraphQL is an idea that was >> hacked together kind of recently, is not as far as I know a standard >> (please correct me if I'm wrong here), and doesn't have namespaced >> attributes, so you're a little stuck not being able to get all of the >> natural polymorphism and extensibility of Datomic and friends as easily. >> However, it's also proven that streamlining the communication of data from >> server to client, and stripping out all of our bloated controllers and REST >> apis is possible, and that it can dramatically shrink code bases and >> accelerate development, which is really awesome. But in short, it's really >> worth seeing what the Clojure community is doing with these ideas, because >> it definitely adds some dimensions of awesomeness. >> >> I'd be remiss if I did not mention that I'm working with some folks on >> building out Datsync, a system for syncing Datomic/DataScript data (EAV / >> triple data, in technical terms) between nodes in a network (either server >> client or P2P). Here, our goal is to extend the scope of what om-next >> describes by automating the synchronization of EAV triples given that this >> is what your data looks like. We do plan to support om-next style pull >> query syntax (so you'd be able to differentially sync using something more >> or less equivalent to a GraphQL query). But we're also considering >> implementing a reactive, incrementally maintained, eventually consistent >> Datalog engine. It's been shown that a subset of Datalog is more or less >> the most expressive eventually consistent language you can construct, so >> this effectively means we'll have maxed out what you can describe without >> needing coordination between peers (and hence some kind of consensus >> algorithm, like Raft or Paxos). In general, it's a really lovely complement >> to the pull query. Taking a step back though, the audacious goal of Datsync >> is to more or less one-up GraphQL by having the full expressiveness of >> Datalog+pull for the description of synchronization scope, together with >> the flexibility of RDF data for data modelling, and almost 0 hook-up (you >> won't have to implement resolvers or anything; just plug in an >> synchronize). There are some caveats to this of course, and there will be >> plenty of work exploring this paradigm, but we're very excited by the >> potentialities! >> >> As for your comments about your experience coming to the Clojure >> ecosystem, I really appreciate your voice here. The Clojure community is >> full of extremely bright folks working on lots of really wonderful things, >> and it can feel a little overwhelming coming to so many new ideas and ways >> of doing things at once. Having done ruby and rails development in the past >> prior to Clojure, I can testify to that feeling. So, while I can say that >> it does get better, there have been discussions in the community of late >> about how we can reduce the burden here. So again, I thank you for voicing >> your perception of things here. However, I can also say having poked a >> stick at various JS tooling that the ClojureScript ecosystem anyway feels >> way saner to me. There are two build systems, but to at least some extent >> they are compatible. Contrast that with Python's infinite menagerie of >> tooling. Also, FP is getting more popular in JS, so folks start bringing in >> libraries to help with that, and instantly, confusion ensues about which >> one, how they handle this edge case, etc. In contrast, ClojureScript has >> good pure data structures built right into the language, as well as all >> (well, most) of the well thought out functional programming utilities baked >> into the clojure.core namespace, so there's never a question about any of >> that. And by building on the Google Closure compiler, ClojureScript is able >> to leverage a bunch of useful properties of that sytem automatically, >> without any real thought, such as code shaking, browser compatibility, etc. >> And yes, it's a little confusing some times figuring out which lib works on >> front end versus back end, but honestly? This is way better than the >> alternative in my opinion. What other functional language has as high a >> utilization across browser, server and distributed system? That's a lot of >> power to pack into the punch of one well thought out language. So I'd argue >> that the mild discomfort of coming into the scene and having to figure out >> what libs are for clojure and which for clojurescript is more or less worth >> it, cause in the end it's only giving you more options. And I think now >> that we have .cljc files for doing this, more and more libraries are doing >> this "first-class" now, and for old libs, they are frequently rewritten to >> work with both after the fact, so the situation is improving overall. But >> that doesn't mean there isn't more we can do to make the situation better. >> >> Ok... I think I got carried away... but hopefully that 2c was useful. >> >> Chris >> >> >> On Friday, June 30, 2017 at 8:28:22 PM UTC-7, mynomoto wrote: >>> >>> Hi Nick, >>> >>> At Xerpa[1], we have being using graphql on a clojurescript project. >>> It's an SPA that uses reagent with json api and its currently being >>> converted to a re-frame one with graphql. >>> >>> We studied the possibility of using relay modern and apollo client but >>> decided to not use them at the moment. >>> >>> We started using graphql-builder[2] which is like yesql[3] but for >>> graphql queries meaning that you write queries in another file directly >>> using graphql and you can use those from clojurescript functions passing >>> parameters when needed. It worked really well for the first couple of views >>> but we found it not flexible enough for our needs in different views. >>> >>> After more research we found a new library venia[4] that uses clojure >>> data structures to generate graphql queries. We needed a mechanism for >>> merging queries requested by each component and requesting the merged query >>> when the view changed. We wrote that in house and it's in production for a >>> couple of months. I hope to find time to write more about that sometime but >>> this is our experience so far. >>> >>> Cheers, >>> >>> mynomoto >>> >>> [1]: http://www.xerpa.com.br/ >>> [2]: https://github.com/retro/graphql-builder >>> [3]: https://github.com/krisajenkins/yesql >>> [4]: https://github.com/Vincit/venia >>> >>> >>> On Friday, June 30, 2017 at 9:52:40 PM UTC-3, Nick Pavlica wrote: >>>> >>>> Hi Dustin, >>>> Thanks for addressing my question, and helping me better understand >>>> ClojureScript, and the community! >>>> >>>> On Friday, June 30, 2017 at 2:35:40 PM UTC-6, Dustin Getz wrote: >>>>> >>>>> It's not clear to me that the cljs community has converged on graphql >>>>> as a best practice. some people have certainly adopted it but it doesn't >>>>> feel like there are very many to me. for example, Datomic has been doing >>>>> what GraphQL offers plus much more since like 2013, it's not clear that >>>>> graphql adds anything to what cljs users have already been doing since at >>>>> least as long as facebook is been doing it internally. this isn't what you >>>>> asked, but could explain the silence. >>>>> >>>> >>>> I'm sure that GraphQL isn't that big of a deal from within the Clojure* >>>> community, but it's pretty exciting when you are coming from traditional >>>> environments where you deal with REST endpoints. I've done a little >>>> research on Datomic, and it sounds awesome, but I haven't used it yet. In >>>> my mind, GraphQL has some non technical advantages over Datomic. The >>>> primary advantage is that it's an open specification, and not a proprietary >>>> product. This allows for multiple implementations, and provides >>>> opportunities for multiple support points. As it stands, there's only one >>>> company that has a Datomic implementation, and if they go down so does your >>>> tech stack. Additionally, if the current implementation of Datomic doesn't >>>> have a feature or function you can't just add it yourself(At-least to my >>>> knowledge); Another potential down side of having only one Datomic vendor, >>>> is the potential of price gouging leading to unforscene budgeting issues. >>>> I'm saying that Cognitech would act that way, but it's something that I >>>> think should at-leas be considered. I'm sure an end to end Clojure stack, >>>> plus Datomic is pretty sweet, I'm just now sure how many can go that >>>> route. It makes me wonder if someone isn't thinking about an open >>>> implementation. >>>> >>>> Many Thanks! >>>> -- Nick >>>> >>> -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/clojurescript/VbJLJS9I-qM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at https://groups.google.com/group/clojurescript. > -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
