Fork me on GitHub

in another set of good news, I did the first OR node optimization today! this optimization covers cases where sub-branches of OR nodes are sub-paths of each other (same resolver sequence, but one with extras), here are screenshots of a before/after the optimization, this is on master but not released yet

🎉 10
👏 6

the example in case is playing with the Twitter API, there are some user data that comes strait from the tweet endpoint, but the tweet endpoint has a reference for the user-id, which leads to a secondary option to fetch the user data form the user endpoint


this is what generates that OR case (get from tweet directly vs get user id from tweet then get data from the user endpoint)


note that in this case, the most common result is that the tweet endpoint will get all the data already, and the resolver to call the user endpoint will be skipped, given the data will be available already


as you can see in the ran version of the graph


but, if for some reason the tweet endpoint misses some of the user data, then the user data resolver will get called for a second chance to get the data


Wow, I think I'll be able to make good use of this optimization!