@U7Q9VAXPT Note that passing around lookup-refs is not sufficient to emulate Peer Entities: you also need to pass the database values, otherwise you may run into inconsistencies.

You're definitely going to face dilemmas you didn't have on Peers, typically simplicity (I want my functions to have little dependencies to each other, and my queries to be about just one thing) vs performance (I don't want the N+1 problem). I advise you do some benchmarking - you'll probably find as I did that a Datalog query has usually much more overhead than an Entity Lookup for the same amount of work.

My intuition is that tools like GraphQL or other similar demand-driven can alleviate a lot of this problem, because a lot of business logic can be expressed via derived attributes, and you can relatively easily build an efficient GraphQL server by using a combination of asynchrony and batching - which is a good fit for a Datomic Client.

GraphQL is for the read-site; as for the write-side, you usually have looser latency and throughput requirements for writes, so I wouldn't worry too much about the performance of that

But I'm very curious to know what you find down that road.

My first take on this, business functions have db as first argument and can take either entity id or lookup ref as additional arguments. I then have a set of functions to create lookup ref from name/uuid/natural key, and another set of functions to resolve entity id from lookup ref (so far only needed for existence test).

I feel like this is a bit worse than N+1, because I'm seeing a lot of colocated on-demand pull of essentially the same information multiple times. Now that each pull is a network request, this worries me. Especially since I'm using ring without async handler...

I think GraphQL clients work around this issue by locally caching every query result. Essentially almost what a peer is doing. So I could theoretically wrap pull with some custom memoize/caching if needed.

Write is actually getting a bit more complicated if I'm designing for Datomic Cloud where db/cas is currently the only transaction function. I can use cas like clojure's ensure but I then have to explicitly handle retries.

Maybe I'm looking at this from the wrong angle. The client library is designed for microservice architecture and I should not worry about performance as long as it is within the same algorithmic complexity and just scale horizontally.

Still, you may have a latency problem. Maybe you should fetch data once and pass data structures to functions that do a lot of validation

news?