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 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.
