Research data-loaders

[valerybugakov]

Context

• Having a GraphQL for each web application page, how can we pre-load this before navigation happens?
• How can we compose/nest data dependencies for our routes/layouts?
• How can we avoid fetch-render waterfalls that slow down the application?

Review options available to us considering our current web application stack. Document possible approaches with pros and cons for each so we can discuss them on the next project sync and document our decision with alternatives review.

[philipp-spiess]

Philipp's Ideas

• We have two overarching possibilities (I'd vote for doing something with 1. to avoid the additional water falling):
  1. One is to make use of data-loaders and extract the loader function completely from the underlying React components. This is performance wise the best approach since it allows us to lazy-load the React component together with the data (for this to properly work we also need to separate the loader function into a different JavaScript file I believe). One thing to keep in mind here is that we need to make sure that the initial payload (the one that contains all the data-loaders, basically) does not end up containing every GraphQL query for every page since that could get quite large.
  2. The other option is to hoist data loading to the "page" component -> The entrypoint for a page (basically the thing that is lazy loaded). Note that this will still create water falling but it allows us to gain lazy-loading for queries automatically.

• Now for how to implement this, I also have a few ideas based on the framework:

  • With Apollo

  • The most naive version would be to manually run a query in the data loader. The issue here is that the data loader is not a hook and is run on discrete actions (e.g. on a link being clicked (or even hovered) the data loader might be run). Because of this, it can't use React hooks so for any code inside it, it would need imperative APIs. In the Apollo case, it would mean that queries are done via ApolloClient#query() instead of useQuery. This, however, comes with some concerns:

    • If we later need to change properties for the query, we'd need to duplicate a useQuery call and make sure to properly support nesting (think e.g. of the case where we have a list and want to support loading the next page)
    • Changing the query parameters may only work for simple queries. If we want to aggressively hoist data loading with Fragments and we have a query that spreads in more complex fragments (including paginated routes), I haven't found a way for us to properly reuse the fragment data to load a next page.
    • Since we're not using a hook, we don't have automatic propagation of invalidated data across the page. We will have to manually revalidate data loaders on mutations.
    • We could build our own APIs on top of Apollo

    • This obviously needs more exploration but I’m thinking of being able to do something like this:

      const QUERY = gql`query { ...}`;
      
      export function loader() {
        return {
          queryReference: preloadQuery(QUERY, {params: {id}}),
        }
      }
      
      function App() {
       const {queryReference} = useLoaderData();
        const data = usePreloadedQuery(data.QUERY, {params: {id}}, queryReference)
      }

      The idea here is to add a preloadQuery function that can do the initial query for us (using ApolloClient#query) and then have it pass some data to a new hook usePreloadedQuery that maybe even use a useSuspendedQuery but also does some book-keeping to make sure we don't start a new query if the query was already preloaded. We could do this by multiple means but one simple idea to get started is to hijack the network layer (so when we encounter a fetch() for this query, we simply return the same Promise that we created in the preloadQuery above?

      • The issues with reloading only fragments inside the query (e.g. for paginated nested resources) still remain.
      • Upside: it might be something that we can open source?
  • Explore Relay
  • Relay would solve some of the problems I've outlined above, specifically:
    • It already has a concept of preloaded queries and loadQuery.
    • Data hoisting with Fragments is different because it only passes through a query reference and not the actual query data, needing fewer re-renders when things change. Fragments can also be reloaded individually which makes it possible to handle with nested paginations.
    • However certain drawbacks exist as well:
    • Additional complexity while we're working with Apollo and Relay at the same time (including a big increase in bundle-size unfortunately. Relay is complex!)
    • Inconsistencies in data caches are updated if we are using both at the same time:
      • Maybe we don't need to rely on Relay or Apollo here much either and just defer it to React router and force a revalidate when things change? Our app isn't that complex so it might be feasible.
    • We still have manual fetchQuery code in our database from before Apollo. How will we ever complete this migration?
  • Create our own light-weight backend?
    • My idea is to go back to before Apollo times. Which comes at the expense of a proper cache (but we'd get the cache from setting up react-router data-loaders correctly). This way everything is in our control but it's likely we spent a lot of time maintaining this approach.

[philipp-spiess]

We ended up implementing a prototype that uses Apollo: https://sourcegraph.slack.com/archives/C04KDBTLG5P/p1673966112312489