Clojurians Log v2

@oliy I’m looking at your lacinia example, and one thing that concerns me is that resolver higher in hierarchy (resolve-pets) has to know about its children (resolve-pet-details).. what if I have many different children (e.g. resolve-pet-details, resolve-pet-age, resolve-pet-size) and whether they should be fetched or not depends on the query? It feels wrong to specify elastic bounds for all of the possible children..

@hlship any ideas where to add that in lacinia? I think it’s going to be much simpler if at some point in query execution I can just say to superlifter “go fetch everything”. I’m okay with maintaining a fork of lacinia, so it’s okay if the solution is “hackish”

you can use the lacinia introspecting to look at the child selections. what i'm not sure about is if you can know if those child selections have their own resolvers or not, i haven't had time to fully investigate. i have this issue https://github.com/oliyh/superlifter/issues/16 describing a neater solution - essentially asking lacinia "how many times is resolver X going to be called" and then sizing the elastic bucket appropriately

if you find a good way of doing this i'd be really interested to know, i'm happy to accept PRs for superlifter or to make additions

I found another issue with elastic triggers that I’m not sure how to solve… Lacinia query execution is depth first. So, given a query like this:

query {
  concepts {
    related {
      type
    }
  }
}

this probably can be solved with some record keeping of how many parents have already been resolved..

i guess you have (N * M) + 2 here

you can increment the elastic bucket size on each resolving of concepts or related

there's a function update-trigger!

yeah yeah, that’s what I’m figuring out..

it feels like this could all become boilerplate in a list resolver, to count the list size, look ahead at child selections that need a bucket, and set up/increment that bucket

or better, a helper in superlifter

I'm not sure how to make Lacinia generate the desired events without breaking APIs and/or affecting performance.

Hello, this is what the elastic trigger is for: 1. Your top level resolver resolves a lost of N shallow items, and creates an elastic bucket of size N 2. Your N child resolvers each put one item in the elastic bucket 3. When the elastic bucket has N items in it, the fetch will be triggered automatically by superlifter 4. Profit

Here is an example of this: https://github.com/oliyh/superlifter#lacinia-usage

This is the primary use case I wanted to solve with superlifter

woah, thanks!

great, that’s exactly what I need

🙏

I have a vague idea about a relationship between Lacinia and ResolveResultPromise such that Lacinia can tell when processing is dead ended pending resolving of at least one promise; ideally there would be a way to notify a library such as Superlifter of this, so that it could automatically engage to resolve promises. The goal is to get some of the above behavior without knowing ahead of time what N is.

I believe the RI and the DataLoader library can do this because it can tell when it gets to the end of one event loop dispatch with outstanding work, and can tell DL to go resolve some stuff.

i guess if the client code provides lacinia with a callback to be called after each layer of resolvers is done would be a way to maintain performance for those not using it, and only grow the api in a minimal way