untangled 2016-10-31

@darrellesh @tony.kay we’re making pretty extensive use of load post-mutations for things like reporting that don’t conform with the database schema. I’m not sure anyone is using the global post-mutate multimethod, We originally added it in because I was working on todomvc and wanted to save to local storage after every mutation, regardless of which one it was.

and didn’t want to have to manually write in the save-to-storage function call in for each mutation

Ah, right. I knew we added it for some reason. I lean towards composition in mutation methods for that sort of code re-use. Truly global operations on every UI transaction are kind of an invitation for heavy-handed design.

hope to see you there

do live in SF or just here for the week?

there was some article about real-time om.next from adstage

yeah, been here for 1.5 years

yeah i wrote that article

where do you work?

we're in civic center

this was all built with untangled?

@currentoor no, we used it to build an internal admin/management tool for the platform

i wish datomic had an open source admin app/service

our external facing website has pretty stringent binary size requirements, and would need server side rendering for google indexing, etc

or even a paid service would be nice

so not as good a choice

i wish datomic was open source

i didn’t mean your external site, just the app itself

also a clojurescript client would be nice

i'm a little nervous about coupling our product to datomic for those reasons, it would be interesting if there was a om.next server that supported a variety of databases, so for example I could use query expressions to interact with mongo, s3, datomic, etc

the facebook graphql server equivalent for clojure

yeah i looked into graphql, used it in a rails app also

i guess we sort of have that going with the untangled server, but our mutations and reads is too specific to app we're developing, maybe that's just my own fault, not sure if it's a design limitation

java has an alright graphql library, and i think it shouldn’t be too hard to translate om.next queries to graphql

this also looks promising but not as complete

personally I am pretty happy with datomic at the moment but we are supplamenting it with postgres

@currentoor very cool, I wish there was an equivalent of https://github.com/tendant/graphql-clj for query expressions, we're so very close

i wrote this to make it easier to use with the pull API https://github.com/AdStage/pluck-api#external-blob-store

your data flows from datomic -> postgres?

then you compute views of datomic?

with the pluck-api we pull with datomic.api/pull then decorate the result based on the query and which keys implement the -pluck multi-method.

ok, so basically it's like datomic pull syntax, + automatic joins with external store?

yeah pretty much

can easily result in n+1 queries but that hasn’t hit us yet

but we’ll probably have to implement pluck-many at some point

anyway looking forward to seeing you at the meetup

we're on mongo for historical reasons, I would love to see some generic library for doing joins across multiple storage services

if you have a large fanout, maybe datomic returns several IDS, and then you want to query that set of IDS in parallel on the external store

this library would parallelize the joins as much as possible

yah likewise, i think i'll be there, i also sent the link out to the office 🙂

glad to see more om.next presentations, cheers man

@darrellesh The new support for server mutation return value handling. I think we added post-mutation because we didn’t leave a hook in merge to handle the returns from mutations.

I’m curious where you’ve needed to use post-mutation, since I know you’re doing optimistic updates.

usually in that case you’d do follow-on reads with post mutations. Oh wait, do you mean load post-mutations? That is not what I was talking about actually

I was talking about the GLOBAL post-mutate mulitmethod