#graphql on the mind
-
-
This Tweet is unavailable.
-
This Tweet is unavailable.
-
Replying to @methylene_
Really new to it but it looks really promising sofar! Im trying out
@apollographql and its great but it challenges alot of my current understanding of how to do things.. like having a#reactjs comp fetch its own data, when before this belonged in a container or store.2 replies 0 retweets 1 like -
Replying to @kviglucci @apollographql
Also recommendations for avoiding bulk fetching of remote data in resolvers, and performing data transformation on the server (sorting & filtering) vs on the client, goes against notions ive already established that are conflicting.
1 reply 0 retweets 1 like -
Replying to @kviglucci @apollographql
I don’t think “avoiding” is the right word here — I mean, for individual resolvers for uninformed non-array fields, yes. But the whole reason DataLoader was created was to solve this problem. If you have an API that supports bulk fetching, you should probably be using it.
1 reply 0 retweets 0 likes -
Replying to @andreduvoisin @apollographql
I swear the docs specifically callout that they recommend individual lookups vs batch fetch, as the individual looks have a better caching profile. I'll have to find the reference in the docs.
1 reply 0 retweets 1 like
Of course. We specifically focus on that in our GQL app (but we also aren’t interfacing with any APIs that support batch, while we have many situations where we‘d use it). It comes down to your use case and the cacheability of your data, as DataLoader wouldn’t exist otherwise.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.