StoreFetchMiddleware

[nevir]

StoreFetchMiddleware allows the caller to rewrite fetches from the store (for example, to redirect a read to another node)

This also includes a reference implementation to cover the case outlined by #332 (and I suspect the primary use of this middleware):

import ApolloClient, { cachedFetchById } from 'apollo-client';
const client = new ApolloClient({
  dataIdFromObject: value => value.id,
  storeFetchMiddleware: cachedFetchById,
});

await client.query({
 query: gql`
    query fetchAll {
      tasks { id, name }
    }
  `,
});

// abc123 is fetched from cache, if fetchAll returned it!
await client.query({
 query: gql`
    query fetchOne($id: ID!) {
      task(id: $id) { id, name }
    }
  `,
  variables: { id: "abc123" },
});

---

Also, FYI, Mocha is promise-aware - just return the promise from a test, and it'll take care of the rest! No need to use done

[nevir]

Alrighty, rebased & it now handles the new IdValue structure for cachedFetchById

[CharlesMangwa]

Hi guys! I'm currently working on a React Native where we use Apollo Client and StoreFetchMiddleware is exactly what we need actually 😱 !! Are you planning to work on it (maybe merge it?) anytime soon?

[LeoLeBras]

+1

[nevir]

Curious what you guys think about this PR?

[igrayson]

any update?

[nevir]

The test failure is node v4 only with:

=============================== FileSize summary ===============================
The total size of index.min.js is 139.77 kB.
The total gzipped size of index.min.js is 37.16 kB.
================================================================================
The total gzipped size of index.min.js exceeds 37 kB.

[igrayson]

Could anyone provide feedback?

[LeoLeBras]

@stubailo Can you please provide any estimations on when this pull request will be merged ?

[deoqc]

Hey @nevir @stubailo, what is the state of this pr?

I have some time and need this feature, so would like to help if I can.

[stubailo]

Hey, sorry I've been a blocker on this PR for a while. I think in order to avoid people manipulating the query AST directly, we should implement this feature after #615, which will let us switch the internal execution implementation to use https://github.com/apollostack/graphql-anywhere

This will allow the store fetch middleware to instead be replaced with custom resolvers on the client, which is much more similar to how GraphQL works on the server, rather than using AST manipulation.

We're hoping to get this refactor done in the next week or two, so perhaps we can wait until then? However if it's really urgent we can add a more hacky solution first. I'd suggest that the hacky solution should not live in the execution layer, but instead somewhere in query manager, where the query can be transformed before being passed into diffQueryAgainstStore.

[deoqc]

Waiting 2 weeks (or a bit more) is just fine for me... I was worried 'cause this is an essential feature.

[stubailo]

Yeah, I agree it's important to be able to use data from the cache, even if you are running a different query. I think it will be way easier after a refactor though, which might also come with a bonus of using any client-side data from GraphQL.

[nevir]

Yeah, local resolvers would be a much better solution

[paynecodes]

@stubailo I thought @nevir was on to something useful with this PR. I understand that the implementation of something like this will change with #615, though. Is there something else planned for covering the use cases here?

[stubailo]

Yeah, if you look at the conversation above we concluded that this feature can be implemented in a much better way after a refactor. Then, you don't have to manipulate the AST, instead you'll be able to define custom client-side resolvers.

[paynecodes]

Gotcha. I saw that. I presumed this PR would reworked accordingly. It would be better to submit an entirely new PR. Thanks!