Fork me on GitHub

the docs at mention: > different fields within the same query may operate on different databases or other backend data sources this is my case, but the example only shows async resolving a single entity in the resolve-user function. what if the fields on a single entity come from different sources? not clear how a single promise could help aggregate those fields within a single resolver.


maybe this is not the right tool or maybe i structured my schema incorrectly. example object:

:stats {:fields
         {:uptime {:type String}
          :adapters {:type Int}
          :users {:type Int}
          :commands_today {:type Int}
          :commands_all_time {:type Int}}}
i want to resolve all of those fields in parallel because they're all aggregations / separate db queries. i thought Asynchronous Field Resolvers would be exactly what I needed but maybe not.


i suppose i can use my own async means of aggregating that data. just curious if lacinia supported something like that.


Yes, I think you would run your own processes asynchronously, and when all are available, you could deliver! the results. You can use the preview API to see just what will be selected.


Or, you could have a resolver for each of those fields (:uptime, :adapters, etc.) and each could return an async ResolverResultPromise. Lacinia will invoke each of your resolvers, then asynchronously process each of them as a value is deliver!-ed.


The resolver for the :stats field can provide, in its resolved value, some form of id that is used by the nested field resolvers. Alternately, it can put a value into the field resolver context using the with-context wrapper.


thanks! i'll explore these options


So I've build a fix for but then I re-read the spec and I'm still not convinced that the current behavior is incorrect. Could someone knowledgable about Apollo client please weigh in?


I just posted a PR that lets you tune the hidden channels used to implement subscriptions.


I forget who it was that suggested this option.