I'd like to float an idea; in a bit of work I'm doing internally, we have a object type ... let's call it Widget. For a Widget most of the data comes from our primary database but if certain selections are made, we go get data from a secondary source and merge it in. So that's cool, and I have a resolver function that does just that: grabs the :widget key from a parent map, checks the selections, and maybe merges in the extra data. BUT I have many objects that contain a :widget key. Fortunately, they are uniform in calling it :widget. So what I'm thinking is: how about allowing a :resolve directly on an Object to localize this kind of logic? The :resolve in this case would be more like a filter .. it would be passed the value and would resolve the same value, modified as necessary. In my case, the value passed in would be the raw Widget and would resolve to the same, or the Widget merged with that external data. I'm trying to think about how this might be abused, cause unexpected problems, break existing code, or cause performance issues.

@hlship seems right can maybe also be used for cashing, like get something from cash, when some conditions are met, get from database?

That's an interesting idea; so maybe I have a :Gadget object with property :widget of type :Widget, but the :widget value in the :Gadget is a widget id, and the object resolver for :Widget is responsible for getting the full :Widget (from cache, or from database).

Something like that I think. I used Lacinia before based on a Kafka topic, where it would build a map. Now I might use it with a jcr repository where I probably need some kind of cache, but haven't thought out all yet.