thanks for sharing this! is it possible to execute a pull pattern on an eem for its derived attributes?

:xform is a bit restrictive in the kind of transformations it can do

are you gonna use it in prod? curious if there’s any back story

It was designed for the problems I was seeing in particular when using entity maps with Lacinia. (That’s also why metadata support: for tagging!) I no longer control whether it actually gets used though!

If you are in a position to have and use pull expressions, I really recommend just using Pathom instead of this—it is designed to give a pull interface over anything

that makes a lot of sense now

i’ll check out pathom. it’s not possible otherwise? d/pull doesn’t operate on entity maps ?

But that said, it shouldn’t be too hard to write something that takes a pull expr and touches a map in the same way

Sorry missed your comment. No, pull produces a map from an id, it doesn’t touch an entity map

It’s really an alternate (eager) interface to map-projection, vs entity-map’s lazy interface

But the laziness means “special magic object with invisible IO”

nods , got it

i made need to use Lacinia over pathom due to work constraints so i’ll have this in my toolkit now

so far just on REST but it’s showing its age

too many APis

Pathom also provides a lazy version. It’s called “smart-maps” over there. Lacinia +pathom would be a good match if you can line up fully-qualified graphql fields to pathom-provided fields. If you convert the gql query to an eql query, you could even use pathom’s execution engine instead

oh interesting

Ie just run the query and return an entire nested result for Lacinia to pull keys out of

i have to write the schema twice then?

Pathom is schemaless

interesting i need to check it out and read up

You need to give it key dependencies , but it doesn’t need to know anything about their values

gql typically has better data and schema exploration tooling , so your customers can figure it out in their own , so sounds like a lethal combo

pathom is 🔥 thanks for the recommendation, i actually used fulcro a long time ago before pathom existed, I believe it was extracted out of there or inspired by its backend, so can't believe it took me this long.

this might be a good time for us to move to https://www.juxt.pro/blog/atomic-architecture/ too, and use mutations for domain ops.

I also started out as a monolith codebase, then moved to polylith, but took our existing monolith and just dumped it in bases/megacorp, and haven't had a ton of time to disentangle the monolith into polylith, so i feel like everythings aligning for a major refactoring.

maybe one qq for you, when writing the EQL Resolvers -> Datomic, what's your suggestion on the building block to implement those? d/entity, eem, d/pull or d/q?

how is EEM equality defined given no associations, is it just :db/id equals?

@U0J3J79FE it is same as datomic’s entity maps, which is the database’s unique name plus entity db id

I'm now using your lib at work, merged in a CL a couple days ago, mainly for the eem/prefer-aevt so far, and I also merged 'on-retract' stuff couple months ago, per your blog post.