Clojurians Log v2
graphql
Funny thing, I just tried running the Lacinia benchmarks where there's no ResolverResultImpl, instead resolve-as creates a ResovlerResultPromise and immediately delivers the value to it. Guess how much that affected the benchmarks?
it's really a tiny uptick. I wonder if there's a difference in real code? And does that mean it might make sense to remove
optimizations from lacinia concerning ResolverResultImpl?
Ultimately, probably safest to keep the code as is, but the optimizations are relatively inconsequential, which is a surprise. I would have thought it would have been more of a double-digit percentage jump in execution time.
I'll push what I have. I actually went further and removed the optimizations that assume a ResolverResult (not a RRPromise).
https://github.com/walmartlabs/lacinia/tree/2019113-resolve-experiment
I try to do several runs with the released version tonight, if it goes well (I did some changes) I can run the branch the next night.
To what degree do you use ResolverResultPromise (e.g., async resolvers)?
I don't use them at all. In my case the Schema is very flat, so it wouldn't really make sense. Every GraphQL query will always be only one database query.
Our scenario is much more complicated, with a mesh of data coming from Cassandra and half a dozen various external services. I'm working on a DataLoader library to help ensure that work is cached, shared across threads, and parallelized and batched where possible.