@brycecovert by "bad trade" I meant "bad tradeoff" . Collocating queries with views is nice, but the tradeoff is that the views become imperative.

I have a data structure that looks like that that I’m going to use subs to pull the values out of. Would people recommend a sub for each value? Or a sub for each group (return a map), and then destructure the values in view code?

@caleb.macdonaldblack I have similar data structures in my app and I’m using https://github.com/vimsical/subgraph to convert JSON data from server API into entities, and to pull them out of app-db. I like the fact that subgraph stores the entities fully normalized and builds the object graphs upon retrieval.

Are there any examples of re-frame and graphql? Looking specifically for how to keep graphql client state/caching in re-frame store or at least if separate somehow subscribe to events

I know there's this: https://github.com/oliyh/re-graph but I haven't used it myself

We're using graphql on the backend but making requests using http-fx and storing the results in the reframe db

I used re-graph, it works great, including subscriptions.