> Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?
Yes, I kind of botched it, but it's my point - GraphQL as state management can mean a lot of things. It can mean Apollo, client-side cache invalidation, use of subscriptions, etc.. I think that I found your statement of GraphQL breaking down above moderate complexity confusing because it was unclear to me what way you meant this in.
RE: apollo client, it's interesting to see that it's large, I agree that contrasted to XState or Mobx or especially Redux it is quite large, I would be happy to see that number come down, but I also am not so scared of 40KB I can serve from cache given I'm rendering "dataflow editors" of some complexity
Finally, I agree I barely use Apollo, I find its graceful property to primarily be cache management but greatly prefer mobx for true application state management because it is blazing fast / the most efficient rendering strategy
Not sure what you want to say with this because it sounds like you used Mobx for state management in that case. Or do I misunderstand you?
> I additionally think that it's a very light layer in terms of managing state
According to bundlephobia:
React + DOM = ~42KB Gzipped
@apollo/client = 39KB Gzipped
For reference redux + redux thunk is like 2KB
Xstate is less than 20KB
> what I really mean is knowing when the client-side cache needs to update
Aha, and that sounds sensible. I agree. There are lots of other things in Apollo though that you apparently aren't using.